fix-pr-review

/fix-pr-review：分类、修复并解决 PR 审查评论

接收来自 CodeRabbit、/review-pr 的 PR 审查结果，或粘贴的文本。对每条发现进行分类，应用经过验证的修复，运行 /done，然后在一个流程中回复并解决 GitHub 对话。

仅当运行仍需要用户做出决定时，才使用 AskUserQuestion：分支安全、暂存确认、有争议条目的确认、--interactive 逐项修复确认、类型检查失败的分类，以及完成后的后续操作。调用 /fix-pr-review 或明确要求修复审查发现，即表示授权执行经过验证的 FIX 计划。不要另行征求计划批准。将每个必需选项标记为具体且已考虑，并按优先级从高到低排列，最优选项后标注“（推荐）”。

快速参考

阶段概览

R 规则摘要（阶段 3 步骤 4；按顺序匹配，命中第一条即止）

R4/R5 排在 R3 之前是有意设计，并非偶然；R10 排在 R6 之前，是为了避免技术上正确的发现仅凭正确性就进入修复流程。完整规则及其排序原因见 references/triage-rubric.md。

关键交叉引用

• R 规则定义：references/triage-rubric.md，由分类子 Agent 在阶段 3 步骤 4 加载，而非由主 Agent 加载
• 计划验证规则：阶段 4（验证 R 规则所需字段）
• 修复执行路由：阶段 5（执行 R6 FIX 项）
• 收敛：阶段 5.5（使用计划中的 class_completeness + inverse_risk；为 fix_status 和逐项修复的 convergence: 报告行提供数据）
• 回复验证器：references/github-reply-resolve.md 步骤 7b（GitHub 回复的格式规则）
• 报告分组：阶段 8（按 R 分类分组）
• 抑制项：阶段 3“加载审查抑制项”（主 Agent 在派发前读取）+ references/triage-prompt.md（子 Agent 在分类前应用抑制项）+ 阶段 8（写入）

参考文件

每个文件的加载条件都写在其使用位置的指针中。需要时再加载，不要预先加载。

• references/fetch-review-data.md：按输入类型获取 GraphQL/REST 数据、CodeRabbit 审查正文结构、Comment 架构。主流程在 Phase 2 的 GitHub 获取步骤加载；如果本地文件路径导致未在此处读取，则在 Comment 架构规范化步骤再次加载。
• references/triage-prompt.md：完整的 Phase 3 子 Agent 提示词（STEP 0 → STEP 6 + 输出格式）。主流程在 Phase 3 读取，替换占位符后原样传递。
• references/triage-rubric.md：R1-R10 详情、NEEDS-INPUT 校准、change_class 示例、回复格式。分诊 SUBAGENT 在 STEP 4 加载。
• references/github-reply-resolve.md：发布/解决的 Step 7a-7d 操作。主流程在 Phase 7 加载；本地文件输入时绝不加载。
• references/final-report.md：Phase 8 报告模板及其渲染规则。主流程在 Phase 8 打印前加载。
• references/branch-safety.md：包含脱离 HEAD 和不同分支问题的仓库及分支切换流程。对于 GitHub 输入，主流程在 Phase 1 加载；本地文件时跳过。
• references/per-fix-loop.md：逐项修复循环、交互确认、范围限定的类型检查和基线对比、重试/跳过/中止。主流程在 Phase 5 循环时加载。
• references/needs-input-triage.md：NEEDS-INPUT 的处理、逐项分诊、Phase 8 修复及验证、GitHub 回复前的预检。仅当数量不为零时，主流程在 Phase 8 第 1 步加载。

此处未附带一个参考文件：${CLAUDE_SKILL_DIR}/../review-pr/references/repo-map.md 包含 repo_map_files / repo_map_exports shell 脚本，是本技能与 /review-pr 共用的唯一副本。若存在 packages/ 或 apps/，主流程会在 Phase 1 加载。

用法

/fix-pr-review https://github.com/owner/repo/pull/123
/fix-pr-review https://github.com/owner/repo/pull/123#pullrequestreview-4089716169
/fix-pr-review https://github.com/owner/repo/pull/123#discussion_r3064352825
/fix-pr-review ./review.md            # local output from /review-pr
/fix-pr-review /tmp/review-pr-123-findings.md  # local review export
/fix-pr-review                         # no arg → ask user to paste

可选标志：

• --dry-run：显示计划后停止，不执行
• --interactive：应用每个 FIX 项目前先询问
• --all-nitpicks：对所有 nitpick 进行完整分诊，而非默认忽略

哪些内容会被分诊

所有审查者的评论都经过相同的分诊流程：CodeRabbit、人类审查者和其他机器人均不例外。全文使用“CodeRabbit”的表述，是因为这是最常见的使用场景。

Phase 1：先决条件 + 输入检测 + 分支安全（主流程）

先决条件检查

command -v gh >/dev/null 2>&1 || { echo "Install gh CLI: https://cli.github.com"; exit 1; }
git rev-parse --is-inside-work-tree >/dev/null 2>&1 || { echo "Not inside a git repo. cd into your clone first."; exit 1; }
gh auth status 2>&1 | grep -q "Logged in" || { echo "Run 'gh auth login' first"; exit 1; }

根据参数检测输入类型

• 包含 #pullrequestreview-<id> → 审查 URL
• 包含 #discussion_r<id> → 讨论 URL（单条评论 + 讨论串）
• 以 ./ / / 开头，或以 .md 结尾 → 本地文件
• 匹配 https://github.com/<owner>/<repo>/pull/<num> 且不含片段 → PR URL
• 为空 → 请用户粘贴内容或提供 URL

记录执行授权

当原始请求明确调用 /fix-pr-review，或以祈使方式要求修复、处理、应用、解决审查发现的问题时，设置 EXECUTION_AUTHORIZED=true。仅提供 URL，或只要求检查、解释、审查、分诊的只读请求，将其设置为 false。将匹配的请求文本保留为 execution_authorization_evidence；Phase 4 可以用明确的执行选择替换它，Phase 7 会将最终证据传递给 preflight-mutations。

确保仓库和分支正确（仅限 GitHub 输入）

从 URL 中解析 owner、repo 和 number，并按照 ${CLAUDE_SKILL_DIR}/references/branch-safety.md 切换到 PR 分支。现在加载该文件。如果工作区正处于合并、变基或拣选提交过程中，请停止，并在进行任何操作前将冲突解决交由 resolving-merge-conflicts 处理。

自动暂存未提交的工作（分支安全）

此步骤适用于所有输入类型，包括 GitHub 和本地文件。修复绝不会直接覆盖未暂存的 WIP。

git status --porcelain

如果非空，请使用 AskUserQuestion：

问题： 标题："暂存" 文本："检测到未提交的更改。是否在应用修复前自动暂存？这些内容将在结束时恢复。" 选项： - 标签："自动暂存" 描述："立即暂存更改。运行完成后会恢复这些更改" - 标签："中止" 描述："停止。我会先手动提交或暂存工作"

选择“自动暂存”时，运行 git stash push -u -m "fix-pr-review auto-stash $(date +%s)"。仅在成功后，记录 STASH_OID=$(git rev-parse -q --verify refs/stash) 并设置 STASH_PUSHED=true，然后确认 git status --porcelain 为空。推送失败时不记录任何内容，并中止运行，而不是标记一个实际上并未创建的暂存。如果运行中止，用户可在 git stash list 中找到名为 fix-pr-review auto-stash <timestamp> 的工作。 选择“中止”时，打印 "Commit or stash your uncommitted work first." 并退出。

暂存恢复保护。 本次运行中的每次恢复操作（包括此处和每个提前退出处）都只能在 STASH_PUSHED=true 时执行：仅当栈顶与记录的 OID 相同时，才按 OID 应用暂存（git stash apply "$STASH_OID"，绝不使用不带参数的 pop）；仅在应用成功且栈顶仍相同时才删除暂存；出现任何不匹配时，保留所有条目不作改动，记录 stash_restored: foreign-top，打印 stash_restored: foreign-top, stash left untouched，并继续运行，不应用或删除任何内容。

计算合并基准（供后续检测是否已修复）

BASE_SHA=$(git merge-base "origin/$(gh pr view <url> --json baseRefName -q .baseRefName)" HEAD)

将其暂存为 BASE_SHA，供第 3 阶段的已修复检查使用。

修复前类型检查基线（窄范围类型检查的对照基准）

在第 5 阶段之前运行一次基线类型检查，并捕获已存在错误的文件集合：

bun turbo run check-types 2>&1 | tee /tmp/fix-pr-review-baseline-$$.log

为整个运行定义一个解析器。对于每条诊断，确定其文件，并在移除文件位置、行号和列号信息后，将 <diagnostic code> + <normalized message> 作为标识；重复标识须以多重集形式保留。使用此解析器将第 1 阶段的输出解析到 baseline_errors[path] 中。第 5 阶段和第 8 阶段的所有基线路径都必须使用相同的解析器和标识规范化方式。如果缺少类型检查工具（没有 turbo、tsc），则跳过基线，并将所有修复的窄范围类型检查标记为 skipped。

计算共享包仓库映射（供可复用性分类使用）

盘点共享包和应用，以便第 3 阶段的分类器可以根据现有内容交叉核验有关复用和提取的注释。同时扫描 packages/ 和 apps/。例如，在 NestJS 风格的单体仓库中，跨应用的辅助函数重复很常见，如 apps/backend/src/modules/v1/feature-a/helpers.ts 与 feature-b/helpers.ts，仅扫描 packages/ 会遗漏这类情况。

加载 ${CLAUDE_SKILL_DIR}/../review-pr/references/repo-map.md，并运行其中的 Local mode 块；这是与 /review-pr 共享的同一份 shell。它通过 bash -c 封装 glob，确保其在 zsh 中也能正常工作，并将每部分限制为 500 行，且会标记截断情况。如果存在 packages/ 或 apps/，则加载该文件；如果两者都不存在，则无需运行，改用下方的回退方案。

将两项输出分别暂存为 repo_map_files 和 repo_map_exports，供第 3 阶段的子 Agent 提示词使用。如果 packages/ 和 apps/ 均不存在（非单体仓库），则将两者都设为 N/A (not a monorepo)，并将 IS_MONOREPO=false。分类器提示词会据此将 grep 的扫描范围改为 src/ 和仓库根目录。

第 2 阶段：获取评审数据（主流程）

/review-pr 发现的双路径输入

/review-pr 现在会将发现作为单独的行内评论发布，每条发现对应一行特定代码。这些评论会在 GitHub 上创建标准的 PullRequestReviewThread，与 CodeRabbit 线程完全相同。现有的下方 GraphQL 获取逻辑可以直接处理，无需任何特殊解析。

手动导出或旧版的 /review-pr 发现文件使用现有的本地文件路径。对于这些输入，Phase 7 会跳过 GitHub 操作。

从 GitHub 获取（PR URL / review URL / discussion URL）

Phase 1 检测到了这三种输入类型中的一种。现在加载 ${CLAUDE_SKILL_DIR}/references/fetch-review-data.md，并且只运行对应类型的部分。其中包含分页 GraphQL reviewThreads 查询及其 isResolved 过滤条件、/pulls/<num>/reviews/<review_id> 和 /pulls/comments/<comment_id> REST 端点、CodeRabbit review 正文结构，以及 🤖 Prompt for all review comments with AI agents 区块的解析方式。该区块是 nitpick 唯一出现的位置，因为它们不会创建行内线程。

如果获取过程报错，会显示错误并退出，因此不会在评论集不完整的情况下运行分类处理。这包括 GraphQL 速率限制、404、私有仓库，以及分页循环中单页获取失败。遇到 404 时，打印 Couldn't access PR. Check repo access and run 'gh auth refresh -s repo'.

对于本地文件（./review.md、/tmp/review-pr-*-findings.md 等）

解析 /review-pr 输出格式。从 ## Findings 部分提取发现，保留 Severity / File / Category / Issue / Why it matters / Suggested fix，以及存在时的 Rule-class / Enclosing-symbol / Inverse risk / Class-sites。/review-pr 会为每条发现输出这些字段；若丢弃它们，就会迫使此技能重新推导审核者已经完成的工作。

用作起点，而非重新推导：存在 Inverse risk: 时，用它为 STEP 5 的 inverse_risk 提供初始值，并根据代码进行验证（确认所述失效模式确实存在且仍然适用），而不是从头推导。存在 Class-sites: <A>/<N> 时，用其中的 N 个站点为 STEP 1.5 的 class_completeness 提供初始值，并通过自己的搜索核实数量。重新搜索只是为了发现审核者遗漏的站点，而不是重新构建列表。Rule-class 和 Enclosing-symbol 为类范围扫描提供 signature 初始值。如果初始值与代码内容矛盾，以代码为准，并在相应字段中记录差异。

严重性映射：/review-pr 使用 Critical | Serious | Moderate | Minor，而 CodeRabbit 使用 Critical | Major | Minor | Refactor | Nitpick。两者均有效。将其规范化为内部 Comment 模式，该模式接受任一约定。分类优先级映射：Critical = 最高，Serious/Major = 高，Moderate = 中，Minor/Refactor = 低，Nitpick = 默认忽略。

规范化为内部 Comment 列表

所有输入路径最终都会到达此处。Comment 模式（即 Phase 3-8 读取的确切字段名称）定义在 references/fetch-review-data.md 中。如果你选择的是本地文件路径且尚未读取该文件，现在就加载它。

提前结束的情况

• 列表为空（所有线程均已解决，或本地文件中没有发现）：打印 Nothing to triage. No unresolved comments found. → 在保护条件下恢复 stash → 以状态码 0 退出。
• 只剩 nitpick 且未设置 --all-nitpicks：打印 Only nitpicks found (N). Pass --all-nitpicks to triage them, or ignore. → 在保护条件下恢复 stash → 以状态码 0 退出。

Phase 3：分类子 Agent（general-purpose）

加载评审抑制规则（主 Agent，在分派之前）

分派子 Agent 之前，从基准修订版本加载 .claude/review-suppressions.yml，绝不能从工作树加载：已检出的 PR 不得抑制自身的分诊结果。对于 GitHub 输入，请在固定的基准 OID 处读取：本地执行 git show "$PINNED_BASE_OID:.claude/review-suppressions.yml"（对象不存在时获取一次 origin），或者在跨仓库模式下执行 gh api repos/<owner>/<repo>/contents/.claude/review-suppressions.yml?ref=$PINNED_BASE_OID。对于没有 PR 的本地文件输入，HEAD 本身可能就是正在分诊的变更。将可信基准解析为唯一一个包含所有其他候选项的候选合并基点：为每条主线各收集一个基点，优先选择远程别名而非对应的本地别名，因为本地主线本身可能就是正在分诊的变更；只有当某个基点是唯一一个包含其余所有基点的基点时，才采用它。若存在并列、互不可比的候选项或候选集为空，则停用抑制规则。

BASES=$(for remote in origin/main origin/master origin/develop; do
  bare=${remote#origin/}
  if git rev-parse --verify -q "$remote" >/dev/null 2>&1; then ref=$remote
  elif git rev-parse --verify -q "$bare" >/dev/null 2>&1; then ref=$bare
  else continue
  fi
  git merge-base HEAD "$ref" 2>/dev/null || continue
done | sort -u)
RESULT=""
if [ -n "$BASES" ]; then RESULT=$(printf '%s\n' "$BASES" | while IFS= read -r b; do
  [ -n "$b" ] || continue
  BAD=$(printf '%s\n' "$BASES" | grep -vx "$b" | while IFS= read -r o; do
    git merge-base --is-ancestor "$o" "$b" 2>/dev/null || printf 'bad\n'
  done)
  [ -z "$BAD" ] && printf 'WINNER %s\n' "$b"
done); fi

读取胜出的提交中的文件，并记录来源。统计胜出项时，确保空输入也能成功，因为 grep -c 在计数为零时会以 1 退出：

WINNERS=$(printf '%s\n' "$RESULT" | grep -c WINNER || true)

仅当 WINNERS 等于 1 且胜出项不是 HEAD 本身时才采用它：若胜出项等于 HEAD，说明没有可供信任的更早基准。否则设置 SUPPRESSIONS = ""：不使用策略进行分诊会增加噪声，信任正在评审的变更则会隐藏发现的问题。候选集为空时不会输出任何胜出项行。如果基准中没有此类文件，则设置 SUPPRESSIONS = ""，并记录忽略了由 PR 添加的文件。

将已加载的抑制规则作为 ## Review suppressions 一节传入子 Agent 提示词（与 CLAUDE.md 内容、PR 差异和仓库映射采用相同方式；主 Agent 获取，子 Agent 将其作为上下文接收）。

分派

分派一个具有 Read、Grep 和 Bash 工具的 general-purpose 子 Agent。分诊计划只能来自这个子 Agent。如果它彻底失败，则中止运行并说明原因。跳过基础核实和类别扫描，直接分类会使整个计划失去依据。

重要：Bash 允许列表（git log/diff/blame/show/merge-base/rev-parse、grep、rg）是提示词级指令。Claude Code 的 Agent 工具不会按命令对 Bash 进行沙箱隔离。子 Agent 受信任，不会运行其他命令，但系统不会以机制阻止它这样做。

提示词模板

完整提示词位于 references/triage-prompt.md。现在读取它，替换其中的 <...> 占位符（<SKILL_DIR> = 此技能的绝对目录，另加 Phase 1 上下文值、git diff <BASE_SHA>...HEAD 输出、仓库映射、SUPPRESSIONS 和 Phase 2 的 Comment[] 数组），然后将结果原样传给子 Agent。它是子 Agent 要运行的字符串，不是要你遵循、总结或在此处改述的指令。

其中的 STEP 4 会让子 Agent 自行读取 references/triage-rubric.md。你不要读取该文件；R-Rubric Summary 表格是主 Agent 的视图。Phase 4 会验证返回的内容：每个 FIX 都会由提示词输出 fix_plan、change_class、test_scenario、inverse_risk: 和 class_completeness:；reusability_context: 则包含在每个条目中，而不只包含在 FIX 中。

Phase 4：计划执行门控（主流程）

根据 R-rubric 进行验证：摘要表格见上文，完整细节见 references/triage-rubric.md。各分类所需字段在该文件中定义。

计划验证（显示前）

向用户展示任何内容之前，先以机械方式验证分类器的输出：

• 每个 rubric: R5 的 DISMISS 都必须有非空的 claude_md_quote。
• 每个 rubric: R4 的 DISMISS 都必须有非空的 prior_commit_sha。
• 每个 DISAGREE 都必须有非空的 disagree_rationale（且不得仅仅表达风格偏好；检查是否出现“prefer”“cleaner”“nicer”等关键词，却没有具体的反驳理由）。
• 每个 FIX 的 fix_plan 长度必须不少于 30 个字符。
• 每个 FIX 的 change_class 必须准确设为 hardening 或 logic-change（分类器采用的校准标准见 references/triage-rubric.md；此项检查仅核对字面值）。
• 每个 FIX 都必须有非空的 test_scenario。对于 change_class: hardening，该值必须准确为 smoke test, happy path unchanged。对于 change_class: logic-change，该值必须是一个具体复现步骤句（不能只是“验证其正常工作”）。
• 每个 FIX 都必须有非空的 inverse_risk，且要么指出具体的故障模式，要么准确为 none, pure addition。含糊表达无法通过验证：空值，或诸如“可能有问题”“风险较小”“有些风险”“可能引入回归”之类的内容，或单独的 none，均不合格。指出故障模式时，必须说明哪里会出什么问题。Phase 5.5 会使用此字段；未说明的风险无法在该阶段验证。
• 每个 FIX 都必须包含 class_completeness 块，其中有非空的 verdict，且以 COMPLETE 或 INCOMPLETE 开头。INCOMPLETE 必须列出排除的代码位置，并逐一说明原因。没有逐项说明原因的 INCOMPLETE 判定无法通过验证。
• 每个 rubric: R10 的 NEEDS-INPUT 都必须有 why_unclear，其中包含 current:、proposed: 和 intent evidence: 三部分，且每部分都非空。具体格式见 references/triage-rubric.md。found nothing 是有效的证据值，空值则无效。
• 每个条目都必须有非空的 grounding_a 和 grounding_b。
• 每个条目都必须包含 reusability_context 字段，即使其值只是 { flagged: false } 也不例外。所有分类都适用，包括 NEEDS-INPUT。Phase 7 的回复验证器会根据此字段进行分支处理，因此缺少此字段会悄然禁用该回复的可复用性检查。
• 验证失败时：使用缺失字段的具体列表重新派发分类器。最多重试 1 次。第二次仍失败时 → 中止并打印验证错误。

计划展示

使用以下标题打印计划：

# Fix Plan, PR #<num>: <title>
# <N> findings triaged: <F> fix, <D> dismiss, <E> defer, <G> disagree, <I> needs-input, <n> nitpicks

突出显示基于 CLAUDE.md 的 DISMISS

如果存在任何 rubric: R5 的 DISMISS，则在主计划之前打印一个单独的重点部分：

## ⚠ Dismissed because they contradict CLAUDE.md: review and override if any are exceptions

[D<n>] <file:line>: <comment ask>
       CLAUDE.md rule: "<verbatim quote>"
       Reply will be: "<reply>"
       If this rule has a legitimate exception in this case, select D<n>
       in the contested-item confirmation to change it to FIX or NEEDS-INPUT.

有争议项目确认（multiSelect）

有争议的项目是指那些会发布回复并解决讨论串、但不会更改代码的项目：所有 DISMISS、DEFER 和 DISAGREE。错误分类会悄然结束审查者的对话。在 Phase 5/7 采取行动前，请确认分流结果。

如果没有有争议的项目，请跳过此步骤。否则，使用 AskUserQuestion：

问题： header: "分流" text: " 个项目将发布回复并解决讨论串，且不更改代码。选择要重新分类的项目。未选中的项目将按计划继续处理。" 选项：[每个 DISMISS/DEFER/DISAGREE 项目对应一个选项："[] file:line：（），<reason，前约 60 个字符>"] multiSelect: true

如果有争议的项目超过选项数上限，请拆分为多个 multiSelect 问题。先处理 DISMISS（错误分类的代价最高）。

对于每个选中的项目，使用后续的 AskUserQuestion：

问题： header: "项目 " text: "file:line，当前分类为 ：。重新分类为？" 选项： - label: "FIX（推荐）" description: "将其视为实际问题，并添加到 FIX 列表，附上修复计划" - label: "NEEDS-INPUT" description: "暂缓处理，不发布任何内容；此项目会显示在最终报告中" - label: "保持原样" description: "由于误选了此项目，保留原分类"

选择“FIX”时：仅针对该项目重新分派分类器，生成完整的 FIX 字段集：fix_plan、change_class、test_scenario、inverse_risk、class_completeness（包括类别扫描；重新分类的项目尚未经过扫描），以及 reusability_context（除非扫描结果改变该值，否则沿用有争议项目自身的值）。然后对更改后的项目重新运行计划验证。此处生成不完整的字段集将导致验证失败，并耗尽唯一一次重试机会。选择“NEEDS-INPUT”时：将其移至 NEEDS-INPUT，并设置 why_unclear: "user contested the <classification> classification"，原样保留项目的 reusability_context。选择“保持原样”时：不做更改。选择“Other”时：将自由文本作为重新分类指令。

此步骤期间不会发布或解决任何内容。只有 Phase 7 会操作 GitHub，且仅处理通过此确认的项目。解决讨论串会在审查者的对话中留下不可逆的干扰：跳过此关卡的 DISMISS、DEFER 或 DISAGREE 项目会保持未解决且没有回复，直到通过此确认。

执行

如果设置了 --dry-run：打印计划，打印 dry run, not executing，在保护机制下恢复 stash，然后以状态码 0 退出。

如果 EXECUTION_AUTHORIZED=true，则直接进入 Phase 5。此次调用已授权执行所有通过验证的 FIX 项目。如果设置了 --interactive，则在 Phase 5 中逐项询问确认。这不会增加计划级别的确认。

否则，使用 AskUserQuestion：

问题： header: "执行" text: "请求未明确授权修改。是否执行已验证的计划？ 个修复， 个忽略， 个延期， 个不同意， 个需要输入。" 选项： - label: "执行计划（推荐）" description: "按依赖顺序应用所有 FIX 项目" - label: "取消" description: "保持工作区不变，并恢复任何 stash"

preedit_snapshot[path] = <full file content from Read>

fix_status[idx] = ok | retried_ok | inconclusive | skipped | aborted | type_check_skipped
                | reverted_inverse_risk | inverse_risk_applied | partial | restored_failed
landed_fix_statuses = {ok, retried_ok, inconclusive, type_check_skipped}

For each fix below, verify against the working tree, not against the fix plan's claims.

1. CLASS COMPLETENESS: every site the class sweep marked `affected` in
   `class_completeness.sites` must actually be changed. A fix that landed on 3 of 4
   sites is INCOMPLETE, not done.
   (Sites the plan's `verdict` deliberately excluded are not counted as unfixed.)
2. INVERSE RISK: the named failure mode must NOT be present in the applied code.
3. NEW SIBLINGS: did the fix itself introduce a new instance of the pattern it fixes,
   or a new branch (error state, empty state, early return) that its siblings have but
   this one lacks?

Report per fix, nothing else:
  fix: <idx>
  class_complete: yes | no, <unfixed site if no>
  inverse_risk_present: no | yes, <file:line + one sentence>
  new_siblings: none | <file:line + one sentence>

Evidence rules differ per check. "I lack evidence" is not an answer for check 1:
  - Check 1 is decided MECHANICALLY by `git diff HEAD`. Each affected site either
    appears in the diff or it does not; there is no undecidable state. Report `no`
    with the unfixed site whenever a site is absent from the diff.
  - Checks 2 and 3 default to `no` / `none` unless you can cite a concrete file:line
    in the applied code. Do not speculate, do not re-review the PR, do not report
  style issues.

self_heal_iter = 0
done_remaining = []
while self_heal_iter < 2:
    findings = run_parallel_review(diff="git diff HEAD")
    blockers = [f for f in findings if f.severity in ("Critical", "Serious")]
    if not blockers:
        break
    # Dispatch fresh subagent per blocker with the finding + the diff
    for f in blockers:
        apply_subagent_corrective_edits(f)
    run_fix_ts_errors()
    self_heal_iter += 1

# After loop: record whatever blockers remain (if any)
done_remaining = blockers

gh_status[idx] = {
  reply_state: landed | verified-existing | confirmed-absent | reconcile-required | skipped | not-applicable,
  reply_err:   <error message if any>,
  resolve_state: resolved | already-resolved | confirmed-open | reconcile-required | skipped | not-applicable,
  resolve_err: <error message if any>
}

if [ "$(git rev-parse -q --verify refs/stash)" = "$STASH_OID" ]; then
  if git stash apply "$STASH_OID"; then
    [ "$(git rev-parse -q --verify refs/stash)" = "$STASH_OID" ] && git stash drop || echo "STASH_CHANGED_MID_RESTORE"
  elif [ -n "$(git diff --name-only --diff-filter=U)" ]; then
    echo "STASH_CONFLICT"
  else
    echo "STASH_APPLY_FAILED"
  fi
else
  echo "STASH_TOP_MISMATCH"
fi

  - pattern: "<normalized pattern from finding: key phrase, not full text>"
    category: "<finding category if available>"
    file: "<finding's file path. Include only if the rationale is specific to one file, omit for generic patterns>"
    reason: "<dismiss/disagree rationale from triage>"
    added: <today's date YYYY-MM-DD>

suppressions:
  - pattern: ...

git push --force-with-lease="<exact-ref>:<expected-sha-or-empty>" "<preflighted-remote>" "<frozen-local-sha>:<exact-ref>"
git ls-remote --heads "<preflighted-remote>" "<exact-ref>"