Closed Remediation Review

---
name: closed-remediation-review
description: 封闭式整改验收 skill。用于一次开放式对抗评审完成并回补后，核验原采纳项与授权裁决是否被完整、无误、无越界地落实。只调用当前运行环境一个全新上下文的只读检查者，再由主线程逐条裁决；禁止发现新设计问题、禁止重开已决策、禁止再次运行多模型对抗评审。触发：评审整改验收、评审回补检查、关闭对抗评审、确认整改没有改变设计语义。
---

# 封闭式整改验收

一句话：**子线程只检，主线程逐条裁；验收范围只来自原评审与可审计授权裁决，不再开放找新问题。**

## 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 / 状态 / 对象位置 / 事实证据 / 是否疑似改变业务语义`。禁止给新方案或优化建议。

## 3. 主线程逐条裁决

检查者意见不是自动修改指令。主线程对每条 `CR-x` 三选一：

| 裁决 | 使用条件 | 动作 |
|---|---|---|
| `❌ 驳回` | 误报、越出固定清单、与明确证据不符 | 不改；写明正式规格或 `DEC-x` 证据 |
| `✅ 采纳` | 确定性遗漏、误写、落点错误，且唯一修法不产生新业务选择 | 主线程修正；记录改动后重跑同一清单 |
| `🚨 停机` | 证据缺失/矛盾，或修复必须新增业务结果、改变死亡线规则、对外契约、持久化语义或实施不可逆处置 | 合并成一张裁决表，请用户一次性拍板 |

主线程可以判断“是否违背既有语义”，但不能替用户选择“新语义是什么”。

特别规则：

- 发现语义变化不等于自动打扰用户。若 `DEC-x` 或正式规格给出唯一答案，主线程直接恢复原义。
- 驳回必须留下“检查者意见 / 不成立原因 / 依据 / 是否改变业务结果”，不得凭直觉否决。
- 主线程不得折中创造第三种方案，不得把子线程建议升级为正式真值。
- 死亡线业务规则没有有效 `DEC-x` 与实际授权角色时必须停机，不能写“已批准”。

## 4. 复验与终态

整改失败后允许复验，但必须满足：

- `closure_scope_hash` 不变；
- 检查项集合不变，只允许失败集合缩小；
- 不得借复验发起 R2/R3 开放式对抗评审；
- 新出现的清单外意见一律按越界驳回，不进入整改。

终态只有三种：

| 终态 | 条件 |
|---|---|
| `PASS` | 全部固定项关闭，主线程裁决完成，无未决语义 |
| `FAIL` | 仍有确定性整改未完成，可继续修正同一清单 |
| `STOP` | 需要用户作新的业务/契约/数据语义裁决 |

`PASS` 前不得把被评审产物交给下游冻结或 Goal。

## 5. 留痕格式

不新建第二份评审真值。主线程把以下内容追加到原 `T{n}-对抗评审报告.md`：

```markdown
## 封闭式整改验收
- closure_scope_hash：
- 检查模型与桥接：<实际值>
- 整改前/后对象哈希：

| CR | 关联 AR/DEC | 检查者意见 | 主线程裁决 | 依据 | 修正 |
|---|---|---|---|---|---|

- 最终状态：PASS / FAIL / STOP
```

报告是过程证据，不取得正式 L1–L7 的规格地位。

## 6. 判失败

- 子线程收到主线程预期答案，而不是冻结证据包。
- 检查者或主线程新增原清单外的设计意见。
- 主线程未逐条裁决，直接照单全改。
- 把“疑似语义变化”一律升级用户，没有先查既有唯一答案。
- 驳回意见没有证据。
- 复验时改变固定清单或重新运行多模型对抗评审。
- `PASS` 时仍存在未落实 `AR-x`、无来源 `DEC-x` 或清单外业务语义变化。