octopus-workflow/examples/sprint-mode-throughput.md

Sprint 模式与吞吐事故：125 张 TD 碎片的教训

组织沉积教学案例；机制已入 Core，本文仅叙事。所涉机制见 core/rules/workflow-routing.md（filing.sprint-mode 开关）与 core/rules/ticket-lifecycle.md（registry-first 登记）。

背景

某组织在 2026-08 冲刺期发现：技术债务工单（TD）队列在数周内膨胀到 125 张碎片工单，日均新建约 9.4 张，而 8 月之前的关闭数为零。冲刺结束 时只能靠一次 115 张的批量清理来"清场"——清理本身又消耗了本该用于交付 的评审与验证容量，当周交付产能接近清零。

事故链

1. 逐票立案的默认：每个验证阶段发现的债务候选都独立开票—— 一次全量测试巡检就能产出十余张"发现票"。
2. 冲刺压力下无人认领：冲刺目标压在交付票上，TD 票无人认领、 无人在意，队列只进不出。
3. 批量清场反噬产能：清场动作本身走完整管线（评审、验证、归并）， 一次性吃掉数天产能。

机制沉淀（已入 Core）

• registry-first（TD 登记册）：发现先落登记行（Tier-1 形态的廉价 台账行），被排期或认领时才升票为独立工单——见 core/rules/ticket-lifecycle.md §登记册。
• sprint-mode 显式降档：冲刺期由负责人翻转 filing.sprint-mode 开关，登记行照写（零丢失），独立工单创建冻结 至开关回落后按正常认领升票——见 core/rules/workflow-routing.md §立案降档。HIGH/MEDIUM 行不受自动回收触碰。

教训

• 队列的吞吐健康比单票的完整流转更重要：登记行的"零丢失 + 延迟升票" 优于"即时立案 + 无限堆积"。
• 降档必须是显式开关 + 显式负责人，不能靠"冲刺期间大家少开点票" 的纪律约定——纪律约定在压力下必然失效。