Initial publish v0.1.0: standalone workflow core (corpus + examples + guards)

2026-09-15 08:41:51 +08:00
commit bb35e661b2
114 changed files with 20240 additions and 0 deletions
@@ -0,0 +1,37 @@
+# WIP 上限与 TD 登记卫生
+
+> 组织沉积教学案例；机制已入 Core，本文仅叙事。所涉机制见
+> `core/rules/ticket-lifecycle.md`（登记册与升票）。
+
+## 背景
+
+某组织在并行会话规模化后观察到：在制品（WIP）无上限时，并行分支数
+随会话数线性增长，合并队列深度失控，单张 PR 的"可合并窗口"被拉长到
+数天——期间的 rebase/重跑 CI 成本吞噬了并行带来的吞吐增益。组织最终
+把 WIP 上限稳定在 40。
+
+## WIP cap 的作用面
+
+- **合并出口串行**：PR 按容量串行开一张、双绿并入再开下一张，
+  避免合并波互相踩踏。
+- **会话-工单一对一**：一张工单同一时刻只有一个归属会话（claim
+  纪律），WIP 上限实际上是"在飞工单数"上限。
+- **超限的反应是停新开、不清在飞**：清场式批量关闭被证明是反模式
+  （见 `examples/sprint-mode-throughput.md`）。
+
+## TD 登记卫生（同一场治理的另一面）
+
+- **登记行零丢失**：任何验证阶段发现的债务候选都落登记行——
+  不开票、不丢弃。
+- **TD 编号经台账分配**：并发会话从分配台账取连续号段，手工
+  "max+1"被禁止——并行竞争曾产生重号。
+- **未升票行 30 天未动 → 自动回收候选**：登记不是永久停车位。
+- **[COLD] 标记**：连续数个周期无人认领的行可标记冷存，不占模块
+  配额，一次认领即复活。
+
+## 教训
+
+- 吞吐治理 = WIP 上限（控入口）+ 登记卫生（控台账）两者缺一不可：
+  只控入口，发现会丢失；只控台账，队列会堆积。
+- 上限值本身不重要（40 是该组织的经验值），重要的是**有上限且
+  超限行为被定义**。