ce-code-review 与 ce-resolve-pr-feedback

ce-code-review

代码评审技能对一个指定的 diff 或 PR 评审 bug、回归、测试与规范。执行骨架包含六个阶段。

ce-code-review 执行骨架。

评审深度门

三条路径：Lite / Focused / Full。只要任一底线触发就强制走 Full：

• 显式 depth:full
• Helper 命名的 hard_block_full（silent-pass 类、不可数可执行文件、规模带 large）
• 第 1c 阶段 criteria 搜索失败或范围不确定
• 应用授权（apply:local 或显式 apply 请求）

任何底线都不可被谈下来。Lite 与 focused 是门选出的路径；full 由底线强制。

评审政策（REVIEW.md）

评审政策是一份 REVIEW.md：告诉评审在这个仓库里怎么评——各级别在这里意味着什么、要跳过的路径或类别、minor 数量上限、某类发现需要什么证据、每次变更要跑什么检查。Claude Code Review 读同一个文件。

• 它不是 criteria 文件：既不提供 criteria 也不取代 criteria，第 1c 阶段的优先级会忽略它。
• 哪些文件生效：根 REVIEW.md 管这次变更整体；某个变更文件的祖先目录里的 REVIEW.md，对它下面的路径追加到根文件之上。
• 本次读到的每条政策来源都会记进结果的 review_policy.sources，产物路径记在 review_policy.path。

3d — 跨模型 peer

当变更足够有风险时，通过 scripts/cross-model-adversarial-review.sh（1,090 行）在 peer 模型上运行对抗评审。每条路由都走同一个被钉死的 acpx 传输（Agent Client Protocol 客户端，acpx@0.19.5，需 Node ≥ 22.13），不再各自接 peer CLI。路由令牌：codex | claude | grok-cli | grok-cursor | cursor | composer | opencode。peer 模型与推理档位由脚本内一张映射钉死：Codex 走 gpt-6-luna（xhigh，基准评测选出的档位；Sol 引脚用 gpt-6.1-sol），Claude 走 claude-opus-5-5（high），Grok 走 grok-4.7（xhigh；grok-cursor 用 Cursor 的 high/fast 预设），composer 走其 fast 档。peer 写入 <run-dir>/adversarial-<provider>.json。已启动的 peer 会替换本地对抗 persona；只有真正失败于范围、白名单、连通、鉴权或启动时，才会回退到本地。

运行原则

• 默认仅报告。进入 apply 需要 apply:local 或显式 apply 请求。mode:autofix 已弃用，被忽略。
• 绝不使用阻塞提问工具。这是明确的——ce-code-review 是本插件中唯一明确禁用 AskUserQuestion / request_user_input / ask_user 的技能。
• 绝不要 gh pr checkout / git checkout / git switch。一个 PR 引用选中评审范围，它并不授权切分支。
• 报告结果，而非机器流程。不要展示内部阶段名、派发簿记或初始化叙述。
• mode:agent 时输出 JSON。一个裸的 JSON 对象——不要用 ```json 围栏（围栏会破坏朴素的 JSON.parse）。PR 范围带 head 引用对照：gh pr view 取回的 headRefOid 是权威头，本地评审树必须包含该 commit（git merge-base --is-ancestor <headRefOid> HEAD）；按 ref 拉取的远端头只有在解析出的 OID 与元数据一致时才交给评审者——跨仓 PR 上同名的无关分支、或 PR 在元数据调用与 fetch 之间移动，都会让 fetch 成功却不等于 PR head；对不上时评审者只靠 diff hunks，并在 Coverage 里注明。

快速评审短路

如果调用参数表明用户想要"quick / fast / light"，且未启用 mode:agent，则路由到宿主内置评审（一次工具调用）并停止。mode:agent 绕过此短路。

JSON 输出结构

  {
    status: "complete" | "failed" | "degraded" | "skipped",
    verdict: "Ready to merge" | "Ready with fixes" | "Not ready",
    scope: { base, branch, head_sha, pr_url, files_changed },
    intent, intent_confidence, reviewers, findings,
    actionable_findings, triage_groups,
    pre_existing_findings, requirements_completeness,
    learnings, agent_native_gaps, deployment_notes,
    residual_risks, testing_gaps,
    review_policy: { path: "<run-dir>/review-policy.md or null", sources: ["<读到的每条 REVIEW.md 路径>"] },
    coverage: { depth: "lite|focused|full" },
    artifact_path, run_id
  }

锚定的置信度（0 / 25 / 50 / 75 / 100），不使用连续的浮点数。每条 finding 在至少两位 reviewer 独立触达时带 independence_verified: true。

ce-resolve-pr-feedback

处理 PR 上留下的反馈——内联评审线程、评审提交正文、顶层 PR 评论。编排器（本技能）判断合法性；子代理只实现已被批准的修复。

模式检测

只有 #discussion_r... 走 Targeted。把 #issuecomment-... 发到 Targeted 端点会 404。

Full 模式：9 步

1. 拉取未解决线程，通过 scripts/get-pr-comments（GraphQL 分页；GHE 需要内联 GH_HOST=）。
2. 分流——把新的与 pending / resolution-pending / 非可执行的分开。pending_review 非空 → 停止（在草稿提交前回复将不可见）。
3. 整合与决策——编排器在同一个上下文中带着所有线程判断合法性。应用评估量表。把每项归入 fix-list / reply-list / human-list。human-list 中「判断型」的项先由编排器自身裁决（见下方评估量表的「先裁决，再升级」）：裁决出立场且动作在授权范围内的，按其裁定的 verdict 归类落地；只有裁不动或越权的才真正升级。
4. 修复——并行派发 fixer（仅针对 fix-list 项）。把 references/agents/pr-comment-resolver.md 作为 fixer prompt 给每个 fixer 注入。1–4 个 fixer 并行；多于 4 个则分批，每批 4 个。触碰同一文件的两个 fixer 不得并行。
5. 校验合并后状态——对所有 fixer 改动运行一次项目的完整校验。触红则针对触及文件内联重跑；未触红则视为预先存在（在 commit message 中注明）。
6. 提交与发布归属——只提交 change set（git add <files>; git commit -m "Address PR review feedback (#PR)"）。普通与 pipeline 模式在进入远端尾部前先 git push 发布；mode:return-to-caller 不推送——把修复 commit SHA 与整条远端尾部（回复、解决、checklist 勾选）存进交接记录，交由调用方发布；mode:resume 在调用方已发布后接管收尾——经 scripts/pending-feedback.py inspect-publication 对照记录的 fix SHA 与远端实际 head（fork PR 与 Enterprise 主机同样适用），只有 publication.verified: true 才进入远端尾部，且不再重跑判断、编辑或修复。resolver 从不替人撰写或提交评审草稿。
7. 回复并解决——对每一条已处理项，发布回复（带引用的上下文）并通过 GraphQL 解决线程。同 class 项的回复要发到每一条被覆盖的线程，不能只发第一条。
8. 验证——重新拉取；检查是否清空（减去 needs-human）。第 3 轮 = 停止并展示模式。
9. 汇总——按 verdict 计数、校验结果；如有则附 ## Needs Needs your decision 段。Declined 行要分别点名因越界而拒的项，方便用户把它们带走；没有代码提交时省略校验行与 Diff change 行，有提交时 Diff change 用 git diff --shortstat 给出本次首个 fix commit 之前的 head 到最后一个之后的 head 的增删行数。

评估量表（编排器的判断）

在任何 fix 派发之前应用：

• 默认修复。大多数反馈是正确的、值得修的。P0–P2 吹毛求疵也算。无论 bot 还是人、形式如何，按价值判断。
• 指令性散文不是代码。对于 SKILL.md / persona prompt / runbook / 规则文件这类目标：已被条件判定的情形不是一项要修的缺陷——以 not-addressing 引用该条件，只修条件或只动所在层。若第二轮再次命中同一段，合并为一条 class 项并重写。
• 读多深。明显的吹毛求疵 = diff + 评论就够。可争议的发现 = 深读调用方、不变量、git blame、作者意图。
• 按根假设聚类。同一 reviewer 在一处错，对其他同类条目也值得怀疑。请求汇聚 = 强修复信号。
• Class fix：当一个根假设横跨本 PR 引入的多个点时启用。在一条 fix-list 项中枚举所有点。
• 命中此前评审修复新增的代码：先查该行是否来自本分支更早的 review-fix commit（git log / git blame）。是的话，这条发现与那次修复共享「失败需要更多代码」的前提——按「已有东西兜住该失败」裁：已兜住就不加层，回复点名那次修复。
• 先裁决，再升级。触发引开的项按「缺的是什么」二分，只有一类真正到人：
  • 权限受限——需要本次运行不持有的权限或知识：安全、鉴权、计费、数据保留、迁移、另一系统、产品 / 业务判断、超出继承授权范围的动作（merge、rebase、force-push、批 CI）、只有用户知道的意图。保持 needs-human，不裁决。
  • 判断受限——有经验的工程师可能合理分歧，且裁决依赖的全部事实都在仓库、PR 与评审线程里：被要求反转的深思熟虑选择、两位 reviewer 要求相反、更多证据才能定界的风险读法、pipeline 下的不收敛根因。先把 decision_context 组成选项集交给 ce-pov（要求 oracle 跨模型面板；无 peer 可达时退化为单模型判断），按每个根决策裁决一次，绝不给没触发引开的项裁决，「拿不准」仍按修复处理。
  裁决出立场且动作在授权范围内 → 按其裁定的普通 verdict（fixed / fixed-differently / declined / replied）落地，回复带上推理、按产品名点名共识/分歧/未运行的 peer（例如 Codex、Grok，绝不写模型版本或 ID）、说明这是自主裁定（作者可事后翻案）；因为这条回复在每个模式里都随 verdict 一起发出，调用方也由此得知哪些 peer 真正跑了。blocked、无立场、动作越权或 ce-pov 在本宿主不可用 → needs-human，并把裁决所得折进 decision_context（调查入 investigation、立场入 recommendation）。
• 引开：
  • 站不住脚 → not-addressing，附证据。
  • 已不再相关 → not-addressing。
  • 会让代码变差 → declined，附引用伤害。
  • 真实但超出本 PR 的目的 → declined，点名目的并留给独立变更。PR 的目的以描述、关联 issue 或计划为准；都没有时，就是这个 diff 改了什么。在 PR 编辑的文件里提出但会新增/改变 PR 未打算改的行为（兄弟代码路径、另一模块的同类问题、新选项或兼容模式、给 PR 没碰的行为补测试）都算越界。改坏的代码与改动在别处造成的破坏在目的之内；人工评审明确要求把更大的改动放进本 PR，就以他设定的范围为准。安全、数据丢失、不可逆效应的发现永不以越界为由 declined——它落在 PR 不改的代码上时是 needs-human。
  • 无实际收益 → 简短 replied。
  • 已有东西兜住该失败 → 发现为真，但失败在造成代价前就会被现有信号暴露——dry run / 预览、响亮报错并停机、使用前会被核对的结果——且能点名是什么在兜 → replied 点名该信号；一个小改动能把信号变清晰（一行用法、更好的 dry-run 报文）则 fixed-differently 并做出该改动。「它很小」「它很少跑」不点名任何东西。代价先落地（数据丢失 / 资金 / 权限错发），或触及安全、鉴权、计费、数据保留、迁移、不可逆外部效应时不适用。
  • 有风险且无界 → 降险（读调用方、加测试）；仍有风险则 needs-human。
  • 撤销一个深思熟虑的设计选择（罕见；需要正向意图证据 + 真正的分歧）→ 先经下方「先裁决，再升级」，裁不动才 needs-human。
  • 这是问题，不是变更 → replied 或 needs-human。

SKILL.md 正文按 Codex 8000 字节预算瘦身（当前约 7.9 KB），判断规则全部下沉到 references/evaluation-rubric.md 与各模式参考文件。

Pipeline 模式

当以 mode:pipeline 调用（来自 ce-babysit-pr）时：

• 永不阻塞提问工具。把 needs-human 挂在该线程上 + 自然回复 + 作为结构化残余返回。
• 越线时传入 trajectory。若 invariant_rounds[]. = 2，改用一条方法层面的 needs-human 答复，而不是逐条小修。
• 返回的 needs-human 决策进入一个持久集合；调用方解析它用于 ## Needs Needs your decision 段。
• 状态枚举：needs-human 是规范字符串之一；绝不要改名。

Targeted 模式（2 步）

1. 从 URL 抽取线程上下文（scripts/get-thread-for-comment）。
2. 通过同一流水线进行判断 / 修复 / 回复 / 解决。不要拉取其他线程。

Pending review 陷阱

若步骤 1 时 pending_review 非空，停止。在你持有一份未提交评审期间，线程回复会被吞进那份草稿：回复调用会像成功一样返回一个 comment ID 与 URL，但在评审者提交草稿前什么也看不到。告诉用户有一份未提交评审；不要自行提交或丢弃。