@fitlab-ai/agent-infra 0.11.2 → 0.11.4

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

@@ -1,8 +1,8 @@
 ---
 name: code-task
 description: >
-  Implement code from the technical plan and output a report.
-  Use when an approved technical plan needs implementing, or code review found issues to fix.
+  Implement code from the selected lifecycle input and output a report.
+  Use when analysis or a technical plan is ready for the selected path, or code review found issues to fix.
   Only invoke this skill automatically when the conversation includes a resolvable task reference.
 ---
 
@@ -11,16 +11,20 @@ description: >
 
 If the entry operands contain `--orchestrated`, bind `{execution-flag}` to `--orchestrated` and forward it unchanged to the completed event; otherwise bind it to an empty value. Never infer it from `orchestration.json`, environment variables, or prior artifacts. Lifecycle events also require explicit trigger data: use `{trigger-initiator}=orchestrator` for orchestration and `model` otherwise; `{request-id}` is a stable single-line identifier for this task and artifact round, and `{reason-code}` is `user-request` for initial work and `review-finding` for fixes or decisions. Reuse the same values for started and completed.
 
-Implement the approved plan and produce `code.md` or `code-r{N}.md`. This skill supports initial implementation, fix mode based on `review-code` feedback, and human-decision-driven implementation.
+Implement from the input selected by the lifecycle path and produce `code.md` or `code-r{N}.md`. This skill supports initial implementation, fix mode based on `review-code` feedback, and human-decision-driven implementation.
 
 ## Boundary / Critical Rules
 
+### Path and rework
+
+This stage consumes only the canonical path fact parsed by core from the latest valid analysis artifact; a stage omitted by that path must not create an artifact. When another Changes Requested verdict follows one completed revision-review cycle in the same stage, classify the rework before the next executor artifact and bind it to the finding, source SHA, and stable task-fact digest. A round or filename change is not new evidence.
+
 ### Persisted Report Evidence
 
 Before generating the implementation report, read `.agents/rules/evidence-reporting.md`. Successful tests record the command, target scope, status or structured result, actual result, and uncovered parts; failures, blocking conditions, or disputes retain a reproducible entry point, exact location, and decisive excerpt instead of complete successful stdout.
 
 - When evaluating candidate qualification or `HD-N`, read `.agents/rules/decision-qualification.md`, audit normalized task constraints/candidates, and record the five qualification-audit tables in the implementation report; unknown or unconfirmed constraints must not automatically exclude a candidate
-- Follow the latest plan artifact: `plan.md` or `plan-r{N}.md`
+- Follow the lifecycle input selected by core: `analysis.md` / `analysis-r{N}.md` for the streamlined path, and `plan.md` / `plan-r{N}.md` for the standard or full path
 - 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
 - Read `.agents/rules/compatibility-policy.md` before implementation. Implement only the compatibility budget explicitly approved by the plan; never retain old branches, result contracts, or migration shims merely to be “safe”
 - Fix mode verifies each finding of the latest `review-code` one by one: fix it if it holds, or rebut it and record it under unresolved if it is unfounded/hallucinated; do not expand to issues the review did not list; manual-validation items are out of scope
@@ -56,7 +60,7 @@ After prerequisites and mode are confirmed and before this round's first artifac
 
 ### 1. Verify Prerequisites
 
-Require `task.md` and at least one plan artifact: `plan.md` or `plan-r{N}.md`.
+Require `task.md`. Step 4 validates the lifecycle input selected by the chosen path; the skill must not require a plan artifact unconditionally.
 
 ### 2. Ensure the Task Branch
 
@@ -78,6 +82,8 @@ status=$?
 echo "$result"
 ```
 
+When `selection.disposition` is `reuse`, reuse `selection.artifact`, do not run started/init, modify code, or write a new artifact, and continue directly to completion verification and next-step guidance. Otherwise continue with the table below.
+
 Dispatch by `$status` and `result.mode`:
 
 - `0` + `"init"`: initial implementation; record `{code-artifact}` and `{code-round}`
@@ -90,11 +96,11 @@ Dispatch by `$status` and `result.mode`:
 
 ### 5. Read Structured Inputs
 
-Use only the structured result from step 4: read the selected plan artifact and, in fix mode, the selected review artifact. Use `next.name` as `{code-artifact}` and `next.round` as `{code-round}`. In decision mode, take the unified identity from `implementation_input`, `decision_id`, and `decision_evidence`; do not rescan or construct identities in the skill.
+Use only the structured result from step 4: read `{lifecycle-input-artifact}` from `inputs` (analysis for the streamlined path, plan otherwise) and, in fix mode, the selected review artifact. Use `next.name` as `{code-artifact}` and `next.round` as `{code-round}`. In decision mode, take the unified identity from `implementation_input`, `decision_id`, and `decision_evidence`; do not rescan or construct identities in the skill.
 
-### 6. Read the Technical Plan
+### 6. Read the Lifecycle Input
 
-Extract implementation steps, files, test strategy, constraints, risks, and approved tradeoffs. In decision mode, also read the `{input-id}` row and its `{decision-evidence}` record in task.md, and implement only that ruling's requested behavior change.
+Extract implementation steps, files, test strategy, constraints, risks, and approved tradeoffs from `{lifecycle-input-artifact}`. In decision mode, also read the `{input-id}` row and its `{decision-evidence}` record in task.md, and implement only that ruling's requested behavior change.
 
 ### 7. Implement the Code
 

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

@@ -1,8 +1,8 @@
 ---
 name: code-task
 description: >
-  根据技术方案编码任务并输出报告。
-  当技术方案已批准需要落地实现，或代码审查发现问题需要修复时使用。
+  根据生命周期输入编码任务并输出报告。
+  当分析或技术方案已按所选路径准备完成，或代码审查发现问题需要修复时使用。
   仅当对话包含可解析的任务引用时才可自动调用本技能。
 ---
 
@@ -11,16 +11,20 @@ description: >
 
 若入口业务操作数包含 `--orchestrated`，绑定 `{execution-flag}` = `--orchestrated` 并原样转发给 completed 事件；否则绑定为空。不得从 `orchestration.json`、环境变量或历史产物推断该标记。生命周期事件还必须携带显式触发信息：编排调用使用 `{trigger-initiator}=orchestrator`，否则使用 `model`；`{request-id}` 是本任务与本轮产物的稳定单行标识，`{reason-code}` 初次实现使用 `user-request`，修复或裁决使用 `review-finding`；started 与 completed 使用同一组值。
 
-根据已批准的技术方案编码任务，并产出 `code.md` 或 `code-r{N}.md`。本技能支持初次实现、基于 `review-code` 反馈的修复，以及人工裁决驱动实现三种模式。
+根据所选生命周期路径的实现输入编码任务，并产出 `code.md` 或 `code-r{N}.md`。本技能支持初次实现、基于 `review-code` 反馈的修复，以及人工裁决驱动实现三种模式。
 
 ## 行为边界 / 关键规则
 
+### 路径与返工
+
+本阶段只消费核心从最新有效分析产物解析出的规范路径事实；未被所选路径包含的阶段不得创建产物。同阶段完成一次修订—复审后再次收到 Changes Requested 时，必须在下一执行产物前提交绑定 finding、来源 SHA 和稳定任务事实摘要的返工分类；轮次或文件名变化不是新证据。
+
 ### 持久化报告证据
 
 生成实现报告时，先读取 `.agents/rules/evidence-reporting.md`。成功测试记录命令、目标范围、状态/结构化结果、实际结果和未覆盖部分；失败、阻塞或争议保留复现入口、准确位置和决定性摘录，不默认粘贴完整成功 stdout。
 
 - 涉及候选资格或 `HD-N` 判断时，先读取 `.agents/rules/decision-qualification.md`，基于 task.md 规范化约束/候选完成资格审计，并在实现报告记录五张资格审计表；不得把来源不明或未确认约束自动升级为排除条件
-- 严格遵循最新方案产物：`plan.md` 或 `plan-r{N}.md`
+- 严格遵循核心选择的最新生命周期输入：精简路径为 `analysis.md` / `analysis-r{N}.md`，标准或完整路径为 `plan.md` / `plan-r{N}.md`
 - 生成会同步到 Issue 的任务或生命周期 Markdown 前，先读取 `.agents/rules/sync-content-generation.md` 并遵循其中的生成端约束；同步端不解析或改写正文
 - 实现前读取 `.agents/rules/compatibility-policy.md`；只实现方案明确批准的兼容预算，不以“稳妥”为由保留旧分支、旧结果契约或迁移 shim
 - 修复模式逐条核实最新 `review-code` 的发现：成立则修复，判定为不成立/幻觉则在报告中反驳并记入 unresolved；不擅自扩大到审查未列出的问题；manual-validation 项不在修复范围
@@ -40,7 +44,7 @@ description: >
 |------|------|
 | 「代码太简单，不需要测试」 | 简单代码也会回归；没有"失败→通过"的用例就没有完成标志，先写验证业务行为的测试。 |
 | 「先写代码再补测试更高效」 | 后补测试常沦为对实现的镜像；目标驱动应先定义可验证用例再让它通过。 |
-| 「方案这里不合理，顺手改更好」 | 偏离 `{plan-artifact}` 必须在报告中记录原因；有异议先停下确认，不擅自改方向。 |
+| 「输入这里不合理，顺手改更好」 | 偏离 `{lifecycle-input-artifact}` 必须在报告中记录原因；有异议按任务规则处理，不擅自改方向。 |
 | 「测试过了，顺便推送一下」 | 本技能只创建本地 checkpoint；远端推送是 `create-pr` 的唯一边界。 |
 | 「审查既然写了，照着改就行」 | 审查可能基于错误 `file:line` 或幻觉；动手前先 Read/Grep 核实，成立才修，不成立就反驳并记入 unresolved，不盲从。 |
 | 「保留旧入口更稳妥，反正只多一个分支」 | 未获批准的兼容是范围扩张和长期债务；没有对象、必要性、期限和退出条件就只实现当前契约。 |
@@ -72,9 +76,8 @@ agent-infra-internal task-snapshot {task-id} --format text
 
 先检查：
 - `.agents/workspace/active/{task-id}/task.md`
-- 至少一个技术方案产物：`plan.md` 或 `plan-r{N}.md`
 
-如果缺少任一文件，立即停止并提示用户先完成前置步骤。
+如果缺少任务文件，立即停止。生命周期输入由步骤 4 的核心查询按已选路径验证；技能不得预先固定要求方案产物。
 
 ### 2. 确保任务分支
 
@@ -105,6 +108,8 @@ status=$?
 echo "$result"
 ```
 
+若 `selection.disposition` 为 `reuse`，复用 `selection.artifact`，不得执行 started、init、代码修改或写入新产物，并直接进入完成校验与下一步提示。其他状态继续按下表处理。
+
 按 `$status` 与 `result.mode` 分流；二者不一致时按 `$status` 为准并报告异常：
 
 | `$status` | `result.mode` | 行动 |
@@ -118,13 +123,13 @@ echo "$result"
 
 > 双模式判定规则见 `reference/dual-mode.md`。执行此步骤前先读取 `reference/dual-mode.md`。
 
-### 5. 确定输入方案
+### 5. 确定生命周期输入
 
-只使用步骤 4 的结构化结果：从 `inputs` 取得 `{plan-artifact}`，从 `next_round` / `next_artifact` 取得 `{code-round}` / `{code-artifact}`；修复模式从 `review_artifact` 取得 `{review-artifact}`；裁决模式从 `implementation_input`、`decision_id`、`decision_evidence` 取得统一输入身份。不得自行扫描轮次或拼装文件名。
+只使用步骤 4 的结构化结果：从 `inputs` 取得核心选择的 `{lifecycle-input-artifact}`（精简路径为 analysis，其他路径为 plan），从 `next_round` / `next_artifact` 取得 `{code-round}` / `{code-artifact}`；修复模式从 `review_artifact` 取得 `{review-artifact}`；裁决模式从 `implementation_input`、`decision_id`、`decision_evidence` 取得统一输入身份。不得自行扫描轮次或拼装文件名。
 
-### 6. 阅读技术方案
+### 6. 阅读生命周期输入
 
-仔细阅读 `{plan-artifact}`，提取：
+仔细阅读 `{lifecycle-input-artifact}`，提取：
 - 实施步骤
 - 需要创建或修改的文件
 - 测试策略
@@ -237,11 +242,11 @@ agent-infra-internal task-verify {task-id} code.completed --artifact {code-artif
 ## 注意事项
 
 - 首轮实现使用 `code.md`，后续轮次使用 `code-r{N}.md`
-- 如偏离 `{plan-artifact}`，必须在报告中记录原因
+- 如偏离 `{lifecycle-input-artifact}`，必须在报告中记录原因
 - 新测试必须验证有意义的业务行为，而不是机械透传
 
 ## 错误处理
 
 - 任务未找到：`Task {task-id} not found`
-- 缺少方案：`Technical plan not found, please run the plan-task skill first`
+- 缺少生命周期输入：透传步骤 4 返回的 `ARTIFACT_INPUT_MISSING`，按所选路径补充 analysis 或 plan
 - 本地修复后仍无法通过测试：说明外部阻塞并停止，且不要创建实现产物

package/templates/.agents/skills/code-task/reference/code-rules.en.md

@@ -14,7 +14,7 @@ Follow the `code` step in `.agents/workflows/feature-development.yaml`.
 - [ ] follow project coding standards
 
 **Implementation principles**:
-1. **Follow the plan strictly**: do not deviate from the technical plan
+1. **Follow the input strictly**: do not deviate from the analysis or plan lifecycle input selected by core
 2. **Work step by step**: execute the planned sequence
 3. **Keep testing continuously**: run the **fast smoke subset** continuously as work progresses (see the `test` skill)
 4. **Keep it simple**: do not add unplanned features
@@ -46,7 +46,7 @@ Two-way failure handling:
 
 ## Notes
 
-1. **Prerequisite**: the approved technical plan must exist (`plan.md` or `plan-r{N}.md`)
+1. **Prerequisite**: the analysis or plan lifecycle input selected by core must exist
 2. **No auto-commit**: do not run `git commit` or `git add`
 3. **Test quality**: new tests must validate meaningful business logic
 4. **Code quality**: follow project coding conventions

package/templates/.agents/skills/code-task/reference/code-rules.zh-CN.md

@@ -14,7 +14,7 @@
 - [ ] 遵守项目编码规范
 
 **实现原则**：
-1. **严格遵循方案**：不要偏离技术方案
+1. **严格遵循输入**：不要偏离核心选择的 analysis 或 plan 生命周期输入
 2. **按步骤推进**：按计划顺序执行
 3. **持续测试**：实现过程中持续运行 **fast smoke 子集**（参见 `test` skill）
 4. **保持简单**：不要加入未计划的功能
@@ -46,7 +46,7 @@
 
 ## 注意事项
 
-1. **前置条件**：必须存在已批准的技术方案（`plan.md` 或 `plan-r{N}.md`）
+1. **前置条件**：必须存在核心按所选路径返回的 analysis 或 plan 生命周期输入
 2. **禁止自动提交**：不要执行 `git commit` 或 `git add`
 3. **测试质量**：新增测试必须验证有意义的业务逻辑
 4. **代码质量**：遵循项目编码规范

package/templates/.agents/skills/code-task/reference/dual-mode.en.md

@@ -8,9 +8,9 @@ This file documents the core artifact lifecycle's code-mode decision. The `task-
 agent-infra-internal task-artifact {task-id} inspect --family code
 ```
 
-The core scans `plan.md` / `plan-r{N}.md`, `review-plan.md` / `review-plan-r{N}.md`, `code.md` / `code-r{N}.md`, and `review-code.md` / `review-code-r{N}.md` in the task directory.
+The core reads the path decision from the latest analysis and selects the lifecycle input: analysis for streamlined, plan for standard or full. The full path also validates review-plan before scanning code and review-code artifacts.
 
-`code.started` persists the plan identity and SHA-256 for the round in task.md frontmatter. `code.completed` uses that start context and verifies the current latest plan; changed input fails closed. The implementation report's `Plan Input` field is reader-facing traceability, not lifecycle identity validation.
+`code.started` persists the lifecycle input identity and SHA-256 for the round in task.md frontmatter. `code.completed` verifies the current latest input against that context; changed input fails closed. The implementation report field is reader-facing traceability only.
 
 ## Eight Branches
 
@@ -18,8 +18,8 @@ The core scans `plan.md` / `plan-r{N}.md`, `review-plan.md` / `review-plan-r{N}.
 
 | Condition | mode | exit | Behavior |
 |---|---|---:|---|
-| no code artifact, and the latest review-plan is exactly `Approved` and references the latest plan | `init` | 0 | initial implementation, output `code.md`; a missing matching approval or `Approved-with-issues` returns an error |
-| latest review-plan is exactly `Approved`, references the latest plan, and the latest code completion receipt does not bind the same plan digest | `init` | 0 | enter a new implementation round. `Approved-with-issues` remains parse-compatible for history but is not cross-stage approval; missing or invalid receipts fail closed |
+| no code artifact and the selected lifecycle input is valid; full also requires an exactly `Approved` review-plan bound to the latest plan | `init` | 0 | initial implementation, output `code.md` |
+| the latest analysis or plan lifecycle input is not bound by the latest code completion receipt | `init` | 0 | enter a new implementation round; missing or invalid receipts fail closed |
 | the latest review-code completion receipt does not bind the latest code identity/SHA | `error` | 2 | latest code is unreviewed; run `review-code`; code and review-code family rounds may advance independently |
 | latest review-code is Approved and a pending implementation input was decided after that review completed | `decision` | 0 | select the earliest `II-N` and enter decision-driven implementation; false/not-required and consumed inputs do not trigger |
 | latest review-code is Approved with 0/0/0 | `refused` | 1 | already approved; do not run `code-task` again |

package/templates/.agents/skills/code-task/reference/dual-mode.zh-CN.md

@@ -8,9 +8,9 @@
 agent-infra-internal task-artifact {task-id} inspect --family code
 ```
 
-核心扫描任务目录中的 `plan.md` / `plan-r{N}.md`、`review-plan.md` / `review-plan-r{N}.md`、`code.md` / `code-r{N}.md` 和 `review-code.md` / `review-code-r{N}.md`。
+核心读取最新 analysis 的路径裁定，并选择生命周期输入：精简路径使用 analysis，标准或完整路径使用 plan；完整路径还校验对应 review-plan。随后扫描 code 与 review-code 产物。
 
-`code.started` 会在 task.md frontmatter 中绑定本轮方案文件及其 SHA-256。`code.completed` 使用该开始上下文并校验当前最新 plan；内容变化失败关闭。实现报告的“方案输入”/“Plan Input”仅供读者追溯，不参与生命周期身份校验。
+`code.started` 会在 task.md frontmatter 中绑定本轮生命周期输入及其 SHA-256。`code.completed` 使用该开始上下文并校验当前最新输入；内容变化失败关闭。实现报告的“生命周期输入”仅供读者追溯，不参与生命周期身份校验。
 
 ## 8 个分支
 
@@ -18,8 +18,8 @@ agent-infra-internal task-artifact {task-id} inspect --family code
 
 | 条件 | mode | exit | 行为 |
 |---|---|---:|---|
-| 无 code 产物，且最新 review-plan 精确为 `Approved` 并引用最新 plan | `init` | 0 | 初次实现，产物为 `code.md`；缺少匹配审批或为 `Approved-with-issues` 时返回 error |
-| 最新 review-plan 精确为 `Approved`，且其「审查输入」/「Review Input」字段引用最新 plan，而最新 code 的完成 receipt 未绑定相同 plan 摘要 | `init` | 0 | plan 内容在 code 输入之后获批；进入新一轮实现。`Approved-with-issues` 仅保留历史解析兼容，不构成跨阶段批准；缺失或无效 receipt 失败关闭 |
+| 无 code 产物，且所选生命周期输入有效；完整路径的最新 review-plan 还必须精确为 `Approved` 并引用最新 plan | `init` | 0 | 初次实现，产物为 `code.md` |
+| 最新 analysis 或 plan 生命周期输入未被最新 code 完成 receipt 绑定 | `init` | 0 | 输入在上轮 code 后发生有效变化，进入新一轮实现；缺失或无效 receipt 失败关闭 |
 | 最新 review-code 的完成收据未绑定最新 code identity/SHA | `error` | 2 | 最新代码未审查，先运行 `review-code`；code 与 review-code 的 family 轮次可独立增长 |
 | 最新 review-code 为 Approved 且存在审查完成后产生的 pending 实现输入 | `decision` | 0 | 选择最早 `II-N`，进入裁决驱动实现；false/not-required 与 consumed 输入不触发 |
 | 最新 review-code 为 Approved 且 0/0/0 | `refused` | 1 | 已通过，无需再次运行 `code-task` |

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

@@ -17,7 +17,7 @@ Use this structure when creating `code.md` or `code-r{N}.md`.
 ## Implementation Input
 
 - **Mode**: {init / fix / decision}
-- **Plan Input**: `{plan-artifact}`
+- **Lifecycle Input**: `{lifecycle-input-artifact}`
 - **Review Input**: `{review-artifact or N/A}`
 - **Decision Input**: `{implementation-input or N/A}`
 - **Ledger ID**: `{decision-id or N/A}`

package/templates/.agents/skills/code-task/reference/report-template.zh-CN.md

@@ -17,7 +17,7 @@
 ## 实现输入
 
 - **模式**：{init / fix / decision}
-- **方案输入**：`{plan-artifact}`
+- **生命周期输入**：`{lifecycle-input-artifact}`
 - **审查输入**：`{review-artifact 或 N/A}`
 - **裁决输入**：`{implementation-input 或 N/A}`
 - **账本 ID**：`{decision-id 或 N/A}`

package/templates/.agents/skills/complete-manual-validation/SKILL.en.md

@@ -21,7 +21,7 @@ Before generating the validation completion report, read `.agents/rules/evidence
 - This skill closes the manual-validation status in an existing PR summary comment; it does not create a parallel ordinary validation comment.
 - It must write `manual-validation.md` or `manual-validation-r{N}.md` so later PR summary refreshes can reuse the validation result.
 - If the `sync-pr` summary comment is missing, fail instead of creating a partial fallback summary; before the receipt, completion log, and final summary are all committed, the remote summary may only be pending/non-pass.
-- Before generating manual-validation artifact Markdown that will be synced to an Issue, read `.agents/rules/sync-content-generation.md` and follow its generator-side constraints; Issue sync remains transparent and does not parse or rewrite the body.
+- Before generating manual-validation artifact Markdown referenced by the task comment and PR summary, read `.agents/rules/sync-content-generation.md` and follow its generator-side constraints. Keep the artifact local instead of publishing it as an Issue artifact comment.
 - After this skill runs, update `task.md` immediately.
 
 Version stamp rule: when creating or updating `task.md` frontmatter, read `.agents/rules/version-stamp.md` first and write or refresh `agent_infra_version`.
@@ -106,7 +106,7 @@ The coordinator owns pending summary, receipt, completion log, final promotion,
 
 After the transaction coordinator succeeds, the core has atomically recorded `manual-validation.completed` with the same transaction/receipt/head identity. Do not append the Activity Log manually.
 
-If the task has a valid `platform_issue_identity`, run `agent-infra-internal platform-comment sync {task-id} --kind task --agent {standard-agent-token}`, then `agent-infra-internal platform-comment sync {task-id} --kind artifact --artifact {manual-validation-artifact} --agent {standard-agent-token}`.
+If the task has a valid `platform_issue_identity`, run only `agent-infra-internal platform-comment sync {task-id} --kind task --agent {standard-agent-token}`. Keep the manual-validation artifact as local evidence and PR-summary input; do not publish it as an Issue comment.
 
 ### 8. Verification Gate
 

package/templates/.agents/skills/complete-manual-validation/SKILL.zh-CN.md

@@ -21,7 +21,7 @@ description: >
 - 本技能用于收尾已有 PR 摘要评论中的人工校验状态，不创建并行的普通验证留言。
 - 必须写入 `manual-validation.md` 或 `manual-validation-r{N}.md`，让后续 PR 摘要刷新可复用人工验证结果。
 - 找不到 `sync-pr` 摘要评论时失败，不创建部分摘要兜底；receipt、通过日志和 final summary 未全部提交前，远端只允许 pending/non-pass 状态。
-- 生成会同步到 Issue 的人工验证 artifact Markdown 前，先读取 `.agents/rules/sync-content-generation.md` 并遵循其中的生成端约束；Issue 同步保持透明，不解析或改写正文。
+- 生成会由 task 评论和 PR 摘要引用的人工验证 artifact Markdown 前，先读取 `.agents/rules/sync-content-generation.md` 并遵循其中的生成端约束；人工验证 artifact 保留在本地，不发布为 Issue artifact 评论。
 - 执行本技能后必须立即更新 `task.md`。
 
 版本戳规则：创建或更新 `task.md` frontmatter 时，先读取 `.agents/rules/version-stamp.md`，并写入或刷新 `agent_infra_version`。
@@ -106,7 +106,7 @@ coordinator 负责 pending summary、receipt、通过日志、final promotion
 
 transaction coordinator 成功后，核心已使用同一 transaction/receipt/head identity 原子登记 `manual-validation.completed`；不要手工补写 Activity Log。
 
-如任务存在有效 `platform_issue_identity`，调用 `agent-infra-internal platform-comment sync {task-id} --kind task --agent {standard-agent-token}`，再调用 `agent-infra-internal platform-comment sync {task-id} --kind artifact --artifact {manual-validation-artifact} --agent {standard-agent-token}`。
+如任务存在有效 `platform_issue_identity`，仅调用 `agent-infra-internal platform-comment sync {task-id} --kind task --agent {standard-agent-token}`。人工验证 artifact 继续作为本地证据和 PR 摘要输入，不发布为 Issue 评论。
 
 ### 8. 完成校验
 

package/templates/.agents/skills/complete-task/SKILL.en.md

@@ -9,7 +9,7 @@ description: >
 # Complete Task
 > `--agent` values are defined in `.agents/rules/task-management.md` under “Collaborator Token Specification”.
 
-Host finalization uses receipt v3 with an immutable `receiptId`, monotonic `revision`, staged summary input, and canonical warnings. Lifecycle/identity/required-PR hard failures return `result: failed|blocked`; after lifecycle succeeds, comment, peripheral verification, and other sync failures return `result: completed_with_warnings` and six-field warnings, retrying only receipt-pending steps.
+Host finalization uses receipt v4 with an immutable `receiptId`, monotonic `revision`, staged summary input, and canonical warnings. Lifecycle/identity/required-PR hard failures return `result: failed|blocked`; after lifecycle succeeds, it retries only receipt-pending peripheral steps or open backfill warnings. Per-check verification warnings transition by observed target: a later observation resolves the prior code while retaining its history, and unobserved targets remain unchanged.
 
 
 ## Boundary / Critical Rules
@@ -59,7 +59,7 @@ If not found in `active/`, check `blocked/` and `completed/`:
 - If in `completed/` without a matching entry: report the incomplete terminal identity and stop without hand-repairing it
 - If in `blocked/`: Inform user the task is blocked; suggest unblocking first
 
-Scenario A is the normal active-task path. Scenario B `finalization-retry` retries only the archived task comment and terminal gate.
+Scenario A is the normal active-task path. Scenario B `finalization-retry` retries allowed artifact backfill, the terminal task comment, completion verification, and summary sealing without moving lifecycle backward.
 
 ### 2. Verify Completion Prerequisites (Failure Must Stop)
 
@@ -141,9 +141,8 @@ Check whether task.md has a valid `platform_issue_identity`. If it does not, ski
 
 When a valid `platform_issue_identity` exists, execute in this exact order:
 
-1. Run `agent-infra-internal platform-comment backfill {task-id} --agent {standard-agent-token}` so core publishes only the completion canonical inventory in fixed order and resolves matching historical warnings only after full success.
-2. Run `agent-infra-internal platform-issue sync {task-id} --agent {standard-agent-token} --requirements --fields`.
-3. Write the business summary to a temporary file and run `agent-infra-internal platform-comment stage-summary {task-id} --body-file {path}`. This stores the body and SHA-256 in the task's durable staging record; it must not publish the summary comment directly.
+1. Run `agent-infra-internal platform-issue sync {task-id} --agent {standard-agent-token} --requirements --fields`.
+2. Write the business summary to a temporary file and run `agent-infra-internal platform-comment stage-summary {task-id} --body-file {path}`. This stores the body and SHA-256 in the task's durable staging record; it must not publish the summary comment directly.
 
 When the ledger contains a valid `PRC-N` post-review exemption, the summary body must mirror the ruling reason, commit scope, human identity, and time from task.md, and state that this is a human override rather than an automatic verification success. If a matching workflow warning exists, also mirror its original failure code/message. If no warning exists yet, state only that the ruling is recorded and final gate verification is pending; do not claim that the exemption has passed. The same `--kind summary` intent remains the sole owner of the summary marker.
 
@@ -152,7 +151,7 @@ Do not sync the task comment here; it requires the terminal task.md written by l
 If any operation fails, the task must remain active and its short id must remain valid. Record the failure with the matching structured warning intent, then continue to Step 5. Platform failures do not block the local lifecycle:
 
 ```bash
-agent-infra-internal task-warning {task-id} add --step complete-task --severity ACTION_REQUIRED --code {COMMENT_SYNC_FAILED|REQUIREMENTS_SYNC_FAILED|SUMMARY_SYNC_FAILED|NETWORK_RETRY_EXHAUSTED} --target {artifact|issue|summary|platform} --message "{error_code}: {error_message}" --action "Fix the platform sync problem and rerun complete-task"
+agent-infra-internal task-warning {task-id} add --step complete-task --severity ACTION_REQUIRED --code {REQUIREMENTS_SYNC_FAILED|SUMMARY_SYNC_FAILED|NETWORK_RETRY_EXHAUSTED} --target {issue|summary|platform} --message "{error_code}: {error_message}" --action "Fix the platform sync problem and rerun complete-task"
 ```
 
 The core deduplicates the stable `step/code/target` tuple. Callers must not allocate warning ids or edit ledger rows.
@@ -177,11 +176,11 @@ If a summary must mirror a human-decided `post-review-commit` exemption, make a
 agent-infra-internal task-finalization {task-id} complete --agent {standard-agent-token}
 ```
 
-Finalization runs lifecycle -> terminal task comment -> core verification -> warning task-comment update -> summary -> post-summary verification in a fixed order and records every step in the host receipt. It clears the staging record only after all steps finish with no open warning. `result=completed` means the host safely completed the task from structured results and the receipt; if peripheral warnings remain, return `result=completed_with_warnings`, warnings, and pending steps. Use `result=failed` or `result=blocked` only for hard or receipt/capability failures, then fix the cause and retry through the same entry point; do not claim completion or hand-repair partial state. A sandbox must not run `ls completed` or a local terminal verification against its historical mount to re-decide this result.
+Finalization runs allowed artifact backfill -> lifecycle -> terminal task comment -> core verification -> warning task-comment update -> summary seal in a fixed order. Every backfill that actually runs must reach a successful terminal result before lifecycle starts; an ordinary replay with a complete receipt and no recovery fact does not rerun backfill, comments, verification, or summary. A completed recovery that may write a managed comment first persists a done summary as pending, then seals it only at the end. Summary seal always reads the durable staging record retained in the task directory; the platform entry point validates marker, owner, and digest, performs any required delete/recreate, and reads back final remote order. `result=completed` means the host safely completed the task from structured results and the receipt; if peripheral warnings or pending steps remain, return `result=completed_with_warnings`, warnings, and pending steps. Use `result=failed` or `result=blocked` only for hard or receipt/capability failures, then fix the cause and retry through the same entry point; do not claim completion or hand-repair partial state. A sandbox must not run `ls completed` or a local terminal verification against its historical mount to re-decide this result.
 
 ### 7. Handle Finalization Retries and Results
 
-Both Scenario A and Scenario B `finalization-retry` run the same `task-finalization` entry point from the host. The receipt is only a re-entry hint, not canonical truth: every re-entry revalidates the terminal task comment and completion gate; only an already `completed` task with its short-id registry entry released may skip the irreversible lifecycle. Do not split the operation into the former lifecycle, comment-sync, or completion-gate commands. If the task comment or gate is blocked by the network, preserve the receipt and completed steps, fix the network, and rerun complete-task. If lifecycle has not completed, keep the task active and resume the pending steps from the receipt.
+Both Scenario A and Scenario B `finalization-retry` run the same `task-finalization` entry point from the host. The receipt is only a re-entry hint, not canonical truth: every re-entry revalidates allowed artifact backfill, the terminal task comment, and completion verification, then repeats summary seal from the retained durable staging record; only an already `completed` task with its short-id registry entry released may skip the irreversible lifecycle. Do not split the operation into the former lifecycle, comment-sync, or completion-gate commands. If backfill, the task comment, summary seal, or verification is blocked by the network, preserve the receipt, durable staging record, and completed steps, fix the network, and rerun complete-task. If lifecycle has not completed, keep the task active and resume the pending steps from the receipt.
 
 Consume the structured finalization result, receipt, and warning projection directly. Continue only for `completed` or `completed_with_warnings`; preserve the receipt and stop for `failed`, `blocked`, or `unknown`, then retry through the same finalization entry point. Do not run `ls completed` or `task-verify complete-task.completed` from a stale sandbox mount, and do not let that local result overrule the host result.
 

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

@@ -9,7 +9,7 @@ description: >
 # 完成任务
 > `--agent` 取值见 `.agents/rules/task-management.md`「合作者 token 规范」。
 
-宿主 finalization 使用 receipt v3（不可变 `receiptId`、单调 `revision`、摘要暂存和 canonical warnings）。生命周期/身份/required PR 等硬失败返回 `result: failed|blocked`；生命周期完成后，评论、外围验证和其他同步失败返回 `result: completed_with_warnings` 及六字段 warning，并仅重试 receipt 中的 pending step。
+宿主 finalization 使用 receipt v4（不可变 `receiptId`、单调 `revision`、摘要暂存和 canonical warnings）。生命周期/身份/required PR 等硬失败返回 `result: failed|blocked`；生命周期完成后，只重试 receipt 指出的 pending 外围步骤或 open backfill warning。逐检查 verification warning 以 observed target 为单位转换：新观察替代旧 code 时保留旧行 resolved 历史，未观察的 target 不变。
 
 
 ## 行为边界 / 关键规则
@@ -58,7 +58,7 @@ agent-infra-internal task-snapshot {task-id} --format text
 - 如果在 `completed/` 但缺少匹配日志：告知用户任务已完成但终态身份不完整并停止，不手工修补
 - 如果在 `blocked/`：告知用户任务被阻塞；建议先解除阻塞
 
-场景 A 为 active 任务的正常完成路径；场景 B `finalization-retry` 只重试归档后的 task 评论与终态门禁。
+场景 A 为 active 任务的正常完成路径；场景 B `finalization-retry` 重试允许的 artifact 回填、终态 task 评论、完成校验和摘要封口，不回迁生命周期。
 
 ### 2. 验证完成前置条件（未满足则必须停止）
 
@@ -140,9 +140,8 @@ Please satisfy the hard prerequisite first, then retry complete-task.
 
 如果存在有效的 `platform_issue_identity`，严格按以下顺序执行：
 
-1. 调用 `agent-infra-internal platform-comment backfill {task-id} --agent {standard-agent-token}`，由 core 仅按 completion canonical inventory 固定顺序补发产物并在全部成功后精确恢复目标历史告警。
-2. 调用 `agent-infra-internal platform-issue sync {task-id} --agent {standard-agent-token} --requirements --fields`。
-3. 把业务摘要写入临时文件，并调用 `agent-infra-internal platform-comment stage-summary {task-id} --body-file {path}`。该命令把正文和 SHA-256 写入 task 目录的 durable staging record；本步骤不得直接发布 summary 评论。
+1. 调用 `agent-infra-internal platform-issue sync {task-id} --agent {standard-agent-token} --requirements --fields`。
+2. 把业务摘要写入临时文件，并调用 `agent-infra-internal platform-comment stage-summary {task-id} --body-file {path}`。该命令把正文和 SHA-256 写入 task 目录的 durable staging record；本步骤不得直接发布 summary 评论。
 
 若账本含合法的 `PRC-N` post-review 豁免，摘要正文必须镜像 task.md 中的裁决理由、提交范围、人工身份与时间，并明确这是人工覆盖而非自动校验成功。已有匹配 workflow warning 时，同时镜像其原始 failure code/message；尚无 warning 时只写“裁决已记录、最终门禁待验证”，不得提前宣称豁免已通过。summary marker 仍由同一 `--kind summary` intent 唯一维护。
 
@@ -151,7 +150,7 @@ Please satisfy the hard prerequisite first, then retry complete-task.
 任一操作失败时，任务仍必须位于 active 且短号仍有效；按失败类型调用以下结构化 warning intent，随后继续步骤 5。平台失败不会阻止本地生命周期。
 
 ```bash
-agent-infra-internal task-warning {task-id} add --step complete-task --severity ACTION_REQUIRED --code {COMMENT_SYNC_FAILED|REQUIREMENTS_SYNC_FAILED|SUMMARY_SYNC_FAILED|NETWORK_RETRY_EXHAUSTED} --target {artifact|issue|summary|platform} --message "{error_code}: {error_message}" --action "修复平台同步问题后重跑 complete-task"
+agent-infra-internal task-warning {task-id} add --step complete-task --severity ACTION_REQUIRED --code {REQUIREMENTS_SYNC_FAILED|SUMMARY_SYNC_FAILED|NETWORK_RETRY_EXHAUSTED} --target {issue|summary|platform} --message "{error_code}: {error_message}" --action "修复平台同步问题后重跑 complete-task"
 ```
 
 相同 `step/code/target` 组合由核心幂等去重；调用方不分配 warning id 或手写账本行。
@@ -176,11 +175,11 @@ agent-infra-internal task-verify {task-id} complete-task.preflight --format text
 agent-infra-internal task-finalization {task-id} complete --agent {standard-agent-token}
 ```
 
-finalization 按 lifecycle → task 评论 → core verification → warning task 评论更新 → summary → post-summary verification 的固定顺序执行，并将每一步的状态写入宿主 receipt。summary 使用暂存正文；仅在所有步骤完成且无未解决 warning 后清理 staging record。`result=completed` 即表示宿主已依据结构化结果和 receipt 安全完成；若还有外围 warning，返回 `result=completed_with_warnings`、warnings 和 pending steps。`result=failed` 或 `result=blocked` 仅用于硬失败或 receipt/capability 失败，修复原因后以同一入口重试，不得宣称完成或手工补写局部状态。沙箱不得从旧挂载执行 `ls completed` 或本地终态校验来重新裁决该结果。
+finalization 按允许的 artifact backfill → lifecycle → task 评论 → core verification → warning task 评论更新 → summary seal 的固定顺序执行。每项实际运行的 backfill 必须取得成功终态，否则不得进入 lifecycle；完整 receipt 且无恢复事实的普通重入不执行 backfill、评论、验证或 summary。任何可能写入 managed comment 的 completed 恢复会先把 done summary 持久化为 pending，恢复末尾才重新 seal。summary seal 始终读取任务目录中保留的 durable staging record；平台入口负责校验 marker、owner 和 digest，必要时删除并重建摘要，再复读最终远端顺序。`result=completed` 即表示宿主已依据结构化结果和 receipt 安全完成；若还有外围 warning 或 pending step，返回 `result=completed_with_warnings`、warnings 和 pending steps。`result=failed` 或 `result=blocked` 仅用于硬失败或 receipt/capability 失败，修复原因后以同一入口重试，不得宣称完成或手工补写局部状态。沙箱不得从旧挂载执行 `ls completed` 或本地终态校验来重新裁决该结果。
 
 ### 7. 处理 finalization 重试与结果
 
-场景 A 与场景 B `finalization-retry` 都从宿主执行同一个 `task-finalization` 入口。receipt 只是重入提示，不是 canonical truth：每次重入都要重新验证终态 task 评论和完成校验；只有任务已处于 `completed` 且短号 registry 已释放时，才可跳过不可逆的 lifecycle。不得拆开调用旧的 lifecycle、评论同步或完成校验命令。若 task 评论或校验因网络问题返回 `blocked`，保留 receipt 和已完成状态，修复网络后重跑 complete-task；若生命周期仍未完成，任务保持 active 并从 receipt 的待处理步骤继续。
+场景 A 与场景 B `finalization-retry` 都从宿主执行同一个 `task-finalization` 入口。receipt 只是重入提示，不是 canonical truth：每次重入都要重新核对允许的 artifact 回填、终态 task 评论、完成校验，并使用保留的 durable staging record 重做 summary seal；只有任务已处于 `completed` 且短号 registry 已释放时，才可跳过不可逆的 lifecycle。不得拆开调用旧的 lifecycle、评论同步或完成校验命令。若回填、task 评论、summary seal 或校验因网络问题返回 `blocked`，保留 receipt、durable staging record 和已完成状态，修复网络后重跑 complete-task；若生命周期仍未完成，任务保持 active 并从 receipt 的待处理步骤继续。
 
 完成结果必须直接消费本次宿主 finalization 的结构化输出、receipt 和 warning projection。`completed` 或 `completed_with_warnings` 才允许继续；`failed` / `blocked` / `unknown` 必须保留 receipt 并停止，之后通过同一 finalization 入口重试。不要在沙箱旧挂载中另行运行 `ls completed` 或 `task-verify complete-task.completed`，也不要用其结果推翻宿主结果。
 

package/templates/.agents/skills/plan-task/SKILL.en.md

@@ -13,13 +13,17 @@ If the entry operands contain `--orchestrated`, bind `{execution-flag}` to `--or
 
 ## Boundary / Critical Rules
 
+### Path and rework
+
+This stage consumes only the canonical path fact parsed by core from the latest valid analysis artifact; a stage omitted by that path must not create an artifact. When another Changes Requested verdict follows one completed revision-review cycle in the same stage, classify the rework before the next executor artifact and bind it to the finding, source SHA, and stable task-fact digest. A round or filename change is not new evidence.
+
 ### Persisted Report Evidence
 
 Before generating the plan report, read `.agents/rules/evidence-reporting.md`. Record the command, target scope, status or structured result, actual result, and uncovered parts for state checks and verification; include decisive raw excerpts only for failures, blocking conditions, or disputes.
 
 - When evaluating candidate qualification or `HD-N`, read `.agents/rules/decision-qualification.md`, audit normalized task constraints/candidates, and record the five qualification-audit tables in the plan artifact; unknown or unconfirmed constraints must not automatically exclude a candidate
 - This skill only outputs a technical plan document (`plan.md` or `plan-r{N}.md`) and does not modify any business code
-- This is a **mandatory human review checkpoint**; do not automatically proceed to implementation
+- The full path proceeds to plan review; the standard path may proceed directly to implementation
 - 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
 - When the plan touches compatibility, migration, old formats, or old entry points, read `.agents/rules/compatibility-policy.md` first. Do not design adapters, shims, dual writes, or parallel state machines without passing its admission gate
 - After executing this skill, you **must** immediately update task status in task.md
@@ -62,7 +66,7 @@ If any required file is missing, prompt the user to complete the prerequisite st
 
 ### 2. Resolve the Artifact Context
 
-Run `agent-infra-internal task-artifact {task-id} inspect --family plan`. Continue only for `ready`; take the latest `{analysis-artifact}` from `inputs` and `{plan-round}` / `{plan-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 plan`. 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 `{analysis-artifact}` from `inputs` and `{plan-round}` / `{plan-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 Requirements Analysis
 
@@ -169,7 +173,9 @@ Keep the gate output in your reply as fresh evidence. Do not claim completion wi
 > Before rendering next steps, read `.agents/rules/next-step-output.md`, invoke the shared helper only for the selected scenario, and insert its stdout at `{next-step-commands}`.
 
 Output format:
-Populate `{next-step-commands}` for this scenario by running `agent-infra-internal agent-client next-steps --skill review-plan --task-ref {task-ref}`.
+Select one command from the canonical path to populate `{next-step-commands}`:
+- Standard: `agent-infra-internal agent-client next-steps --skill code-task --task-ref {task-ref}`
+- Full: `agent-infra-internal agent-client next-steps --skill review-plan --task-ref {task-ref}`
 
 ```
 Technical plan complete for task {task-id}.
@@ -184,10 +190,7 @@ Plan summary:
 Output file:
 - Technical plan: .agents/workspace/active/{task-id}/{plan-artifact}
 
-Important: human review checkpoint.
-Please review the technical plan before continuing to implementation.
-
-Next step - review the technical plan:
+Next step - continue on the selected path:
 {next-step-commands}
 ```
 
@@ -201,18 +204,18 @@ Next step - review the technical plan:
 - [ ] Recorded `{plan-artifact}` as a completed artifact in task.md
 - [ ] Marked technical-design as complete in workflow progress
 - [ ] Appended an Activity Log entry to task.md
-- [ ] Informed the user that this is a human review checkpoint
+- [ ] Selected code implementation or plan review from the canonical path
 - [ ] Rendered the selected next-step commands through the shared helper
 
 ## STOP
 
 After completing the checklist, **stop immediately**.
-This is a **mandatory human review checkpoint**; the user must review and approve the plan before implementation can continue.
+The full path proceeds to plan review here; the standard path proceeds directly to code implementation.
 
 ## Notes
 
 1. **Prerequisite**: at least one round of requirements analysis must already be complete (`analysis.md` or `analysis-r{N}.md` exists)
-2. **Human review**: this is a mandatory checkpoint; do not automatically proceed to implementation
+2. **Next stage**: standard proceeds to code implementation; full proceeds to plan review
 3. **Plan quality**: the plan should be detailed enough that another AI agent can implement it without extra context
 4. **Versioning rule**: the first plan uses `plan.md`; later revisions use `plan-r{N}.md`
 

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

@@ -13,6 +13,10 @@ description: >
 
 ## 行为边界 / 关键规则
 
+### 路径与返工
+
+本阶段只消费核心从最新有效分析产物解析出的规范路径事实；未被所选路径包含的阶段不得创建产物。同阶段完成一次修订—复审后再次收到 Changes Requested 时，必须在下一执行产物前提交绑定 finding、来源 SHA 和稳定任务事实摘要的返工分类；轮次或文件名变化不是新证据。
+
 ### 持久化报告证据
 
 生成方案报告时，先读取 `.agents/rules/evidence-reporting.md`。状态核对和验证记录命令、目标范围、状态/结构化结果、实际结果和未覆盖部分；失败、阻塞或争议才附决定性原文摘录。
@@ -20,7 +24,7 @@ description: >
 - 涉及候选资格或 `HD-N` 判断时，先读取 `.agents/rules/decision-qualification.md`，基于 task.md 规范化约束/候选完成资格审计，并在方案产物记录五张资格审计表；不得把来源不明或未确认约束自动升级为排除条件
 - 本技能仅产出技术方案文档（`plan.md` 或 `plan-r{N}.md`）—— 不修改任何业务代码
 - 生成会同步到 Issue 的任务或生命周期 Markdown 前，先读取 `.agents/rules/sync-content-generation.md` 并遵循其中的生成端约束；同步端不解析或改写正文
-- 这是一个**强制性的人工审查检查点** —— 不要自动进入实现阶段
+- 完整路径进入方案审查；标准路径完成方案后可直接进入实现阶段
 - 方案涉及兼容、迁移、旧格式或旧入口时，先读取 `.agents/rules/compatibility-policy.md`；未通过准入门槛时不得设计 adapter、shim、双写或并行状态机
 - 执行本技能后，你**必须**立即更新 task.md 中的任务状态
 
@@ -65,7 +69,7 @@ agent-infra-internal task-event {task-id} plan.started --agent {standard-agent-t
 
 ### 2. 解析方案上下文
 
-运行 `agent-infra-internal task-artifact {task-id} inspect --family plan`。仅当结果为 `ready` 时继续；从 `inputs` 取得最新 `{analysis-artifact}`，从 `next.round` / `next.name` 取得 `{plan-round}` / `{plan-artifact}`。不得自行扫描轮次或拼装文件名。随后执行 started 事件并复核返回身份。
+运行 `agent-infra-internal task-artifact {task-id} inspect --family plan`。仅当结果为 `ready` 时继续。若 `selection.disposition` 为 `reuse`，复用 `selection.artifact`，不得执行 started、init 或写入新产物，并直接进入完成校验与下一步提示。其他状态从 `inputs` 取得最新 `{analysis-artifact}`，从 `next.round` / `next.name` 取得 `{plan-round}` / `{plan-artifact}`；不得自行扫描轮次或拼装文件名。随后执行 started 事件并复核返回身份。
 
 ### 3. 阅读需求分析
 
@@ -165,7 +169,9 @@ agent-infra-internal task-verify {task-id} plan.completed --artifact {plan-artif
 > 渲染下一步前先读取 `.agents/rules/next-step-output.md`，仅为已选场景调用统一 helper，并将 stdout 填入 `{next-step-commands}`。
 
 输出格式：
-使用 `agent-infra-internal agent-client next-steps --skill review-plan --task-ref {task-ref}` 生成本场景的 `{next-step-commands}`。
+按分析中的规范路径选择一条命令生成 `{next-step-commands}`：
+- 标准路径：`agent-infra-internal agent-client next-steps --skill code-task --task-ref {task-ref}`
+- 完整路径：`agent-infra-internal agent-client next-steps --skill review-plan --task-ref {task-ref}`
 
 ```
 任务 {task-id} 技术方案完成。
@@ -180,10 +186,7 @@ agent-infra-internal task-verify {task-id} plan.completed --artifact {plan-artif
 产出文件：
 - 技术方案：.agents/workspace/active/{task-id}/{plan-artifact}
 
-重要：人工审查检查点。
-请在继续实现之前审查技术方案。
-
-下一步 - 审查技术方案：
+下一步 - 按所选路径继续：
 {next-step-commands}
 ```
 
@@ -197,18 +200,18 @@ agent-infra-internal task-verify {task-id} plan.completed --artifact {plan-artif
 - [ ] 在 task.md 中记录了 `{plan-artifact}` 为已完成产物
 - [ ] 在工作流进度中标记了 technical-design 为已完成
 - [ ] 追加了 Activity Log 条目到 task.md
-- [ ] 告知了用户这是人工审查检查点
+- [ ] 已按所选路径选择代码实现或方案审查
 - [ ] 已通过统一 helper 渲染已选场景的下一步命令
 
 ## 停止
 
 完成检查清单后，**立即停止**。
-这是一个**强制性的人工审查检查点** —— 用户必须审查并批准计划后才能继续实现。
+完整路径在此进入方案审查；标准路径直接进入代码实现。
 
 ## 注意事项
 
 1. **前置条件**：必须已完成至少一轮需求分析（`analysis.md` 或 `analysis-r{N}.md` 存在）
-2. **人工审查**：这是强制性检查点 —— 不要自动进入实现阶段
+2. **后续阶段**：标准路径进入代码实现，完整路径进入方案审查
 3. **计划质量**：计划应足够具体，使另一个 AI 代理无需额外上下文即可实现
 4. **版本化规则**：首轮方案使用 `plan.md`；后续修订使用 `plan-r{N}.md`