# 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 行不受自动回收触碰。

## 教训

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