@ranger1/dx 0.1.105 → 0.1.106

package/skills/pr-train-ship/SKILL.md

@@ -7,7 +7,7 @@ description: 仅在用户显式调用 $pr-train-ship 或明确要求使用 pr-tr
 
 ## Overview
 
-接收一个**已存在的 PR 编号**，跑 **双源审查（≤3 轮）→ 双 comment → 修复循环 → 验证总结 → `gh pr merge --squash --auto` → 等真 merge 到 main**。Train 模式下严格串行：本 PR 真合并后才允许调用方启动下一 PR。
+接收一个**已存在的 PR 编号**，跑 **两波并行审查（Wave 1 验证+验收 → Wave 2 三源代码审查：审查者 A 架构 + 审查者 B 逻辑 + 审查者 C 系统 `/code-review`，≤3 轮）→ 审查质量自检 → 三 comment（验收/审查/修复）→ 修复循环 → 验证总结 → `gh pr merge --squash --auto` → 独立 subagent 等真 merge 到 main**。Train 模式下严格串行：本 PR 真合并后才允许调用方启动下一 PR。
 
 **不负责** commit / push / 创建 PR — 这些由 `feature-decide-plan-execute` 完成后把 PR 编号交给本 skill。
 
@@ -116,15 +116,22 @@ git merge --no-commit --no-ff origin/main
 
 循环变量：`ROUND=1`，`MAX_ROUNDS=3`，`CODE_CHANGED_SINCE_LAST_CHECK=true`
 
-### 3.1 验证流水线 + 代码审查 + Issue 验收（并行启动 4 个 subagent）
+### 3.1 验证流水线 + Issue 验收 + 代码审查（两波并行，共 4 个 subagent）
 
 仅在 `CODE_CHANGED_SINCE_LAST_CHECK=true` 时跑验证流水线（主线 A）。主线 B/C 每轮都跑。
 
-**审查方式对齐 `git-pr-ship` 阶段四 4.1**：3 个 subagent 分别做 3 件事（验证 / 架构审查 / 逻辑审查），**额外**再派 1 个 subagent 做 Issue 验收检查（PR 是否真的实现了关联 Issue 的功能）。共计 **4 个 subagent 并行**。
+**核心改进**：subagent 不再"一次并行"，拆成 **两波**，避免主 agent 同时融合多份风格迥异的报告导致代码审查深度被稀释：
 
-> **关键约束**：所有 subagent（主线 A 验证 / 审查者 A / 审查者 B / 主线 C Issue 验收）**只向主 agent 返回结果文本，禁止自行调用 `gh pr comment` 或任何方式直接发布 PR 评论**。只有主 agent 在 3.3 / 3.5 / 3.7 发布唯一汇总报告。违反 → PR 上会出现多条重复审核报告。
+- **Wave 1（并行 2 个，事实层扫描）**：主线 A 验证流水线 + 主线 C Issue 验收。两者负责"流水线是否过关 / 功能是否到位"的事实层结论。
+- **Wave 2（并行 3 个，深度审查）**：审查者 A 架构 + 审查者 B 逻辑 + 审查者 C 系统 `/code-review`。**必须把 Wave 1 的 Issue 验收结论作为 prompt 输入**，并反向约束："功能缺失主线 C 已覆盖，你只挑 diff 内的代码 bug，不要重复列功能缺失"。
 
-**主线 A：验证流水线（subagent 串行有错即停）**
+> **审查者 C = 系统 `/code-review` 第三路**：在裸 subagent 内调用系统 `/code-review`（**禁带 `--comment` / `--fix`**），让它只读地扫 diff、返回 findings 文本给主 agent。系统 `/code-review` 裸跑本身就是只读不发评论不改码，与「主 agent 唯一发布者」架构兼容——它的 findings 与审查者 A/B 一样并入 3.2 汇总，由主 agent 在 3.3b 统一发布。**绝不允许 `--comment`（会绕过单发布者产生重复评论）或 `--fix`（会越权改业务代码，违反 Hard Gate 7）。**
+
+Wave 1 失败不阻塞 Wave 2 启动；但 Wave 2 的 prompt 必须带 Wave 1 验收结论。
+
+> **关键约束**：所有 subagent（主线 A 验证 / 主线 C Issue 验收 / 审查者 A / 审查者 B）**只向主 agent 返回结果文本，禁止自行调用 `gh pr comment` 或任何方式直接发布 PR 评论**。只有主 agent 在 3.3a / 3.3b / 3.5 / 3.7 发布唯一汇总报告。违反 → PR 上会出现多条重复审核报告。
+
+**Wave 1 — 主线 A：验证流水线（subagent 串行有错即停）**
 
 派独立 subagent（后台运行）。不要在主 agent 直接跑——主 agent 易被打断。
 
@@ -135,14 +142,22 @@ Subagent prompt：
 
 【重要】只负责执行验证并返回结果文本。禁止调用 gh pr comment 或以任何方式直接发评论。
 
-【重要】返回的失败错误必须完整原样输出（含文件:行号 / 报错栈），不要做"是否本 PR 引入"的判断——主 agent 会统一处理，所有 lint/build/test 错误（含历史遗留）都要修。
+【重要】返回的失败错误必须完整原样输出（含文件:行号 / 报错栈）。
+针对每个失败，额外用 git blame 或 git log -L 判定该行最近一次修改是否在本 PR 提交范围内：
+- 取 PR base sha：BASE=$(gh pr view <PR_NUMBER> --json baseRefOid --jq .baseRefOid)
+- 取 PR head sha：HEAD=$(gh pr view <PR_NUMBER> --json headRefOid --jq .headRefOid)
+- 对失败行运行 `git log $BASE..$HEAD --oneline -- <file>` 看是否有 commit；或 `git blame -L <line>,<line> <file>` 看作者 commit 是否在 $BASE..$HEAD 范围内
+分类输出：
+  [本 PR 引入]  <file>:<line> <错误>
+  [历史遗留]    <file>:<line> <错误>
+所有错误都要返回——分类是给主 agent 决定 commit 拆分用，不是允许跳过的依据（Hard Gate 10）。
 
 Step 1: dx lint
-- 失败：记录所有错误，停止
+- 失败：记录所有错误（按上面分类），停止
 - 通过：继续
 
 Step 2: dx build affected --dev
-- 失败：记录错误，停止
+- 失败：记录错误（按上面分类），停止
 - 通过：继续
 
 Step 3: 运行关联测试（按改动范围判断）
@@ -155,41 +170,99 @@ Step 3: 运行关联测试（按改动范围判断）
 - 执行到第几步
 - 每步通过/失败
 - 失败步骤完整错误输出
+- 每条错误的 [本 PR 引入] / [历史遗留] 分类标签
 ```
 
 完成后设 `CODE_CHANGED_SINCE_LAST_CHECK=false`。
 
-**主线 B：代码审查**
+**历史遗留错误的 commit 隔离规则**（避免污染下一轮代码审查的 diff）：
+
+- "本 PR 引入"失败 → 走 3.4 常规修复 commit（`fix:` 前缀，挂本 Issue）
+- "历史遗留"失败 → **单独 commit**，前缀 `chore(precheck):`，commit body 写明"非本 PR diff 引入，按 Hard Gate 10 顺手修"；如确实修不动 → 不 commit，直接进入 Hard Gate 10 后半段（PR body + 审核报告双处登记 follow-up Issue 编号）
+- 下一轮的代码审查 prompt 必须明确告知"本轮 commit 含历史遗留修复（commit hash: xxx），审查者请聚焦本 PR 业务 diff，不要在这些文件里做 nitpick"
 
-**第一轮：双源审查（必须）**
+**Wave 2 — 主线 B：代码审查**（必须在 Wave 1 主线 C 输出可用后再启动，A/B prompt 中嵌入主线 C 验收结论）
 
-派两个独立 subagent：
+**第一轮：三源审查（必须）**
+
+派三个独立 subagent（审查者 A 架构 + 审查者 B 逻辑 + 审查者 C 系统 `/code-review`）。**三个 prompt 都必须先嵌入主线 C 输出，再说明任务**：
 
 **审查者 A** — 架构与代码质量：
 
 ```
-作为资深架构师审查 PR #<PR_NUMBER> 的 diff，关注架构合理性、SOLID、错误处理、性能、安全。
-审查 diff 涉及的文件时如顺便发现同一文件内的历史遗留问题，也一并报告（不主动扩大到 diff 之外）。
+【背景：主线 C Issue 验收结论已就位】
+<这里粘贴主线 C 完整报告：验收标准条目数、✅/⚠️/❌ 表格、结论>
+
+你是资深架构师，审查 PR #<PR_NUMBER> 的 diff。
+
+【关注点】架构合理性、SOLID、错误处理、性能、安全、并发安全、资源泄漏、跨模块耦合。
+【反向约束】Issue 验收已由主线 C 覆盖——你不要在报告里重复列「功能未实现 / 部分实现」，专注 diff 内代码层 bug。门禁 / 流程合规问题也不在你的范围内。
+【范围】审查 diff 涉及的文件时如顺便发现同一文件内的历史遗留代码 bug 也报告（不主动扩大到 diff 之外）。本轮若 commit 含 `chore(precheck):` 历史遗留修复 commit，列入审查范围的代码 diff 排除这些 commit 的改动。
+
+【输出格式】每条问题必须给出：
+- 严重级（Critical / Major / Minor）
+- 文件:行号
+- 问题描述（≥1 句具体说明，禁止"建议优化"这类含糊表述）
+- 建议改法（具体到代码层面，不写"考虑使用 X 模式"这种空话）
+缺任一字段视为该条无效。
 
 【重要】只返回审查结果文本。禁止调用 gh pr comment 或任何方式发评论——主 agent 统一发布。
 
 获取 diff：gh pr diff <PR_NUMBER>
+本 PR 历史遗留修复 commit 列表（若有）：<commit hash 列表，由主 agent 填入>
 ```
 
 **审查者 B** — 逻辑缺陷与规范：
 
 ```
-作为质量工程师审查 PR #<PR_NUMBER> 的 diff，关注逻辑缺陷、边界条件、命名规范、类型安全、测试覆盖。
-审查 diff 涉及的文件时如顺便发现同一文件内的历史遗留问题，也一并报告（不主动扩大）。
+【背景：主线 C Issue 验收结论已就位】
+<这里粘贴主线 C 完整报告>
+
+你是质量工程师，审查 PR #<PR_NUMBER> 的 diff。
+
+【关注点】逻辑缺陷、边界条件、空值 / 异常路径、命名规范、类型安全、测试覆盖、回归风险。
+【反向约束】Issue 验收已由主线 C 覆盖——你不要重复列「功能未实现」，专注 diff 内代码层 bug 与规范偏离。
+【范围】审查 diff 涉及的文件时如顺便发现同一文件内的历史遗留代码 bug 也报告（不主动扩大）。本轮历史遗留修复 commit 的改动从审查范围排除。
+
+【输出格式】同审查者 A：严重级 + 文件:行号 + 问题描述 ≥1 句 + 具体改法。缺一视为无效。
 
 【重要】只返回审查结果文本。禁止调用 gh pr comment 或任何方式发评论——主 agent 统一发布。
 
 获取 diff：gh pr diff <PR_NUMBER>
+本 PR 历史遗留修复 commit 列表（若有）：<commit hash 列表，由主 agent 填入>
+```
+
+**审查者 C** — 系统 `/code-review` 第三路（裸 subagent 内调用，只读返回 findings）：
+
 ```
+【背景：主线 C Issue 验收结论已就位】
+<这里粘贴主线 C 完整报告>
+
+你是第三路代码审查者，对 PR #<PR_NUMBER> 的 diff 跑系统内置 /code-review。
+
+【调用方式】调用系统 skill：/code-review --effort medium
+- 严禁带 --comment（会直接发 PR 评论，绕过主 agent 单发布者，产生重复审核报告）
+- 严禁带 --fix（会改工作区业务代码，违反本 skill 零业务改动约束）
+- 只跑只读审查，把 /code-review 输出的 findings 原样整理成下方格式返回主 agent
+
+【反向约束】Issue 验收已由主线 C 覆盖——findings 里若有"功能未实现"类条目请剔除，只保留 diff 内代码层 bug / 复用-简化-效率类清理项。
 
-> ⚠️ **禁止使用 `code-review` 技能或 `oh-my-claudecode:code-reviewer` agent** —— 这些工具内置自动发 PR 评论行为，导致重复审核报告。必须用裸 subagent 并显式约束"禁止发评论"。
+【输出格式】把 /code-review 的每条 finding 归一化为：
+- 严重级（Critical / Major / Minor；/code-review 的 bug 类→按严重程度，cleanup 类→Minor）
+- 文件:行号
+- 问题描述（≥1 句）
+- 建议改法（具体到代码层面）
+缺任一字段的条目剔除。
+
+【重要】只返回归一化后的 findings 文本。禁止 gh pr comment、禁止 --comment、禁止 --fix、禁止任何写操作——主 agent 统一发布、统一决定修/拒。
+
+获取 diff：gh pr diff <PR_NUMBER>（/code-review 默认审当前 diff）
+本 PR 历史遗留修复 commit 列表（若有）：<commit hash 列表，由主 agent 填入>
+```
 
-**主线 C — Issue 验收检查者**（独立 subagent，每轮必须派）：
+> ⚠️ **审查者 A/B 仍用裸 subagent，不得调用 `code-review` 技能或 `oh-my-claudecode:code-reviewer` agent**。只有**审查者 C** 专门承载系统 `/code-review`，且**必须裸跑（不带 `--comment` / `--fix`）**——裸跑只读不发评论不改码，findings 仍经主 agent 统一发布。带 `--comment` = 重复评论；带 `--fix` = 越权改码，两者都禁止。
+
+**Wave 1 — 主线 C — Issue 验收检查者**（独立 subagent，每轮必须派，与主线 A 并行）：
 
 目的：审 PR diff 是否真把关联 Issue 的"验收标准 / 目标"逐条落地，避免「代码改了但功能没做完」「PR 描述说做了但 diff 里没体现」。
 
@@ -225,8 +298,9 @@ Step 3: 运行关联测试（按改动范围判断）
 
 **第二轮及以后：按需降级**
 
-- 单源审查（默认）：上一轮修复少 / 仅 Minor / 改动集中少数文件 → 派一个 subagent
-- 双源审查：改动大 / 涉核心逻辑 / 上一轮有 Critical 修复 → 仍派两个
+- 单源审查（默认）：上一轮修复少 / 仅 Minor / 改动集中少数文件 → 派一个 subagent（优先保留审查者 C `/code-review`，或审查者 B 逻辑，二选一）
+- 多源审查：改动大 / 涉核心逻辑 / 上一轮有 Critical 修复 → 仍派审查者 A + B + C
+- **审查者 C `/code-review` 始终 medium 档**，不随轮次升降档（轮次降级只减审查者数量，不改 effort）
 - **主线 C Issue 验收**：每轮都派，不降级（功能完成度必须每轮复核，因修复可能引入新的偏离）
 
 是否进第二/三轮：
@@ -234,9 +308,23 @@ Step 3: 运行关联测试（按改动范围判断）
 - 上一轮全部修复且改动简单（仅格式/命名）→ 跳过后续审查，直接最终验证
 - 上一轮有 Critical/Major 修复 → 应进下一轮
 
+### 3.1.5 审查质量自检（主 agent 内联，无新增 subagent）
+
+Wave 2 返回后,主 agent 必须按下面清单**逐条核对审查者 A/B/C 的报告**,不达标则**就地把不达标条目退回**对应 subagent 要求补充(同一 subagent,带原 prompt + 不达标条目清单 + "请补全:文件:行号 / 具体描述 / 具体改法",直到达标或退回 2 次仍不达标——记为该条无效,不写入审核报告)。
+
+清单:
+
+- [ ] 每条问题都带 **严重级 + 文件:行号 + ≥1 句具体描述 + 具体改法** 四要素
+- [ ] 没有"建议优化"/"考虑使用 X 模式"这类无具体改法的空话条目
+- [ ] 审查者 A/B/C 报告中均不含「功能未实现」类条目(那是主线 C 的范围)
+- [ ] 审查者 C 的 findings 已归一化(剔除功能缺失类、补齐四要素),且确认其调用未带 `--comment` / `--fix`
+- [ ] 报告中没有针对 `chore(precheck):` 历史遗留修复 commit 的 nitpick
+
+这一步**不发 PR 评论**,只是主 agent 把不合格条目踢回 subagent。目的是保证最终落到 3.3b 审核报告里的每条都有可执行的改法。
+
 ### 3.2 问题汇总与去重
 
-汇总主线 A（lint/build/test 失败）、主线 B（架构 / 逻辑审查发现）、主线 C（Issue 验收偏离）所有问题。
+汇总主线 A（lint/build/test 失败）、主线 B（审查者 A 架构 / B 逻辑 / C 系统 `/code-review` 的发现）、主线 C（Issue 验收偏离）所有问题。
 
 **主线 A 错误一律纳入本轮问题**：不区分"本 PR 引入"还是"历史遗留"，全部按 Critical / Major 处理并修复。确实无法在本 skill 内修（跨服务 / 大规模重构）→ 在审核报告 + PR body 双处登记 follow-up Issue 编号后才能放行。
 
@@ -258,42 +346,79 @@ Step 3: 运行关联测试（按改动范围判断）
 - **Major** — 逻辑缺陷 / 错误处理缺失 / 性能问题
 - **Minor** — 命名 / 风格 / 文档
 
-### 3.3 发布审核报告到 PR
+### 3.3 发布审核报告到 PR（拆三条评论，职责单一）
 
 无问题 → 跳 3.6 通过流程。
 
+> **核心改进**：Issue 验收 / 代码审查 / 修复进度分别发独立评论（Hard Gate 3 升级为「三 comment gate」）。让 reviewer 在 GitHub PR 时间线上能按主题快速定位，不要把三种异构信息塞进同一长评论。
+
+#### 3.3a Issue 验收独立评论（每轮第一条评论，主线 C 输出闭环）
+
 ```bash
 gh pr comment $PR_NUMBER --body-file - <<'MSG'
-## 审核报告（第 N 轮）
+## Issue 验收报告（第 N 轮）
+
+- Issue：#<id> <标题>
+- 验收标准条目数：N
+- 结论：[全部完成 / 部分完成（欠 X 条） / 严重缺失（欠 Y 条核心项）]
+
+### 逐条比对
+
+| # | 验收标准 | 状态 | 证据 / 欠缺 |
+|---|----------|------|------------|
+| 1 | <原文> | ✅/⚠️/❌ | <文件:行号 或 欠缺描述> |
+
+### 后续处理
+
+- ❌ 未实现项 → 进入 3.4 修复或拆 follow-up Issue（附编号）
+- ⚠️ 部分实现项 → 进入 3.4 修复
+- ➕ 超出范围项 → 要求 PR body 补释或拆 follow-up Issue
+
+---
+*主线 C 产出，与代码审查解耦发布*
+MSG
+```
+
+#### 3.3b 代码审查 + 验证审核报告（每轮第二条评论，主线 A + 主线 B 汇总）
+
+```bash
+gh pr comment $PR_NUMBER --body-file - <<'MSG'
+## 代码审查报告（第 N 轮）
 
 ### 概要
 - Critical：X 个
 - Major：Y 个
 - Minor：Z 个
 
-### Issue 验收结果（主线 C）
-- Issue：#<id>
-- 验收标准：N 条，✅ a / ⚠️ b / ❌ c
-- 结论：[全部完成 / 部分完成 / 严重缺失]
+### 验证流水线（主线 A）
+- Lint：✅/❌
+- 构建：✅/❌
+- 测试：✅/❌（列实际执行的命令）
+- 错误分类：本 PR 引入 X 条 / 历史遗留 Y 条（详见下方表）
+
+### 历史遗留错误处理（若 Y > 0）
+| # | 文件:行号 | 错误 | 本轮处理 |
+|---|-----------|------|----------|
+| 1 | path/file:42 | 描述 | 已 chore(precheck) 修复 / 已开 follow-up Issue #NNN |
 
 ### Critical 问题
-| # | 来源 | 文件:行号 | 描述 |
-|---|------|-----------|------|
-| 1 | Lint/构建/测试/验收 | path/to/file:42 | 描述 |
+| # | 来源 | 文件:行号 | 描述 | 建议改法 |
+|---|------|-----------|------|----------|
+| 1 | 审查者A / 审查者B / 审查者C(code-review) / 验证 | path/to/file:42 | 描述 | 改法 |
 
 ### Major 问题
-| # | 来源 | 文件:行号 | 描述 |
-|---|------|-----------|------|
+| # | 来源 | 文件:行号 | 描述 | 建议改法 |
+|---|------|-----------|------|----------|
 
 ### Minor 问题
-| # | 来源 | 文件:行号 | 描述 |
-|---|------|-----------|------|
+| # | 来源 | 文件:行号 | 描述 | 建议改法 |
+|---|------|-----------|------|----------|
 
 ### 处理决策
-逐条标 修/拒（拒绝附 ≥1 句理由）
+逐条标 修/拒（拒绝附 ≥1 句理由，"超出范围"不是唯一合法理由）
 
 ---
-*审查工具：dx lint -> dx build -> dx test + 双源代码审查 + Issue 验收检查*
+*主线 A 验证 + 主线 B 三源代码审查（架构 A / 逻辑 B / 系统 code-review C）汇总，与 Issue 验收解耦发布*
 MSG
 ```
 
@@ -413,18 +538,31 @@ gh pr merge $PR_NUMBER --squash --auto
 - `--admin` 越权
 - `--squash --auto || --squash` 短路 fallback
 
-### Auto-merge 监控
+### Auto-merge 监控（独立 subagent）
 
-设定 `--auto` 后等待 main 真合并：
+设定 `--auto` 后,主 agent 派**独立 subagent 后台监控**, 自己释放上下文(避免审核完成后主 agent 还背着轮询任务,精力分散)。
 
-```bash
-# 监控 PR 状态（间隔轮询；stuck > 30 min 人工介入）
-gh pr view $PR_NUMBER --json state,mergedAt,statusCheckRollup,mergeStateStatus
+Subagent prompt：
+
+```
+你是 auto-merge 监控者。轮询 PR #<PR_NUMBER> 直到合并完成或达到 stuck 阈值。
+
+【任务】
+1. 每 60 秒跑一次：
+   gh pr view <PR_NUMBER> --json state,mergedAt,statusCheckRollup,mergeStateStatus
+2. 满足任一终止条件即返回：
+   - mergedAt 不为 null → 返回"已合并,merged_at=<ts>"
+   - state = CLOSED 且 mergedAt 为 null → 返回"PR 已关闭未合并"
+   - statusCheckRollup 出现 FAILURE → 返回"CI 失败,需修复",列失败 check 名称
+   - 累计轮询超过 30 分钟 → 返回"stuck > 30 min,当前 mergeStateStatus=<状态>"
+3. 期间若 statusCheckRollup 还在 PENDING / IN_PROGRESS,继续等待,不要主动重跑 CI 或推 commit。
+
+【重要】只返回结果文本。禁止调用 gh pr comment / gh pr merge / git push 等任何写操作。
 ```
 
-**正常路径**：CI 全绿后 GitHub 自动 merge → `mergedAt` 不为 null → 本 skill 完成。
+**正常路径**：CI 全绿后 GitHub 自动 merge → subagent 返回"已合并" → 本 skill 完成。
 
-**Stuck > 30 min**：人工介入，检查 CI / required reviews / branch protection。本 skill 输出"auto-merge stuck，需人工介入"提示，给出当前 `mergeStateStatus`，结束。
+**Stuck > 30 min**：subagent 返回 stuck 状态,主 agent 输出"auto-merge stuck,需人工介入",附 `mergeStateStatus`,结束。**禁止主 agent 自行 `--admin` 越权合并**。
 
 > Train 模式：本 PR 真正 merge 到 main 之前**调用方不允许启动下一 PR**。这是 train 串行的核心约束（由 `feature-decide-plan-execute` C-Step 3 阶段 1 的依赖检查兜底）。
 
@@ -453,11 +591,18 @@ PR Ship 完成！
 
 1. **输入 gate** — 必须有 PR 编号输入（或当前分支能查到 PR）。PR 不存在 → 拒绝执行，提示先用 `feature-decide-plan-execute` 建 PR。
 2. **依赖串行 gate** — PR body 含 `PR Train` 标记时，依赖的上游 PR 必须已 merge 到 main（`mergedAt` 不为 null）才能继续。
-3. **双 comment gate** — 每轮必须发**两条**评论：`审核报告`（issue table）+ `修复报告`（修复+拒绝 table）。**不允许合并成一条**。reviewer 用 review comment 决定 approve，用 fix comment 验证落实。
-4. **Subagent 禁发评论 gate** — 验证流水线 / 审查者 / Issue 验收 subagent **只返回文本**，禁止自己 `gh pr comment`。主 agent 统一发布。
-4.1. **4 subagent 并行 gate** — 阶段三 3.1 每轮必须并行派 4 个 subagent：主线 A 验证 + 审查者 A 架构 + 审查者 B 逻辑 + 主线 C Issue 验收。任一缺失视为流程违规。第二轮起代码审查可降级为单源，但 **主线 C 不可降级、不可跳过**。
+3. **三 comment gate** — 每轮必须发**三条**评论：`Issue 验收报告`（3.3a，主线 C 输出）+ `代码审查报告`（3.3b，主线 A 验证 + 主线 B 审查汇总）+ `修复报告`（3.5，修复+拒绝 table）。**不允许合并**。reviewer 用验收 comment 看功能完成度，用审查 comment 看代码质量，用修复 comment 验证落实。
+4. **Subagent 禁发评论 gate** — 验证流水线 / 审查者 / Issue 验收 / auto-merge 监控 subagent **只返回文本**，禁止自己 `gh pr comment`。主 agent 统一发布。
+4.1. **两波 5 subagent gate** — 阶段三 3.1 每轮（第一轮）必须按两波派 subagent：
+   - Wave 1 并行 2 个：主线 A 验证 + 主线 C Issue 验收
+   - Wave 2 并行 3 个：审查者 A 架构 + 审查者 B 逻辑 + 审查者 C 系统 `/code-review`（三者 prompt 必须嵌入 Wave 1 主线 C 验收结论 + 历史遗留 commit hash 列表）
+   任一波缺失视为流程违规。第二轮起代码审查可降级减少审查者数量，但 **主线 C 不可降级、不可跳过**，且**审查者 C `/code-review` 固定 medium 档不随轮次升降**；Wave 1→Wave 2 的顺序依赖不可省略（即使主线 C 还在跑也要等它完成才能启动 Wave 2，因为 Wave 2 prompt 依赖其输出）。
 4.2. **Issue 验收 gate** — 主线 C 报告「❌ 未实现核心验收标准」时，本轮不得跳到 3.6 通过流程；必须进入 3.4 修复（补做功能）或在 PR body 显式声明拆 follow-up Issue 并附编号，才能放行。
-5. **禁用 code-review 技能 / code-reviewer agent gate** — 这些工具内置自动发评论。必须用裸 subagent。
+4.3. **审查质量自检 gate** — Wave 2 返回后必须按 3.1.5 清单核对 A/B 报告，缺四要素（严重级 + 文件:行号 + 描述 + 改法）的条目要退回 subagent 补全；最多退回 2 次，仍不达标的条目不写入 3.3b 审核报告。避免审查者用"建议优化"等空话凑数。
+5. **`/code-review` 受控接入 gate** —
+   - 审查者 C 在裸 subagent 内调用系统 `/code-review --effort medium`，**必须只读**：严禁 `--comment`（会绕过单发布者产生重复评论）、严禁 `--fix`（会越权改业务代码，违反 Hard Gate 7）。findings 文本返回主 agent，由主 agent 在 3.3b 统一发布。
+   - 审查者 A / B 仍用**裸 subagent**，**不得**调用 `code-review` 技能或 `oh-my-claudecode:code-reviewer` agent（保持双源人格审查的多样性，且避免重复跑 `/code-review`）。
+   - 任何 subagent 都禁止 `gh pr comment`。
 6. **Auto-merge gate** — 最终合并只能 `gh pr merge --squash --auto`。禁止不带 `--auto`、禁止 `--admin`、禁止 fallback。
 7. **不越界做业务代码改动** — 本 skill 只产出"修复审查问题"的 commit；新增功能 / 重构 / 拆 PR 等动作回退给 `feature-decide-plan-execute`。
 8. **Heredoc gate** — `gh pr comment` / commit message 多行内容必须 heredoc，禁止 `--body "...\n..."`。
@@ -494,10 +639,15 @@ PR Ship 完成！
 |------|------|
 | 没传 PR 编号也没法从当前分支查到 | Hard Gate 1：先用 `feature-decide-plan-execute` 建 PR |
 | 验证流水线 / 审查 / Issue 验收 subagent 自己 `gh pr comment` | Hard Gate 4：subagent 只返回文本 |
-| 阶段三只派 3 个 subagent，漏掉 Issue 验收 | Hard Gate 4.1：必须 4 个并行 |
+| 阶段三只派 3 个 subagent，漏掉 Issue 验收 | Hard Gate 4.1：必须两波 5 个（Wave2 三源） |
+| 把 5 个 subagent 一次并行不分波 | Hard Gate 4.1：必须 Wave 1 完成主线 C 后再启 Wave 2，prompt 嵌验收结论 |
+| Wave 2 审查者 prompt 没嵌主线 C 结论，跑出"功能未实现"重复条目 | Hard Gate 4.1：prompt 强制反向约束（审查者 A/B/C 都要剔除功能缺失类） |
+| 审查者用"建议优化"凑条目 | Hard Gate 4.3：四要素自检退回补全 |
 | Issue 验收报 ❌ 但 PR 直接合并 | Hard Gate 4.2：要么补做要么拆 follow-up Issue |
-| 用 `code-review` 技能 / `code-reviewer` agent | Hard Gate 5：必须裸 subagent |
-| 把 review + fix 合并成一条评论 | Hard Gate 3：双 comment 必须分开 |
+| 审查者 C 跑 `/code-review --comment` 直接发评论 | Hard Gate 5：必须裸跑只读，findings 经主 agent 统一发，禁 `--comment` |
+| 审查者 C 跑 `/code-review --fix` 改了业务代码 | Hard Gate 5 + 7：禁 `--fix`，零业务改动，修复走 3.4 主 agent 决策 |
+| 审查者 A/B 也去调 `/code-review` 技能 / `code-reviewer` agent | Hard Gate 5：只有审查者 C 承载 `/code-review`，A/B 裸 subagent 保人格多样性 |
+| 把 Issue 验收 + 审核 + 修复 合并成一条评论 | Hard Gate 3：三 comment 必须分开 |
 | `gh pr merge --squash` 不带 `--auto` | Hard Gate 6：绕过 CI |
 | `gh pr merge --squash --auto \|\| --squash` 短路 fallback | 同上 |
 | Train 依赖 PR 未 merge 就开始本 skill | Hard Gate 2：依赖串行 |
@@ -508,9 +658,12 @@ PR Ship 完成！
 | 拒绝修复只写"超出范围" | 必须 ≥1 句具体理由 |
 | 主线 A 报的 lint/build/test 错误标"非本 PR 引入"跳过 | Hard Gate 10：预存错误零放行，必须修或登记 follow-up Issue |
 | 把历史遗留 lint 错误留 TODO 不修 | Hard Gate 10：当场修；修不动就开 Issue 登记，不留口头承诺 |
+| 历史遗留修复和本 PR 业务修复混在同一个 `fix:` commit | 3.1 隔离规则：历史遗留走 `chore(precheck):`，本 PR 走 `fix:`，下一轮审查 diff 排除历史 commit |
+| 主 agent 自己轮询 auto-merge | 阶段四：独立 subagent 监控，主 agent 完成审核闭环即释放 |
 | 简单改动跳过双 comment 直接 squash | 流程一致，避免漏掉历史遗留问题 |
 
 ## Tie-In With Other Skills
 
 - `feature-decide-plan-execute` — 上游：建好 PR 后把 PR 编号交给本 skill
 - `oh-my-claudecode:critic` agent — 阶段三审查子任务可调度（约束"禁发评论"）
+- 系统 `/code-review` — 阶段三 Wave 2 审查者 C 的承载工具，裸跑（`--effort medium`，禁 `--comment`/`--fix`），findings 经主 agent 统一发布

package/skills/backend-layering-audit-fixer/SKILL.md

@@ -1,180 +0,0 @@
----
-name: backend-layering-audit-fixer
-description: Use when backend、NestJS 分层架构或事务规范审查中，需要检查 Service 是否绕过 Repository 直接访问数据库、Controller 是否跨层注入 Repository、Service 是否伪装 Repository、事务装饰器是否匹配 afterCommit 使用、非 HTTP 场景事务模式是否正确、SSE 端点是否误加事务装饰器、以及是否存在直接 prisma.$transaction() 调用。
----
-
-# 后端三层架构与事务规范合规检查
-
-## 概览
-
-扫描后端代码是否遵守 **Controller → Service → Repository** 三层架构约束及事务规范。默认只输出审计结果和修复建议；用户明确要求时才自动修复。
-
-规则来源：`ruler/conventions.md` 第 4 节 "NestJS/Prisma 约定" + 第 5 节 "事务规范"。
-
-## 检查项
-
-### 分层架构
-
-| 编号 | 违规类型 | 说明 |
-|------|----------|------|
-| L1 | Service 直接访问数据库 | Service 注入 `PrismaService` 并调用 `this.prisma.*` |
-| L2 | Service 伪装为 Repository | Service 文件含 `getClient()` / `txHost.tx` 模式，实质是 Repository |
-| L3 | Service 死依赖 | Service 注入 `PrismaService` 但从未使用 |
-| L4 | Controller 跨层调用 | Controller 直接注入 Repository |
-
-### 事务规范
-
-| 编号 | 违规类型 | 说明 |
-|------|----------|------|
-| T1 | afterCommit 未被排空 | Controller 用 `@Transactional()` 但调用链中存在 `txEvents.afterCommit()` 回调（应改用 `@TransactionalWithAfterCommit()`） |
-| T2 | Service 违规传播类型 | Service 使用 `Propagation.Required` / `RequiresNew` / `Nested`（禁止 Service 自行创建事务） |
-| T3 | 直接 `prisma.$transaction()` | 绕过 `TransactionHost` 抽象，直接调用 `prisma.$transaction()` |
-| T4 | SSE/流式端点加事务装饰器 | `@Sse()` 或流式返回的方法上使用了 `@Transactional()` / `@TransactionalWithAfterCommit()`（会导致 afterCommit 提前排空） |
-| T5 | 非 HTTP 场景事务模式错误 | Subscriber/Scheduler 使用了 `@Transactional()` 装饰器而非 `txHost.withTransaction()` 或 `txEvents.withAfterCommit()` |
-| T6 | 非 HTTP 场景缺少 CLS 作用域 | Scheduler 调用 `txHost.withTransaction()` 前未用 `cls.run()` 创建 CLS 作用域 |
-
-## 审计命令
-
-**分层架构扫描（并行执行）：**
-
-```bash
-# L1 + L2 + L3：Service 注入 PrismaService
-rg "PrismaService" apps/backend/src/modules --glob '*.service.ts' -l
-
-# L2：Service 含 Repository 模式
-rg "getClient|txHost\.tx" apps/backend/src/modules --glob '*.service.ts' -l
-
-# L4：Controller 注入 Repository
-rg "Repository" apps/backend/src/modules --glob '*.controller.ts' -l
-```
-
-**事务规范扫描（并行执行）：**
-
-```bash
-# T1：找出所有只用 @Transactional() 的 Controller 方法（排除 @TransactionalWithAfterCommit）
-rg "@Transactional\(\)" apps/backend/src/modules --glob '*.controller.ts' -l
-
-# T2：Service 违规传播类型
-rg "Propagation\.(Required|RequiresNew|Nested)" apps/backend/src/modules --glob '*.service.ts' -l
-
-# T3：直接 prisma.$transaction()
-rg "prisma\.\$transaction" apps/backend/src/modules -l
-
-# T4：SSE 端点是否带事务装饰器（需人工确认上下文）
-rg "@Sse\(\)" apps/backend/src/modules --glob '*.controller.ts' -l
-
-# T5：Subscriber/Scheduler 误用 @Transactional 装饰器
-rg "@Transactional" apps/backend/src/modules --glob '*.subscriber.ts' --glob '*.task.ts' --glob '*.scheduler*.ts' -l
-
-# T6：Scheduler 使用 txHost.withTransaction 但未包 cls.run
-rg "txHost\.withTransaction" apps/backend/src/modules --glob '*.scheduler*.ts' --glob '*.task.ts' -l
-```
-
-## 执行流程
-
-1. 执行上述审计命令，收集命中文件列表
-2. **分层检查**：对每个命中文件，读取构造函数和使用处，判定违规类型：
-   - 注入了 `PrismaService` 且有 `this.prisma.*` 调用 → **L1**
-   - 注入了 `PrismaService`/`txHost` 且有 `getClient()` → **L2**
-   - 注入了 `PrismaService` 但无任何 `this.prisma.*` 调用 → **L3**
-   - Controller 文件 import/注入 Repository → **L4**
-3. **事务检查**：
-   - T1：对只用 `@Transactional()` 的 Controller，追踪其调用的 Service 方法，检查是否存在 `txEvents.afterCommit()` 调用
-   - T2：直接匹配即违规
-   - T3：直接匹配即违规
-   - T4：对 `@Sse()` 方法，检查同一方法上是否有事务装饰器
-   - T5：直接匹配即违规（Subscriber/Scheduler 不应用装饰器声明事务）
-   - T6：对命中文件，检查 `txHost.withTransaction()` 调用是否在 `cls.run()` 回调内部
-4. 输出审计报告（按模块分组，标注违规类型和行号）
-5. 仅当用户明确要求修复时，才执行修复
-
-## 修复策略
-
-### 分层架构
-
-**L1：Service 直接访问数据库**
-- 将数据库查询逻辑提取到对应 Repository（新建或复用已有）
-- Service 改为注入 Repository 调用
-
-**L2：Service 伪装为 Repository**
-- 重命名文件为 `*.repository.ts`，类名改为 `*Repository`
-- 更新所有引用（import、Module providers、注入处）
-- 确认 Service 层消费者改为注入新 Repository
-
-**L3：Service 死依赖**
-- 移除构造函数中 `PrismaService` 注入
-- 移除对应 import 语句
-- 运行 lint 确认无残留
-
-**L4：Controller 跨层调用**
-- Controller 中的 Repository 调用下沉到 Service
-- Controller 改为调用 Service 方法
-
-### 事务规范
-
-**T1：afterCommit 未被排空**
-- 将 Controller 方法的 `@Transactional()` 改为 `@TransactionalWithAfterCommit()`
-- 或确认调用链中确实不存在 `afterCommit()` 回调（则无需修改）
-
-**T2：Service 违规传播类型**
-- 改为 `Propagation.Mandatory`（必须在事务中调用）或 `Propagation.Supports`（有事务则加入）
-- 事务边界上移到 Controller 层
-
-**T3：直接 `prisma.$transaction()`**
-- 改用 `txHost.withTransaction()` 或由 Controller 层 `@Transactional()` 声明事务边界
-- Repository 内通过 `txHost.tx` 自动参与事务
-
-**T4：SSE/流式端点加事务装饰器**
-- 移除事务装饰器
-- 如需事务操作，在流式逻辑内部用 `cls.run()` + `txHost.withTransaction()` 局部处理
-
-**T5：非 HTTP 场景误用 @Transactional 装饰器**
-- Subscriber：改用 `txEvents.withAfterCommit()` 包裹处理逻辑
-- Scheduler/Task：改用 `cls.run()` + `txHost.withTransaction()`
-
-**T6：非 HTTP 场景缺少 CLS 作用域**
-- 在 `txHost.withTransaction()` 外层包裹 `cls.run()`：
-  ```typescript
-  await this.cls.run(async () => {
-    await this.txHost.withTransaction(async () => { /* ... */ })
-  })
-  ```
-
-## 排除项
-
-以下场景不视为违规：
-- `*.repository.ts` 文件中使用 `PrismaService` / `getClient()` / `txHost`（Repository 正常职责）
-- `prisma/` 目录下的基础设施文件（`prisma.service.ts` 等）
-- `common/` 目录下的事务基础设施（`TransactionEventsService`、`AfterCommitInterceptor` 等）
-- `*.spec.ts` / `e2e/` 测试文件
-- Subscriber / Scheduler 中通过 `txHost.withTransaction()` 管理事务（正确模式，但其中数据库查询仍应走 Repository）
-
-## 审计报告模板
-
-```
-## 后端分层架构与事务规范审计报告
-
-### 违规汇总
-
-**分层架构：**
-- L1（Service 直接访问 DB）：N 处
-- L2（Service 伪装 Repository）：N 处
-- L3（Service 死依赖）：N 处
-- L4（Controller 跨层调用）：N 处
-
-**事务规范：**
-- T1（afterCommit 未被排空）：N 处
-- T2（Service 违规传播类型）：N 处
-- T3（直接 prisma.$transaction）：N 处
-- T4（SSE 端点加事务装饰器）：N 处
-- T5（非 HTTP 场景误用装饰器）：N 处
-- T6（非 HTTP 缺少 CLS 作用域）：N 处
-
-### 详细列表
-
-#### [模块名]
-| 文件 | 违规类型 | 行号 | 说明 |
-|------|----------|------|------|
-| ... | L1 | 39 | `this.prisma.user.findMany()` |
-| ... | T1 | 85 | `@Transactional()` 但调用链含 `afterCommit()` |
-```