@fitlab-ai/agent-infra 0.11.5 → 0.11.7

package/templates/.agents/skills/plan-task/SKILL.zh-CN.md

@@ -21,7 +21,7 @@ description: >
 
 生成方案报告时，先读取 `.agents/rules/evidence-reporting.md`。状态核对和验证记录命令、目标范围、状态/结构化结果、实际结果和未覆盖部分；失败、阻塞或争议才附决定性原文摘录。
 
-- 涉及候选资格或 `HD-N` 判断时，先读取 `.agents/rules/decision-qualification.md`，基于 task.md 规范化约束/候选完成资格审计，并在方案产物记录五张资格审计表；不得把来源不明或未确认约束自动升级为排除条件
+- 涉及候选资格或 `HD-N` 判断时，先读取 `.agents/rules/decision-qualification.md`，基于 task.md 规范化约束/候选完成资格审计，并在方案产物记录三张资格审计决策表和资格快照；不得把来源不明或未确认约束自动升级为排除条件
 - 本技能仅产出技术方案文档（`plan.md` 或 `plan-r{N}.md`）—— 不修改任何业务代码
 - 生成会同步到 Issue 的任务或生命周期 Markdown 前，先读取 `.agents/rules/sync-content-generation.md` 并遵循其中的生成端约束；同步端不解析或改写正文
 - 完整路径进入方案审查；标准路径完成方案后可直接进入实现阶段
@@ -92,7 +92,7 @@ agent-infra-internal task-event {task-id} plan.started --agent {standard-agent-t
 
 ### 5. 设计技术方案
 
-方案必须按 `.agents/rules/decision-qualification.md` 复核规范化约束和候选，并在方案产物保留五张资格审计表及真实上游关系；来源不明或未人工确认的约束不得自动排除候选。
+仅当方案阶段实际判断候选资格、约束依赖或人工裁决资格时，才按 `.agents/rules/decision-qualification.md` 复核规范化约束和候选，并在方案产物记录完整资格审计；否则省略整个审计段。来源不明或未人工确认的约束不得自动排除候选。
 
 遵循 `.agents/workflows/feature-development.yaml` 中的 `technical-design` 步骤：
 
@@ -160,7 +160,7 @@ agent-infra-internal task-verify {task-id} plan.completed --artifact {plan-artif
 - 退出码 1（校验失败）-> 根据输出修复问题后重新运行校验
 - 退出码 2（网络中断）-> 停止执行并告知用户需要人工介入
 
-将校验输出保留在回复中作为当次验证输出。没有当次校验输出，不得声明完成。
+按 `.agents/rules/validation-output.md` 展示当次校验摘要；没有当次校验输出，不得声明完成。
 
 ### 9. 告知用户
 

package/templates/.agents/skills/review-analysis/SKILL.en.md

@@ -23,7 +23,7 @@ This stage consumes only the canonical path fact parsed by core from the latest
 
 Before generating the review report, read `.agents/rules/evidence-reporting.md`. Normal inspection records the command, scope, structured result, actual conclusion, and uncovered parts; findings, blocking conditions, or disputes retain reproducible locations and decisive excerpts, while identity fields remain exact.
 
-- When reviewing candidate qualification or `HD-N`, read `.agents/rules/decision-qualification.md` and check the five qualification-audit tables, digests, QCR, and upstream relations; do not treat a process label as identity authentication
+- When reviewing candidate qualification or `HD-N`, read `.agents/rules/decision-qualification.md` and check the three qualification-audit decision tables, snapshot, digests, and QCR; do not treat a process label as identity authentication
 - This skill only reviews analysis artifacts and writes a report; it does not modify product code.
 - Before generating task or lifecycle Markdown that will be synchronized to an Issue, read `.agents/rules/sync-content-generation.md` and apply its producer-side constraints; the sync path does not parse or rewrite the body
 - After executing this skill, you **must** immediately update task.md.
@@ -111,6 +111,8 @@ Before writing the summary, the finalization intent checks decision-detail ids;
 agent-infra-internal task-verify {task-id} review-analysis.completed --artifact {review-artifact} --format text
 ```
 
+Present the verification summary per `.agents/rules/validation-output.md`, retaining necessary failure, blocked, and soft-warning diagnostics.
+
 ### 8. Tell the User
 
 Use the conclusion branch in `reference/output-templates.md` and render the selected next-step commands through the shared helper.

package/templates/.agents/skills/review-analysis/SKILL.zh-CN.md

@@ -23,7 +23,7 @@ description: >
 
 生成审查报告时，先读取 `.agents/rules/evidence-reporting.md`。正常检视记录命令、范围、结构化结果、实际结论和未覆盖部分；finding、阻塞或争议保留可复现位置与决定性摘录，身份字段必须精确保留。
 
-- 审查候选资格或 `HD-N` 判断时，先读取 `.agents/rules/decision-qualification.md`，逐项复核产物中的五张资格审计表、digest、QCR 和上游关系；不得把流程标签当作身份认证
+- 审查候选资格或 `HD-N` 判断时，先读取 `.agents/rules/decision-qualification.md`，逐项复核产物中的三张资格审计决策表、资格快照、digest 和 QCR；不得把流程标签当作身份认证
 - 本技能只审查分析产物并写报告，不修改业务代码
 - 生成会同步到 Issue 的任务或生命周期 Markdown 前，先读取 `.agents/rules/sync-content-generation.md` 并遵循其中的生成端约束；同步端不解析或改写正文
 - 执行本技能后，你**必须**立即更新 task.md
@@ -114,6 +114,8 @@ agent-infra-internal task-artifact {task-id} init --family review-analysis --art
 agent-infra-internal task-verify {task-id} review-analysis.completed --artifact {review-artifact} --format text
 ```
 
+按 `.agents/rules/validation-output.md` 展示当次校验摘要；失败、阻塞和软警告保留必要诊断。
+
 校验通过后继续告知用户；校验失败则修复报告或 task 状态后重跑。
 
 ### 8. 告知用户

package/templates/.agents/skills/review-analysis/reference/report-template.en.md

@@ -26,7 +26,7 @@ Use this template when writing `review-analysis.md` or `review-analysis-r{N}.md`
 
 ## Qualification Audit Review
 
-> Use `.agents/rules/decision-qualification.md` to review the five tables: constraint dependencies, candidate qualification, classification results, upstream relations, and dependency snapshot.
+> Include this section only when this stage actually reviews candidate qualification, constraint dependencies, or human-decision eligibility. In that case, review all three decision tables and the qualification snapshot per `.agents/rules/decision-qualification.md`; otherwise omit this section entirely.
 
 ### Constraint Dependencies
 | constraint_id | constraint_digest | role | evidence |
@@ -40,13 +40,9 @@ Use this template when writing `review-analysis.md` or `review-analysis-r{N}.md`
 | decision_id | classification | evidence |
 | --- | --- | --- |
 
-### Upstream Relations
-| upstream_family | upstream_artifact | upstream_round | upstream_sha256 | relation |
-| --- | --- | --- | --- | --- |
-
-### Dependency Snapshot
-| task_input_digest | non_constraint_input_digest | upstream_artifact_digest |
-| --- | --- | --- |
+### Qualification Snapshot
+| task_input_digest | non_constraint_input_digest |
+| --- | --- |
 
 ## Inspection Coverage
 

package/templates/.agents/skills/review-analysis/reference/report-template.zh-CN.md

@@ -26,7 +26,7 @@
 
 ## 资格审计复核
 
-> 按 `.agents/rules/decision-qualification.md` 复核：约束依赖、候选资格、分类结果、上游关系和依赖快照五张表。
+> 仅当本阶段实际复核了候选资格、约束依赖或人工裁决资格时填写本节，并按 `.agents/rules/decision-qualification.md` 完整复核三张决策表和资格快照；否则删除整个审计段。
 
 ### 约束依赖
 | constraint_id | constraint_digest | role | evidence |
@@ -40,13 +40,9 @@
 | decision_id | classification | evidence |
 | --- | --- | --- |
 
-### 上游关系
-| upstream_family | upstream_artifact | upstream_round | upstream_sha256 | relation |
-| --- | --- | --- | --- | --- |
-
-### 依赖快照
-| task_input_digest | non_constraint_input_digest | upstream_artifact_digest |
-| --- | --- | --- |
+### 资格快照
+| task_input_digest | non_constraint_input_digest |
+| --- | --- |
 
 ## 检视覆盖声明
 

package/templates/.agents/skills/review-code/SKILL.en.md

@@ -23,7 +23,7 @@ This stage consumes only the canonical path fact parsed by core from the latest
 
 Before generating the review report, read `.agents/rules/evidence-reporting.md`. Normal inspection records the command, scope, structured result, actual conclusion, and uncovered parts; findings, blocking conditions, or disputes retain reproducible locations and decisive excerpts, while identity fields remain exact.
 
-- When reviewing candidate qualification or `HD-N`, read `.agents/rules/decision-qualification.md` and check the five qualification-audit tables, digests, QCR, and upstream relations; do not treat a process label as identity authentication
+- When reviewing candidate qualification or `HD-N`, read `.agents/rules/decision-qualification.md` and check the three qualification-audit decision tables, snapshot, digests, and QCR; do not treat a process label as identity authentication
 - This skill reviews code and writes a report; it does not modify product code
 - Before generating task or lifecycle Markdown that will be synchronized to an Issue, read `.agents/rules/sync-content-generation.md` and apply its producer-side constraints; the sync path does not parse or rewrite the body
 - After executing this skill, you **must** immediately update task.md
@@ -67,30 +67,29 @@ After resolving the artifact context and before this round's first artifact acti
 
 Require:
 - `.agents/workspace/active/{task-id}/task.md`
-- at least one code artifact: `code.md` or `code-r{N}.md`
+- a resolvable task branch and Git review target. Implementation artifacts are optional context and must not gate review eligibility.
 
 ### 2. Resolve the Artifact Context
 
-Run `agent-infra-internal task-artifact {task-id} inspect --family review-code`. Continue only for `ready`. When `selection.disposition` is `reuse`, reuse `selection.artifact`, do not run started/init or write a new artifact, and continue directly to completion verification and next-step guidance. Otherwise take the latest `{code-artifact}` from `inputs` and `{review-round}` / `{review-artifact}` from `next.round` / `next.name`. Do not scan rounds or construct names in the skill. Then run the started event and verify the returned identity.
+Run `agent-infra-internal task-artifact {task-id} inspect --family review-code`. Continue only for `ready`. When `selection.disposition` is `reuse`, reuse `selection.artifact`, do not run started/init or write a new artifact, and continue directly to completion verification and next-step guidance. Otherwise take any available latest `{code-artifact}` and `{plan-artifact}` from `inputs`, and `{review-round}` / `{review-artifact}` from `next.round` / `next.name`. Do not scan rounds or construct names in the skill. If no code or plan artifact exists, review the Git diff and record the missing context in the report. Then run the started event and verify the returned identity.
 
 ### 3. Read Implementation and Refinement Context
 
-Read the highest-round code artifact and, if present, the highest-round fix artifact. After reading, record the actually reviewed highest-round code artifact (and the highest-round fix artifact, if present) by filename in the report's `Review Input` field; leave it blank when it cannot be reliably determined—do not fabricate.
+Read the available code and plan context returned in step 2. Record the artifact filenames actually read in the report's `Review Input` field; identify missing context without fabricating an artifact. When no implementation artifact exists, review the Git diff as the review subject.
 
 ### 4. Perform the Review
 
-Follow `.agents/workflows/feature-development.yaml` and inspect the full change context:
+Follow `.agents/workflows/feature-development.yaml` and inspect the full change context. HD-1 decided that changes within the reviewed scope must be committed first: before writing the started event, check the post-review paths and stop with an actionable commit instruction when tracked or untracked changes remain. Do not create a review report for a dirty reviewed scope. Bind the report identity to the exact HEAD of a clean worktree:
 - Resolve the task's bound delivery remote/base and read the target SHA once at review start, `M=$(git ls-remote --refs {remote} refs/heads/{baseRef})`; then capture the reviewed commit `R=$(git rev-parse HEAD)` once and compute `D=$(git merge-base "$R" "$M")`. Save M/D/R as historical evidence and never overwrite them with a later live target value
 - If the delivery target cannot be resolved or its target commit is unavailable, stop and record the target error; M/D/R must come from one fact-collection round and must not be replaced by PR-existence evidence
-- `git diff --binary "$D" -- <post-review-globs>` covers committed and uncommitted tracked changes from D to the current worktree
-- `git ls-files -o --exclude-standard -z -- <post-review-globs>` for untracked new files
-- Write `mode=worktree`, `baseline=R`, and `diffBase=D` to a temporary JSON file, then call `agent-infra-internal git-workflow snapshot --input {file}` to generate a reviewed diff fingerprint `F` for the complete committed range and a reviewed snapshot tree `T` for the current worktree; write M, R, D, F, and T into the report
+- `git diff --binary "$D" "$R" -- <post-review-globs>` covers committed tracked changes from D to R; commit any uncommitted or untracked reviewed paths before starting, as required by HD-1
+- Write `mode=worktree`, `baseline=R`, and `diffBase=D` to a temporary JSON file, then call `agent-infra-internal git-workflow snapshot --input {file}` to generate a reviewed diff fingerprint `F` for the committed range and a snapshot tree `T`; write M, R, D, F, and T into the report
 
 > After collecting those facts, read `.agents/rules/review-method.md`, use them as readiness evidence, and run Passes 2–5 for traceability, risk lenses, counterevidence, and classification; the report must record all five passes.
 > Detailed review criteria, severity rules, and reviewer expectations live in `reference/review-criteria.md`. Read `reference/review-criteria.md` before reviewing.
 
 Apply the shared five-pass protocol to code in this order:
-- Pass 1 reads the complete diff, untracked files, latest code artifact, approved plan/review-plan, task source, and raw test results.
+- Pass 1 reads the complete diff, any available code/plan artifacts, task source, and raw test results; when code or plan context is missing, record that gap and continue with the Git diff.
 - Pass 2 maps acceptance/plan → implementation → verification and records changed lines, necessary callers/callees, state/data flow, and uncovered areas per file.
 - Pass 3 reviews overall design before per-file semantics, evaluates every shared registry trigger, and reads every matched reference in full. Test changes load `.agents/rules/testing-discipline.md` through the registry's `testing-discipline` lens; do not maintain a second trigger list.
 - Pass 4 checks guards, call constraints, test coverage, and narrower impact boundaries as counterevidence.
@@ -129,7 +128,7 @@ Update task.md:
 
   The intent atomically finalizes the report summary and returns the same ledger snapshot. Do not call `stage-status`, replace placeholders manually, or rescan the finding list. After a failure, the model may edit the same controlled artifact and rerun the same intent only when the shared rule's mechanical gates pass; reassess convergence after every failure. The final complete result determines the verdict and counts from that same snapshot: `stageStatus.canAdvance=true` with an Approved conclusion permits cross-stage advancement; `stageStatus.canAdvance=false` still requires `agent-infra-internal task-event {task-id} review-code.completed --agent {standard-agent-token} --initiator {trigger-initiator} --request-id {request-id} --reason-code {reason-code} --artifact {review-artifact} --verdict {approved|changes-requested|rejected} --blockers {unresolved-blockers} --major {unresolved-major} --minor {unresolved-minor} --manual-validation {n} {execution-flag}`, using `changes-requested` and routing to same-stage revision/review (use `rejected` when the report explicitly rejects). On failure, model stop, lack of progress, or the emergency cap, do not publish a completion event or cross-stage command; use the `repair-stop` scenario in `reference/output-templates.md` to show existing summary/findings, the artifact, actual repair attempts, the last diagnostic, and the stop reason
 - Only when `canAdvance=true`, the verdict is Approved, and `T == R^{tree}`, write `last_reviewed_commit: {R}`. Clear an old value for an Approved snapshot with uncommitted differences; otherwise preserve the existing value and do not advance it
-- For an Approved exit, collect PR and all-check facts as defined in `reference/output-templates.md`: route uncommitted/unpushed code to `commit`, no PR to `create-pr` (except no-PR flow), non-terminal checks to `watch-pr`, and route to `complete-task` only when `HEAD == last_reviewed_commit == PR head` with checks `passed|no-required`; never route by review round alone
+- For an Approved exit, use `reference/output-templates.md` to select one branch and its `agent-client next-steps` helper to generate the next command.
 - After handling `last_reviewed_commit`, run `agent-infra-internal task-event {task-id} review-code.completed --agent {standard-agent-token} --initiator {trigger-initiator} --request-id {request-id} --reason-code {reason-code} --artifact {review-artifact} --verdict {approved|changes-requested|rejected} --blockers {unresolved-blockers} --major {unresolved-major} --minor {unresolved-minor} --manual-validation {n} {execution-flag}`
 
 Always include the `Manual-validation: {n}` field in the done log, including when it is 0.
@@ -150,6 +149,8 @@ Run the verification gate to confirm the task artifact and sync state are valid:
 agent-infra-internal task-verify {task-id} review-code.completed --artifact {review-artifact} --format text
 ```
 
+Present the verification summary per `.agents/rules/validation-output.md`, retaining necessary failure, blocked, and soft-warning diagnostics.
+
 Handle the result as follows:
 - exit code 0 (all checks passed) -> continue to the "Inform User" step
 - exit code 1 (validation failed) -> fix the reported issues and run the gate again
@@ -161,7 +162,7 @@ Keep the gate output in your reply as fresh evidence. Do not claim completion wi
 
 > Execute this step only after the verification gate passes.
 
-> **Important — branch labels are not values for the verdict field**. The four labels below are user-output template categories (scenarios A/B/C/D), **not** values for the `**Overall Verdict**:` field. The field accepts exactly one of the three canonical values (`Approved` / `Changes Requested` / `Rejected`, or zh-CN `通过` / `需要修改` / `拒绝`); combined phrases like `Approved with issues` will be rejected by the verify gate.
+> **Important — scenario labels are not values for the verdict field**. A/B/C are result scenarios; R displays existing results when lifecycle finalization stops. None are values for the `**Overall Verdict**:` field, which accepts exactly one of the three canonical values (`Approved` / `Changes Requested` / `Rejected`, or zh-CN `通过` / `需要修改` / `拒绝`).
 
 Choose exactly one branch based on the findings:
 - `stageStatus.canAdvance=true` -> approved
@@ -170,7 +171,7 @@ Choose exactly one branch based on the findings:
 
 manual-validation counts do not influence branch selection; they are displayed only as manual validation counts.
 
-> The full four-branch output templates, selection rules, and prohibition clauses live in `reference/output-templates.md`. Read `reference/output-templates.md` before reporting the review result.
+> The A/B/C output templates, selection rules, and prohibition clauses live in `reference/output-templates.md`. Read `reference/output-templates.md` before reporting the review result.
 
 > Before rendering the final output, read `.agents/rules/next-step-output.md` and apply both of its rules: (1) render `{task-ref}` in the "Next steps" commands as the current task's short id `NN` (see that file for lookup and fallback), while other `{task-id}` placeholders (report titles, paths) keep the full TASK-id form; (2) append the `Completed at` line as the very last line of the user-facing output (this applies to every user-facing output — success, error, and early-return paths alike, not only the success path).
 

package/templates/.agents/skills/review-code/SKILL.zh-CN.md

@@ -23,7 +23,7 @@ description: >
 
 生成审查报告时，先读取 `.agents/rules/evidence-reporting.md`。正常检视记录命令、范围、结构化结果、实际结论和未覆盖部分；finding、阻塞或争议保留可复现位置与决定性摘录，身份字段必须精确保留。
 
-- 审查候选资格或 `HD-N` 判断时，先读取 `.agents/rules/decision-qualification.md`，逐项复核产物中的五张资格审计表、digest、QCR 和上游关系；不得把流程标签当作身份认证
+- 审查候选资格或 `HD-N` 判断时，先读取 `.agents/rules/decision-qualification.md`，逐项复核产物中的三张资格审计决策表、资格快照、digest 和 QCR；不得把流程标签当作身份认证
 - 本技能只审查代码并写报告，不修改业务代码
 - 生成会同步到 Issue 的任务或生命周期 Markdown 前，先读取 `.agents/rules/sync-content-generation.md` 并遵循其中的生成端约束；同步端不解析或改写正文
 - 执行本技能后，你**必须**立即更新 task.md
@@ -66,24 +66,23 @@ agent-infra-internal task-snapshot {task-id} --format text
 
 要求存在：
 - `.agents/workspace/active/{task-id}/task.md`
-- 至少一个实现产物：`code.md` 或 `code-r{N}.md`
+- 可解析的任务分支与 Git 审查目标。实现产物属于可选上下文，不得作为审查资格门槛。
 
 ### 2. 解析审查上下文
 
-运行 `agent-infra-internal task-artifact {task-id} inspect --family review-code`。仅当结果为 `ready` 时继续。若 `selection.disposition` 为 `reuse`，复用 `selection.artifact`，不得执行 started、init 或写入新产物，并直接进入完成校验与下一步提示。其他状态从 `inputs` 取得最新 `{code-artifact}`，从 `next.round` / `next.name` 取得 `{review-round}` / `{review-artifact}`；不得自行扫描轮次或拼装文件名。随后执行 started 事件并复核返回身份。
+运行 `agent-infra-internal task-artifact {task-id} inspect --family review-code`。仅当结果为 `ready` 时继续。若 `selection.disposition` 为 `reuse`，复用 `selection.artifact`，不得执行 started、init 或写入新产物，并直接进入完成校验与下一步提示。其他状态从 `inputs` 读取可用的最新 `{code-artifact}` 和 `{plan-artifact}`，从 `next.round` / `next.name` 取得 `{review-round}` / `{review-artifact}`；不得自行扫描轮次或拼装文件名。若没有 code 或 plan artifact，直接审查 Git 差异，并在报告中说明缺少的上下文。随后执行 started 事件并复核返回身份。
 
 ### 3. 阅读实现与修复上下文
 
-读取步骤 2 返回的最新 `{code-artifact}`。读取后，把本轮实际检视的 code artifact 按文件名回填到报告 `审查输入` 段；无法可靠取得时留空，不要伪造。
+读取步骤 2 返回的可用 code 与 plan 上下文。把实际读取的 artifact 文件名写入报告 `审查输入` 段；未提供的 artifact 说明为缺失，不要伪造。实现产物缺失时，仍以 Git 审查差异作为审查对象。
 
 ### 4. 执行审查
 
-遵循 `.agents/workflows/feature-development.yaml`，并同时检查完整变更上下文：
+遵循 `.agents/workflows/feature-development.yaml`，并同时检查完整变更上下文。HD-1 已裁定受审范围内的改动必须先提交：在声明 started 前检查 post-review 路径；存在已跟踪或未跟踪改动时停止并提示先提交，不创建审查报告。报告身份必须绑定干净工作树的确切 HEAD commit：
 - 在审查开始时解析任务绑定的 delivery remote/base，并一次性读取目标分支 SHA `M=$(git ls-remote --refs {remote} refs/heads/{baseRef})`；随后一次性记录审查提交 `R=$(git rev-parse HEAD)`，计算 `D=$(git merge-base "$R" "$M")`。报告保存 M/D/R，不能用后续实时目标值覆盖本轮历史证据
 - 若 delivery target 无法解析或目标 commit 不可用，停止并记录 target 错误；M/D/R 必须来自同一轮事实采集，不以 PR 是否存在替代 delivery target 证据
-- `git diff --binary "$D" -- <post-review-globs>` 覆盖 `D` 到当前工作区的已提交与未提交跟踪变更
-- `git ls-files -o --exclude-standard -z -- <post-review-globs>` 覆盖未跟踪新文件
-- 把 `mode=worktree`、`baseline=R`、`diffBase=D` 写入临时 JSON，调用 `agent-infra-internal git-workflow snapshot --input {file}` 一次生成覆盖完整提交范围的审查差异指纹 `F` 与当前工作区审查快照树 `T`；把 M、R、D、F、T 全部写入报告
+- `git diff --binary "$D" "$R" -- <post-review-globs>` 覆盖 `D` 到 `R` 的已提交跟踪变更；未提交或未跟踪的受审路径按 HD-1 先提交后再开始审查
+- 把 `mode=worktree`、`baseline=R`、`diffBase=D` 写入临时 JSON，调用 `agent-infra-internal git-workflow snapshot --input {file}` 一次生成已提交范围的审查差异指纹 `F` 与快照树 `T`；把 M、R、D、F、T 全部写入报告
 
 > 上述事实采集完成后，先读取 `.agents/rules/review-method.md`，以其作为 readiness 证据并按 Pass 2–5 完成追踪、风险镜头、反证和归类；报告必须记录全部五遍覆盖。
 > 详细审查标准、严重程度划分和 reviewer 关注点见 `reference/review-criteria.md`。执行此步骤前先读取 `reference/review-criteria.md`。
@@ -127,7 +126,7 @@ agent-infra-internal task-artifact {task-id} init --family review-code --artifac
 
   该 intent 原子最终化报告摘要并返回同一次账本快照；不得再调用 `stage-status`、手工替换占位符或扫描问题清单。失败后，模型只能在共享规则的机械安全门通过时修改同一个受控 artifact，并完整重跑相同 intent；每次失败都重新判断是否收敛。最终一次完整成功返回决定同一快照的 verdict 和计数：`stageStatus.canAdvance=true` 且结论为 Approved 时允许跨阶段推进；`stageStatus.canAdvance=false` 时仍须执行 `agent-infra-internal task-event {task-id} review-code.completed --agent {standard-agent-token} --initiator {trigger-initiator} --request-id {request-id} --reason-code {reason-code} --artifact {review-artifact} --verdict {approved|changes-requested|rejected} --blockers {unresolved-blockers} --major {unresolved-major} --minor {unresolved-minor} --manual-validation {n} {execution-flag}`，使用 `changes-requested` 并路由到同阶段修订/复审（报告明确拒绝时使用 `rejected`）。失败、模型停止、无进展或紧急熔断时，不发布完成事件或跨阶段命令，但必须按 `reference/output-templates.md` 的 `repair-stop` 场景展示已有 summary/findings、artifact、实际修复次数、最后诊断和停止原因
 - 仅当 `canAdvance=true`、本轮结论为 Approved 且 `T == R^{tree}` 时写入 `last_reviewed_commit: {R}`；Approved 快照包含未提交差异时清除旧值。否则保留既有值，不得推进或清空
-- Approved 出口继续按 `reference/output-templates.md` 采集 PR 与全部 checks 事实：未提交/未推送走 `commit`，无 PR 走 `create-pr`（无 PR 流程除外），checks 未终态走 `watch-pr`，仅 `HEAD == last_reviewed_commit == PR head` 且 checks 为 `passed|no-required` 时走 `complete-task`；不得仅按审查轮次分流
+- Approved 出口按 `reference/output-templates.md` 选择唯一场景，并使用对应的 `agent-client next-steps` helper 生成下一步命令。
 - 完成 `last_reviewed_commit` 处理后执行 `agent-infra-internal task-event {task-id} review-code.completed --agent {standard-agent-token} --initiator {trigger-initiator} --request-id {request-id} --reason-code {reason-code} --artifact {review-artifact} --verdict {approved|changes-requested|rejected} --blockers {unresolved-blockers} --major {unresolved-major} --minor {unresolved-minor} --manual-validation {n} {execution-flag}`
 
 完成日志必须始终写入 `Manual-validation: {n}` 字段，0 也保留。
@@ -153,13 +152,13 @@ agent-infra-internal task-verify {task-id} review-code.completed --artifact {rev
 - 退出码 1（校验失败）-> 根据输出修复问题后重新运行校验
 - 退出码 2（网络中断）-> 停止执行并告知用户需要人工介入
 
-将校验输出保留在回复中作为当次验证输出。没有当次校验输出，不得声明完成。
+按 `.agents/rules/validation-output.md` 展示当次校验摘要；没有当次校验输出，不得声明完成。
 
 ### 8. 告知用户
 
 > 仅在校验通过后执行本步骤。
 
-> **重要：分支名 ≠ 字段值**。以下 4 个标签是用户输出模板的分类（场景 A/B/C/D），**不是**产物 `**总体结论**：` 字段的取值。产物字段只取 3 个规范值之一（`通过` / `需要修改` / `拒绝`，或 EN 对应 `Approved` / `Changes Requested` / `Rejected`）；写成 `通过但有问题`、`通过 / 需要修改` 等组合短语会被 verify gate 拦下。
+> **重要：场景名 ≠ 字段值**。以下 A/B/C 是结果输出场景，R 只展示生命周期停止时已有的结果；它们都不是产物 `**总体结论**：` 字段的取值。产物字段只取 3 个规范值之一（`通过` / `需要修改` / `拒绝`，或 EN 对应 `Approved` / `Changes Requested` / `Rejected`）。
 
 必须先判断结果，再只选择一个输出分支：
 - `stageStatus.canAdvance=true` -> 通过
@@ -168,7 +167,7 @@ agent-infra-internal task-verify {task-id} review-code.completed --artifact {rev
 
 manual-validation 的数量不参与分支选择，只作为人工校验计数显示。
 
-> 完整的 4 分支输出模板、判断规则和禁止条款见 `reference/output-templates.md`。向用户汇报审查结论前先读取 `reference/output-templates.md`。
+> 完整的 A/B/C 输出模板、判断规则和禁止条款见 `reference/output-templates.md`。向用户汇报审查结论前先读取 `reference/output-templates.md`。
 
 > 渲染最终输出前先读取 `.agents/rules/next-step-output.md` 并落实其两类规则：(1) 「下一步」命令的 `{task-ref}` 渲染为当前任务短号 `NN`（取值与回退见该文件），其他 `{task-id}` 占位（报告标题、路径）保持完整 TASK-id 形式；(2) 在面向用户输出的绝对最后一行追加 `Completed at` 收尾行（成功、错误、早退等任何面向用户输出都适用，不限于校验通过的成功态）。
 

package/templates/.agents/skills/review-code/config/verify.en.json

@@ -24,9 +24,7 @@
       "stage": "code"
     },
     "review-fact": {},
-    "activity-log": {
-      "expected_action_pattern": "(Review Code|Code Review) \\(Round \\d+\\)"
-    },
+    "activity-log": {},
     "platform-sync": {
       "when": "platform_issue_identity_exists"
     }

package/templates/.agents/skills/review-code/config/verify.zh-CN.json

@@ -24,9 +24,7 @@
       "stage": "code"
     },
     "review-fact": {},
-    "activity-log": {
-      "expected_action_pattern": "(Review Code|Code Review) \\(Round \\d+\\)"
-    },
+    "activity-log": {},
     "platform-sync": {
       "when": "platform_issue_identity_exists"
     }

package/templates/.agents/skills/review-code/reference/output-templates.en.md

@@ -2,21 +2,20 @@
 
 Read this file before presenting the final review result to the user.
 
-> This file describes the four **user reply** categories (Branches A/B/C/D) used in the "Inform User" step. It is **not** the value of the review-code artifact's `**Overall Verdict**:` field — that field is fixed to one of three canonical tokens (`Approved` / `Changes Requested` / `Rejected`, or zh-CN `通过` / `需要修改` / `拒绝`). Do not mix the two.
+> This file describes three result scenarios (A/B/C) used in the "Inform User" step. Scenario R displays existing results when lifecycle finalization stops; it is not a verdict category. The review-code artifact's `**Overall Verdict**:` field remains one of three canonical tokens (`Approved` / `Changes Requested` / `Rejected`, or zh-CN `通过` / `需要修改` / `拒绝`).
 
 ## Choose Exactly One Output Branch
 
 Select from `stage-status` (**manual-validation and advisory counts do not participate**):
 1. if `stageStatus.canAdvance=true`, use Branch A
-2. if `stageStatus.canAdvance=false` and there are no blockers, use Branch B
-3. if `Blocker > 0` and the work can be repaired in a focused refinement pass, use Branch C
-4. if the task requires major redesign, broad reimplementation, or a restart, use Branch D
+2. if the verdict is changes requested and findings can be addressed locally, use Branch B regardless of blocker count
+3. if the task requires major redesign, broad reimplementation, or a restart, use Branch C
 
 Prohibitions:
 - never skip the branch-selection step
 - never mix text from different branches
 - if `Blocker > 0`, never output an approval template
-- never count manual-validation findings as blockers / major issues / minor issues, and never use them to trigger Branch B/C/D
+- never count manual-validation findings as blockers / major issues / minor issues, and never use them to trigger Branch B/C
 - generate `{next-step-commands}` for the selected branch through the shared helper
 - The count line shows 5 numbers. Manual-validation (`{e}`) does not affect selection. `Human-decision` (`{h}`) counts this stage's `needs-human-decision` rows; because those rows are unresolved, `{h} > 0` means `canAdvance=false`. Expand the "Pending human-decision pre-block" from `.agents/rules/next-step-output.md` and show revision and re-review paths only.
 
@@ -40,13 +39,12 @@ If the summary cannot be parsed safely, set `{last-readable-review-result}` to "
 
 ### Branch A: Approved with No Findings
 
-Do not route by review round. Compare reviewed snapshot tree `T` with the tree of baseline `R`, then read `prFlow` / verified `pr_delivery_fact`; when a PR exists, call `agent-infra-internal platform-checks inspect {task-id}`. Select exactly one mutually exclusive exit:
+Do not route by review round. Read `prFlow` / verified `pr_delivery_fact`; when a PR exists, call `agent-infra-internal platform-checks inspect {task-id}`. Select exactly one mutually exclusive exit:
 
-- `T != R^{tree}`: Branch A1 (commit).
-- `T == R^{tree}` without a PR: Branch A4 for `prFlow=disabled`, otherwise Branch A2 (create PR).
-- Existing PR with PR head != `R`: Branch A1 (commit/push).
-- PR head = `R` with `pending|failed|cancelled` checks or temporarily unavailable platform state: Branch A3 (watch); never show completion.
-- PR head = `R` with `passed|no-required` checks: Branch A4 (complete).
+- No PR: use Branch A3 (complete) when `prFlow=disabled`; otherwise use Branch A1 (create PR).
+- Existing PR with PR head != `R`: Branch A1 (create or update the PR).
+- PR head = `R` with `pending|failed|cancelled` checks or temporarily unavailable platform state: Branch A2 (watch); never show completion.
+- PR head = `R` with `passed|no-required` checks: Branch A3 (complete).
 
 Common Branch A summary:
 
@@ -54,21 +52,9 @@ Common Branch A summary:
 Task {task-id} review completed. Verdict: approved.
 - Blockers: 0 | Major: 0 | Minor: 0 | Manual-validation: {e} | Human-decision: {h}
 [- Review report: .agents/workspace/active/{task-id}/{review-artifact}]
-
-[When manual-validation > 0, append this final line:]
-Reminder: manual-validation findings must be carried in the PR description as a "manual verification required" checklist and should not trigger /code-task.
-```
-
-#### Branch A1: Commit or Push
-
-Populate `{next-step-commands}` for this scenario by running `agent-infra-internal agent-client next-steps --skill commit --task-ref {task-ref}`.
-
-```text
-Next step - commit or push the code:
-{next-step-commands}
 ```
 
-#### Branch A2: Create a Pull Request
+#### Branch A1: Create a Pull Request
 
 Populate `{next-step-commands}` for this scenario by running `agent-infra-internal agent-client next-steps --skill create-pr --task-ref {task-ref}`.
 
@@ -77,7 +63,7 @@ Next step - create a Pull Request:
 {next-step-commands}
 ```
 
-#### Branch A3: Watch All Checks
+#### Branch A2: Watch All Checks
 
 Populate `{next-step-commands}` for this scenario by running `agent-infra-internal agent-client next-steps --skill watch-pr --task-ref {task-ref}`.
 
@@ -86,7 +72,7 @@ Next step - watch PR checks:
 {next-step-commands}
 ```
 
-#### Branch A4: Complete and Archive
+#### Branch A3: Complete and Archive
 
 Populate `{next-step-commands}` for this scenario by running `agent-infra-internal agent-client next-steps --skill complete-task --task-ref {task-ref}`.
 
@@ -95,52 +81,43 @@ Next step - complete and archive the task:
 {next-step-commands}
 ```
 
-### Branch B: Changes Requested (Major / Minor)
+### Branch B: Local Fixes Needed
 
-Populate `{next-step-commands}` for this scenario by running `agent-infra-internal agent-client next-steps --skill code-task --task-ref {task-ref}`.
+Use this scenario for findings that can be fixed locally, regardless of blocker count. Fill in `{blockers}`, `{major}`, and `{minor}` with the unresolved counts. When `h > 0`, show the pending human-decision block required by `.agents/rules/next-step-output.md`; after those decisions, generate the re-review command with the `review-code` helper and do not show `code-task`. When `h = 0`, generate the repair command with the `code-task` helper.
+
+When `h = 0`, populate `{next-step-commands}` by running `agent-infra-internal agent-client next-steps --skill code-task --task-ref {task-ref}`:
 
 ```text
 Task {task-id} review completed. Verdict: changes requested.
-- Blockers: 0 | Major: {n} | Minor: {n} | Manual-validation: {e} | Human-decision: {h}
+- Blockers: {blockers} | Major: {major} | Minor: {minor} | Manual-validation: {e} | Human-decision: {h}
 - Review report: .agents/workspace/active/{task-id}/{review-artifact}
 
 Next step - fix the findings:
 {next-step-commands}
 
-[When manual-validation > 0, append this final line:]
-Reminder: manual-validation findings must be carried in the PR description as a "manual verification required" checklist and should not trigger /code-task.
 ```
 
-### Branch C: Changes Requested
+When `h > 0`, run `agent-infra-internal agent-client next-steps --skill review-code --task-ref {task-ref}` to generate `{next-step-commands}` for use after resolving the human decisions; show the required decision block before the command.
 
-Populate `{next-step-commands}` for this scenario by running `agent-infra-internal agent-client next-steps --skill code-task --task-ref {task-ref}`.
+## Manual-validation Reminder
 
-```text
-Task {task-id} review completed. Verdict: changes requested.
-- Blockers: {n} | Major: {n} | Minor: {n} | Manual-validation: {e} | Human-decision: {h}
-- Review report: .agents/workspace/active/{task-id}/{review-artifact}
+For scenarios A/B/C, append this reminder after the selected scenario when `{e} > 0`. Do not use it for scenario R.
 
-Next step - fix the findings:
-{next-step-commands}
-
-[When manual-validation > 0, append this final line:]
+```text
 Reminder: manual-validation findings must be carried in the PR description as a "manual verification required" checklist and should not trigger /code-task.
 ```
 
-### Branch D: Rejected
+### Branch C: Rejected and Re-design
 
 Populate `{next-step-commands}` for this scenario by running `agent-infra-internal agent-client next-steps --skill plan-task --task-ref {task-ref}`.
 
 ```text
 Task {task-id} review completed. Verdict: rejected, re-design the technical plan.
-- Blockers: {n} | Major: {n} | Minor: {n} | Manual-validation: {e} | Human-decision: {h}
+- Blockers: {blockers} | Major: {major} | Minor: {minor} | Manual-validation: {e} | Human-decision: {h}
 - Review report: .agents/workspace/active/{task-id}/{review-artifact}
 
 Next step - re-design the technical plan:
 {next-step-commands}
 
 > Note: Rejected means the implementation direction needs to be reworked end-to-end, not patched locally. Core artifact lifecycle branch #7 refuses a direct `/code-task` and requires a fresh plan first.
-
-[When manual-validation > 0, append this final line:]
-Reminder: manual-validation findings must be carried in the PR description as a "manual verification required" checklist and should not trigger /code-task.
 ```