@fitlab-ai/agent-infra 0.12.0 → 0.12.2

package/templates/.agents/skills/commit/reference/pr-summary-sync.zh-CN.md

@@ -3,7 +3,7 @@
 仅当 `{task-id}` 有效且 `task.md` 存在 `bound/verified` 的 `pr_delivery_fact` 时执行；否则跳过。
 
 1. 调用 `agent-infra-internal platform-pr summary-context {task-id}` 获取 canonical 聚合输入和报告状态；sidecar stale/missing 时先按 `change-report` 流程重建当前 head 报告。
-2. 按 `.agents/rules/pr-sync.md` 生成只含一次 `<!-- canonical-pr-change-report -->` 的纯摘要正文并写入临时文件。
+2. 按 `.agents/rules/pr-sync.md` 生成完整 PR 摘要 JSON payload 并写入临时文件；字段和零值状态由内容合同规定。
 3. 调用 `agent-infra-internal platform-pr summary-sync {task-id} --agent {standard-agent-token} --body-file {summary-body-file} --change-report-file <task-workspace>/active/{task-id}/pr-change-report.json --result no_op`。commit 路径只同步已有 PR 摘要，不创建或复用 PR，因此固定使用 `no_op` 表示 PR 身份未变化。
 
 同步失败只记录 warning，不阻塞或回滚已经完成的 commit。`no-op` 回传 `summary skipped (no diff)`。

package/templates/.agents/skills/complete-manual-validation/reference/summary-update.en.md

@@ -4,7 +4,7 @@ Run only for a valid `{task-id}` whose task.md binds a verified `pr_delivery_fac
 
 Follow `.agents/rules/pr-sync.md` for the shared summary structure and failure semantics.
 
-1. Run `agent-infra-internal platform-pr summary-context {task-id}` to obtain the canonical summary body; the maintainer's PR validation comment and validation summary are the human-validation authority.
+1. Run `agent-infra-internal platform-pr summary-context {task-id}` to obtain canonical summary facts. `--summary-file` uses the complete PR summary JSON payload; the maintainer's PR validation comment and validation summary are the human-validation authority.
 2. Before creating the canonical `manual-validation*` artifact, call the transaction coordinator in prepare mode to record `started` before writing the prepared transaction:
 
 ```bash
@@ -13,7 +13,7 @@ agent-infra-internal manual-validation transaction {task-id} --prepare \
   --summary-file {summary-body-file} --agent {standard-agent-token}
 ```
 
-3. After prepare succeeds, write the canonical `manual-validation*` artifact, write the pending plain body with exactly one `<!-- canonical-pr-change-report -->` placeholder to a temporary file, and run the transaction coordinator:
+3. After prepare succeeds, write the canonical `manual-validation*` artifact, set the JSON payload's `manualValidation.state` to `pending` with a non-empty explanation, and run the transaction coordinator:
 
 ```bash
 agent-infra-internal manual-validation transaction {task-id} \

package/templates/.agents/skills/complete-manual-validation/reference/summary-update.zh-CN.md

@@ -4,7 +4,7 @@
 
 摘要结构与失败语义统一遵循 `.agents/rules/pr-sync.md`。
 
-1. 调用 `agent-infra-internal platform-pr summary-context {task-id}`，取得 canonical 摘要正文；维护者提供的 PR 人工验证留言和验证说明作为完成人工校验依据。
+1. 调用 `agent-infra-internal platform-pr summary-context {task-id}`，取得 canonical 摘要事实；`--summary-file` 使用完整 PR 摘要 JSON payload，维护者提供的 PR 人工验证留言和验证说明作为完成人工校验依据。
 2. 在创建 canonical `manual-validation*` artifact 前，调用 transaction coordinator 的 prepare 模式，先登记 started，再写 prepared transaction：
 
 ```bash
@@ -13,7 +13,7 @@ agent-infra-internal manual-validation transaction {task-id} --prepare \
   --summary-file {summary-body-file} --agent {standard-agent-token}
 ```
 
-3. prepare 成功后写入 canonical `manual-validation*` artifact，并把只含一次 `<!-- canonical-pr-change-report -->` 的 pending 正文写入临时文件，调用 transaction coordinator：
+3. prepare 成功后写入 canonical `manual-validation*` artifact，并将 JSON payload 中 `manualValidation` 设置为 `pending`、提供非空说明后写入临时文件，调用 transaction coordinator：
 
 ```bash
 agent-infra-internal manual-validation transaction {task-id} \

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

@@ -18,8 +18,7 @@ Host finalization uses receipt v4 with an immutable `receiptId`, monotonic `revi
 
 Before generating a completion report or synchronized content, read `.agents/rules/evidence-reporting.md`. Successful checks record the command, 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.
 
-- This command updates task metadata AND physically moves the task directory
-- Do not move a task that has incomplete workflow steps unless forced
+- Host finalization updates task metadata and atomically moves the task directory
 - The entry point accepts optional `--external-pr <N>` only to select among ambiguous external-delivery candidates; it never bypasses identity or platform gates
 
 Version stamp rule: when creating or updating `task.md` frontmatter, read `.agents/rules/version-stamp.md` first and write or refresh `agent_infra_version`.
@@ -142,7 +141,7 @@ 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-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.
+2. Write the completion summary as JSON fields `taskId`, `title`, `summary`, `artifacts`, and `verification:{state,detail}`, then run `agent-infra-internal platform-comment stage-summary {task-id} --body-file {path}`. Use the current artifact registry (`[]` when empty). If final verification has not run, use `state:"not-run"` with a non-empty explanation. The command persists the normalized payload; do not publish the summary comment in this step.
 
 The summary body records only delivery results, the associated PR and actual merge facts, verification commands with their scope/results/uncovered areas, and known todo items supported by current task evidence. Include the related commit when it helps explain verification scope. Do not infer unsupported facts; list unfinished work as a todo. This is an Issue closeout summary, not a PR comment.
 
@@ -225,32 +224,18 @@ ai sandbox rm {task-id}  # or use the task's retained short id
 
 ## Completion Checklist
 
-- [ ] Verified all workflow steps are complete
-- [ ] Updated task.md with completed status and timestamp
-- [ ] Moved task directory to `<task-workspace>/completed/`
-- [ ] Verified move succeeded
-- [ ] Informed user of completion
+- [ ] Hard prerequisites are satisfied and the pre-completion gate passes
+- [ ] Host finalization returns `result=completed` or `result=completed_with_warnings`
+- [ ] Completion verification passes
+- [ ] The structured completion result and applicable warnings are reported to the user
 
 ## Notes
 
-1. **Premature completion**: Do not move a task that has incomplete steps. Examples of incomplete situations:
-   - Code is written but not committed
-   - Code is committed but not reviewed
-   - Review found blockers that haven't been fixed
-   - PR is created but not merged
-   - Manual validation items are incomplete
-
-2. **Rollback**: If a task was incorrectly moved:
-   ```bash
-   mv <task-workspace>/completed/{task-id} <task-workspace>/active/{task-id}
-   ```
-   Then update task.md status back to `active`.
-
-3. **Multiple contributors**: If multiple AI agents worked on the task, ensure all contributions are committed before completing.
+- When multiple AI agents contributed, ensure all contributions are included in the local checkpoint.
 
 ## Error Handling
 
 - Task not found: Prompt "Task {task-id} not found in active directory"
-- Already completed: Prompt "Task {task-id} is already in completed directory"
-- Task is blocked: Prompt "Task {task-id} is blocked. Unblock it first by moving to active/"
-- Move failed: Prompt error and suggest manual move
+- Already completed: Enter `finalization-retry` only when a matching Complete Task Activity Log exists; otherwise report incomplete terminal identity and stop
+- Task is blocked: Satisfy the recorded unblock condition, then reactivate it through `task-lifecycle activate` before retrying
+- Finalization failed or blocked: Preserve source data and the receipt, then recover through the same finalization entry point using its structured error; do not manually rewrite terminal state or move the task directory

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

@@ -18,8 +18,7 @@ description: >
 
 生成收尾报告或同步内容时，先读取 `.agents/rules/evidence-reporting.md`。成功检查记录命令、范围、状态/结构化结果、实际结果和未覆盖部分；失败、阻塞或争议保留复现入口、准确位置和决定性摘录。
 
-- 本命令更新任务元数据并物理移动任务目录
-- 除非强制执行，不要转移有未完成工作流步骤的任务
+- 本命令由宿主更新任务元数据并原子移动任务目录
 - 入口接受可选 `--external-pr <N>`；仅用于外部交付候选歧义时的显式选择，不绕过身份或平台门禁
 
 版本戳规则：创建或更新 `task.md` frontmatter 时，先读取 `.agents/rules/version-stamp.md`，并写入或刷新 `agent_infra_version`。
@@ -141,9 +140,9 @@ Please satisfy the hard prerequisite first, then retry complete-task.
 如果存在有效的 `platform_issue_identity`，严格按以下顺序执行：
 
 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 评论。
+2. 把完成摘要字段写成 JSON 临时文件，并调用 `agent-infra-internal platform-comment stage-summary {task-id} --body-file {path}`。字段为 `taskId`、`title`、`summary`、`artifacts`、`verification:{state,detail}`；`taskId` 必须是当前完整任务 ID，`title` 来自 task.md，`artifacts` 来自当前 artifact registry（无产物用 `[]`）。验证尚未执行时写 `state:"not-run"` 和非空说明，不等待之后的终态事件或最终验证。命令把规范 payload 与摘要写入 durable staging record；本步骤不得直接发布 summary 评论。
 
-摘要正文只记录当前任务证据能够支持的交付结果、关联 PR 与实际合入事实、验证命令及其范围/结果/未覆盖部分，以及已知待办；需要说明验证范围时可注明对应提交。没有证据支持的事实不推断，未完成事项写入待办。这是 Issue 收尾摘要，不是 PR 留言。
+`summary` 字段只记录当前任务证据能够支持的交付结果、关联 PR 与实际合入事实、验证命令及其范围/结果/未覆盖部分，以及已知待办；需要说明验证范围时可注明对应提交。没有证据支持的事实不推断，未完成事项写入待办。这是 Issue 收尾摘要，不是 PR 留言。
 
 摘要默认使用当前技能的语言：中文技能生成中文摘要，英文技能生成英文摘要。中英文摘要保持相同字段结构。
 
@@ -224,32 +223,18 @@ ai sandbox rm {task-id}  # 或使用本任务仍保留的短号
 
 ## 完成检查清单
 
-- [ ] 验证了所有工作流步骤已完成
-- [ ] 更新了 task.md 的完成状态和时间戳
-- [ ] 将任务目录移动到 `<task-workspace>/completed/`
-- [ ] 验证了转移成功
-- [ ] 告知了用户完成情况
+- [ ] 满足了硬性前置条件并通过预完成门禁
+- [ ] 宿主 finalization 返回 `result=completed` 或 `result=completed_with_warnings`
+- [ ] 完成校验通过
+- [ ] 已向用户报告结构化完成结果和适用的警告
 
 ## 注意事项
 
-1. **过早完成**：不要转移有未完成步骤的任务。未完成的情况示例：
-   - 代码已编写但未提交
-   - 代码已提交但未审查
-   - 审查发现阻塞项但未修复
-   - PR 已创建但未合并
-   - 人工校验项未完成
-
-2. **回滚**：如果任务被错误转移：
-   ```bash
-   mv <task-workspace>/completed/{task-id} <task-workspace>/active/{task-id}
-   ```
-   然后将 task.md 中的状态改回 `active`。
-
-3. **多贡献者**：如果多个 AI 代理参与了任务，确保所有贡献都已提交后再完成。
+- 如果多个 AI 代理参与任务，确保所有贡献都包含在本地 checkpoint 中。
 
 ## 错误处理
 
 - 任务未找到：提示 "Task {task-id} not found in active directory"
-- 已完成：提示 "Task {task-id} is already in completed directory"
-- 任务被阻塞：提示 "Task {task-id} is blocked. Unblock it first by moving to active/"
-- 移动失败：提示错误并建议手动移动
+- 已完成：仅当存在匹配的 Complete Task Activity Log 时进入 `finalization-retry`；否则说明终态身份不完整并停止
+- 任务被阻塞：满足记录的解除条件后，通过 `task-lifecycle activate` 恢复任务，再重试
+- finalization 失败或阻塞：保留源数据和 receipt，根据结构化错误通过同一 finalization 入口恢复；不要手工改写终态或移动任务目录

package/templates/.agents/skills/create-pr/SKILL.en.md

@@ -86,7 +86,7 @@ The core renderer owns the report section. It is part of the reviewer summary be
 
 Read the latest context artifacts when they exist: `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`.
 
-Aggregate a reviewer-facing summary from those artifacts with exactly one `<!-- canonical-pr-change-report -->` placeholder, and maintain a single idempotent summary comment via the hidden marker. Pass `--change-report-file <task-workspace>/active/{task-id}/pr-change-report.json` and the same `--result {primary-result}` to `summary-sync`; a sync substep must not infer whether the PR was created or reused.
+Assemble a structured reviewer summary JSON from those artifacts with overview, tests, review, manual validation, open decisions, and risks. Report valid not-started states honestly; do not include later validation or event results in advance. Maintain one idempotent summary comment via the hidden marker; the core renderer generates the fixed summary sections and change report. Pass the summary JSON, `--change-report-file <task-workspace>/active/{task-id}/pr-change-report.json`, and the same `--result {primary-result}` to `summary-sync`; a sync substep must not infer whether the PR was created or reused.
 
 > Canonical context, aggregation, and the `summary-sync` call live in `reference/comment-publish.md`, which points to `.agents/rules/pr-sync.md`. Read that reference before publishing.
 

package/templates/.agents/skills/create-pr/SKILL.zh-CN.md

@@ -86,7 +86,7 @@ description: >
 
 读取最新的上下文产物：`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`（存在时）。
 
-基于这些产物聚合 reviewer 摘要，正文只放一次 `<!-- canonical-pr-change-report -->` 占位符，再使用隐藏标记维护唯一且幂等的摘要评论。调用 `summary-sync` 时传入 `--change-report-file <task-workspace>/active/{task-id}/pr-change-report.json`，并继续传递同一个 `--result {primary-result}`；不得根据同步子步骤猜测 PR 是创建还是复用。
+基于这些产物组装结构化 reviewer 摘要 JSON，包含概览、测试、Review、人工校验、待决事项和风险；将合法未启动状态如实传入，不提前写入后续验证或事件结果。使用隐藏标记维护唯一且幂等的摘要评论；核心 renderer 负责生成固定摘要段落和 change report。调用 `summary-sync` 时传入摘要 JSON 与 `--change-report-file <task-workspace>/active/{task-id}/pr-change-report.json`，并继续传递同一个 `--result {primary-result}`；不得根据同步子步骤猜测 PR 是创建还是复用。
 
 > canonical context、摘要聚合和 `summary-sync` 调用见 `reference/comment-publish.md`（其引用 `.agents/rules/pr-sync.md`）。发布摘要前先读取该 reference。
 

package/templates/.agents/skills/create-pr/reference/change-report.en.md

@@ -24,9 +24,16 @@ agent-infra-internal platform-pr change-report {task-id} \
 
 The core validates the task-intent digest, PR identity, complete patch SHA, totals, and the ordered checks `target-alignment`, `change-composition`, `compatibility-policy`, `legacy-path-cleanup`, `redundancy`, and `scope-discipline`. A `needs-review` check routes to `review-code`; `formalReview` remains `false`.
 
-When generating the candidate, use the six existing `rationale` fields and `Evidence[]` as readable analysis for each logical change group; do not add group fields. For each group, explain its goal and acceptance-criteria alignment, added and removed behavior, necessity, redundancy or duplicate implementation, scope, related tests, and whether the tests are sufficient. Cite paths, line ranges, and concise evidence for the conclusions. Each check must still state its actual finding: `target-alignment` explains the goal relationship, `change-composition` summarizes responsibilities and behavior changes, `compatibility-policy` states the compatibility result, `legacy-path-cleanup` states how legacy paths were handled, `redundancy` states the redundancy result, and `scope-discipline` states the scope judgment. Do not reuse generic boilerplate; mark unsupported conclusions as unconfirmed. Use the deployed skill's language. Chinese skill deployments must use Chinese. The canonical renderer displays every item in each `Evidence[]`.
+Before generating the candidate, list functional change groups from the task goal and complete diff; file responsibilities or category totals are not functional groups. Represent each group as a typed object in the existing `change-composition.groups[]` with `id`, `target`, `behaviorChange`, `necessity`, `files[]`, and `tests:{coverage,cost}`. `rationale` and `Evidence[]` may support the judgment and locations but cannot replace group objects.
 
-Explain applicable production-code, test, and documentation changes for each group. Keep source line changes, execution/call-count changes, and workflow unification distinct. Diff line counts support text changes only; they do not prove fewer executions or a unified workflow. Execution behavior and test adequacy need their own direct evidence. State gaps where evidence is missing. Green CI does not prove necessity or absence of redundancy.
+- `files[]` must reference canonical paths (`oldPath ?? newPath`) from the complete formal diff. A rename remains one mechanical file record with both old and new paths. Assign every formal diff file to exactly one group; do not omit, duplicate, or invent paths.
+- Do not enter group line counts in the candidate. Core derives each group's additions, deletions, and net from the bound formal diff's per-file counts and reconciles group totals with the complete diff. A `null` count stays uncountable; the file still belongs to one group and must not be represented as zero.
+- `Evidence[].detail` may cite relevant code, test, or documentation changes. Use `tests.coverage` and `tests.cost` for existing/new test coverage and fixture/test cost. If no test changed, state why existing coverage is sufficient.
+- List and reconcile complete-PR changes separately from the current head-to-head increment. Do not infer increment values when the previous head is unconfirmed.
+
+`target-alignment` passes only when every group maps to a task goal or acceptance criterion. Typed structure, file membership, and derived counts are structural checks; the existing semantic review still decides whether groups, behavior added/removed, necessity, test coverage/cost, and evidence are adequately explained. Missing, contradictory, or unverifiable structure or explanation remains `needs-review`; state the gap so the core routes to `review-code`. Complete structure or green CI does not establish sufficient explanation.
+
+State the actual finding for each of the other four checks. Use the deployed skill's language for evidence; Chinese deployments must use Chinese. The canonical renderer displays every rationale and evidence item. Source line counts describe text additions/deletions only; they do not prove execution counts or workflow unification.
 
 ## Complete PR and Per-Round Increment
 

package/templates/.agents/skills/create-pr/reference/change-report.zh-CN.md

@@ -24,9 +24,16 @@ agent-infra-internal platform-pr change-report {task-id} \
 
 core 校验任务意图 digest、PR identity、完整 patch SHA、统计合计和固定顺序的 `target-alignment`、`change-composition`、`compatibility-policy`、`legacy-path-cleanup`、`redundancy`、`scope-discipline`。任一项为 `needs-review` 时路由到 `review-code`，`formalReview` 仍为 `false`。
 
-生成 candidate 时，按逻辑变化组用六项 `rationale` 和 `Evidence[]` 给出可读分析，不新增组级字段。每组说明其目标/验收对应、行为增加与减少、必要性、冗余或重复实现、范围、对应测试及测试是否充分；列出支撑结论的路径、行号和简短证据。六项检查各自仍须写实际结论：`target-alignment` 说明目标对应关系，`change-composition` 概括职责和行为变化，`compatibility-policy` 说明兼容策略，`legacy-path-cleanup` 说明旧路径处理，`redundancy` 说明重复/冗余结果，`scope-discipline` 说明范围判断。不得复用泛化套话；证据不足的维度明确标记未确认，不推断结论。证据详情遵循当前已部署技能的语言，中文技能必须使用中文。canonical renderer 会完整展示每项 `Evidence[]`。
+生成 candidate 前，先根据任务目标和完整 diff 列出功能变化组；不得把文件职责概述或类别总数当作功能组。每个功能组作为现有 `change-composition` 检查中的 typed `groups[]` 对象，包含 `id`、`target`、`behaviorChange`、`necessity`、`files[]` 和 `tests:{coverage,cost}`。`rationale`/`Evidence[]` 仅补充判断和定位，不能替代组对象。
 
-每组解释覆盖生产代码、测试和文档中适用的变化，并区分源码行数变化、执行/调用次数变化和流程统一。diff 行数仅支持代码文本增减；不能据此推断执行次数减少或流程统一。执行次数、流程行为和测试充分性须有各自直接证据；没有证据时明确说明缺口。CI 全绿不能代替必要性或冗余判断。
+- `files[]` 只能引用完整正式 diff 中的 canonical 文件路径（机械报告的 `oldPath ?? newPath`）；rename 仍作为一条机械记录保留 old/new 两端。正式 diff 中每个文件必须恰好归入一个组，不得遗漏、重复或引用 diff 外文件。
+- 不要在 candidate 中填写组级行数。core 从绑定的正式 diff 逐文件 additions/deletions 聚合各组的新增、删除和净增，并将各组加总与正式 diff totals 对账。`null` 行数保持不可计数，文件仍需归组且不能改写为零。
+- 每条 `Evidence[].detail` 可引用具体代码、测试或文档变更；`tests.coverage` 与 `tests.cost` 分别说明覆盖风险/已有覆盖依据，以及本次新增 fixture / 测试的成本。没有测试变更时说明现有覆盖依据。
+- 完整 PR 与本轮 head-to-head 增量分别列示和对账；上一 head 未确认时不得推算增量数值。
+
+`target-alignment` 只有在每个功能组都能对应任务目标或验收标准时才能判为 `pass`。`change-composition` 的 typed 结构、文件集合和机械计数通过结构校验后，仍须按现有语义判断组别、行为增减、必要性、测试覆盖/成本和证据是否充分；结构或解释缺项、矛盾、无法核实时保持 `needs-review` 并说明缺口，使 core 路由到 `review-code`。不得因结构完整或 CI 通过而自动判定内容充分。
+
+其他四项检查仍分别给出实际结论；证据详情遵循当前已部署技能的语言，中文技能必须使用中文。canonical renderer 会展示全部 rationale 和 evidence。源码行数只说明文本增删；不能据此推断执行次数或流程统一。
 
 ## 完整 PR 与本轮增量
 

package/templates/.agents/skills/create-pr/reference/comment-publish.en.md

@@ -2,7 +2,7 @@
 
 After PR creation, run `agent-infra-internal platform-pr summary-context {task-id}` and aggregate the reviewer summary only from its canonical artifacts according to `.agents/rules/pr-sync.md`.
 
-Write the plain summary body, containing exactly one `<!-- canonical-pr-change-report -->` placeholder and no report heading/JSON, marker, or HEAD metadata, to a temporary file, then run:
+Write the PR summary JSON fields from `.agents/rules/pr-sync.md` to a temporary file, then run. The core renderer adds the feature change section from the canonical report:
 
 ```bash
 agent-infra-internal platform-pr summary-sync {task-id} \
@@ -11,4 +11,4 @@ agent-infra-internal platform-pr summary-sync {task-id} \
   --result {primary-result}
 ```
 
-The caller does not add markers, HEAD metadata, report sections, or comment API parameters. The typed core rechecks the task-bound sidecar against the authoritative PR snapshot and renders the report. `--result` is required and must be passed unchanged from `platform-pr create`; `no_op` maps to `no_op_with_warnings` if summary synchronization degrades. Missing/stale/invalid sidecars or body bypasses do not publish, and summary failures do not roll back a created or reused PR.
+The caller does not add markers, HEAD metadata, report sections, or comment API parameters. The typed core validates fields, renders fixed sections, rechecks the task-bound sidecar against the authoritative PR snapshot, then reads back and compares the remote body. `--result` is required and passed unchanged from `platform-pr create`; incomplete structure does not publish, and summary failures do not roll back a created or reused PR.

package/templates/.agents/skills/create-pr/reference/comment-publish.zh-CN.md

@@ -2,7 +2,7 @@
 
 创建 PR 后先调用 `agent-infra-internal platform-pr summary-context {task-id}`，只根据返回的 canonical 产物按 `.agents/rules/pr-sync.md` 聚合 reviewer 摘要。
 
-把恰好包含一次 `<!-- canonical-pr-change-report -->` 且不含报告标题/JSON、marker 或 HEAD 元数据的纯摘要正文写入临时文件，再调用：
+按 `.agents/rules/pr-sync.md` 填写 PR 摘要 JSON 字段（overview、tests、review、manualValidation、humanDecisions、risks），写入临时文件，再调用。功能增减章节由 core renderer 从 canonical report 生成：
 
 ```bash
 agent-infra-internal platform-pr summary-sync {task-id} \
@@ -11,4 +11,4 @@ agent-infra-internal platform-pr summary-sync {task-id} \
   --result {primary-result}
 ```
 
-调用方不添加 marker、HEAD、报告段或评论 API 参数。typed core 会重新校验任务绑定 sidecar 与权威 PR snapshot 并渲染报告。`--result` 是必填的，必须把 `platform-pr create` 的 `result` 原样传入；sidecar 缺失/过期/非法或正文旁路时不发布，摘要失败沿用该 primary result 映射 warning（`no_op` 对应 `no_op_with_warnings`），不回滚已创建或复用的 PR。结果映射沿用 `.agents/rules/pr-sync.md`。
+调用方不添加 marker、HEAD、报告段或评论 API 参数。typed core 会校验字段结构、渲染固定章节、重新校验任务绑定 sidecar 与权威 PR snapshot，并在发布后回读比较远端正文。`--result` 是必填的，必须把 `platform-pr create` 的 `result` 原样传入；sidecar 缺失/过期/非法或结构不完整时不发布，摘要失败沿用该 primary result 映射 warning（`no_op` 对应 `no_op_with_warnings`），不回滚已创建或复用的 PR。结果映射沿用 `.agents/rules/pr-sync.md`。

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

@@ -93,24 +93,6 @@ agent-infra-internal task-create --input "$candidate_file"
 
 The host owns TASK-id/timestamps/version, workflow and branch derivation, template rendering, atomic persistence, short ids, Issue sync, and warnings. The skill must not create task directories, copy templates, allocate short ids, or call platform subcommands directly.
 
-Task metadata (`task.md` YAML front matter):
-```yaml
-id: TASK-{yyyyMMdd-HHmmss}
-type: feature|bugfix|refactor|docs|chore
-branch: <project>-<type>-<slug>
-workflow: feature-development|bug-fix|refactoring
-status: active
-created_at: {YYYY-MM-DD HH:mm:ss±HH:MM}
-updated_at: {YYYY-MM-DD HH:mm:ss±HH:MM}
-agent_infra_version: {agent_infra_version}
-priority:                  # required; inferred by the AI from the title/description; Urgent | High | Medium | Low
-effort:                    # required; inferred by the AI from the title/description; High | Medium | Low
-start_date:                # optional; YYYY-MM-DD
-target_date:               # optional; YYYY-MM-DD
-current_step: requirement-analysis
-assigned_to: {current AI agent}
-```
-
 priority / effort are required: the AI infers them from the task title and description (candidates in `.agents/rules/issue-fields.md`; normalize localized input). Leave start_date / target_date empty at creation: `start_date` is written by the analyze stage and `target_date` by the complete stage; do not invent dates.
 
 ### 3. Handle the Structured Result

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

@@ -92,24 +92,6 @@ agent-infra-internal task-create --input "$candidate_file"
 
 宿主负责 TASK-id/时间戳/版本戳、workflow/branch 派生、模板渲染、原子持久化、短号、Issue 与 warning。技能不得自行 `mkdir`、复制任务模板、分配短号或直接调用平台子命令。
 
-任务元数据（task.md YAML front matter）：
-```yaml
-id: TASK-{yyyyMMdd-HHmmss}
-type: feature|bugfix|refactor|docs|chore
-branch: <project>-<type>-<slug>
-workflow: feature-development|bug-fix|refactoring
-status: active
-created_at: {YYYY-MM-DD HH:mm:ss±HH:MM}
-updated_at: {YYYY-MM-DD HH:mm:ss±HH:MM}
-agent_infra_version: {agent_infra_version}
-priority:                  # 必填；由 AI 从标题/描述推断；Urgent | High | Medium | Low
-effort:                    # 必填；由 AI 从标题/描述推断；High | Medium | Low
-start_date:                # 可选；YYYY-MM-DD
-target_date:               # 可选；YYYY-MM-DD
-current_step: requirement-analysis
-assigned_to: {当前 AI 代理}
-```
-
 priority / effort 必填：由 AI 从任务标题与描述推断后填入（候选值见 `.agents/rules/issue-fields.md`；中文输入按本地化映射规范化）。start_date / target_date 创建时保持留空：`start_date` 由 analyze 阶段写入、`target_date` 由 complete 阶段写入；不要臆测日期。
 
 ### 3. 处理结构化结果

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

@@ -9,7 +9,7 @@ description: >
 # Design Technical Plan
 > `--agent` values are defined in `.agents/rules/task-management.md` under “Collaborator Token Specification”.
 
-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`, `new-requirement`, or `upstream-fact-doubt`. Reuse the same values for started and completed.
+Lifecycle events require explicit trigger data: ordinary skill invocation uses `model`; use `human` only when the user explicitly requests it. `{request-id}` is a stable single-line identifier for this task and artifact round, and `{reason-code}` use `user-request`, `new-requirement`, or `upstream-fact-doubt`. Reuse the same values for started and completed.
 
 ## Boundary / Critical Rules
 
@@ -145,7 +145,7 @@ agent-infra-internal task-artifact {task-id} finalize-local --family plan --arti
 - On `status=failed`, correct the formal artifact directly and rerun the finalizer completely; if the current diagnostic remains unresolved, continue to the next attempt.
 - On an external formal-artifact change, an unsafe repair, repeated diagnostics or fingerprints, no progress, or the shared edit limit, stop without publishing a completed event.
 
-Use the digests from that same `status=passed` result in `agent-infra-internal task-event {task-id} plan.completed --agent {standard-agent-token} --initiator {trigger-initiator} --request-id {request-id} --reason-code {reason-code} --artifact {plan-artifact} --artifact-sha256 {artifact-sha256} --semantic-digest {semantic-digest} {execution-flag}` so the core records the link, stage, agent, metadata, and Activity Log atomically.
+Use the digests from that same `status=passed` result in `agent-infra-internal task-event {task-id} plan.completed --agent {standard-agent-token} --initiator {trigger-initiator} --request-id {request-id} --reason-code {reason-code} --artifact {plan-artifact} --artifact-sha256 {artifact-sha256} --semantic-digest {semantic-digest}` so the core records the link, stage, agent, metadata, and Activity Log atomically.
   - {YYYY-MM-DD HH:mm:ss±HH:MM} — **Plan Task (Round {N})** by {agent} — Plan completed, awaiting human review → {artifact-filename}
   ```
 

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

@@ -9,7 +9,7 @@ description: >
 # 设计技术方案
 > `--agent` 取值见 `.agents/rules/task-management.md`「合作者 token 规范」。
 
-若入口业务操作数包含 `--orchestrated`，绑定 `{execution-flag}` = `--orchestrated` 并原样转发给 completed 事件；否则绑定为空。不得从 `orchestration.json`、环境变量或历史产物推断该标记。生命周期事件还必须携带显式触发信息：编排调用使用 `{trigger-initiator}=orchestrator`，否则使用 `model`；`{request-id}` 是本任务与本轮产物的稳定单行标识，`{reason-code}` 使用 `user-request`、`new-requirement` 或 `upstream-fact-doubt`；started 与 completed 使用同一组值。
+生命周期事件必须携带显式触发信息：普通技能调用使用 `model`；仅用户明确要求时使用 `human`。`{request-id}` 是本任务与本轮产物的稳定单行标识，`{reason-code}` 使用 `user-request`、`new-requirement` 或 `upstream-fact-doubt`；started 与 completed 使用同一组值。
 
 ## 行为边界 / 关键规则
 
@@ -143,7 +143,7 @@ agent-infra-internal task-artifact {task-id} init --family plan --artifact {plan
   - `status=passed`：保存本次返回的 `artifactSha256` 和 `semanticDigest`；finalizer 已记录对应的一次性本地 provenance intent。
   - `status=failed`：直接修正正式产物并完整重跑 finalizer；若仍失败且诊断未解决，继续下一轮。
   - 当前正式产物发生外部变化、无法安全修复、诊断或指纹重复、无进展，或达到共享规则的编辑上限时停止，不发布 completed 事件。
-- 使用同一次 `status=passed` 返回的摘要执行 `agent-infra-internal task-event {task-id} plan.completed --agent {standard-agent-token} --initiator {trigger-initiator} --request-id {request-id} --reason-code {reason-code} --artifact {plan-artifact} --artifact-sha256 {artifact-sha256} --semantic-digest {semantic-digest} {execution-flag}`，由核心登记链接、阶段、代理、时间、版本和 Activity Log。
+- 使用同一次 `status=passed` 返回的摘要执行 `agent-infra-internal task-event {task-id} plan.completed --agent {standard-agent-token} --initiator {trigger-initiator} --request-id {request-id} --reason-code {reason-code} --artifact {plan-artifact} --artifact-sha256 {artifact-sha256} --semantic-digest {semantic-digest}`，由核心登记链接、阶段、代理、时间、版本和 Activity Log。
 
 如果 task.md 中存在有效的 `platform_issue_identity`，执行以下同步操作（任一失败则跳过并继续）：
 - 调用 `agent-infra-internal platform-issue sync {task-id} --agent {standard-agent-token} --status pending-design-work --fields`

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

@@ -9,7 +9,7 @@ description: >
 # Requirement Analysis Review
 > `--agent` values are defined in `.agents/rules/task-management.md` under “Collaborator Token Specification”.
 
-If the entry operands contain `--orchestrated`, bind `{execution-flag}` to `--orchestrated` and forward it unchanged to both the summary finalizer and 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` or `review-finding`. Reuse the same values for started and completed.
+Lifecycle events require explicit trigger data: ordinary skill invocation uses `model`; use `human` only when the user explicitly requests it. `{request-id}` is a stable single-line identifier for this task and artifact round, and `{reason-code}` use `user-request` or `review-finding`. Reuse the same values for started and completed.
 
 Review the latest analysis artifact and produce `review-analysis.md` or `review-analysis-r{N}.md`.
 
@@ -87,7 +87,7 @@ Create `<task-workspace>/active/{task-id}/{review-artifact}`.
 
 ### 6. Update Task Status
 
-After the report, call `agent-infra-internal task-review {task-id} preflight --stage analysis --artifact {review-artifact} {execution-flag}` before any ledger write. On failure, correct the formal artifact directly and rerun it. Only after preflight passes, submit each new finding with `agent-infra-internal task-ledger {task-id} finding-upsert --stage analysis --review-artifact {review-artifact} --ordinal {n} --severity {blocker|major|minor} --evidence {review-artifact}#{anchor}` or 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-review {task-id} finalize-summary --stage analysis --artifact {review-artifact} {execution-flag}`; never treat an error type or `changed=false` as automatic authorization.
+After the report, call `agent-infra-internal task-review {task-id} preflight --stage analysis --artifact {review-artifact}` before any ledger write. On failure, correct the formal artifact directly and rerun it. Only after preflight passes, submit each new finding with `agent-infra-internal task-ledger {task-id} finding-upsert --stage analysis --review-artifact {review-artifact} --ordinal {n} --severity {blocker|major|minor} --evidence {review-artifact}#{anchor}` or 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-review {task-id} finalize-summary --stage analysis --artifact {review-artifact}`; never treat an error type or `changed=false` as automatic authorization.
 
 Bind and reuse this structured mapping from that one response:
 
@@ -97,7 +97,7 @@ Bind and reuse this structured mapping from that one response:
 {unresolved-minor} = stageStatus.unresolvedFindingCounts.minor
 ```
 
-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-analysis.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.
+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-analysis.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}`, 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.
 
 `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.
 

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

@@ -9,7 +9,7 @@ description: >
 # 需求分析审查
 > `--agent` 取值见 `.agents/rules/task-management.md`「合作者 token 规范」。
 
-若入口业务操作数包含 `--orchestrated`，绑定 `{execution-flag}` = `--orchestrated` 并原样转发给 summary finalizer 与 completed 事件；否则绑定为空。不得从 `orchestration.json`、环境变量或历史产物推断该标记。生命周期事件还必须携带显式触发信息：编排调用使用 `{trigger-initiator}=orchestrator`，否则使用 `model`；`{request-id}` 是本任务与本轮产物的稳定单行标识，`{reason-code}` 使用 `user-request` 或 `review-finding`；started 与 completed 使用同一组值。
+生命周期事件必须携带显式触发信息：普通技能调用使用 `model`；仅用户明确要求时使用 `human`。`{request-id}` 是本任务与本轮产物的稳定单行标识，`{reason-code}` 使用 `user-request` 或 `review-finding`；started 与 completed 使用同一组值。
 
 审查最新需求分析产物，并产出 `review-analysis.md` 或 `review-analysis-r{N}.md`。
 
@@ -90,7 +90,7 @@ agent-infra-internal task-artifact {task-id} init --family review-analysis --art
 
 ### 6. 更新任务状态
 
-报告完成后，先调用 `agent-infra-internal task-review {task-id} preflight --stage analysis --artifact {review-artifact} {execution-flag}`，不得先写入账本。失败后直接修正正式产物并重跑；只有 preflight 通过后，才逐条调用 `agent-infra-internal task-ledger {task-id} finding-upsert --stage analysis --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-review {task-id} finalize-summary --stage analysis --artifact {review-artifact} {execution-flag}`；不能把失败类型或 `changed=false` 当作自动授权。
+报告完成后，先调用 `agent-infra-internal task-review {task-id} preflight --stage analysis --artifact {review-artifact}`，不得先写入账本。失败后直接修正正式产物并重跑；只有 preflight 通过后，才逐条调用 `agent-infra-internal task-ledger {task-id} finding-upsert --stage analysis --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-review {task-id} finalize-summary --stage analysis --artifact {review-artifact}`；不能把失败类型或 `changed=false` 当作自动授权。
 
 从该次返回值绑定并复用以下结构化映射：
 
@@ -100,7 +100,7 @@ agent-infra-internal task-artifact {task-id} init --family review-analysis --art
 {unresolved-minor} = stageStatus.unresolvedFindingCounts.minor
 ```
 
-该 intent 原子最终化报告摘要并返回同一次账本快照；不得再调用 `stage-status`、手工替换占位符或扫描问题清单。失败后，模型只能在共享规则的机械安全门通过时修改同一个受控 artifact，并完整重跑相同 intent；每次失败都重新判断是否收敛。最终一次完整成功返回决定同一快照的 verdict 和计数：`stageStatus.canAdvance=true` 且结论为 Approved 时允许跨阶段推进；`stageStatus.canAdvance=false` 时仍须执行 `agent-infra-internal task-event {task-id} review-analysis.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、实际修复次数、最后诊断和停止原因。
+该 intent 原子最终化报告摘要并返回同一次账本快照；不得再调用 `stage-status`、手工替换占位符或扫描问题清单。失败后，模型只能在共享规则的机械安全门通过时修改同一个受控 artifact，并完整重跑相同 intent；每次失败都重新判断是否收敛。最终一次完整成功返回决定同一快照的 verdict 和计数：`stageStatus.canAdvance=true` 且结论为 Approved 时允许跨阶段推进；`stageStatus.canAdvance=false` 时仍须执行 `agent-infra-internal task-event {task-id} review-analysis.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}`，使用 `changes-requested` 并路由到同阶段修订/复审（报告明确拒绝时使用 `rejected`）。失败、模型停止、无进展或紧急熔断时，不发布完成事件或跨阶段命令，但必须按 `reference/output-templates.md` 的 `repair-stop` 场景展示已有 summary/findings、artifact、实际修复次数、最后诊断和停止原因。
 
 `manual-validation` 是 `ai task log` 中 review 行「人工校验点」（EN `Manual-validation`）计数的数据源；不要新增并行人工验证字段。
 

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

@@ -9,7 +9,7 @@ description: >
 # Code Review
 > `--agent` values are defined in `.agents/rules/task-management.md` under “Collaborator Token Specification”.
 
-If the entry operands contain `--orchestrated`, bind `{execution-flag}` to `--orchestrated` and forward it unchanged to both the summary finalizer and 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` or `review-finding` for ordinary reviews. Only an explicitly requested supplemental human review uses `--initiator human --reason-code manual-review-supplement`. Reuse the same values for started and completed.
+Lifecycle events require explicit trigger data: ordinary review uses `model`; only an explicitly requested supplemental human review uses `--initiator human --reason-code manual-review-supplement`. `{request-id}` is a stable single-line identifier for this task and artifact round, and `{reason-code}` use `user-request` or `review-finding` for ordinary reviews. Reuse the same values for started and completed.
 
 Review the latest code round and produce `review-code.md` or `review-code-r{N}.md`.
 
@@ -114,9 +114,9 @@ Create `<task-workspace>/active/{task-id}/{review-artifact}`.
 ### 6. Update Task Status
 
 Update task.md:
-- After the report, call `agent-infra-internal task-review {task-id} preflight --stage code --artifact {review-artifact} {execution-flag}` before any ledger write. On failure, correct the formal artifact directly and rerun it.
+- After the report, call `agent-infra-internal task-review {task-id} preflight --stage code --artifact {review-artifact}` before any ledger write. On failure, correct the formal artifact directly and rerun it.
 - Only after preflight passes, 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}`. When escalating to `needs-human-decision`, append `--needs-implementation true|false` using the judgment recorded in the detail block. Do not scan ids or edit ledger rows
-- After all ledger writes, call `agent-infra-internal task-review {task-id} finalize-summary --stage code --artifact {review-artifact} {execution-flag}`; never treat an error type or `changed=false` as automatic authorization
+- After all ledger writes, call `agent-infra-internal task-review {task-id} finalize-summary --stage code --artifact {review-artifact}`; never treat an error type or `changed=false` as automatic authorization
 
   Bind and reuse this structured mapping from that one response:
 
@@ -126,10 +126,10 @@ Update task.md:
   {unresolved-minor} = stageStatus.unresolvedFindingCounts.minor
   ```
 
-  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
+  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}`, 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, 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}`
+- 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}`
 
 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.

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

@@ -9,7 +9,7 @@ description: >
 # 代码审查
 > `--agent` 取值见 `.agents/rules/task-management.md`「合作者 token 规范」。
 
-若入口业务操作数包含 `--orchestrated`，绑定 `{execution-flag}` = `--orchestrated` 并原样转发给 summary finalizer 与 completed 事件；否则绑定为空。不得从 `orchestration.json`、环境变量或历史产物推断该标记。生命周期事件还必须携带显式触发信息：编排调用使用 `{trigger-initiator}=orchestrator`，否则使用 `model`；`{request-id}` 是本任务与本轮产物的稳定单行标识，普通调用的 `{reason-code}` 使用 `user-request` 或 `review-finding`；仅用户明确要求补充审查时，使用 `--initiator human --reason-code manual-review-supplement`。started 与 completed 使用同一组值。
+生命周期事件必须携带显式触发信息：普通调用使用 `model`；仅用户明确要求补充审查时，使用 `--initiator human --reason-code manual-review-supplement`。`{request-id}` 是本任务与本轮产物的稳定单行标识，`{reason-code}` 普通审查使用 `user-request` 或 `review-finding`；started 与 completed 使用同一组值。
 
 审查最新代码轮次，并产出 `review-code.md` 或 `review-code-r{N}.md`。
 
@@ -112,9 +112,9 @@ agent-infra-internal task-artifact {task-id} init --family review-code --artifac
 
 ### 6. 更新任务状态
 
-- 报告完成后，先调用 `agent-infra-internal task-review {task-id} preflight --stage code --artifact {review-artifact} {execution-flag}`，不得先写入账本。失败后直接修正正式产物并重跑。
+- 报告完成后，先调用 `agent-infra-internal task-review {task-id} preflight --stage code --artifact {review-artifact}`，不得先写入账本。失败后直接修正正式产物并重跑。
 - 只有 preflight 通过后，新 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 {相称证据}`。升级为 `needs-human-decision` 时，按详情块中的判断追加 `--needs-implementation true|false`。不得扫描编号或手写账本行
-- 全部账本写入完成后调用 `agent-infra-internal task-review {task-id} finalize-summary --stage code --artifact {review-artifact} {execution-flag}`；不能把失败类型或 `changed=false` 当作自动授权
+- 全部账本写入完成后调用 `agent-infra-internal task-review {task-id} finalize-summary --stage code --artifact {review-artifact}`；不能把失败类型或 `changed=false` 当作自动授权
 
   从该次返回值绑定并复用以下结构化映射：
 
@@ -124,10 +124,10 @@ agent-infra-internal task-artifact {task-id} init --family review-code --artifac
   {unresolved-minor} = stageStatus.unresolvedFindingCounts.minor
   ```
 
-  该 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、实际修复次数、最后诊断和停止原因
+  该 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}`，使用 `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` 选择唯一场景，并使用对应的 `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}`
+- 完成 `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}`
 
 完成日志必须始终写入 `Manual-validation: {n}` 字段，0 也保留。
 `manual-validation` 是 `ai task log` 中 review 行「人工校验点」（EN `Manual-validation`）计数的数据源；不要新增并行人工验证字段。

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

@@ -9,7 +9,7 @@ description: >
 # Technical Plan Review
 > `--agent` values are defined in `.agents/rules/task-management.md` under “Collaborator Token Specification”.
 
-If the entry operands contain `--orchestrated`, bind `{execution-flag}` to `--orchestrated` and forward it unchanged to both the summary finalizer and 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` or `review-finding`. Reuse the same values for started and completed.
+Lifecycle events require explicit trigger data: ordinary skill invocation uses `model`; use `human` only when the user explicitly requests it. `{request-id}` is a stable single-line identifier for this task and artifact round, and `{reason-code}` use `user-request` or `review-finding`. Reuse the same values for started and completed.
 
 Review the latest plan artifact and produce `review-plan.md` or `review-plan-r{N}.md`.
 
@@ -87,7 +87,7 @@ Create `<task-workspace>/active/{task-id}/{review-artifact}`.
 
 ### 6. Update Task Status
 
-After the report, call `agent-infra-internal task-review {task-id} preflight --stage plan --artifact {review-artifact} {execution-flag}` before any ledger write. On failure, correct the formal artifact directly and rerun it. Only after preflight passes, submit each new finding with `agent-infra-internal task-ledger {task-id} finding-upsert --stage plan --review-artifact {review-artifact} --ordinal {n} --severity {blocker|major|minor} --evidence {review-artifact}#{anchor}` or 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-review {task-id} finalize-summary --stage plan --artifact {review-artifact} {execution-flag}`; never treat an error type or `changed=false` as automatic authorization.
+After the report, call `agent-infra-internal task-review {task-id} preflight --stage plan --artifact {review-artifact}` before any ledger write. On failure, correct the formal artifact directly and rerun it. Only after preflight passes, submit each new finding with `agent-infra-internal task-ledger {task-id} finding-upsert --stage plan --review-artifact {review-artifact} --ordinal {n} --severity {blocker|major|minor} --evidence {review-artifact}#{anchor}` or 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-review {task-id} finalize-summary --stage plan --artifact {review-artifact}`; never treat an error type or `changed=false` as automatic authorization.
 
 Bind and reuse this structured mapping from that one response:
 
@@ -97,7 +97,7 @@ Bind and reuse this structured mapping from that one response:
 {unresolved-minor} = stageStatus.unresolvedFindingCounts.minor
 ```
 
-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-plan.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.
+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-plan.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}`, 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.
 
 `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.