octopus-workflow/examples/wip-cap-and-td-hygiene.md

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 是该组织的经验值），重要的是有上限且 超限行为被定义。