BackToCimaCoppi 封闭式整改验收
一句话：子线程只检，主线程逐条裁；验收范围只来自原评审与可审计授权裁决，不再开放找新问题。
0. 与开放式对抗评审的边界
| 环节 | 目的 | 模型 |
|---|---|---|
| 开放式对抗评审 | 找未知漏洞、暴露不同视角 | 默认 Fable 5 + GPT-5.6-Sol，可点选加入 Cursor Grok/GLM/Kimi；主线程直接裁决 |
| 封闭式整改验收 | 核对已知整改是否正确关闭 | 当前工具一个原生子线程 + 主线程裁决 |
本 skill 不是第二轮对抗评审。满足下列前提才运行：
- 同一评审对象、同一真值基线下的开放式对抗评审已经且只运行过一次。
- 原报告的每条意见有稳定
AR-x、处置结论和整改要求。 - 需要业务决策负责人批准的项目已写入
_shared/用户裁决记录.md，每条有稳定DEC-x、实际授权角色与原始证据。 - 整改前对象、整改后对象、允许改动范围均可定位。
任一前提缺失，不得靠本 skill 补做设计；退回原评审收口或授权裁决记录补全。
1. 固定验收清单
运行前由主线程冻结以下输入，并计算或记录 closure_scope_hash：
review_id、评审对象路径、整改前/后对象哈希。- 原对抗评审报告全文及全部
AR-x裁决。 - 全部
DEC-x授权裁决记录：授权角色原话或明确选项、实际角色、日期、来源位置、适用范围。 - 上游正式真值与“已决策·不得重开”清单。
- 本轮允许修改的对象与语义范围。
- 整改前后 diff。
验收清单只包括：
- 原报告
✅ 桶1采纳项是否完整落实。 DEC-x是否按原义物化，无遗漏、改写或捆绑替换。- 原报告明确要求进入自愈清单的项目是否正确归位。
- 整改 diff 是否包含清单之外的业务语义变化。
- 评审报告、正式规格、测试用例之间的追溯是否因整改断裂。
清单冻结后不得扩张。 验收中看到其他设计问题，不记录为新意见、不顺手修改；它不属于本次封闭验收。
2. 子线程只读检查（Claude Code 适配）
只调用一个 Claude Code 原生子线程：
Agent(
description: "封闭式整改验收·只读检查",
model: "opus",
prompt: <本节证据包与检查提示>
)
要求：
- 使用全新上下文；只提供冻结证据包，不灌入主线程解释或预设结论。
- 只读文件，不写被验收对象、不修改报告。
- 不调用 codex，不做多模型评审，不再起子线程。
- 逐字比较原意见、授权裁决、整改 diff 与正式落点。
- 不评价原设计“选得好不好”，只判断有没有忠实落实。
子线程只能输出以下状态：
| 状态 | 含义 |
|---|---|
PASS |
对应清单项已正确关闭 |
FAIL-MISSING |
原采纳项或裁决有遗漏 |
FAIL-WRONG |
已回补，但改变了原意或落错层 |
FAIL-OUT-OF-SCOPE |
出现清单外的业务语义变化 |
FAIL-PROVENANCE |
“已批准”等结论缺少可审计 DEC-x 或实际授权角色 |
输出表每行必须包含：CR-x / 关联 AR-x 或 DEC-x / 状态 / 对象位置 / 事实证据 / 是否疑似改变业务语义。禁止给新方案或优化建议。
3. 主线程逐条裁决
子线程意见不是自动修改指令。主线程对每条 CR-x 三选一：
| 裁决 | 使用条件 | 动作 |
|---|---|---|
❌ 驳回 |
误报、越出固定清单、与明确证据不符 | 不改；写明正式规格或 DEC-x 证据 |
✅ 采纳 |
确定性遗漏、误写、落点错误，且唯一修法不产生新业务选择 | 主线程修正；记录改动后重跑同一清单 |
🚨 停机 |
证据缺失/矛盾，或修复必须新增业务结果、改变死亡线规则、对外契约、持久化语义或实施不可逆处置 | 合并成一张裁决表，请用户一次性拍板 |
主线程可以判断“是否违背既有语义”，但不能替用户选择“新语义是什么”。
特别规则：
- 发现语义变化不等于自动打扰用户。若
DEC-x或正式规格给出唯一答案，主线程直接恢复原义。 - 驳回必须留下“子线程意见 / 不成立原因 / 依据 / 是否改变业务结果”，不得凭直觉否决。
- 主线程不得折中创造第三种方案，不得把子线程建议升级为正式真值。
- 死亡线业务规则没有有效
DEC-x与实际授权角色时必须停机，不能写“已批准”。
4. 复验与终态
整改失败后允许复验，但必须满足：
closure_scope_hash不变；- 检查项集合不变，只允许失败集合缩小；
- 不得借复验发起 R2/R3 开放式对抗评审；
- 新出现的清单外意见一律按越界驳回，不进入整改。
终态只有三种：
| 终态 | 条件 |
|---|---|
PASS |
全部固定项关闭，主线程裁决完成，无未决语义 |
FAIL |
仍有确定性整改未完成，可继续修正同一清单 |
STOP |
需要用户作新的业务/契约/数据语义裁决 |
PASS 前不得把被评审产物交给下游冻结或 Goal。
5. 留痕格式
不新建第二份评审真值。主线程把以下内容追加到原 T{n}-对抗评审报告.md：
## 封闭式整改验收
- closure_scope_hash：
- 检查模型：Opus 5（Claude Code 原生子线程）
- 整改前/后对象哈希：
| CR | 关联 AR/DEC | 子线程意见 | 主线程裁决 | 依据 | 修正 |
|---|---|---|---|---|---|
- 最终状态：PASS / FAIL / STOP
报告是过程证据，不取得正式 L1–L7 的规格地位。
6. 判失败
- 子线程收到主线程预期答案，而不是冻结证据包。
- 子线程或主线程新增原清单外的设计意见。
- 主线程未逐条裁决，直接照单全改。
- 把“疑似语义变化”一律升级用户，没有先查既有唯一答案。
- 驳回意见没有证据。
- 复验时改变固定清单或重新运行多模型对抗评审。
PASS时仍存在未落实AR-x、无来源DEC-x或清单外业务语义变化。