@fitlab-ai/agent-infra 0.9.12 → 0.9.13

package/templates/.agents/rules/issue-sync.en.md

@@ -25,6 +25,8 @@ agent-infra-internal platform-issue sync {task-id} --agent {standard-agent-token
 
 The core owns status/in labels, assignees, milestones, Issue Type, pinned fields, requirements, state, capabilities, dry-run, retries, errors, and idempotency. Omitted flags preserve values; `none` explicitly clears them. Status labels converge to at most one, and ambiguous requirement identity fails closed.
 
+PR event `in:` synchronization uses `agent-infra-internal platform-pr sync-in-labels --pr <N> [--cwd <path>]`. PR files are the event evidence; a unique closing Issue is written and re-read before the PR. Zero or multiple closing Issues update only the PR and return `degraded`; unknown side effects or failed convergence return `blocked` with `IN_LABEL_SYNC_PARTIAL`.
+
 `planned|applied|no-op|degraded` exit 0; `failed` exits 1; `blocked` exits 2.
 
 Map material degraded/failed/blocked results to workflow warnings through the structured intent; callers must not edit warning rows directly:

package/templates/.agents/rules/issue-sync.zh-CN.md

@@ -71,6 +71,8 @@ agent-infra-internal platform-issue sync {task-id} --agent {standard-agent-token
 
 status labels 始终至多一个；关闭后不保留 status label。`in:` labels 只从项目允许映射与仓库实际 labels 交集产生。需求复选框以 task.md 原文为身份，歧义时 fail closed。
 
+PR event 的 `in:` 同步使用 `agent-infra-internal platform-pr sync-in-labels --pr <N> [--cwd <path>]`。PR files 是事件证据；唯一 closing Issue 按 Issue→PR 顺序写入并复读，零或多个 closing Issue 只写 PR 并返回 `degraded`。写入后副作用不明或复读未收敛必须返回 `blocked` 与 `IN_LABEL_SYNC_PARTIAL`。
+
 ## 补发
 
 complete-task 按 artifact catalog 时间线遍历本地已有产物：task 使用 `--kind task`，其余使用 `--kind artifact --artifact <file> --backfill`；最后用 `--kind summary --body-file <path>` 原地同步交付摘要。artifact backfill 在远端缺少 marker 时创建带“历史产物补发”提示的评论；已存在合法 marker 集合时保持原评论和分片不变并返回 `no-op`；marker 冲突仍失败。该判定由 core 完成，不由 Skill 扫描评论或拼标题。

package/templates/.agents/rules/local-artifact-repair.en.md

@@ -1,12 +1,19 @@
 # General Rule - Model-Driven Local Artifact Repair
 
-This rule applies only when `review-analysis`, `review-plan`, or `review-code` handles a finalizer failure for **the same controlled review artifact**. It does not apply to `task.md`, the ledger, receipts, source code, Git, platform resources, or lifecycle state.
+This rule applies when `analyze-task`, `plan-task`, or `code-task` handles **the same controlled local artifact** before its completed event, and when `review-analysis`, `review-plan`, or `review-code` handles a finalizer failure for **the same controlled review artifact**. It does not apply to `task.md`, the ledger, receipts, source code, Git, platform resources, or lifecycle state.
+
+## Pre-completion gate for analysis, plan, and code artifacts
+
+- `analyze-task`, `plan-task`, and `code-task` must call `task-artifact ... finalize-local` before publishing a completed event; pass only that call's `artifactSha256` and `semanticDigest` to the completed event.
+- `finalize-local` does not modify the artifact or task state, but it writes a one-shot local provenance intent in the repository workspace. After `failed`, the model may make one minimal edit in the same artifact only when `repairable=true` and the diagnostic explicitly describes a one-line replacement, then rerun the same call completely; count each byte-changing edit, up to 8.
+- The first repairable failure's semantic digest is retained in that intent; a later `passed` result must match the baseline, and the completed event must verify and atomically transition the same intent to `consumed` before writing `task.md` under the task lock. A consumption failure must not write the task; the consumed intent is durable and retryable, so no failure-prone post-write deletion is attempted. Do not replace a failed baseline with a newly computed digest or publish a completed event without the finalizer.
+- After `failed`, no progress, or a repeated diagnostic or fingerprint, do not publish a completed event. After `passed`, do not rescan or manually write summary data.
 
 ## Authorization Boundary
 
 - The finalizer only reads facts, validates state, normalizes successful results, and performs atomic writes. It does not maintain a recoverable-error allowlist, infer repairability, or choose report content to delete.
 - The initial finalizer call is not counted as a repair attempt. Editing is allowed only after the mechanical safety gates pass and the model explicitly determines that the current problem can be solved by a minimal, explainable artifact change.
-- The model may edit only the one ordinary review artifact declared by the current review skill, and the file must be inside the current task directory. It must not edit `task.md`, the review disagreement ledger, receipts, source code, other reports, or remote resources.
+- The model may edit only the one ordinary local artifact declared by the current skill, and the file must be inside the current task directory. It must not edit `task.md`, the review disagreement ledger, receipts, source code, other reports, or remote resources.
 - `changed=false`, an error code, or a format shape is diagnostic evidence, not automatic authorization. The model must judge each case using the complete diagnostic, artifact content, and context.
 
 ## Non-bypassable Mechanical Safety Gates

package/templates/.agents/rules/local-artifact-repair.zh-CN.md

@@ -1,12 +1,19 @@
 # 通用规则 - 模型驱动的本地产物修复
 
-本规则只适用于 `review-analysis`、`review-plan`、`review-code` 在 finalizer 失败后处理**同一个受控 review artifact** 的场景。它不适用于 task.md、账本、receipt、源码、Git、平台资源或生命周期状态。
+本规则适用于 `analyze-task`、`plan-task`、`code-task` 在 completed 事件前处理**同一个受控本地产物**，以及 `review-analysis`、`review-plan`、`review-code` 在 finalizer 失败后处理**同一个受控 review artifact** 的场景。它不适用于 task.md、账本、receipt、源码、Git、平台资源或生命周期状态。
+
+## 分析、方案和代码产物完成前门禁
+
+- `analyze-task`、`plan-task` 和 `code-task` 必须在发布 completed 事件前调用 `task-artifact ... finalize-local`；只有同一次返回的 `artifactSha256` 和 `semanticDigest` 才能传给 completed 事件。
+- `finalize-local` 不修改产物或任务状态，但会在仓库工作区写入一次性的本地 provenance intent。返回 `failed` 时，只有 `repairable=true` 且诊断明确为单行替换，模型才可在同一产物中执行一次最小编辑，然后完整重跑同一调用；每次实际字节修改计一次，最多 8 次。
+- 首次可修复失败的 semantic digest 会保存在该 intent 中；后续 `passed` 必须匹配该基线，completed event 还必须在任务锁内验证并在写 task.md 前原子转换为 `consumed` 状态。消费失败时不得写任务；转换后的 intent 是可重试的 durable 记录，成功写入后不再执行可能失败的后置删除。不得用重新计算的新摘要替换失败基线，也不得绕过 finalizer 直接发布 completed event。
+- 返回 `failed`、无进展、诊断或指纹重复时不得发布 completed 事件；返回 `passed` 后也不得重新扫描或手工补写摘要。
 
 ## 授权边界
 
 - finalizer 只负责读取事实、校验状态、规范化成功结果和原子写入；它不维护可修复错误码白名单，不推断 repairability，也不自动选择要删除的报告内容。
 - 首次 finalizer 调用不计入修复次数。只有在机械安全门通过后，模型明确判断当前问题能通过最小、可解释的 artifact 修改解决时，才允许编辑。
-- 模型只能修改当前 review skill 声明的一个普通 review artifact，且该文件必须位于当前 task 目录。不得修改 task.md、审查分歧账本、receipt、源码、其他报告或远端资源。
+- 模型只能修改当前 skill 声明的一个普通本地产物，且该文件必须位于当前 task 目录。不得修改 task.md、审查分歧账本、receipt、源码、其他报告或远端资源。
 - `changed=false`、错误码或某个格式形状只是诊断事实，不是自动批准。模型必须结合完整诊断、artifact 内容和上下文逐例判断。
 
 ## 不可绕过的机械安全门

package/templates/.agents/rules/pr-sync.en.md

@@ -2,7 +2,7 @@
 
 > `--agent` values are defined in `.agents/rules/task-management.md` under “Collaborator Token Specification”.
 
-The model writes the semantic reviewer summary. Typed core owns canonical artifact selection, marker/HEAD wrapping, paginated comment lookup, and reconciliation.
+The model writes the semantic reviewer summary. Typed core owns the task-intent digest, complete three-dot diff, canonical `pr-change-report.json` sidecar, report rendering, authoritative PR-head wrapping, paginated comment lookup, and reconciliation.
 
 ## Three-Layer Isolation
 
@@ -15,11 +15,17 @@ The three never cross: a regular PR comment does not carry the full process copy
 ```bash
 agent-infra-internal platform-pr summary-context {task-id}
 
+agent-infra-internal platform-pr change-report {task-id} \
+  --agent {standard-agent-token} --mechanical-file {mechanical-report-file} \
+  --precheck-file {precheck-candidate-file}
+
 agent-infra-internal platform-pr summary-sync {task-id} \
-  --agent {standard-agent-token} --body-file {summary-body-file}
+  --agent {standard-agent-token} --body-file {summary-body-file} \
+  --change-report-file .agents/workspace/active/{task-id}/pr-change-report.json \
+  --result {primary-result}
 ```
 
-Use only canonical inputs returned by the context command. Write the plain body without marker or SHA. The core owns `<!-- sync-pr:{task-id}:summary -->`, current `<!-- last-commit: ... -->`, create/update/no-op behavior, and duplicate-marker conflicts. Summary failure never rolls back a PR or commit.
+Use only canonical inputs returned by the context command. The precheck must contain file evidence for six fixed checks; `formalReview` is always false and `needs-review` routes to `review-code`. Write the plain body with exactly one `<!-- canonical-pr-change-report -->` placeholder, without a report heading/JSON, marker, or SHA. The core validates the task-intent digest, bound PR identity, complete patch SHA, and mechanical totals before rendering the report, then owns `<!-- sync-pr:{task-id}:summary -->`, authoritative `<!-- last-commit: ... -->`, create/update/no-op behavior, and duplicate-marker conflicts. Missing, stale, invalid, or bypassed report input never publishes; summary failure never rolls back a PR or commit.
 
 The canonical comment envelope produced by the core is:
 
@@ -34,7 +40,7 @@ The canonical comment envelope produced by the core is:
 ### PR Code Changes
 ```
 
-Canonical inputs include `manual-validation.md`. The manual-validation section is one of `### ✅ Manual Validation Passed`, `### ⚠️ Manual Verification Required`, or `### ✅ No Manual Verification Needed`; `complete-manual-validation` refreshes the same summary in place. The PR code-change section uses authoritative base/head facts from `platform-pr inspect` and the complete `git diff --find-renames --numstat base...head`, reconciles runtime, test, skill/rule, template, documentation, and other categories, and explains renames, mechanical mirrors, and potentially unnecessary changes.
+Canonical inputs include `manual-validation.md`. The manual-validation section is one of `### ✅ Manual Validation Passed`, `### ⚠️ Manual Verification Required`, or `### ✅ No Manual Verification Needed`; `complete-manual-validation` refreshes the same summary in place. The PR code-change section uses authoritative base/head facts from `platform-pr inspect` and the complete `git diff --find-renames --numstat base...head`, reconciles runtime, test, skill/rule, template, documentation, and other categories, and explains renames, mechanical mirrors, and potentially unnecessary changes. The caller supplies the placeholder; the core renderer supplies the canonical `### PR Code Changes` section.
 
 ```bash
 agent-infra-internal task-warning {task-id} add --step {step} --severity WARNING \

package/templates/.agents/rules/pr-sync.zh-CN.md

@@ -2,7 +2,7 @@
 
 > `--agent` 取值见 `.agents/rules/task-management.md`「合作者 token 规范」。
 
-PR 摘要的语义聚合由模型完成；canonical 产物选择、marker、当前 HEAD、分页评论查找和 create/update/no-op 由 typed core 负责。
+PR 摘要的语义聚合由模型完成；任务意图 digest、完整三点 diff、canonical `pr-change-report.json` sidecar、报告渲染、marker、权威 PR head、分页评论查找和 create/update/no-op 由 typed core 负责。
 
 ## 三层隔离
 
@@ -24,7 +24,8 @@ agent-infra-internal platform-pr summary-context {task-id}
 - 测试结果
 - 审查历程与当前结论
 - 人工校验三态：`### ⚠️ 需人工校验`、`### ✅ 人工验证已通过` 或 `### ✅ 无需人工校验`
-- `### PR 代码增减`：基于 `platform-pr inspect` 的权威 base/head 和完整 `git diff --find-renames --numstat base...head`，按运行时代码、测试、Skill/规则、模板、文档及其他分类核算，并说明 rename、机械镜像与疑似不必要变化
+- 变更摘要、实现范围、测试结果、审查历程和人工校验三态
+- 一个 `<!-- canonical-pr-change-report -->` 占位符；`### PR 代码增减` 由 core renderer 基于权威 diff 生成，调用方不自行写标题或统计
 
 保留人工校验项时，每条写明校验内容、定位和只能人工完成的原因。
 
@@ -41,16 +42,28 @@ core 最终包装出的 canonical 评论结构为：
 ### PR 代码增减
 ```
 
+先用机械脚本和模型预检生成输入，再写入任务目录固定 sidecar：
+
+```bash
+agent-infra-internal platform-pr change-report {task-id} \
+  --agent {standard-agent-token} --mechanical-file {mechanical-report-file} \
+  --precheck-file {precheck-candidate-file}
+```
+
+precheck 必须覆盖六项固定检查并提供文件证据；`formalReview` 固定为 `false`，`needs-review` 路由到 `review-code`。sidecar 是当前 head 的可丢弃派生缓存，不是 lifecycle artifact 或 Issue artifact。
+
 ## 发布
 
 把聚合后的纯正文写入 `{summary-body-file}`，不要自行添加 marker 或 commit SHA：
 
 ```bash
 agent-infra-internal platform-pr summary-sync {task-id} \
-  --agent {standard-agent-token} --body-file {summary-body-file}
+  --agent {standard-agent-token} --body-file {summary-body-file} \
+  --change-report-file .agents/workspace/active/{task-id}/pr-change-report.json \
+  --result {primary-result}
 ```
 
-core 会包装唯一 `<!-- sync-pr:{task-id}:summary -->` 和当前 `<!-- last-commit: ... -->`，分页查找 PR 普通评论：不存在则创建、正文变化则原地更新、无差异则 no-op、重复 marker 则稳定失败。正文通过文件输入，调用方不得拼 shell/heredoc。
+正文必须恰好包含一次 `<!-- canonical-pr-change-report -->`，不得自行拼接报告标题/JSON、marker 或 last-commit。core 会重新校验任务意图 digest、绑定 PR identity、完整 patch SHA 和机械统计，由 renderer 生成报告段，再包装唯一 `<!-- sync-pr:{task-id}:summary -->` 和权威 `<!-- last-commit: ... -->`，分页查找 PR 普通评论：不存在则创建、正文变化则原地更新、无差异则 no-op、重复 marker 或报告失配则稳定失败。正文通过文件输入，调用方不得拼 shell/heredoc。
 
 ## 结果回传
 

package/templates/.agents/rules/task-short-id.en.md

@@ -123,7 +123,4 @@ repair hint.
 ## Cross-TUI use
 
 Bare numeric `N` is safe in every shell and TUI without quoting:
-`ai sandbox exec 11 'npm test'`, `/review-analysis 11`.
-
-Starting with the next major version, migrate the old `#NN` form to `NN`;
-even a quoted value delivered intact to the CLI is rejected.
+`ai sandbox exec 11 'npm test'`, `/review-analysis --task 11`.

package/templates/.agents/rules/task-short-id.zh-CN.md

@@ -97,6 +97,4 @@ fi
 ## 跨 TUI 使用
 
 裸数字 `N` 在所有 shell 与 TUI 中都安全无需引号：
-`ai sandbox exec 11 'npm test'`、`/review-analysis 11`。
-
-从下一个大版本起，原 `#NN` 写法必须迁移为 `NN`；即使引用后完整传入 CLI 也会被拒绝。
+`ai sandbox exec 11 'npm test'`、`/review-analysis --task 11`。

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

@@ -9,7 +9,7 @@ description: >
 # Analyze Task
 > `--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.
+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.
 
 ## Boundary / Critical Rules
 
@@ -41,7 +41,7 @@ Before the state check is complete, do not make external-state assertions such a
 
 ## Step Start: Declare the started Event
 
-After resolving the artifact context and before this round's first artifact action, run `agent-infra-internal task-event {task-id} analyze.started --agent {standard-agent-token}` and verify the returned `artifactContext`.
+After resolving the artifact context and before this round's first artifact action, run `agent-infra-internal task-event {task-id} analyze.started --agent {standard-agent-token} --initiator {trigger-initiator} --request-id {request-id} --reason-code {reason-code}` and verify the returned `artifactContext`.
 
 ## Steps
 
@@ -203,7 +203,17 @@ Update `.agents/workspace/active/{task-id}/task.md`:
   - Overwrite the `priority` field in frontmatter with the new value
   - Append a `## Priority Re-estimate` section to this round's analysis artifact `{analysis-artifact}`, recording: `priority {old} → {new} (rationale: {short basis grounded in this analysis})`
   If the re-estimated value matches the current value, skip it: do not write the `## Priority Re-estimate` section. The Flow A sync that follows reads the possibly updated frontmatter and propagates the new value to the Issue automatically.
-After the business fields are updated, run `agent-infra-internal task-event {task-id} analyze.completed --agent {standard-agent-token} --artifact {analysis-artifact} {execution-flag}` so the core atomically records the link, stage, agent, metadata, and Activity Log.
+After writing the local artifact, run the pre-completion gate:
+
+```bash
+agent-infra-internal task-artifact {task-id} finalize-local --family analysis --artifact {analysis-artifact}
+```
+
+- On `status=passed`, save that result's `artifactSha256` and `semanticDigest`; the finalizer has recorded the matching one-shot local provenance intent.
+- On `status=failed` with `repairable=true`, apply only the diagnostic's `replace-line` operation once, then rerun the same command completely; count an attempt only after bytes change, up to 8 attempts.
+- The first repairable failure's `semanticDigest` is retained as the baseline; a retried `status=passed` result must match it. On baseline mismatch, any other failure, no progress, or a repeated diagnostic, stop without publishing a completed event.
+
+Use the digests from that same `status=passed` result in `agent-infra-internal task-event {task-id} analyze.completed --agent {standard-agent-token} --initiator {trigger-initiator} --request-id {request-id} --reason-code {reason-code} --artifact {analysis-artifact} --artifact-sha256 {artifact-sha256} --semantic-digest {semantic-digest} {execution-flag}` so the core records the link, stage, agent, metadata, and Activity Log atomically.
   - {YYYY-MM-DD HH:mm:ss±HH:MM} — **Analyze Task (Round {N})** by {agent} — Analysis completed → {analysis-artifact}
   ```
 

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

@@ -9,7 +9,7 @@ description: >
 # 分析任务
 > `--agent` 取值见 `.agents/rules/task-management.md`「合作者 token 规范」。
 
-若入口业务操作数包含 `--orchestrated`，绑定 `{execution-flag}` = `--orchestrated` 并原样转发给 completed 事件；否则绑定为空。不得从 `orchestration.json`、环境变量或历史产物推断该标记。
+若入口业务操作数包含 `--orchestrated`，绑定 `{execution-flag}` = `--orchestrated` 并原样转发给 completed 事件；否则绑定为空。不得从 `orchestration.json`、环境变量或历史产物推断该标记。生命周期事件还必须携带显式触发信息：编排调用使用 `{trigger-initiator}=orchestrator`，否则使用 `model`；`{request-id}` 是本任务与本轮产物的稳定单行标识，`{reason-code}` 使用 `user-request`、`new-requirement` 或 `upstream-fact-doubt`；started 与 completed 使用同一组值。
 
 ## 行为边界 / 关键规则
 
@@ -44,7 +44,7 @@ agent-infra-internal task-snapshot {task-id} --format text
 确认前置条件和轮次后、本轮第一个产出动作之前执行：
 
 ```bash
-agent-infra-internal task-event {task-id} analyze.started --agent {standard-agent-token}
+agent-infra-internal task-event {task-id} analyze.started --agent {standard-agent-token} --initiator {trigger-initiator} --request-id {request-id} --reason-code {reason-code}
 ```
 
 ## 执行步骤
@@ -204,7 +204,14 @@ agent-infra-internal task-event {task-id} analyze.started --agent {standard-agen
   - 用新值覆盖 frontmatter 的 `priority` 字段
   - 在本轮分析产物 `{analysis-artifact}` 中追加 `## 优先级重估` 段，记录一条：`priority {old} → {new} (rationale: {基于本轮分析的简短依据})`
   若重估值与当前值一致，跳过：不写入 `## 优先级重估` 段。后续 Flow A 同步会读取可能更新过的 frontmatter，并自动把新值同步到 Issue。
-- 完成业务内容更新后执行 `agent-infra-internal task-event {task-id} analyze.completed --agent {standard-agent-token} --artifact {analysis-artifact} {execution-flag}`，由核心原子登记链接、阶段、代理、时间、版本和 Activity Log。
+- 完成本地产物后，先执行本地完成前门禁：
+  ```bash
+  agent-infra-internal task-artifact {task-id} finalize-local --family analysis --artifact {analysis-artifact}
+  ```
+  - `status=passed`：保存本次返回的 `artifactSha256` 和 `semanticDigest`；finalizer 已记录对应的一次性本地 provenance intent。
+  - `status=failed` 且 `repairable=true`：仅按诊断中的 `replace-line` 操作做一次最小修改，然后完整重跑同一命令；实际字节发生变化才计一次 `repairAttempts`，最多 8 次。
+  - 首次可修复失败的 `semanticDigest` 由 finalizer 保留为基线；重试后的 `status=passed` 必须匹配该基线。基线不匹配、其他失败、无进展或重复诊断：停止，不发布 completed 事件。
+- 使用同一次 `status=passed` 返回的摘要执行 `agent-infra-internal task-event {task-id} analyze.completed --agent {standard-agent-token} --initiator {trigger-initiator} --request-id {request-id} --reason-code {reason-code} --artifact {analysis-artifact} --artifact-sha256 {artifact-sha256} --semantic-digest {semantic-digest} {execution-flag}`，由核心登记链接、阶段、代理、时间、版本和 Activity Log。
 
 如果 task.md 中存在有效的 `issue_number`，执行以下同步操作（任一失败则跳过并继续）：
 - 调用 `agent-infra-internal platform-issue sync {task-id} --agent {standard-agent-token} --status pending-design-work --fields`

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

@@ -11,7 +11,7 @@ description: >
 ## Boundary / Critical Rules
 
 - This skill is **read-only** -- do not modify any files
-- Mechanical facts (frontmatter metadata, artifact grouping, git/platform state, and locating the task across the active, blocked, and completed directories) are delegated to the deterministic `ai task status` command. This skill only adds the semantic layer the CLI cannot produce: workflow-stage interpretation, review-verdict parsing, and the next-step recommendation.
+- Mechanical facts (frontmatter metadata, artifact grouping, git/platform state, and locating the task across the active, blocked, and completed directories) are delegated to the deterministic `ai task status` command. This skill only adds the semantic layer the CLI cannot produce: workflow-stage interpretation and review-verdict parsing; the next action comes directly from the CLI's canonical recommendation.
 
 ## Task Context Resolution
 
@@ -45,7 +45,7 @@ This is the semantic layer the CLI does not produce. Using the `Artifacts` group
   - `[pending]` - not started yet
   - `[blocked]` - blocked
   - `[skipped]` - skipped
-- For the latest review artifact of each stage (`review-analysis`, `review-plan`, `review-code`), read the report body and parse its conclusion: the overall verdict (Approved / Changes Requested / Rejected) and the blocker / major / minor counts. The CLI does not parse review bodies, so this reading is required to choose the next action in step 3.
+- For the latest review artifact of each stage (`review-analysis`, `review-plan`, `review-code`), read the report body and parse its conclusion: the overall verdict (Approved / Changes Requested / Rejected) and the blocker / major / minor counts. Use these conclusions only to explain stage status; do not recompute the next action from them.
 
 Present the workflow progress as an overlay on top of the CLI output, marking the latest round and the parsed review verdict, for example:
 
@@ -57,41 +57,20 @@ Workflow progress:
   [pending]    Plan Review
 ```
 
-### 3. Recommend Next Action
-
-Recommend the appropriate next skill based on the current workflow state.
-
-> **⚠️ CONDITION CHECK — you must choose the single matching row in the table below based on `status`, `current_step`, the latest artifacts, and the latest review result:**
->
-> - `status = blocked` -> choose "Task Blocked"
-> - `status = completed` -> choose "Task Completed"
-> - `current_step = requirement-analysis` and the latest analysis artifact is complete -> choose "Analysis Complete"
-> - `current_step = requirement-analysis-review` and the latest analysis review artifact is approved -> choose "Analysis Review Passed"
-> - `current_step = requirement-analysis-review` and the latest analysis review artifact exists but is not approved or has findings -> choose "Analysis Review Has Issues"
-> - `current_step = technical-design` and the latest plan artifact is complete -> choose "Plan Complete"
-> - `current_step = technical-design-review` and the latest plan review artifact is approved -> choose "Plan Review Passed"
-> - `current_step = technical-design-review` and the latest plan review artifact exists but is not approved or has findings -> choose "Plan Review Has Issues"
-> - The latest code artifact exists and there is still no latest code review artifact -> choose "Code Complete"
-> - `current_step = code-review` and the latest code review artifact exists, the verdict is `Approved`, and `Blocker = 0`, `Major = 0`, `Minor = 0` -> choose "Code Review Passed"
-> - `current_step = code-review` and the latest code review artifact exists, but any `Blocker`, `Major`, or `Minor` issue remains, or the verdict is not a clean approval -> choose "Code Review Has Issues"
->
-> **Important: if the latest review report contains any issue at all, do not use the corresponding review-passed row. Use the corresponding has-issues row instead.**
->
-> Before rendering the final output, read `.agents/rules/next-step-output.md`. After selecting an actionable row, invoke `agent-infra-internal agent-client next-steps --skill {next-skill} [--task-ref {task-ref}]` exactly once and render stdout verbatim as `{next-step-commands}`. Do not invoke the helper for `Task Blocked` or `Task Completed`. Append the `Completed at` trailing line last.
-
-| Current State              | next skill        | task ref |
-|----------------------------|-------------------|----------|
-| Analysis Complete          | `review-analysis` | required |
-| Analysis Review Passed     | `plan-task`       | required |
-| Analysis Review Has Issues | `analyze-task`    | required |
-| Plan Complete              | `review-plan`     | required |
-| Plan Review Passed         | `code-task`       | required |
-| Plan Review Has Issues     | `plan-task`       | required |
-| Code Complete              | `review-code`     | required |
-| Code Review Passed         | `commit`          | omitted  |
-| Code Review Has Issues     | `code-task`       | required |
-| Task Blocked               | —                 | —        |
-| Task Completed             | —                 | —        |
+### 3. Display the canonical recommendation
+
+Read only `Recommendation.action` from the `ai task status --task {task-id}` output and use it as the sole source of the next action. Do not recompute an action from `current_step`, the latest files, review prose, or the Activity Log.
+
+When the action is non-empty, perform only this literal action-to-skill conversion, then invoke the shared helper once:
+
+| Recommendation.action | next skill |
+|-----------------------|------------|
+| `analysis` | `analyze-task` |
+| `plan` | `plan-task` |
+| `code` | `code-task` |
+| any other action | same-named skill |
+
+When the action is empty, do not invoke the helper; state that no next skill is currently recommended. Before rendering the final output, read `.agents/rules/next-step-output.md`; invoke `agent-infra-internal agent-client next-steps --skill {next-skill} --task-ref {task-ref}` and render stdout verbatim as `{next-step-commands}`. Append the `Completed at` trailing line last.
 
 ## Notes
 

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

@@ -11,7 +11,7 @@ description: >
 ## 行为边界 / 关键规则
 
 - 本技能是**只读**操作 —— 不修改任何文件
-- 机械数据（frontmatter 元数据、产物分组、Git/Platform 状态，以及跨 active、blocked、completed 三目录定位任务）一律委托给确定性的 `ai task status` 命令。本技能只负责 CLI 无法产出的语义层：工作流阶段解读、审查结论解析、下一步建议。
+- 机械数据（frontmatter 元数据、产物分组、Git/Platform 状态，以及跨 active、blocked、completed 三目录定位任务）一律委托给确定性的 `ai task status` 命令。本技能只负责 CLI 无法产出的语义层：工作流阶段解读和审查结论解析；下一步 action 直接使用 CLI 的 canonical recommendation。
 
 ## 任务上下文解析
 
@@ -45,7 +45,7 @@ ai task status --task {task-id}
   - `[pending]` - 尚未开始
   - `[blocked]` - 被阻塞
   - `[skipped]` - 已跳过
-- 对各阶段最新的审查产物（`review-analysis`、`review-plan`、`review-code`），读取报告正文并解析结论：总体结论（通过 / 需要修改 / 拒绝）与阻塞项 / 主要问题 / 次要问题计数。CLI 不解析审查正文，因此这一步是步骤 3 选择下一步操作的必要输入。
+- 对各阶段最新的审查产物（`review-analysis`、`review-plan`、`review-code`），读取报告正文并解析结论：总体结论（通过 / 需要修改 / 拒绝）与阻塞项 / 主要问题 / 次要问题计数。这些结论只用于阶段状态展示和解释，不得用于重算下一步 action。
 
 把工作流进度作为 CLI 输出之上的叠加层呈现，标注最新轮次与解析出的审查结论，例如：
 
@@ -57,41 +57,20 @@ ai task status --task {task-id}
   [pending]    技术方案审查
 ```
 
-### 3. 建议下一步操作
-
-根据当前工作流状态，建议合适的下一个技能：
-
-> **⚠️ 条件判断 — 你必须先根据 `status`、`current_step`、最新产物和最新审查结果，选择下表中唯一匹配的一行：**
->
-> - `status = blocked` → 选择「任务被阻塞」
-> - `status = completed` → 选择「任务已完成」
-> - `current_step = requirement-analysis` 且最新分析产物已完成 → 选择「分析完成」
-> - `current_step = requirement-analysis-review` 且最新需求分析审查产物通过 → 选择「需求分析审查通过」
-> - `current_step = requirement-analysis-review` 且最新需求分析审查产物存在但未通过或有问题 → 选择「需求分析审查有问题」
-> - `current_step = technical-design` 且最新计划产物已完成 → 选择「计划完成」
-> - `current_step = technical-design-review` 且最新技术方案审查产物通过 → 选择「技术方案审查通过」
-> - `current_step = technical-design-review` 且最新技术方案审查产物存在但未通过或有问题 → 选择「技术方案审查有问题」
-> - 最新实现产物已存在，且尚无最新审查产物 → 选择「实现完成」
-> - `current_step = code-review` 且最新代码审查产物存在，且结论为 `Approved`，同时 `Blocker = 0`、`Major = 0`、`Minor = 0` → 选择「代码审查通过」
-> - `current_step = code-review` 且最新代码审查产物存在，但仍有任何 `Blocker`、`Major` 或 `Minor` 问题，或结论不是无问题通过 → 选择「代码审查有问题」
->
-> **特别注意：只要最新审查报告中存在任何问题，就不能使用对应「审查通过」行。必须改用对应「审查有问题」行。**
->
-> 渲染最终输出前先读取 `.agents/rules/next-step-output.md`。选中可执行行后只调用一次 `agent-infra-internal agent-client next-steps --skill {next-skill} [--task-ref {task-ref}]`，将 stdout 原样输出为 `{next-step-commands}`；`任务被阻塞` 与 `任务已完成` 不调用 helper。最后追加 `Completed at` 收尾行。
-
-| 当前状态           | next skill        | task ref |
-|--------------------|-------------------|----------|
-| 分析完成           | `review-analysis` | required |
-| 需求分析审查通过   | `plan-task`       | required |
-| 需求分析审查有问题 | `analyze-task`    | required |
-| 计划完成           | `review-plan`     | required |
-| 技术方案审查通过   | `code-task`       | required |
-| 技术方案审查有问题 | `plan-task`       | required |
-| 实现完成           | `review-code`     | required |
-| 代码审查通过       | `commit`          | omitted  |
-| 代码审查有问题     | `code-task`       | required |
-| 任务被阻塞         | —                 | —        |
-| 任务已完成         | —                 | —        |
+### 3. 展示 canonical recommendation
+
+只读取 `ai task status --task {task-id}` 输出中的 `Recommendation.action`，将其作为唯一下一步来源。不要根据 `current_step`、目录中的最新产物、审查正文或 Activity Log 再计算 action。
+
+当 action 非空时，仅做以下 action 到 skill 的字面转换，然后调用一次统一 helper：
+
+| Recommendation.action | next skill |
+|-----------------------|------------|
+| `analysis` | `analyze-task` |
+| `plan` | `plan-task` |
+| `code` | `code-task` |
+| 其他 action | 同名 skill |
+
+`action` 为空时不调用 helper，只说明当前没有可推荐的下一技能。渲染最终输出前先读取 `.agents/rules/next-step-output.md`；helper 命令为 `agent-infra-internal agent-client next-steps --skill {next-skill} --task-ref {task-ref}`，stdout 原样作为 `{next-step-commands}` 下一步命令。最后追加 `Completed at` 收尾行。
 
 ## 注意事项
 

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

@@ -9,7 +9,7 @@ description: >
 # Code Task
 > `--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.
+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.
 
@@ -19,6 +19,7 @@ Implement the approved plan and produce `code.md` or `code-r{N}.md`. This skill
 - 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
+- Before `code.completed`, the implementation report must pass `task-artifact ... finalize-local --family code`; follow `.agents/rules/local-artifact-repair.md` for any provably safe minimal structural repair in that same report, and pass only that successful call's digests to the completion event
 - If implementation encounters a key design decision not covered by the plan, run `agent-infra-internal task-ledger {task-id} decision-next-id`, write the returned `HD-N` detail block per `.agents/rules/human-decision-context.md` and determine whether implementation is required, then run `decision-upsert --id {HD-N} --stage code --artifact {code-artifact} --needs-implementation {true|false}`. Do not scan ids, assemble ledger rows, ask mid-flow, or silently expand scope
 - Do not invoke the `commit` skill or push to a remote; after tests pass, call the shared commit core with `delivery: { mode: 'local' }` to create the local checkpoint. The durable intent must close only after the checkpoint and task state sync succeed; only then emit `code.completed`
 - Create a new code artifact for each round and never overwrite an older one
@@ -44,7 +45,7 @@ agent-infra-internal task-snapshot {task-id} --format text
 
 ## Step Start: Write the started Marker
 
-After prerequisites and mode are confirmed and before this round's first artifact action, run `agent-infra-internal task-event {task-id} code.started --agent {standard-agent-token}`. Append `--fix-for {review-artifact}` in fix mode or `--implementation-input {input-id}` in decision mode. The core derives and validates the round and input identity; record the returned `artifactContext`.
+After prerequisites and mode are confirmed and before this round's first artifact action, run `agent-infra-internal task-event {task-id} code.started --agent {standard-agent-token} --initiator {trigger-initiator} --request-id {request-id} --reason-code {reason-code}`. Append `--fix-for {review-artifact}` in fix mode or `--implementation-input {input-id}` in decision mode. The core derives and validates the round and input identity; record the returned `artifactContext`.
 
 ## Steps
 
@@ -60,7 +61,7 @@ Read `reference/branch-management.md`, ensure the current branch matches the tas
 
 **Mandatory; do not skip.** If task.md has a valid `issue_number`, run `agent-infra-internal platform-issue sync {task-id} --agent {standard-agent-token} --milestone specific`.
 
-> If the milestone remains `X.Y.x`, step 11 `task-verify code.completed` blocks through the typed milestone check.
+> If the milestone remains `X.Y.x`, step 12 `task-verify code.completed` blocks through the typed milestone check.
 
 ### 4. Determine Mode and Round
 
@@ -106,28 +107,46 @@ When triaging a test failure or unexpected behavior, first read `.agents/rules/d
 
 After tests pass, call the shared commit core with `agent-infra-internal git-workflow commit --input {checkpoint-input}`. Pass `delivery: { "mode": "local" }`, explicit paths, expected HEAD/tree, task ref, agent, and the code round. This creates only a local checkpoint and does not contact a remote. The core writes a durable intent before committing and removes it after task-writer synchronization; do not emit `code.completed` if either checkpoint or task synchronization fails.
 
+After the checkpoint succeeds, when task.md has an `issue_number`, run `agent-infra-internal platform-issue sync {task-id} --agent {standard-agent-token} --in-labels from-diff --base {delivery-base-ref}`. The task-bound `delivery_base_ref` is the only source for Issue `in:` evidence; record a warning and stop this round without emitting `code.completed` if this sync fails.
+
 ### 9. Write the Code Report
 
 Create `.agents/workspace/active/{task-id}/{code-artifact}`.
 
 > Read `reference/report-template.md` before writing the report.
 
-### 10. Update Task Status
+### 10. Pre-completion Report Gate
+
+After writing the report and before publishing `code.completed`, read and follow `.agents/rules/local-artifact-repair.md` and run:
+
+```bash
+finalizer=$(agent-infra-internal task-artifact {task-id} finalize-local --family code --artifact {code-artifact})
+status=$?
+echo "$finalizer"
+```
+
+- `status=0` with `finalizer.status="passed"`: bind `{artifact-sha256}` and `{semantic-digest}` from this result.
+- `status=1` with `repairable=true` and a diagnostic explicitly describing a one-line replacement: confirm task, round, artifact, and provenance are unchanged; edit only that `code*.md` once, confirm the bytes changed, then rerun the same command completely.
+- For any other failure, lack of progress, repeated diagnostic, or eight actual report edits, stop without publishing `code.completed`.
+
+Do not rescan or manually write digest data; the completion event must include `--artifact-sha256 {artifact-sha256} --semantic-digest {semantic-digest}` from the successful finalizer result.
+
+### 11. Update Task Status
 
-After requirement checkboxes are updated, run the initial event `agent-infra-internal task-event {task-id} code.completed --agent {standard-agent-token} --artifact {code-artifact} --files-modified {n} --tests-passed {n} {execution-flag}`; in fix mode use `--fix-for {review-artifact} --blockers {n} --major {n} --minor {n} --manual-validation {n} {execution-flag}` instead; in decision mode add `--implementation-input {input-id}` to the initial counts. The core atomically records the artifact link, stage, metadata, done log, and decision-input consumption.
+After requirement checkboxes are updated, run the initial event `agent-infra-internal task-event {task-id} code.completed --agent {standard-agent-token} --initiator {trigger-initiator} --request-id {request-id} --reason-code {reason-code} --artifact {code-artifact} --artifact-sha256 {artifact-sha256} --semantic-digest {semantic-digest} --files-modified {n} --tests-passed {n} {execution-flag}`; in fix mode add `--fix-for {review-artifact} --blockers {n} --major {n} --minor {n} --manual-validation {n} {execution-flag}` instead; in decision mode add `--implementation-input {input-id}` to the initial counts. The core atomically records the artifact link, stage, metadata, done log, and decision-input consumption.
 
-If task.md has a valid `issue_number`, read `.agents/rules/issue-sync.md`, then:
+If task.md has a valid `issue_number`, read `.agents/rules/issue-sync.md`, then (status/comment failures follow the warning rules; an Issue `in:` evidence failure must not emit `code.completed`):
 - Run `agent-infra-internal platform-issue sync {task-id} --agent {standard-agent-token} --status in-progress`
 - Run `agent-infra-internal platform-comment sync {task-id} --kind task --agent {standard-agent-token}`
 - Run `agent-infra-internal platform-comment sync {task-id} --kind artifact --artifact {code-artifact} --agent {standard-agent-token}`
 
-### 11. Run Completion Gate
+### 12. Run Completion Gate
 
 ```bash
 agent-infra-internal task-verify {task-id} code.completed --artifact {code-artifact} --format text
 ```
 
-### 12. Tell the User
+### 13. Tell the User
 
 Use `reference/output-template.md` (or `reference/fix-mode.md` in fix mode) and render the selected next-step commands through the shared helper. Do not push, create a PR, or invoke the `commit` skill here.
 

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

@@ -9,7 +9,7 @@ description: >
 # 编码任务
 > `--agent` 取值见 `.agents/rules/task-management.md`「合作者 token 规范」。
 
-若入口业务操作数包含 `--orchestrated`，绑定 `{execution-flag}` = `--orchestrated` 并原样转发给 completed 事件；否则绑定为空。不得从 `orchestration.json`、环境变量或历史产物推断该标记。
+若入口业务操作数包含 `--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` 反馈的修复，以及人工裁决驱动实现三种模式。
 
@@ -19,6 +19,7 @@ description: >
 - 生成会同步到 Issue 的任务或生命周期 Markdown 前，先读取 `.agents/rules/sync-content-generation.md` 并遵循其中的生成端约束；同步端不解析或改写正文
 - 实现前读取 `.agents/rules/compatibility-policy.md`；只实现方案明确批准的兼容预算，不以“稳妥”为由保留旧分支、旧结果契约或迁移 shim
 - 修复模式逐条核实最新 `review-code` 的发现：成立则修复，判定为不成立/幻觉则在报告中反驳并记入 unresolved；不擅自扩大到审查未列出的问题；manual-validation 项不在修复范围
+- 实现报告在 `code.completed` 前必须通过 `task-artifact ... finalize-local --family code`；按 `.agents/rules/local-artifact-repair.md` 处理同一报告内可证明安全的最小结构修复，并只把同一次通过结果的摘要传给完成事件
 - 实现中遇到方案未覆盖的关键设计决策时，先调用 `agent-infra-internal task-ledger {task-id} decision-next-id` 取得 `HD-N`，按 `.agents/rules/human-decision-context.md` 写入实现报告的 `## 人工裁决待办` 详情块并判断是否需要实现，再调用 `decision-upsert --id {HD-N} --stage code --artifact {code-artifact} --needs-implementation {true|false}`；不得扫描编号、手写账本行、中途提问或擅自扩范围
 - 不调用 `commit` 技能，也不推送远端；测试通过后直接调用共享 commit core 的 `delivery: { mode: 'local' }` 创建本地 checkpoint。checkpoint 使用 durable intent，只有 checkpoint 与 task 状态同步成功后才发送 `code.completed`
 - 每轮实现都创建新的实现产物，不覆盖旧文件
@@ -59,7 +60,7 @@ agent-infra-internal task-snapshot {task-id} --format text
 
 ## 步骤开始：声明 started 事件
 
-确认前置条件与模式后、本轮第一个产出动作之前执行 `agent-infra-internal task-event {task-id} code.started --agent {standard-agent-token}`。修复模式追加 `--fix-for {review-artifact}`，裁决模式追加 `--implementation-input {input-id}`。核心根据 artifact context 推导并校验轮次与输入身份；以返回的 `artifactContext` 记录本轮身份。
+确认前置条件与模式后、本轮第一个产出动作之前执行 `agent-infra-internal task-event {task-id} code.started --agent {standard-agent-token} --initiator {trigger-initiator} --request-id {request-id} --reason-code {reason-code}`。修复模式追加 `--fix-for {review-artifact}`，裁决模式追加 `--implementation-input {input-id}`。核心根据 artifact context 推导并校验轮次与输入身份；以返回的 `artifactContext` 记录本轮身份。
 
 ## 执行步骤
 ### 1. 验证前置条件
@@ -87,7 +88,7 @@ agent-infra-internal task-snapshot {task-id} --format text
 
 **必须执行，不得跳过。** 如果 task.md 中存在有效的 `issue_number`，调用 `agent-infra-internal platform-issue sync {task-id} --agent {standard-agent-token} --milestone specific`；里程碑推断、权限降级与幂等写入由 internal core 处理。
 
-> 若跳过或收窄后仍为 `X.Y.x`，步骤 11 的 `task-verify code.completed` 会通过 typed milestone check 截停本轮。
+> 若跳过或收窄后仍为 `X.Y.x`，步骤 12 的 `task-verify code.completed` 会通过 typed milestone check 截停本轮。
 
 ### 4. 确定模式与轮次
 
@@ -144,6 +145,8 @@ echo "$result"
 
 测试通过后，通过 `agent-infra-internal git-workflow commit --input {checkpoint-input}` 调用共享 commit core，输入 `delivery: { "mode": "local" }`、明确 paths、expected HEAD/tree、task ref、agent 和 code round。该调用只创建本地 checkpoint，不访问远端；core 会在 commit 前写入 durable intent，并在 task writer 成功后清理 intent。checkpoint 失败或 task 状态未闭合时，不得发送 `code.completed`。
 
+checkpoint 成功后，若任务存在 `issue_number`，调用 `agent-infra-internal platform-issue sync {task-id} --agent {standard-agent-token} --in-labels from-diff --base {delivery-base-ref}`，由 task-bound `delivery_base_ref` 产生 Issue 的 `in:` target；该同步失败时记录 warning 并停止本轮，不发送 `code.completed`。
+
 排查测试失败或行为不符合预期时，先读取 `.agents/rules/debugging-guide.md`，按其四阶段流程定位根因，禁止盲目改代码重试。
 
 ### 9. 编写实现报告
@@ -152,22 +155,38 @@ echo "$result"
 
 > 报告结构、必填章节和完整模板见 `reference/report-template.md`。写报告前先读取 `reference/report-template.md`。
 
-### 10. 更新任务状态
+### 10. 报告完成前门禁
+
+报告写入后、发布 `code.completed` 前，读取并遵循 `.agents/rules/local-artifact-repair.md`，执行：
+
+```bash
+finalizer=$(agent-infra-internal task-artifact {task-id} finalize-local --family code --artifact {code-artifact})
+status=$?
+echo "$finalizer"
+```
+
+- `status=0` 且 `finalizer.status="passed"`：绑定这一次返回的 `{artifact-sha256}` 和 `{semantic-digest}`。
+- `status=1` 且返回 `repairable=true`、诊断明确为当前报告中的单行替换：确认任务、轮次、产物和 provenance 未变化后，只编辑该 `code*.md` 一次，确认字节确实变化，再完整重跑同一命令。
+- 其他失败、无进展、诊断重复或达到 8 次实际报告编辑：停止，不发布 `code.completed`。
+
+不得重新扫描或手工补写摘要；完成事件必须携带本次 `passed` 结果的 `--artifact-sha256 {artifact-sha256} --semantic-digest {semantic-digest}`。
+
+### 11. 更新任务状态
 
 更新 `.agents/workspace/active/{task-id}/task.md`：
 - 审查 `## 需求` 段落，仅把本轮已由代码实现且有测试通过支撑的条目从 `- [ ]` 勾为 `- [x]`
 - 产物链接、阶段与完成日志由 completed 事件统一登记
 - 完成业务内容更新后声明完成事件：
-  - 初次实现：`agent-infra-internal task-event {task-id} code.completed --agent {standard-agent-token} --artifact {code-artifact} --files-modified {n} --tests-passed {n} {execution-flag}`
-  - 修复模式：`agent-infra-internal task-event {task-id} code.completed --agent {standard-agent-token} --artifact {code-artifact} --fix-for {review-artifact} --blockers {n} --major {n} --minor {n} --manual-validation {n} {execution-flag}`
-  - 裁决模式：`agent-infra-internal task-event {task-id} code.completed --agent {standard-agent-token} --artifact {code-artifact} --implementation-input {input-id} --files-modified {n} --tests-passed {n} {execution-flag}`
+  - 初次实现：`agent-infra-internal task-event {task-id} code.completed --agent {standard-agent-token} --initiator {trigger-initiator} --request-id {request-id} --reason-code {reason-code} --artifact {code-artifact} --artifact-sha256 {artifact-sha256} --semantic-digest {semantic-digest} --files-modified {n} --tests-passed {n} {execution-flag}`
+  - 修复模式：`agent-infra-internal task-event {task-id} code.completed --agent {standard-agent-token} --initiator {trigger-initiator} --request-id {request-id} --reason-code {reason-code} --artifact {code-artifact} --artifact-sha256 {artifact-sha256} --semantic-digest {semantic-digest} --fix-for {review-artifact} --blockers {n} --major {n} --minor {n} --manual-validation {n} {execution-flag}`
+  - 裁决模式：`agent-infra-internal task-event {task-id} code.completed --agent {standard-agent-token} --initiator {trigger-initiator} --request-id {request-id} --reason-code {reason-code} --artifact {code-artifact} --artifact-sha256 {artifact-sha256} --semantic-digest {semantic-digest} --implementation-input {input-id} --files-modified {n} --tests-passed {n} {execution-flag}`
 
-如果 task.md 中存在有效的 `issue_number`，执行以下同步操作（任一失败则记录 warning 并继续；Issue 元数据边界仍见 `.agents/rules/issue-sync.md`）：
+如果 task.md 中存在有效的 `issue_number`，执行以下同步操作（状态/评论失败按规则记录 warning；Issue `in:` evidence 同步失败不得发送 `code.completed`；边界见 `.agents/rules/issue-sync.md`）：
 - 调用 `agent-infra-internal platform-issue sync {task-id} --agent {standard-agent-token} --status in-progress`
 - 调用 `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 {code-artifact} --agent {standard-agent-token}`
 
-### 11. 完成校验
+### 12. 完成校验
 
 运行完成校验，确认任务产物和同步状态符合规范：
 
@@ -182,7 +201,7 @@ agent-infra-internal task-verify {task-id} code.completed --artifact {code-artif
 
 将校验输出保留在回复中作为当次验证输出。没有当次校验输出，不得声明完成。
 
-### 12. 告知用户
+### 13. 告知用户
 
 > 仅在校验通过后执行本步骤。