closed-remediation-reviewlisted

# 封闭式整改验收 一句话：**子线程只检，主线程逐条裁；验收范围只来自原评审与用户裁决，不再开放找新问题。** ## 0. 与开放式对抗评审的边界 | 环节 | 目的 | 模型 | |---|---|---| | 开放式对抗评审 | 找未知漏洞、暴露不同视角 | Opus 5 + GPT-5.6-Sol；主线程直接裁决 | | 封闭式整改验收 | 核对已知整改是否正确关闭 | 当前工具一个原生子线程 + 主线程裁决 | 本 skill 不是第二轮对抗评审。满足下列前提才运行： 1. 同一评审对象、同一真值基线下的开放式对抗评审已经且只运行过一次。 2. 原报告的每条意见有稳定 `AR-x`、处置结论和整改要求。 3. 需要用户拍板的项目已写入 `_shared/用户裁决记录.md`，每条有稳定 `DEC-x` 与原始证据。 4. 整改前对象、整改后对象、允许改动范围均可定位。 任一前提缺失，不得靠本 skill 补做设计；退回原评审收口或用户裁决记录补全。 ## 1. 固定验收清单 运行前由主线程冻结以下输入，并计算或记录 `closure_scope_hash`： - `review_id`、评审对象路径、整改前/后对象哈希。 - 原对抗评审报告全文及全部 `AR-x` 裁决。 - 全部 `DEC-x` 用户裁决记录：用户原话或明确选项、日期、来源位置、适用范围。 - 上游正式真值与“已决策·不得重开”清单。 - 本轮允许修改的对象与语义范围。 - 整改前后 diff。 验收清单只包括： 1. 原报告 `✅ 桶1采纳` 项是否完整落实。 2. `DEC-x` 是否按原义物化，无遗漏、改写或捆绑替换。 3. 原报告明确要求进入自愈清单的项目是否正确归位。 4. 整改 diff 是否包含清单之外的业务语义变化。 5. 评审报告、正式规格、测试用例之间的追溯是否因整改断裂。 **清单冻结后不得扩张。** 验收中看到其他设计问题，不记录为新意见、不顺手修改；它不属于本次封闭验收。 ## 2. 子线程只读检查（Claude Code 适配） 只调用一个 Claude Code 原生子线程： ```text 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