@fitlab-ai/agent-infra 0.8.5 → 0.9.0

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

@@ -3,6 +3,7 @@ name: review-code
 description: >
   Review code implementation and output a code review report.
   Use when a code implementation needs review before merging.
+  Only invoke this skill automatically when the conversation includes a resolvable task reference.
 ---
 
 # Code Review
@@ -32,26 +33,20 @@ After loading workflow / skill / rules instructions, and before any task-state j
 Run these commands and paste the raw output into both the user-facing reply and this round's `## State Check` section:
 
 ```bash
-git status -s
-ls -la .agents/workspace/active/{task-id}/
-tail .agents/workspace/active/{task-id}/task.md
+agent-infra-internal task-snapshot {task-id} --format text
 ```
 
 Before the state check is complete, do not make external-state assertions such as "the code is unchanged", "tests passed", or "there are no other references", including in reasoning. This gate is only a structural floor; evidence pairing and authenticity still require the report template and review discipline.
 
-## Task id short ref
+## Task Context Resolution
 
-> If `{task-id}` matches `^[#]?[0-9]+$` (bare numeric or `#`-prefixed), follow the "SKILL parameter resolver" section of `.agents/rules/task-short-id.md`; treat `{task-id}` as the resolved full `TASK-YYYYMMDD-HHMMSS` form for every downstream command.
+> The entry point may omit the task ref and also accepts a legacy positional ref or `--task <ref>` / `-t <ref>`. Separate task scope from the full arguments while preserving every business operand, then call `agent-infra-internal task-context resolve {task-scope}` where `{task-scope}` is empty, one positional ref, or one task flag. Read only `taskId` from the structured result and bind `{task-id}` to that full `TASK-YYYYMMDD-HHMMSS` for downstream commands. Pass through resolution failures without scanning tasks locally.
 
-## Step Start: Write the started Marker
-
-After prerequisites pass and before this round's first artifact action, append a started marker to task.md `## Activity Log` (same base action as this round's done entry plus a ` [started]` suffix, note `started`):
+> Resolve the task reference, then confirm that the task is in a state or directory supported by this skill and that `task.md` exists; if it cannot be located, handle it as a missing task and stop.
 
-```
-- {YYYY-MM-DD HH:mm:ss±HH:MM} — **Review Code (Round {N}) [started]** by {agent} — started
-```
+## Step Start: Write the started Marker
 
-`ai task log` pairs it with the done entry written when the review completes onto one row (in progress → done). Format and pairing rules: see the "Activity Log started / done dual-marker convention" in `.agents/rules/task-management.md`.
+After resolving the artifact context and before this round's first artifact action, run `agent-infra-internal task-event {task-id} review-code.started --agent {agent}`.
 
 ## Steps
 
@@ -61,11 +56,9 @@ Require:
 - `.agents/workspace/active/{task-id}/task.md`
 - at least one code artifact: `code.md` or `code-r{N}.md`
 
-### 2. Determine Review Round
+### 2. Resolve the Artifact Context
 
-Scan the task directory and record:
-- `{review-round}`
-- `{review-artifact}` as `review-code.md` or `review-code-r{N}.md`
+Run `agent-infra-internal task-artifact {task-id} inspect --family review-code`. Continue only for `ready`; 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.
 
 ### 3. Read Implementation and Refinement Context
 
@@ -77,7 +70,7 @@ Follow `.agents/workflows/feature-development.yaml` and inspect the full change
 - Capture `R=$(git rev-parse HEAD)` exactly once; reuse that R for this round's report, fingerprint, and task review fact, and do not re-read HEAD later as a substitute
 - `git diff --binary "$R" -- <post-review-globs>` for tracked changes
 - `git ls-files -o --exclude-standard -z -- <post-review-globs>` for untracked new files
-- `node .agents/scripts/review-diff-fingerprint.js worktree "$R" --format json` to generate the reviewed diff fingerprint `F` and reviewed snapshot tree `T` together; write both into the report
+- Write `mode=worktree` and baseline `R` to a temporary JSON file, then call `agent-infra-internal git-workflow snapshot --input {file}` to generate the reviewed diff fingerprint `F` and reviewed snapshot tree `T` together; write both into the report
 
 > Detailed review criteria, severity rules, and reviewer expectations live in `reference/review-criteria.md`. Read `reference/review-criteria.md` before reviewing.
 > Test review gate: when `git diff` touches test files, read `.agents/rules/testing-discipline.md` first and check it item by item, especially "do not add negative assertions when a positive assertion already covers the behavior".
@@ -90,33 +83,27 @@ Create `.agents/workspace/active/{task-id}/{review-artifact}`.
 
 ### 6. Update Task Status
 
-Get the current time:
-
-```bash
-date "+%Y-%m-%d %H:%M:%S%z" | sed 's/\([+-][0-9][0-9]\)\([0-9][0-9]\)$/\1:\2/'
-```
-
 Update task.md:
-- When this round's `Overall Verdict` / `总体结论` is `Approved` / `通过` and `T == R^{tree}`, write `last_reviewed_commit: {R}`; when the Approved snapshot contains uncommitted changes, clear any existing `last_reviewed_commit` until `commit` anchors it
-- When this round is not Approved, preserve the existing `last_reviewed_commit`; do not advance or clear it
-- Append:
-`- {YYYY-MM-DD HH:mm:ss±HH:MM} — **Review Code (Round {N})** by {agent} — Verdict: {Approved/Changes Requested/Rejected}, blockers: {n}, major: {n}, minor: {n}, Manual-validation: {n} → {artifact-filename}`
+- After the report, submit each new finding with `agent-infra-internal task-ledger {task-id} finding-upsert --stage code --review-artifact {review-artifact} --ordinal {n} --severity {blocker|major|minor} --evidence {review-artifact}#{anchor}`; submit prior-response dispositions with `finding-review --id {ledger-id} --status {confirmed|closed|open|needs-human-decision} --evidence {evidence}`. Do not scan ids or edit ledger rows
+- After all ledger writes, call `agent-infra-internal task-ledger {task-id} stage-status --stage code` exactly once. Derive the verdict and next-step branch from `stageStatus.canAdvance`, and blocker/major/minor event counts from `unresolvedFindingCounts`; only `canAdvance=true` permits Approved
+- 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 required-checks 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
+- After handling `last_reviewed_commit`, run `agent-infra-internal task-event {task-id} review-code.completed --agent {agent} --artifact {review-artifact} --verdict {approved|changes-requested|rejected} --blockers {n} --major {n} --minor {n} --manual-validation {n}`
 
 Always include the `Manual-validation: {n}` field in the done log, including when it is 0.
 `manual-validation` is the data source for the `Manual-validation` count folded into review rows in `ai task log`; do not add a parallel manual-verification field.
 
 If task.md contains a valid `issue_number`, perform these sync actions (skip and continue on any failure):
-- Read `.agents/rules/issue-sync.md` before syncing, and complete upstream repository detection plus permission detection
-- Set `status: in-progress` by following issue-sync.md
-- Create or update the task comment marker defined in `.agents/rules/issue-sync.md` (follow the task.md comment sync rule in issue-sync.md)
-- Publish the `{review-artifact}` comment
+- Run `agent-infra-internal platform-issue sync {task-id} --agent {agent} --status in-progress`
+- Run `agent-infra-internal platform-comment sync {task-id} --kind task --agent {agent}`
+- Run `agent-infra-internal platform-comment sync {task-id} --kind artifact --artifact {review-artifact} --agent {agent}`
 
 ### 7. Verification Gate
 
 Run the verification gate to confirm the task artifact and sync state are valid:
 
 ```bash
-node .agents/scripts/validate-artifact.js gate review-code .agents/workspace/active/{task-id} {review-artifact} --format text
+agent-infra-internal task-verify {task-id} review-code.completed --artifact {review-artifact} --format text
 ```
 
 Handle the result as follows:
@@ -133,16 +120,15 @@ Keep the gate output in your reply as fresh evidence. Do not claim completion wi
 > **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.
 
 Choose exactly one branch based on the findings:
-- no blockers, no major, no minor -> approved with no issues
-- no blockers, but major or minor findings -> approved with issues
-- blockers that can be fixed in a focused pass -> changes requested
+- `stageStatus.canAdvance=true` -> approved
+- `stageStatus.canAdvance=false` and focused fixes are sufficient -> changes requested
 - major redesign or re-implementation needed -> rejected
 
 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.
 
-> 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).
+> 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).
 
 Include all TUI command formats in the next-step output. If `.agents/.airc.json` configures custom TUIs (via `customTUIs`), read each tool's `name` and `invoke`, then add the matching command line in the same format (`${skillName}` becomes the skill name and `${projectName}` becomes the project name).
 

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

@@ -3,6 +3,7 @@ name: review-code
 description: >
   审查代码实现并输出代码审查报告。
   当代码实现需要在合入前接受审查时使用。
+  仅当对话包含可解析的任务引用时才可自动调用本技能。
 ---
 
 # 代码审查
@@ -32,26 +33,20 @@ description: >
 运行以下命令，并把原文粘贴到回复正文和本轮产物的 `## 状态核对` 段：
 
 ```bash
-git status -s
-ls -la .agents/workspace/active/{task-id}/
-tail .agents/workspace/active/{task-id}/task.md
+agent-infra-internal task-snapshot {task-id} --format text
 ```
 
 状态核对完成前，禁止任何关于外部状态的断言（例如“代码没变”“测试已通过”“没有其他引用”），包括思考阶段。本门禁只提供结构下限；逐条证据配对和真实性仍需按报告模板与审查要求核对。
 
-## 任务入参短号别名
+## 任务上下文解析
 
-> 如果 `{task-id}` 入参匹配 `^[#]?[0-9]+$`（裸数字或带 `#` 前缀），先读取 `.agents/rules/task-short-id.md` 的「SKILL 入参解析」段执行解析；后续命令视 `{task-id}` 为解析后的全长 `TASK-YYYYMMDD-HHMMSS` 形式。
+> 入口允许省略 task ref，也接受旧位置 task ref 或 `--task <ref>` / `-t <ref>`。先从完整参数中分离 task scope 并原样保留其他业务操作数，再调用 `agent-infra-internal task-context resolve {task-scope}`；`{task-scope}` 为空、位置 ref 或 task flag 之一。只读取结构化结果的 `taskId`，后续把 `{task-id}` 绑定为该完整 `TASK-YYYYMMDD-HHMMSS`。解析失败时透传非零退出码，不自行扫描任务。
 
-## 步骤开始：写入 started 标记
+> 解析任务引用，并确认任务位于本技能支持的状态或目录且存在 `task.md`；无法定位时按未找到任务处理并停止。
 
-确认前置条件后、本轮第一个产出动作之前，向 task.md `## 活动日志` 追加一条 started 标记（与本轮 done 条目同基名 + ` [started]` 后缀，note 用 `started`）：
+## 步骤开始：声明 started 事件
 
-```
-- {YYYY-MM-DD HH:mm:ss±HH:MM} — **Review Code (Round {N}) [started]** by {agent} — started
-```
-
-`ai task log` 会把它与审查完成时写入的 done 条目配对成一行（进行中 → 已完成）。格式与配对规则见 `.agents/rules/task-management.md` 的「Activity Log started / done 双标记约定」。
+确认前置条件和产物上下文后、本轮第一个产出动作之前执行 `agent-infra-internal task-event {task-id} review-code.started --agent {agent}`。
 
 ## 执行步骤
 ### 1. 验证前置条件
@@ -60,15 +55,13 @@ tail .agents/workspace/active/{task-id}/task.md
 - `.agents/workspace/active/{task-id}/task.md`
 - 至少一个实现产物：`code.md` 或 `code-r{N}.md`
 
-### 2. 确定审查轮次
+### 2. 解析审查上下文
 
-扫描任务目录并记录：
-- `{review-round}`
-- 作为本轮产物的 `{review-artifact}`，格式为 `review-code.md` 或 `review-code-r{N}.md`
+运行 `agent-infra-internal task-artifact {task-id} inspect --family review-code`。仅当结果为 `ready` 时继续；从 `inputs` 取得最新 `{code-artifact}`，从 `next.round` / `next.name` 取得 `{review-round}` / `{review-artifact}`。不得自行扫描轮次或拼装文件名。随后执行 started 事件并复核返回身份。
 
 ### 3. 阅读实现与修复上下文
 
-读取最高轮次的实现产物；如存在修复产物，也读取最高轮次的修复产物。读取后，把本轮实际检视的最高轮 code artifact（及如存在的最高轮修复产物）按文件名回填到报告 `审查输入` 段；无法可靠取得时留空，不要伪造。
+读取步骤 2 返回的最新 `{code-artifact}`。读取后，把本轮实际检视的 code artifact 按文件名回填到报告 `审查输入` 段；无法可靠取得时留空，不要伪造。
 
 ### 4. 执行审查
 
@@ -76,7 +69,7 @@ tail .agents/workspace/active/{task-id}/task.md
 - 一次性记录 `R=$(git rev-parse HEAD)`；本轮报告、指纹和任务审查事实都复用该 R，禁止稍后重新读取 HEAD 代替
 - `git diff --binary "$R" -- <post-review-globs>` 覆盖已跟踪变更
 - `git ls-files -o --exclude-standard -z -- <post-review-globs>` 覆盖未跟踪新文件
-- `node .agents/scripts/review-diff-fingerprint.js worktree "$R" --format json` 一次生成审查差异指纹 `F` 与审查快照树 `T`，并写入报告
+- 把 `mode=worktree`、基线 `R` 写入临时 JSON，调用 `agent-infra-internal git-workflow snapshot --input {file}` 一次生成审查差异指纹 `F` 与审查快照树 `T`，并写入报告
 
 > 详细审查标准、严重程度划分和 reviewer 关注点见 `reference/review-criteria.md`。执行此步骤前先读取 `reference/review-criteria.md`。
 > 测试审查硬门禁：当 `git diff` 触及测试文件时，必须先读取 `.agents/rules/testing-discipline.md` 并逐条核对（尤其"正向已覆盖时不应再加反向断言"）。
@@ -89,36 +82,26 @@ tail .agents/workspace/active/{task-id}/task.md
 
 ### 6. 更新任务状态
 
-获取当前时间：
-
-```bash
-date "+%Y-%m-%d %H:%M:%S%z" | sed 's/\([+-][0-9][0-9]\)\([0-9][0-9]\)$/\1:\2/'
-```
-
-- `current_step`：code-review
-- `assigned_to`：{当前代理}
-- `updated_at`：{当前时间}
-- `agent_infra_version`：按 `.agents/rules/version-stamp.md` 取值
-- 若本轮 `总体结论` / `Overall Verdict` 为 `通过` / `Approved` 且 `T == R^{tree}`，写入 `last_reviewed_commit: {R}`；若 Approved 快照包含未提交差异，则清除既有 `last_reviewed_commit`，等待 `commit` 锚定
-- 若本轮结论不是 Approved，保留既有 `last_reviewed_commit`，不得推进或清空
-- 追加：
-`- {YYYY-MM-DD HH:mm:ss±HH:MM} — **Review Code (Round {N})** by {agent} — Verdict: {Approved/Changes Requested/Rejected}, blockers: {n}, major: {n}, minor: {n}, Manual-validation: {n} → {artifact-filename}`
+- 报告完成后，新 finding 逐条调用 `agent-infra-internal task-ledger {task-id} finding-upsert --stage code --review-artifact {review-artifact} --ordinal {n} --severity {blocker|major|minor} --evidence {review-artifact}#{anchor}`；复核上一轮响应时调用 `finding-review --id {ledger-id} --status {confirmed|closed|open|needs-human-decision} --evidence {相称证据}`。不得扫描编号或手写账本行
+- 全部账本写入完成后只调用一次 `agent-infra-internal task-ledger {task-id} stage-status --stage code`。以 `stageStatus.canAdvance` 决定 verdict 和下一步，并以 `unresolvedFindingCounts` 填写 blocker/major/minor；仅 `canAdvance=true` 可用 Approved
+- 仅当 `canAdvance=true`、本轮结论为 Approved 且 `T == R^{tree}` 时写入 `last_reviewed_commit: {R}`；Approved 快照包含未提交差异时清除旧值。否则保留既有值，不得推进或清空
+- Approved 出口继续按 `reference/output-templates.md` 采集 PR 与 required-checks 事实：未提交/未推送走 `commit`，无 PR 走 `create-pr`（无 PR 流程除外），checks 未终态走 `watch-pr`，仅 `HEAD == last_reviewed_commit == PR head` 且 checks 为 `passed|no-required` 时走 `complete-task`；不得仅按审查轮次分流
+- 完成 `last_reviewed_commit` 处理后执行 `agent-infra-internal task-event {task-id} review-code.completed --agent {agent} --artifact {review-artifact} --verdict {approved|changes-requested|rejected} --blockers {n} --major {n} --minor {n} --manual-validation {n}`
 
 完成日志必须始终写入 `Manual-validation: {n}` 字段，0 也保留。
 `manual-validation` 是 `ai task log` 中 review 行「人工校验点」（EN `Manual-validation`）计数的数据源；不要新增并行人工验证字段。
 
 如果 task.md 中存在有效的 `issue_number`，执行以下同步操作（任一失败则跳过并继续）：
-- 执行前先读取 `.agents/rules/issue-sync.md`，完成 upstream 仓库检测和权限检测
-- 按 issue-sync.md 设置 `status: in-progress`
-- 创建或更新 `.agents/rules/issue-sync.md` 中定义的 task 评论标记（按 issue-sync.md 的 task.md 评论同步规则）
-- 发布 `{review-artifact}` 评论
+- 调用 `agent-infra-internal platform-issue sync {task-id} --agent {agent} --status in-progress`
+- 调用 `agent-infra-internal platform-comment sync {task-id} --kind task --agent {agent}`
+- 调用 `agent-infra-internal platform-comment sync {task-id} --kind artifact --artifact {review-artifact} --agent {agent}`
 
 ### 7. 完成校验
 
 运行完成校验，确认任务产物和同步状态符合规范：
 
 ```bash
-node .agents/scripts/validate-artifact.js gate review-code .agents/workspace/active/{task-id} {review-artifact} --format text
+agent-infra-internal task-verify {task-id} review-code.completed --artifact {review-artifact} --format text
 ```
 
 处理结果：
@@ -135,16 +118,15 @@ node .agents/scripts/validate-artifact.js gate review-code .agents/workspace/act
 > **重要：分支名 ≠ 字段值**。以下 4 个标签是用户输出模板的分类（场景 A/B/C/D），**不是**产物 `**总体结论**：` 字段的取值。产物字段只取 3 个规范值之一（`通过` / `需要修改` / `拒绝`，或 EN 对应 `Approved` / `Changes Requested` / `Rejected`）；写成 `通过但有问题`、`通过 / 需要修改` 等组合短语会被 verify gate 拦下。
 
 必须先判断结果，再只选择一个输出分支：
-- 无 blocker、major、minor -> 通过且无问题
-- 无 blocker，但有 major 或 minor -> 通过但有问题
-- 有 blocker，且可集中修复 -> 需要修改
+- `stageStatus.canAdvance=true` -> 通过
+- `stageStatus.canAdvance=false` 且可集中修复 -> 需要修改
 - 需要重大返工或重新实现 -> 拒绝
 
 manual-validation 的数量不参与分支选择，只作为人工校验计数显示。
 
 > 完整的 4 分支输出模板、判断规则和禁止条款见 `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` 收尾行（成功、错误、早退等任何面向用户输出都适用，不限于校验通过的成功态）。
+> 渲染最终输出前先读取 `.agents/rules/next-step-output.md` 并落实其两类规则：(1) 「下一步」命令的 `{task-ref}` 渲染为当前任务短号 `NN`（取值与回退见该文件），其他 `{task-id}` 占位（报告标题、路径）保持完整 TASK-id 形式；(2) 在面向用户输出的绝对最后一行追加 `Completed at` 收尾行（成功、错误、早退等任何面向用户输出都适用，不限于校验通过的成功态）。
 
 向用户展示下一步时，必须包含所有 TUI 命令格式。如果 `.agents/.airc.json` 中配置了自定义 TUI（`customTUIs`），读取每个工具的 `name` 和 `invoke`，按同样格式补充对应命令行（`${skillName}` 替换为技能名，`${projectName}` 替换为项目名）。
 

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

@@ -20,6 +20,7 @@
       "required_sections": [
         "Review Summary",
         "Findings",
+        "Non-blocking Advisories",
         "Manual Validation Items",
         "Conclusion and Recommendations",
         "State Check",
@@ -34,13 +35,11 @@
         "^- \\*\\*Review Baseline Commit\\*\\*[:：]\\s*\\S",
         "^- \\*\\*Reviewed Diff Fingerprint\\*\\*[:：]\\s*sha256:[0-9a-f]{64}\\s*$",
         "^- \\*\\*Reviewed Snapshot Tree\\*\\*[:：]\\s*[0-9a-f]{40,64}\\s*$"
-      ],
-      "freshness_minutes": 30
+      ]
     },
     "review-fact": {},
     "activity-log": {
-      "expected_action_pattern": "(Review Code|Code Review) \\(Round \\d+\\)",
-      "freshness_minutes": 30
+      "expected_action_pattern": "(Review Code|Code Review) \\(Round \\d+\\)"
     },
     "platform-sync": {
       "when": "issue_number_exists",

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

@@ -20,6 +20,7 @@
       "required_sections": [
         "审查摘要",
         "问题清单",
+        "非阻塞建议",
         "人工校验项",
         "结论与建议",
         "状态核对",
@@ -34,13 +35,11 @@
         "^- \\*\\*审查基线提交\\*\\*[:：]\\s*\\S",
         "^- \\*\\*审查差异指纹\\*\\*[:：]\\s*sha256:[0-9a-f]{64}\\s*$",
         "^- \\*\\*审查快照树\\*\\*[:：]\\s*[0-9a-f]{40,64}\\s*$"
-      ],
-      "freshness_minutes": 30
+      ]
     },
     "review-fact": {},
     "activity-log": {
-      "expected_action_pattern": "(Review Code|Code Review) \\(Round \\d+\\)",
-      "freshness_minutes": 30
+      "expected_action_pattern": "(Review Code|Code Review) \\(Round \\d+\\)"
     },
     "platform-sync": {
       "when": "issue_number_exists",

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

@@ -6,9 +6,9 @@ Read this file before presenting the final review result to the user.
 
 ## Choose Exactly One Output Branch
 
-Apply these rules in order (**note: manual-validation counts do not participate in selection**):
-1. if `Blocker = 0` and `Major = 0` and `Minor = 0`, use Branch A (regardless of whether manual-validation > 0)
-2. if `Blocker = 0` and (`Major > 0` or `Minor > 0`), use Branch B
+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
 
@@ -18,41 +18,79 @@ Prohibitions:
 - 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
 - always include every TUI command format in the selected branch
-- the count line always shows 5 numbers: the first three (Blockers / Major / Minor) must be 0 to proceed; the last two are "pending human" items and need not be zero — `Manual-validation` (`{e}`) = this round's manual-validation count, `Human-decision` (`{h}`) = the number of rows in task.md `## 审查分歧账本` with `stage=code` and `status=needs-human-decision`; neither participates in branch selection. When `{h} > 0`, before the selected scenario's "Next steps" commands you must expand each pending ruling per the "Pending human-decision pre-block" in `.agents/rules/next-step-output.md` and prompt to resolve them first
+- 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.
+
+For Branches B/C/D, follow the revision commands with re-review commands: `/review-code {task-ref}`, `/{{project}}:review-code {task-ref}`, and `$review-code {task-ref}`.
 
 ### 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` / `pr_number`; 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).
+
+Common Branch A summary:
+
 ```text
 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}]
 
-Next step - commit the code:
-  - Claude Code / OpenCode: /commit
-  - Gemini CLI: /{{project}}:commit
-  - Codex CLI: $commit
-
 [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 B: Approved with Findings
+#### Branch A1: Commit or Push
 
 ```text
-Task {task-id} review completed. Verdict: approved.
+Next step - commit or push the code:
+  - Claude Code / OpenCode: /commit {task-ref}
+  - Gemini CLI: /{{project}}:commit {task-ref}
+  - Codex CLI: $commit {task-ref}
+```
+
+#### Branch A2: Create a Pull Request
+
+```text
+Next step - create a Pull Request:
+  - Claude Code / OpenCode: /create-pr {task-ref}
+  - Gemini CLI: /{{project}}:create-pr {task-ref}
+  - Codex CLI: $create-pr {task-ref}
+```
+
+#### Branch A3: Watch Required Checks
+
+```text
+Next step - watch PR checks:
+  - Claude Code / OpenCode: /watch-pr {task-ref}
+  - Gemini CLI: /{{project}}:watch-pr {task-ref}
+  - Codex CLI: $watch-pr {task-ref}
+```
+
+#### Branch A4: Complete and Archive
+
+```text
+Next step - complete and archive the task:
+  - Claude Code / OpenCode: /complete-task {task-ref}
+  - Gemini CLI: /{{project}}:complete-task {task-ref}
+  - Codex CLI: $complete-task {task-ref}
+```
+
+### Branch B: Changes Requested (Major / Minor)
+
+```text
+Task {task-id} review completed. Verdict: changes requested.
 - Blockers: 0 | Major: {n} | Minor: {n} | Manual-validation: {e} | Human-decision: {h}
 - Review report: .agents/workspace/active/{task-id}/{review-artifact}
 
-Next step - fix before commit (recommended):
+Next step - fix the findings:
   - Claude Code / OpenCode: /code-task {task-ref}
   - Gemini CLI: /{{project}}:code-task {task-ref}
   - Codex CLI: $code-task {task-ref}
 
-Or commit directly (skip fix):
-  - Claude Code / OpenCode: /commit
-  - Gemini CLI: /{{project}}:commit
-  - Codex CLI: $commit
-
 [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.
 ```
@@ -85,7 +123,7 @@ Next step - re-design the technical plan:
   - Gemini CLI: /{{project}}:plan-task {task-ref}
   - Codex CLI: $plan-task {task-ref}
 
-> Note: Rejected means the implementation direction needs to be reworked end-to-end, not patched locally. `code-task/scripts/detect-mode.js` branch #7 refuses a direct `/code-task` and requires a fresh plan first.
+> 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.

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

@@ -6,9 +6,9 @@
 
 ## 选择唯一输出场景
 
-按以下顺序判断（**注意：manual-validation 数量不参与判断**）：
-1. 如果 `Blocker = 0` 且 `Major = 0` 且 `Minor = 0`，使用场景 A（不管 manual-validation 是否 > 0）
-2. 如果 `Blocker = 0` 且（`Major > 0` 或 `Minor > 0`），使用场景 B
+按 `stage-status` 结果判断（**注意：manual-validation 和 advisory 数量不参与判断**）：
+1. 如果 `stageStatus.canAdvance=true`，使用场景 A
+2. 如果 `stageStatus.canAdvance=false` 且无 blocker，使用场景 B
 3. 如果 `Blocker > 0`，且问题可以通过一次聚焦修复解决，使用场景 C
 4. 如果任务需要重大重构、大范围重写或整体重来，使用场景 D
 
@@ -18,41 +18,79 @@
 - 只要 `Blocker > 0`，就绝对不能输出通过模板
 - manual-validation 项绝对不能被计入 blocker / major / minor 计数，也不能用作触发场景 B/C/D 的依据
 - 所选场景中必须包含所有 TUI 命令格式
-- 计数行固定显示 5 个数字：前三项（阻塞 / 主要 / 次要）必须为 0 才进下一步；后两项是「待人处理」项、不要求归零——`人工校验点`（`{e}`）= 本轮 manual-validation 计数，`人工裁决`（`{h}`）= task.md `## 审查分歧账本` 中 `stage=code` 且 `status=needs-human-decision` 的行数；二者均不参与场景判断。当 `{h} > 0` 时，必须在选定场景的「下一步」命令之前，按 `.agents/rules/next-step-output.md`「人工裁决待办前置块」逐项展开裁决项并提示先完成裁决
+- 计数行固定显示 5 个数字。manual-validation（`{e}`）不影响分支；`人工裁决`（`{h}`）是本阶段 `needs-human-decision` 行数，属于未闭环账本状态，因此 `{h} > 0` 时 `canAdvance=false`，必须按 `.agents/rules/next-step-output.md` 的「人工裁决待办前置块」展开详情，并只输出修订与复审路径。
+
+场景 B/C/D 在修订命令后继续列出复审命令：`/review-code {task-ref}`、`/{{project}}:review-code {task-ref}`、`$review-code {task-ref}`。
 
 ### 场景 A：通过且无问题
 
+通过后不得按轮次路由。先比较审查快照树 `T` 与基线 `R` 的树，再读取任务的 `prFlow` / `pr_number`；存在 PR 时调用 `agent-infra-internal platform-checks inspect {task-id}`。只选择以下一个互斥出口：
+
+- `T != R^{tree}`：场景 A1（提交）。
+- `T == R^{tree}` 且无 PR：`prFlow=disabled` 用场景 A4（完成），否则用场景 A2（创建 PR）。
+- 已有 PR 但 PR head != `R`：场景 A1（提交/推送）。
+- PR head = `R`，checks 为 `pending|failed|cancelled` 或平台暂不可用：场景 A3（监控），不得输出完成命令。
+- PR head = `R`，checks 为 `passed|no-required`：场景 A4（完成）。
+
+场景 A 的共同摘要：
+
 ```text
 任务 {task-id} 代码审查完成。结论：通过。
 - 阻塞项：0 | 主要问题：0 | 次要问题：0 | 人工校验点：{e} | 人工裁决：{h}
 [- 审查报告：.agents/workspace/active/{task-id}/{review-artifact}]
 
-下一步 - 提交代码：
-  - Claude Code / OpenCode：/commit
-  - Gemini CLI：/{{project}}:commit
-  - Codex CLI：$commit
-
 [当 manual-validation > 0 时，在最后附加一行：]
 提醒：manual-validation 项需在 PR description 的「待人工验证」清单中承接，不应触发 /code-task。
 ```
 
-### 场景 B：通过但有问题
+#### 场景 A1：提交或推送
 
 ```text
-任务 {task-id} 代码审查完成。结论：通过。
+下一步 - 提交或推送代码：
+  - Claude Code / OpenCode：/commit {task-ref}
+  - Gemini CLI：/{{project}}:commit {task-ref}
+  - Codex CLI：$commit {task-ref}
+```
+
+#### 场景 A2：创建 Pull Request
+
+```text
+下一步 - 创建 Pull Request：
+  - Claude Code / OpenCode：/create-pr {task-ref}
+  - Gemini CLI：/{{project}}:create-pr {task-ref}
+  - Codex CLI：$create-pr {task-ref}
+```
+
+#### 场景 A3：监控 required checks
+
+```text
+下一步 - 监控 PR 检查：
+  - Claude Code / OpenCode：/watch-pr {task-ref}
+  - Gemini CLI：/{{project}}:watch-pr {task-ref}
+  - Codex CLI：$watch-pr {task-ref}
+```
+
+#### 场景 A4：完成并归档
+
+```text
+下一步 - 完成并归档任务：
+  - Claude Code / OpenCode：/complete-task {task-ref}
+  - Gemini CLI：/{{project}}:complete-task {task-ref}
+  - Codex CLI：$complete-task {task-ref}
+```
+
+### 场景 B：需要修改（major / minor）
+
+```text
+任务 {task-id} 代码审查完成。结论：需要修改。
 - 阻塞项：0 | 主要问题：{n} | 次要问题：{n} | 人工校验点：{e} | 人工裁决：{h}
 - 审查报告：.agents/workspace/active/{task-id}/{review-artifact}
 
-下一步 - 修复问题后提交（推荐）：
+下一步 - 修复问题：
   - Claude Code / OpenCode：/code-task {task-ref}
   - Gemini CLI：/{{project}}:code-task {task-ref}
   - Codex CLI：$code-task {task-ref}
 
-或直接提交（跳过修复）：
-  - Claude Code / OpenCode：/commit
-  - Gemini CLI：/{{project}}:commit
-  - Codex CLI：$commit
-
 [当 manual-validation > 0 时，在最后附加一行：]
 提醒：manual-validation 项需在 PR description 的「待人工验证」清单中承接，不应触发 /code-task。
 ```
@@ -85,7 +123,7 @@
   - Gemini CLI：/{{project}}:plan-task {task-ref}
   - Codex CLI：$plan-task {task-ref}
 
-> 注意：Rejected 表示实现方向需要整体重做，不是局部修复。`code-task/scripts/detect-mode.js` 分支 #7 会拒绝直接 `/code-task`，要求先重新方案设计。
+> 注意：Rejected 表示实现方向需要整体重做，不是局部修复。核心 artifact lifecycle 的分支 #7 会拒绝直接 `/code-task`，要求先重新方案设计。
 
 [当 manual-validation > 0 时，在最后附加一行：]
 提醒：manual-validation 项需在 PR description 的「待人工验证」清单中承接，不应触发 /code-task。

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

@@ -22,8 +22,8 @@ Use this template when writing `review-code.md` or `review-code-r{N}.md`.
 - **Review Time**: {timestamp}
 - **Scope**: {file-count and major modules}
 - **Review Baseline Commit**: {raw R captured once for this round} (diff base only; see `.agents/rules/review-handshake.md`)
-- **Reviewed Diff Fingerprint**: {raw node .agents/scripts/review-diff-fingerprint.js worktree "$R"}
-- **Reviewed Snapshot Tree**: {tree field from node .agents/scripts/review-diff-fingerprint.js worktree "$R" --format json}
+- **Reviewed Diff Fingerprint**: {fingerprint field from git-workflow snapshot}
+- **Reviewed Snapshot Tree**: {tree field from git-workflow snapshot}
 - **Overall Verdict**: {Approved / Changes Requested / Rejected} (pick exactly one; combined phrases will fail the verify gate)
 - **Findings (AI-actionable)**: 0 blockers, 0 majors, 0 minors / **Manual validation**: 0
 
@@ -43,12 +43,18 @@ Use this template when writing `review-code.md` or `review-code-r{N}.md`.
 **Description**: {details}
 **Suggested Fix**: {fix suggestion}
 
-### Minor Issues (optional improvements)
+### Minor Issues (low impact, closure required)
 
 #### 1. {Improvement point}
 **File**: `{file-path}:{line-number}`
 **Suggestion**: {improvement suggestion}
 
+## Non-blocking Advisories
+
+> Record only future optimizations that do not affect the current artifact's completeness, correctness, or acceptance. Advisories do not enter the disagreement ledger, finding counts, or verdict.
+
+- {future optimization}
+
 ## Manual Validation Items
 
 > Items the AI agent cannot close in the current execution environment; they do not participate in the next code round. Maintainers carry them in the PR description as a "manual verification required" checklist.
@@ -64,7 +70,8 @@ Use this template when writing `review-code.md` or `review-code-r{N}.md`.
 
 ## Review Disagreement Ledger Writeback
 
-> Upsert each finding this round into the task.md disagreement ledger: append an `open` row for new findings (id prefix `CD-`, stage=code); per the hand-back duty set the executor's prior-round responses to `confirmed` / back to `open` / `needs-human-decision`. State machine and evidence rules: `.agents/rules/review-handshake.md`.
+> Record the structured intents to submit: use `task-ledger finding-upsert` for new findings and `finding-review` for prior responses. The core allocates `CD-N` and validates transitions; do not edit task.md table rows.
+> Every finding escalated to `needs-human-decision` must include a self-contained detail block per `.agents/rules/human-decision-context.md`, with evidence pointing to that stable anchor.
 
 ## Evidence