closed-remediation-reviewlisted

# 封闭式整改验收 一句话：**子线程只检，主线程逐条裁；验收范围只来自原评审与可审计授权裁决，不再开放找新问题。** ## 0. 与开放式对抗评审的边界 | 环节 | 目的 | 模型 | |---|---|---| | 开放式对抗评审 | 找未知漏洞、暴露不同视角 | 触发时由用户从本机可用 Claude Code、Cursor Agent、Codex 模型中选择至少一个；主线程直接裁决 | | 封闭式整改验收 | 核对已知整改是否正确关闭 | 当前工具一个原生子线程 + 主线程裁决 | 本 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. 单模型只读检查 使用当前运行环境的一名全新上下文检查者；若当前环境没有隔离上下文能力，可从对抗评审中已选且仍可用的桥接调用**一个**只读模型。模型与桥接记录实际值；不重新开放模型竞赛或设计评审。调用方式遵循 `adversarial-review` 的只读边界。 要求： - 使用全新上下文；只提供冻结证据包，不灌入主线程解释或预设结论。 - 只读文件，不写被验收对象、不修改报告。 - 不做多模型评审，不再派生检查者。 - 逐字比较原意见、授权裁决、整改 diff 与正式落点。 - 不评价原设计“选得好不好”，只判断有没有忠实落实。 子线程只能输出以下状态： | 状态 | 含义 | |---|---| | `PASS` | 对应清单项已正确关闭 | | `FAIL-MISSING` | 原采纳项或裁决有遗漏 | | `FAIL-WRONG` | 已回补，但改变了原意或落错层 | | `FAIL-OUT-OF-SCOPE` | 出现清单外的业务语义变化 | | `FAIL-PROVENANCE` | “已批准”等结论缺少可审计 `DEC-x` 或实际授权角色 | 输出表每行必须包含：`CR-x / 关联 AR-x 或 DEC-x / 状态 / 对象位置 / 事实证据 / 是否疑似改变业务语义`。禁止给新方案或优化建议。