冻结一条结论，理由不是「我确定它对」，而是「我不确定它对，而且我知道我会怎么改错它」。冻结不是信心的表达，是谦逊的表达。
replay_check.js + baseline_snapshot.json，零消耗）。新会话上手第 2 步：先去代码里复核现状，「不要相信本文件，只相信代码」。
代码 + 实测产物 > 本文档 > 根 README.md / CODEBUDDY.md / autobot/README.md / 方案全解析。后三份已明显漂移，勿当事实。rejected 并写明原因。一个允许自己被推翻的文档，比一个永远正确的文档有用得多。
| v1（已作废） | v2（现行） | |
|---|---|---|
| 值 | 30 | 30（未变） |
| 依据 | 171 句零分句仅 0.6%；候选段均 60.1 字；容量比 ≈0.18~0.3，与 0.289 吻合 | 调它只改分母不改每句包含度；真正该做的是源头压短；真实副作用（丢弃 61.5%）此前无人知晓 |
| 状态 | frozen | unfrozen（C-001） |
解冻理由：覆盖率是连续值，「零分句少」推不出「不存在尾部整段归零」。实测未播出组 0.134、得分 ≥0.6 占比 0.0%，两场一致。
必须做的一件事：config.js 那段结案注释（"瓶颈在平台侧每段只保留约 60 字"）必须重写——留着它，下一个会话还会照它调参。
后来真发生了：该注释被人照旧方向又写回一次 → 台账单列 C-008，附言"看到又变回 60 字是瓶颈，说明有人照旧方向改了，改回来"。
一个错误的理由留在代码里，杀伤力比一个错误的数值大得多——数值还能被测量否定，理由会自我繁殖。
正确动作：在台账加一行（双方 R-ID + 现象 + 候选方案），状态待定，等人类拍板；裁决后才动正文。优先级：冲突台账优先于正文。
台账从 C-001 记到 C-011。§1.2.1 裁决表是权威——不要再信 §1.2 各条末尾的旧字样。
C-011 的例子：提议"赶紧 git init" → 反方指出首次提交会吞掉多轮历史改动、审计价值归零（而这正是建仓的立项理由）→ 裁决：先补历史改动清单，再建仓。
ANSWER_MAX_SEC 不动。answer_start 会整体晚 0.3–0.4s——"这是预期行为，不要误判为回归"。| 冻结项 | 内容 | 依据 |
|---|---|---|
| R-FREEZE-004（P0） | 不改平台 / 不做反检测 / 摄像头真人真画面 | VIRTUAL_CAM_RE=null + 边界声明 |
| R-FREEZE-002（P0） | BRIDGE_PAUSE_IV=false | 实测 job17：关闭 100% vs 开启 15%~62% |
| R-FREEZE-003（P1） | BRIDGE_TTS_ALLOW_SAPI_FALLBACK=false | 机械音更易被平台误听；失败走记账不播报 |
R-FREEZE-004 现状诚实写着：代码守住了边界，但运行环境实际是纯色占位帧（已知偏差，必须在产物中标注）。
§2 修订协议：允许改 状态/证据行号/现状/期望行为/验收方式/影响/工作量/依赖/禁止；不允许改 ID / 优先级 / 条目顺序；新增在所属 AREA 末尾追加（编号 +1）并在 §4 加一行；每条实质改动 → §5 追加一行。
工程教训：文档必须 UTF-8 无 BOM——PowerShell 5.1 不加 -Encoding UTF8 会把中文读成乱码，所有含中文的匹配返回 0（首版即踩坑）。改完自检：5 个数字必须全部相等。
autobot/docs/REQUIREMENTS-DEV.md §0 新会话 30 秒上手 + v2 / v3 / v4 / v4.1 必读；§1.1 状态机与冲突的强制规则（4 条）；§1.2.1 裁决表（v4）；§3.8 FREEZE（R-FREEZE-001 解冻重写 / 002 / 003 / 004）；§2 修订协议与自检命令。