目标
稳定期一旦把“大家都修累了”当成出口，就会无限漂移。冻结前公布出关标准、每日分诊、阻塞缺陷燃尽，把这段时间变成有测量轨迹、有明确终点的过程——出关引用的是标准达成状态，而不是任何人的耐力。
步骤要点
- 宣布冻结日同时公布出关标准：开放阻塞缺陷为零、超过 48 小时的严重缺陷为零，且该状态保持一整天。
- 切换每日分诊：十五分钟过一遍所有新旧 issue，逐一归类为阻塞、严重、延后或非阻塞，并指定负责人。
- 按优先级投入产能：先阻塞后严重，延后项记录进下周期而不是悄悄消失。
- 每个修复必须在当前 RC 产物上验证，开发者本地构建的验证不算数，关闭的 issue 引用确认版本。
- 按标准出关：标准保持整天成立即发布，确需带病发布时以书面豁免降级阻塞项并署名。
排错提示
燃尽曲线先降后升是又合入了坏修复，冻结期修复本身要走最小 diff 原则并重点回归；同一严重缺陷三天没人碰说明分诊只扫新增，把存量也纳入每日清单；豁免越来越多是标准定得脱离实际，修标准而不是纵容豁免，书面豁免永远好于沉默降级。
适用边界
每日分诊对团队有固定时间成本，周期过短的发布应改用持续交付而非反复冻结；出关标准只能约束已知缺陷，探索性测试与灰度观察仍是发布后防线。
代码示例
exit criteria (published day 1):
open blockers = 0
open criticals > 48h = 0
held for one full day
day blockers criticals deferred
1 9 14 0
4 5 8 11
8 2 3 17
11 0 1 19 <- one 30h-old critical
12 0 0 19 <- EXIT (criteria held)