@fitlab-ai/agent-infra 0.9.8 → 0.9.10

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

@@ -4,6 +4,6 @@
 
 1. 调用 `agent-infra-internal platform-pr summary-context {task-id}` 获取 canonical 聚合输入。
 2. 按 `.agents/rules/pr-sync.md` 生成纯摘要正文并写入临时文件。
-3. 调用 `agent-infra-internal platform-pr summary-sync {task-id} --agent {standard-agent-token} --body-file {summary-body-file}`。
+3. 调用 `agent-infra-internal platform-pr summary-sync {task-id} --agent {standard-agent-token} --body-file {summary-body-file} --result no_op`。commit 路径只同步已有 PR 摘要，不创建或复用 PR，因此固定使用 `no_op` 表示 PR 身份未变化。
 
 同步失败只记录 warning，不阻塞或回滚已经完成的 commit。`no-op` 回传 `summary skipped (no diff)`。

package/templates/.agents/skills/commit/reference/task-status-update.en.md

@@ -12,19 +12,13 @@ Get the current time first:
 date "+%Y-%m-%d %H:%M:%S%z" | sed 's/\([+-][0-9][0-9]\)\([0-9][0-9]\)$/\1:\2/'
 ```
 
-The `commit-complete` / `commit-recover` core has already atomically written this Activity Log entry:
+The `commit-operation.execute` core writes this Activity Log entry for task-bound operations:
 
 ```text
 - {YYYY-MM-DD HH:mm:ss±HH:MM} — **Commit** by {agent} — {commit hash short} {commit subject}
 ```
 
-When the evidence is satisfied, core also writes or refreshes:
-
-```yaml
-last_reviewed_commit: {new_head}
-```
-
-This field is the only baseline for the `complete-task` `post-review-commit` gate. The caller must not append Commit done again or write this field directly.
+Task metadata is best-effort synchronization after the Git primary action: an Activity Log or frontmatter write failure returns a `TASK_STATUS_SYNC_FAILED` warning without undoing the commit or push, and a later no-change retry may repair the record. `review-code`, review anchors, and `last_reviewed_commit` are not commit/push prerequisites. The caller must not append Activity Log entries directly.
 
 ### Scenario 5: Existing-PR push wrap-up
 
@@ -39,33 +33,6 @@ Next step - watch PR checks:
 
 If push fails, keep the task active and preserve local HEAD; show diagnostics and manual push guidance only, never `watch-pr` or `complete-task`. This scenario takes precedence over the final `prFlow` route below.
 
-### Scenario 4: pre-commit snapshot block
-
-This scenario ends the run before `git commit` and does not enter the successful post-commit scenario selection below. When any of `pre_head != R`, `W != T`, or `S != T` applies:
-
-- Do not run `git commit`, push, successful state updates, Issue/PR success sync, or the commit completion gate; preserve the current worktree and index.
-- Refresh task `updated_at`, `assigned_to`, and `agent_infra_version`, then append a done log with action `Commit`: `Blocked before git commit: reviewed snapshot mismatch (worktree added={a}, missing={m}, different={d}; staged added={a}, missing={m}, different={d})`.
-- User output must include `No commit was created.` and show Added/Missing/Different under both `Current worktree vs reviewed snapshot` and `Staged snapshot vs reviewed snapshot`; render an empty set as `- (none)` and list paths only in user output.
-- When `pre_head != R` or `W != T`, the only next step is a fresh `review-code`; when only `W == T && S != T`, tell the user to fix staging and rerun `commit` without re-review.
-
-Full re-review commands:
-
-Populate `{next-step-commands}` for this scenario by running `agent-infra-internal agent-client next-steps --skill review-code --task-ref {task-ref}`.
-
-```text
-Next step - re-run code review:
-{next-step-commands}
-```
-
-Full staging-only retry commands:
-
-Populate `{next-step-commands}` for this scenario by running `agent-infra-internal agent-client next-steps --skill commit --task-ref {task-ref}`.
-
-```text
-Next step - fix staging and retry commit:
-{next-step-commands}
-```
-
 Before selecting the next step, verify:
 - `current_step` and the latest workflow progress in `task.md`
 - whether the latest `review-code.md` / `review-code-r{N}.md` passed without findings

package/templates/.agents/skills/commit/reference/task-status-update.zh-CN.md

@@ -12,19 +12,13 @@
 date "+%Y-%m-%d %H:%M:%S%z" | sed 's/\([+-][0-9][0-9]\)\([0-9][0-9]\)$/\1:\2/'
 ```
 
-`commit-complete` / `commit-recover` 核心已原子写入以下 Activity Log：
+`commit-operation.execute` 在 task-bound 模式下负责写入以下 Activity Log：
 
 ```text
 - {YYYY-MM-DD HH:mm:ss±HH:MM} — **Commit** by {agent} — {commit hash short} {commit subject}
 ```
 
-证据满足时核心同时写入或刷新：
-
-```yaml
-last_reviewed_commit: {new_head}
-```
-
-该字段是 `complete-task` 的 `post-review-commit` gate 唯一 baseline。调用方只读取核心结果选择后续路由，不得再次追加 Commit done 或手写/推进该字段。
+任务记录是 Git 主动作之后的尽力同步：Activity Log 或 frontmatter 写入失败只返回 `TASK_STATUS_SYNC_FAILED` warning，不撤销 commit 或 push；后续无改动重跑可以再次尝试补齐记录。`review-code`、review anchor 和 `last_reviewed_commit` 不再是 commit/push 的前置条件，调用方只读取核心结果选择后续路由，不得手写 Activity Log。
 
 ### 场景 5：已有 PR 推送收尾
 
@@ -39,33 +33,6 @@ last_reviewed_commit: {new_head}
 
 push 失败时保留任务 active 与本地 HEAD，只展示诊断和人工推送提示；不得渲染 `watch-pr` 或 `complete-task`。该场景优先于下方 `prFlow` 终态路由。
 
-### 场景 4：提交前快照阻断
-
-此场景在 `git commit` 前终止本轮，不进入下方提交成功后的场景选择。任一 `pre_head != R`、`W != T` 或 `S != T` 命中时：
-
-- 不执行 `git commit`、push、成功状态更新、Issue/PR 成功同步或 commit 完成 gate；保留当前工作区与暂存区。
-- 刷新任务的 `updated_at`、`assigned_to`、`agent_infra_version`，并以 action `Commit` 追加 done 日志：`Blocked before git commit: reviewed snapshot mismatch (worktree added={a}, missing={m}, different={d}; staged added={a}, missing={m}, different={d})`。
-- 用户输出必须包含 `No commit was created.`，并分别按 `Current worktree vs reviewed snapshot`、`Staged snapshot vs reviewed snapshot` 展示 Added/Missing/Different；空集合显示 `- (none)`，路径只在用户输出中逐行展示。
-- `pre_head != R` 或 `W != T` 时，下一步只指向重新 `review-code`；仅 `W == T && S != T` 时，提示修正暂存后重跑 `commit`，无需重审。
-
-重新审查的完整命令：
-
-使用 `agent-infra-internal agent-client next-steps --skill review-code --task-ref {task-ref}` 生成本场景的 `{next-step-commands}`。
-
-```text
-下一步 - 重新代码审查：
-{next-step-commands}
-```
-
-仅修正暂存的完整命令：
-
-使用 `agent-infra-internal agent-client next-steps --skill commit --task-ref {task-ref}` 生成本场景的 `{next-step-commands}`。
-
-```text
-下一步 - 修正暂存后重新提交：
-{next-step-commands}
-```
-
 在决定下一步之前，先确认：
 - `task.md` 中的 `current_step` 和最新工作流进度
 - 最新的 `review-code.md` / `review-code-r{N}.md` 是否无问题通过

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

@@ -9,6 +9,8 @@ description: >
 # Complete Task
 > `--agent` values follow the "Collaborator Token Specification" in `.agents/rules/task-management.md`: standard AI short tokens (`claude`/`codex`/`antigravity`/`opencode`/`cursor`), long-name normalization (`claude-code`->`claude`, `antigravity-cli`->`antigravity`), or the `human` manual exception.
 
+Host finalization uses receipt v2 with an immutable `receiptId`, monotonic `revision`, and canonical warnings. Lifecycle/identity/required-PR hard failures return `result: failed|blocked`; after lifecycle succeeds, comment, peripheral verification, and other sync failures return `result: completed_with_warnings` and six-field warnings, retrying only receipt-pending steps.
+
 
 ## Boundary / Critical Rules
 
@@ -38,7 +40,7 @@ Before the state check is complete, do not make external-state assertions such a
 
 ## Step Start: Local Lifecycle Boundary
 
-On the normal path, complete business updates, platform sync, and the pre-completion gate while the task is active. Only then may the lifecycle intent in Step 6 atomically commit base terminal fields, the started/done pair, the directory move, and short-id release. Do not write those mechanical fields first. An archived task may only enter `finalization-retry`; do not move it back or rerun lifecycle.
+On the normal path, complete business updates, platform sync, and the pre-completion gate while the task is active. Only then may the single finalization intent in Step 6 advance lifecycle, the terminal task comment, and the completion gate in a fixed order. Do not write those mechanical fields first. An archived task may only enter `finalization-retry`; do not move it back or rerun lifecycle.
 
 ## Steps
 
@@ -63,7 +65,7 @@ Read `reference/external-delivery.md`, then run for the active task:
 agent-infra-internal platform-pr resolve-external {task-id} --agent {standard-agent-token} [--pr {external-pr}]
 ```
 
-- `mode=external`: only this invocation's typed `authorization` and `selected` fields authorize and identify external delivery; continue through every existing hard gate below.
+- `mode=external`: only this invocation's typed `authorization` and `selected` fields authorize and identify external delivery; continue through the required-PR, local lifecycle, and terminal checks, while peripheral evidence failures become warnings after lifecycle.
 - `mode=normal`: use the existing local lifecycle prerequisites; historical `pr_number` / `pr_status` values do not authorize external delivery.
 - `status=failed|blocked`: stop immediately and show the stable error; `--force` cannot bypass it.
 
@@ -95,31 +97,28 @@ This project enforces the PR flow (prFlow: "required") and the task has no PR ye
 Run /create-pr {task-ref} first, then complete; --skip-pr is not accepted under a mandatory PR flow.
 ```
 
-Before marking complete, verify ALL of these:
-- [ ] All workflow steps are complete (check workflow progress in task.md; **for the `pr_tasks` list under each yaml `commit` step, decide whether to count them by the "PR path" rule: `prFlow=required` always counts; `prFlow=disabled` never counts; when absent, exclude only if `pr_status=skipped`, otherwise count**)
-- [ ] Code has been reviewed (`review-code.md` or `review-code-r{N}.md` exists, and the latest review verdict is Approved; or review was done externally)
-- [ ] Code has been committed (no uncommitted changes related to this task)
-- [ ] Tests are passing
-- [ ] The disagreement ledger has no unclosed disagreements or un-re-reviewed post-review commits; on a bound-PR path local HEAD, `last_reviewed_commit`, and PR head either match strictly, or a merged squash has complete platform snapshot and remote Git equivalence evidence and current Git credentials can read the evidence refs; without a valid PR, a single-parent local rewrite is content-equivalent to `last_reviewed_commit` and has no later protected commits
-- [ ] Manual validation items are complete (when the latest review-code's Manual validation count is > 0, a passed manual-validation artifact and its completion record must exist, and that completion record must sit after the latest review-code; skipped when the count is 0 or there are no pending items)
+Before lifecycle, verify only the hard gates:
+- [ ] Task identity, active state, concurrency locks, and local atomic lifecycle operations are available
+- [ ] Required-PR delivery is satisfied when `prFlow=required`
+- [ ] Other business evidence (workflow, review, commit, tests, disagreement ledger, manual validation, and platform sync) is recorded or can be checked after lifecycle
 
 > **⚠️ Prerequisite Branch Check — you must decide whether to continue or stop before proceeding:**
 >
-> - If all conditions above are satisfied -> continue to Step 3
-> - If any condition is missing -> **stop by default** and output the prerequisite warning
-> - Only continue with unmet prerequisites when the user explicitly requested `--force`
+> - If the hard gates pass -> continue to Step 3
+> - If a hard gate is missing -> stop and output the prerequisite warning
+> - Missing peripheral evidence does not block lifecycle; represent it as warning/pending steps after lifecycle
 >
 > **Do not continue to Steps 3-8 when prerequisites are not met, and do not output "Task {task-id} completed; task directory moved to completed/."**
 
-If any prerequisite is not met, warn the user:
+If a hard prerequisite is not met, warn the user:
 ```
 Cannot complete task {task-id} - prerequisites not met:
 - [ ] {Missing prerequisite}
 
-Please complete the missing steps first, or use --force to override.
+Please satisfy the hard prerequisite first, then retry complete-task.
 ```
 
-If prerequisites are not met and the user did not explicitly provide `--force`, stop immediately and do not execute Steps 3-8.
+If a hard gate is not met, stop immediately and do not execute Steps 3-8.
 
 ### 3. Complete Business-Only Content
 
@@ -146,7 +145,7 @@ When the ledger contains a valid `PRC-N` post-review exemption, the summary body
 
 Do not sync the task comment here; it requires the terminal task.md written by lifecycle. Do not set a `status:` label; platform automation clears status labels after the Issue closes.
 
-If any operation fails, the task must remain active and its short id must remain valid. Record the failure with the matching structured warning intent, then stop without entering Step 5:
+If any operation fails, the task must remain active and its short id must remain valid. Record the failure with the matching structured warning intent, then continue to Step 5. Platform failures do not block the local lifecycle:
 
 ```bash
 agent-infra-internal task-warning {task-id} add --step complete-task --severity ACTION_REQUIRED --code {COMMENT_SYNC_FAILED|REQUIREMENTS_SYNC_FAILED|SUMMARY_SYNC_FAILED|NETWORK_RETRY_EXHAUSTED} --target {artifact|issue|summary|platform} --message "{error_code}: {error_message}" --action "Fix the platform sync problem and rerun complete-task"
@@ -162,46 +161,40 @@ After platform writes succeed and before moving the directory or releasing the s
 agent-infra-internal task-verify {task-id} complete-task.preflight --format text
 ```
 
-This event runs `review-ledger`, `manual-validation`, `post-review-commit`, then `platform-sync-preflight`. On any non-zero exit (fail/blocked), keep the task active, derive the stable code/target from the gate result, record it through `task-warning ... add --step complete-task ...`, and stop. For a review/head mismatch, rerun `commit` or `review-code`; never fall back to the review baseline.
+This event runs only the required-PR delivery hard preflight; host finalization still enforces identity, concurrency, and local atomicity before lifecycle. Peripheral review/manual/platform checks run through `complete-task.completed` after lifecycle and are projected as warning/pending steps. On a hard-gate non-zero exit (fail/blocked), keep the task active, record the stable code/target, and stop.
 
-When preflight's `post-review-commit` check passes through a human-decided exemption, update the same summary marker from Step 4 before entering Step 6. Add the original failure code/message and PRC id/evidence from the check output together with the ruling reason, commit scope, human identity, and time from task.md. When a warning exists, treat its historical record as canonical and reconcile it with the current check output; otherwise use the current check output as the original-failure source. Run the same `platform-comment sync ... --kind summary` intent again. If it fails, record `SUMMARY_SYNC_FAILED`, keep the task active, and stop before lifecycle.
+If a summary must mirror a human-decided `post-review-commit` exemption, make a best-effort sync in Step 4 with the original failure code/message, PRC id/evidence, and ruling details. A sync failure records `SUMMARY_SYNC_FAILED` and still allows lifecycle; terminal verification decides the final state.
 
-`--force` does not lift this hard gate: close ledger disagreements; re-review or exempt post-review commits, use the platform adapter's authoritative snapshot and remote refs for the bound change request (PR/MR) to prove a content-equivalent single-parent squash merge in an isolated temporary repository, or, without a valid change request, prove from local Git objects that the only protected commit is a content-equivalent single-parent rewrite with no later protected commits; then pass platform preflight. An unsupported adapter capability, missing required platform facts, Git objects, topology, or content evidence, or current Git credentials that cannot read the remote evidence refs fails closed. The platform adapter supplies normalized state for all checks, enforced before merge by the `review-code` / `watch-pr` routes; required checks remain additionally enforced by branch protection / rulesets.
+`--force` cannot lift identity, concurrency, local atomicity, or required-PR hard gates; failures there must stop. Other review, manual-validation, and platform evidence is recorded by terminal verification as warning/pending and can be repaired by retrying.
 
-### 6. Apply the Local Lifecycle Intent and Verify the Move
+### 6. Run the Host Finalization Entry Point and Verify the Terminal State
 
 ```bash
-agent-infra-internal task-lifecycle {task-id} complete --agent {standard-agent-token}
+agent-infra-internal task-finalization {task-id} complete --agent {standard-agent-token}
 ```
 
-Only `status=applied|no-op` means local completion succeeded. On `status=failed`, show the structured error and recovery steps and retry the same intent; do not claim completion or hand-repair partial state.
+Finalization runs lifecycle -> the terminal task comment -> the `complete-task.completed` gate in a fixed order and records each step in the host receipt. `result=completed` means lifecycle completed safely; if peripheral warnings remain, return `result=completed_with_warnings`, warnings, and pending steps. Use `result=failed` or `result=blocked` only for hard or receipt/capability failures, then fix the cause and retry through the same entry point; do not claim completion or hand-repair partial state.
 
 ```bash
 ls .agents/workspace/completed/{task-id}/task.md
 ```
 
-Confirm the task directory was successfully moved.
-
-### 7. Sync the Terminal Task Comment and Run the Gate
-
-Both Scenario A and Scenario B `finalization-retry` execute this step from the completed directory. If a valid `issue_number` exists, first run:
+Check the task directory only after finalization returns `status=completed`.
 
-```bash
-agent-infra-internal platform-comment sync {task-id} --kind task --agent {standard-agent-token}
-```
+### 7. Handle Finalization Retries and Results
 
-If this call fails, the task is already archived and `task-warning` cannot accept it. Keep the task completed and stop. After fixing the network or platform issue, rerun complete-task; Step 1 will enter `finalization-retry` and repeat only this step.
+Both Scenario A and Scenario B `finalization-retry` run the same `task-finalization` entry point from the host. The receipt is only a re-entry hint, not canonical truth: every re-entry revalidates the terminal task comment and completion gate; only an already `completed` task with its short-id registry entry released may skip the irreversible lifecycle. Do not split the operation into the former lifecycle, comment-sync, or completion-gate commands. If the task comment or gate is blocked by the network, preserve the receipt and completed steps, fix the network, and rerun complete-task. If lifecycle has not completed, keep the task active and resume the pending steps from the receipt.
 
-Run the verification gate to confirm the task artifact and sync state are valid:
+The result must include the structured output from this finalization run, confirming that the task artifact and sync state are valid:
 
 ```bash
 agent-infra-internal task-verify {task-id} complete-task.completed --format text
 ```
 
 Handle the result as follows:
-- exit code 0 (all checks passed) -> continue to the "Inform User" step
-- exit code 1 (validation failed) -> fix the reported issues and run the gate again
-- exit code 2 (network blocked or status-label cleanup is still pending) -> keep the task completed and stop; rerun complete-task later to enter `finalization-retry`
+- `status=completed` / exit code 0 (all checks passed) -> continue to the "Inform User" step
+- `status=failed` / exit code 1 -> fix the reported issues and run finalization again
+- `status=blocked` / exit code 2 -> preserve the receipt and completed steps and stop; rerun complete-task later to enter `finalization-retry`
 
 Keep the gate output in your reply as fresh evidence. Do not claim completion without output from this run.
 
@@ -211,7 +204,7 @@ Keep the gate output in your reply as fresh evidence. Do not claim completion wi
 
 > The completion timestamp line (the last line of the whole output) uses `date "+%Y-%m-%d %H:%M:%S"` (local timezone, no offset) and always sits at the very end of the output for at-a-glance scanning across windows. This skill renders no "Next steps" commands, but it does render an **optional sandbox-cleanup hint** before the timestamp line (see the gate below), and still prints the line.
 
-> **Optional sandbox-cleanup hint (gated)**: Render the "Optional: clean up this task's sandbox" block in the output below only when BOTH (1) `.agents/.airc.json` has a `sandbox` field and (2) task.md's `branch` field exists and is not `main` / `master`; otherwise omit the whole block. `{branch}` is the `branch` value from the task.md you already loaded (the task has moved to completed/, so read it from `.agents/workspace/completed/{task-id}/task.md`). This block is independent of "Next steps" semantics — it is not a workflow successor command.
+> **Optional sandbox-cleanup hint (gated)**: Render the "Optional: clean up this task's sandbox" block in the output below only when BOTH (1) `.agents/.airc.json` has a `sandbox` field and (2) task.md's `branch` field exists and is not `main` / `master`; otherwise omit the whole block. Use the full `{task-id}` for cleanup; do not substitute the branch name. This block is independent of "Next steps" semantics — it is not a workflow successor command.
 
 Output format:
 ```
@@ -226,9 +219,9 @@ Deliverables:
 - {List of key outputs: files modified, tests added, etc.}
 
 Optional: clean up this task's sandbox
-(The task is archived; the sandbox container and per-branch config directory are not reclaimed automatically. Run this if you no longer need them:)
+(The task is completed; the sandbox container and per-branch config directory are not reclaimed automatically. Run this if you no longer need them:)
 
-ai sandbox rm {branch}
+ai sandbox rm {task-id}
 
 Completed at: {completion-time}
 ```

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

@@ -9,6 +9,8 @@ description: >
 # 完成任务
 > `--agent` 取值见 `.agents/rules/task-management.md`「合作者 token 规范」：标准 AI 短名（`claude`/`codex`/`antigravity`/`opencode`/`cursor`）、长名归一化（`claude-code`→`claude`、`antigravity-cli`→`antigravity`）或人工例外 `human`。
 
+宿主 finalization 使用 receipt v2（不可变 `receiptId`、单调 `revision` 和 canonical warnings）。生命周期/身份/required PR 等硬失败返回 `result: failed|blocked`；生命周期完成后，评论、外围验证和其他同步失败返回 `result: completed_with_warnings` 及六字段 warning，并仅重试 receipt 中的 pending step。
+
 
 ## 行为边界 / 关键规则
 
@@ -38,7 +40,7 @@ agent-infra-internal task-snapshot {task-id} --format text
 
 ## 步骤开始：本地生命周期边界
 
-正常完成路径在 active 阶段完成业务更新、平台同步和预完成门禁后，才由步骤 6 的单次 lifecycle intent 原子完成基础终态字段、started/done 日志、目录转移和短号释放；不得提前手工写入这些机械状态。已归档任务只允许进入 `finalization-retry` 场景，不回迁目录或重新执行 lifecycle。
+正常完成路径在 active 阶段完成业务更新、平台同步和预完成门禁后，才由步骤 6 的单次 finalization intent 按固定顺序原子推进生命周期、终态 task 评论和完成校验；不得提前手工写入这些机械状态。已归档任务只允许进入 `finalization-retry` 场景，不回迁目录或重新执行 lifecycle。
 
 ## 执行步骤
 ### 1. 验证任务存在
@@ -62,7 +64,7 @@ agent-infra-internal task-snapshot {task-id} --format text
 agent-infra-internal platform-pr resolve-external {task-id} --agent {standard-agent-token} [--pr {external-pr}]
 ```
 
-- `mode=external`：只以本次 typed result 的 `authorization` 和 `selected` 作为外部交付授权与绑定身份，继续本步骤的既有硬门禁。
+- `mode=external`：只以本次 typed result 的 `authorization` 和 `selected` 作为外部交付授权与绑定身份，继续 required-PR、本地生命周期和终态校验；外围证据失败在 lifecycle 后记录为 warning。
 - `mode=normal`：走现有本地生命周期前置条件；历史 `pr_number` / `pr_status` 不构成外部授权。
 - `status=failed|blocked`：立即停止并展示稳定错误；`--force` 不得绕过。
 
@@ -94,31 +96,28 @@ agent-infra-internal platform-pr resolve-external {task-id} --agent {standard-ag
 请先运行 /create-pr {task-ref} 创建 PR 后再完成；--skip-pr 在强制 PR 下不被接受。
 ```
 
-标记完成之前，验证以下所有条件：
-- [ ] 所有工作流步骤已完成（检查 task.md 中的工作流进度；**对 yaml 中 commit 步骤的 `pr_tasks` 列表，按「走 PR 路径」判定是否计入未完成判定：`prFlow=required` 始终计入；`prFlow=disabled` 不计入；缺省下仅当 `pr_status=skipped` 时不计入，否则计入**）
-- [ ] 代码已审查（`review-code.md` 或 `review-code-r{N}.md` 存在，且最新审查结论为 Approved；或已在外部完成审查）
-- [ ] 代码已提交（没有与此任务相关的未提交变更）
-- [ ] 测试通过
-- [ ] 审查分歧账本无未关闭分歧、无未复审的 post-review 提交；绑定 PR 路径中本地 HEAD、`last_reviewed_commit`、PR head 严格一致，或已合并 squash 的平台快照与远端 Git 等价证据完整且当前 Git 凭据可读取证据 refs；无有效 PR 路径中本地单父重写与 `last_reviewed_commit` 内容等价且之后无受保护提交
-- [ ] 人工校验项已完成（最新 review-code 的 Manual validation 计数 > 0 时，须存在通过校验的 manual-validation 产物及其完成记录，且该完成记录位于最新 review-code 之后；计数为 0 或无未决项时跳过）
+生命周期前只验证硬门禁：
+- [ ] task 身份、active 状态、并发锁和本地原子生命周期操作可用
+- [ ] `prFlow=required` 时已满足 required-PR delivery
+- [ ] 其余业务证据（工作流、审查、提交、测试、分歧账本、人工校验和平台同步）已记录或可在生命周期后校验
 
 > **⚠️ 前置条件分支判断 — 你必须先判断“继续”还是“停止”：**
 >
-> - 如果以上所有条件都满足 → 继续步骤 3
-> - 如果任意一个条件不满足 → **默认停止**，输出前置条件未满足的警告
-> - 只有用户明确要求 `--force` 时，才可以在前置条件未满足时继续
+> - 如果硬门禁满足 → 继续步骤 3
+> - 如果硬门禁不满足 → 停止并输出前置条件未满足的警告
+> - 外围业务证据不满足不阻止生命周期；在生命周期后以 warning/pending steps 表示
 >
 > **禁止在前置条件未满足时继续执行步骤 3-8，也不要输出「任务 {task-id} 已完成，任务目录已转移到 completed/。」**
 
-如果任何前置条件未满足，警告用户：
+如果硬门禁未满足，警告用户：
 ```
 Cannot complete task {task-id} - prerequisites not met:
 - [ ] {缺失的前置条件}
 
-Please complete the missing steps first, or use --force to override.
+Please satisfy the hard prerequisite first, then retry complete-task.
 ```
 
-如果前置条件未满足且用户未明确提供 `--force`，立即停止，不执行步骤 3-8。
+如果硬门禁未满足，立即停止，不执行步骤 3-8。
 
 ### 3. 完成业务内容更新
 
@@ -145,7 +144,7 @@ Please complete the missing steps first, or use --force to override.
 
 不要在本步骤同步 task 评论；它依赖 lifecycle 写入后的完整终态 task.md。不要设置 `status:` label，平台自动化应在 Issue 关闭后清理状态标签。
 
-任一操作失败时，任务仍必须位于 active 且短号仍有效；先按失败类型调用以下结构化 warning intent，再立即停止，不进入步骤 5：
+任一操作失败时，任务仍必须位于 active 且短号仍有效；按失败类型调用以下结构化 warning intent，随后继续步骤 5。平台失败不会阻止本地生命周期。
 
 ```bash
 agent-infra-internal task-warning {task-id} add --step complete-task --severity ACTION_REQUIRED --code {COMMENT_SYNC_FAILED|REQUIREMENTS_SYNC_FAILED|SUMMARY_SYNC_FAILED|NETWORK_RETRY_EXHAUSTED} --target {artifact|issue|summary|platform} --message "{error_code}: {error_message}" --action "修复平台同步问题后重跑 complete-task"
@@ -161,46 +160,40 @@ agent-infra-internal task-warning {task-id} add --step complete-task --severity
 agent-infra-internal task-verify {task-id} complete-task.preflight --format text
 ```
 
-该事件依次执行 `review-ledger`、`manual-validation`、`post-review-commit`、`platform-sync-preflight`。任一退出码非 0（fail/blocked）时，任务必须继续留在 active；从 gate 结果取稳定 code/target，通过 `task-warning ... add --step complete-task ...` 落账后停止。若审查基线或 head 不一致，必须先重新 `commit` / `review-code`；不得回退审查基线。
+该事件只执行 required-PR delivery hard preflight；身份、并发和本地原子性仍由宿主 finalization 强制执行。外围 review/manual/platform 检查在 lifecycle 后由 `complete-task.completed` 处理，并投影为 warning/pending steps。硬门禁退出码非 0（fail/blocked）时，任务继续留在 active，记录稳定 code/target 后停止。
 
-若 preflight 的 `post-review-commit` 以 human-decided exemption 通过，在进入步骤 6 前必须把该 check 输出中的原始 failure code/message 与 PRC id/evidence，连同 task.md 中的裁决理由、提交范围、人工身份与时间，原地补入步骤 4 的同一 summary marker。已有 warning 时以其历史记录为 canonical 证据并与本次 check 输出核对；无 warning 时以本次 check 输出补齐原始失败。再次调用同一 `platform-comment sync ... --kind summary`；失败时记录 `SUMMARY_SYNC_FAILED`、保持任务 active 并停止，不进入 lifecycle。
+若需要在摘要中镜像 `post-review-commit` 的 human-decided exemption，在步骤 4 尽力同步原始 failure code/message、PRC id/evidence 和裁决信息；同步失败只记录 `SUMMARY_SYNC_FAILED` warning，仍继续生命周期。最终是否完成由生命周期后的 terminal verification 决定。
 
-`--force` 不解除本硬门禁：未关闭分歧必须先在账本闭合，未复审提交必须重新审查、具备有效豁免，或由平台适配器为绑定的变更请求（PR/MR）提供权威合并快照与远端 refs，并在隔离临时仓库中证明单父 squash merge 等价，或在无有效变更请求时由本地 Git 对象证明唯一受保护提交是内容等价的单父重写且之后无受保护提交；平台 preflight 必须通过。适配器不支持所需能力，平台事实、Git 对象、拓扑、内容证据缺失，或当前 Git 凭据不能读取远端证据 refs 时 fail closed。全部 checks 由平台适配器提供规范化状态，并在合并前通过 `review-code` / `watch-pr` 路由承担；其中 required checks 仍受分支保护 / ruleset 强制。
+`--force` 不能解除身份、并发、本地原子性或 required-PR hard gate；这些能力失败时必须停止。其余审查、人工校验和平台证据由 terminal verification 记录为 warning/pending，并通过后续重试恢复。
 
-### 6. 执行本地生命周期意图并验证转移
+### 6. 执行宿主 finalization 入口并验证终态
 
 ```bash
-agent-infra-internal task-lifecycle {task-id} complete --agent {standard-agent-token}
+agent-infra-internal task-finalization {task-id} complete --agent {standard-agent-token}
 ```
 
-仅 `status=applied|no-op` 视为本地完成。`status=failed` 时展示 `error` 与 completed/pending steps，以同一 intent 重试；不得宣称完成或手工补写局部状态。
+finalization 按 lifecycle → task 评论 → `complete-task.completed` 校验的固定顺序执行，并将每一步的状态写入宿主 receipt。`result=completed` 即表示 lifecycle 已安全完成；若还有外围 warning，返回 `result=completed_with_warnings`、warnings 和 pending steps。`result=failed` 或 `result=blocked` 仅用于硬失败或 receipt/capability 失败，修复原因后以同一入口重试，不得宣称完成或手工补写局部状态。
 
 ```bash
 ls .agents/workspace/completed/{task-id}/task.md
 ```
 
-确认任务目录已成功移动。
-
-### 7. 同步终态 task 评论并完成校验
-
-场景 A 与场景 B `finalization-retry` 都从 completed 目录执行本步骤。若存在有效的 `issue_number`，先调用：
+仅在 finalization 返回 `status=completed` 后确认任务目录已成功移动。
 
-```bash
-agent-infra-internal platform-comment sync {task-id} --kind task --agent {standard-agent-token}
-```
+### 7. 处理 finalization 重试与结果
 
-该调用失败时任务已归档，不能调用只接受 active 任务的 `task-warning`；保留 completed 状态并停止。修复网络或平台问题后重跑 complete-task，会由步骤 1 进入 `finalization-retry`，只重复本步骤。
+场景 A 与场景 B `finalization-retry` 都从宿主执行同一个 `task-finalization` 入口。receipt 只是重入提示，不是 canonical truth：每次重入都要重新验证终态 task 评论和完成校验；只有任务已处于 `completed` 且短号 registry 已释放时，才可跳过不可逆的 lifecycle。不得拆开调用旧的 lifecycle、评论同步或完成校验命令。若 task 评论或校验因网络问题返回 `blocked`，保留 receipt 和已完成状态，修复网络后重跑 complete-task；若生命周期仍未完成，任务保持 active 并从 receipt 的待处理步骤继续。
 
-运行完成校验，确认任务产物和同步状态符合规范：
+完成结果必须包含本次 finalization 的结构化输出，确认任务产物和同步状态符合规范：
 
 ```bash
 agent-infra-internal task-verify {task-id} complete-task.completed --format text
 ```
 
 处理结果：
-- 退出码 0（全部通过）-> 继续到「告知用户」步骤
-- 退出码 1（校验失败）-> 根据输出修复问题后重新运行校验
-- 退出码 2（网络中断或状态标签清理尚未收敛）-> 保留 completed 状态并停止；稍后重跑 complete-task 进入 `finalization-retry`
+- `status=completed` / 退出码 0（全部通过）-> 继续到「告知用户」步骤
+- `status=failed` / 退出码 1 -> 根据输出修复问题后重新运行 finalization
+- `status=blocked` / 退出码 2 -> 保留 receipt 与已完成的步骤并停止；稍后重跑 complete-task 进入 `finalization-retry`
 
 将校验输出保留在回复中作为当次验证输出。没有当次校验输出，不得声明完成。
 
@@ -210,7 +203,7 @@ agent-infra-internal task-verify {task-id} complete-task.completed --format text
 
 > 完成时间收尾行（整段输出的最后一行）取值 `date "+%Y-%m-%d %H:%M:%S"`（本地时区、不带偏移），固定放在输出的绝对末尾，便于多窗口扫视。本 skill 不渲染「下一步」命令，但会在收尾行之前渲染一段**可选的沙箱清理提示**（见下方门控），且仍统一打印该收尾行。
 
-> **可选沙箱清理提示（门控渲染）**：仅当同时满足 (1) `.agents/.airc.json` 存在 `sandbox` 字段、(2) task.md 的 `branch` 字段存在且不是 `main` / `master` 时，才渲染下方输出中的「可选：清理本任务的沙箱」块；任一不满足则整段省略。`{branch}` 取已读入的 task.md 的 `branch` 值（任务此时已移动到 completed/，从 `.agents/workspace/completed/{task-id}/task.md` 读取）。该块独立于「下一步」语义，不是工作流后继命令。
+> **可选沙箱清理提示（门控渲染）**：仅当同时满足 (1) `.agents/.airc.json` 存在 `sandbox` 字段、(2) task.md 的 `branch` 字段存在且不是 `main` / `master` 时，才渲染下方输出中的「可选：清理本任务的沙箱」块；任一不满足则整段省略。清理时使用完整 `{task-id}`，不要改用 branch 名。该块独立于「下一步」语义，不是工作流后继命令。
 
 输出格式：
 ```
@@ -225,9 +218,9 @@ agent-infra-internal task-verify {task-id} complete-task.completed --format text
 - {关键产出列表：修改的文件、添加的测试等}
 
 可选：清理本任务的沙箱
-（任务已归档，沙箱容器和 per-branch 配置目录不会自动回收。如果不再需要可执行：）
+（任务已完成，沙箱容器和 per-branch 配置目录不会自动回收。如果不再需要可执行：）
 
-ai sandbox rm {branch}
+ai sandbox rm {task-id}
 
 Completed at: {completion-time}
 ```

package/templates/.agents/skills/complete-task/config/verify.en.json

@@ -38,6 +38,7 @@
       "verify_closed_issue_has_no_status_labels": false,
       "expected_comment_marker_key": "summary"
     },
+    "required-pr-delivery": {},
     "platform-sync": {
       "when": "issue_number_exists",
       "verify_task_comment_content": true,

package/templates/.agents/skills/complete-task/config/verify.zh-CN.json

@@ -38,6 +38,7 @@
       "verify_closed_issue_has_no_status_labels": false,
       "expected_comment_marker_key": "summary"
     },
+    "required-pr-delivery": {},
     "platform-sync": {
       "when": "issue_number_exists",
       "verify_task_comment_content": true,

package/templates/.agents/skills/complete-task/reference/external-delivery.en.md

@@ -14,4 +14,4 @@ Only the current typed result's `mode=external`, `authorization`, and `selected`
 
 A successful bind atomically writes PR fields and appends a `Bind External PR` Activity Log entry containing the authorization source, Issue, PR URL/number, base/head repository/ref/SHA, merge time, and merge commit. Replaying identical complete evidence is a no-op; an existing same-number binding without the signature adds it once; number or identity changes fail. The PR create path must never run.
 
-External mode still passes review-ledger, manual-validation, post-review-commit, platform-sync, preflight, and terminal gates. Without a canonical review-code artifact, only existing verifier N/A rules apply. `--force` does not disable any hard gate.
+External mode still passes identity, required-PR, local lifecycle, and terminal checks; review-ledger, manual-validation, post-review-commit, and platform-sync evidence is projected as warning/pending steps after lifecycle. Without a canonical review-code artifact, only existing verifier N/A rules apply. `--force` does not disable identity, local atomicity, or required-PR hard gates.

package/templates/.agents/skills/complete-task/reference/external-delivery.zh-CN.md

@@ -14,4 +14,4 @@ core 通过平台 adapter 读取 Issue 的权威 closing change requests，穷
 
 成功绑定会原子写入 PR 字段并追加 `Bind External PR` Activity Log，记录授权来源、Issue、PR URL/编号、base/head repository/ref/SHA、合并时间和 merge commit。相同完整证据重试为 no-op；已有同号但缺审计签名时补写一次；编号或身份变化失败。不得调用 PR create 路径。
 
-外部模式仍须通过 review ledger、manual validation、post-review commit、平台同步、preflight 与终态校验。无 canonical review-code 时仅沿用 verifier 已定义的 N/A 规则；`--force` 不解除任何硬门禁。
+外部模式仍须通过身份、required-PR、本地生命周期与终态校验；review ledger、manual validation、post-review commit 和平台同步等外围证据在 lifecycle 后作为 warning/pending steps 投影。无 canonical review-code 时仅沿用 verifier 已定义的 N/A 规则；`--force` 不解除身份、本地原子性或 required-PR 硬门禁。

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

@@ -11,6 +11,8 @@ description: >
 
 Create a Pull Request and, when task-related, sync the essential metadata and reviewer summary immediately.
 
+`platform-pr create` returns the single `result` / `warnings` fields; successful results are `pr_created`, `pr_reused`, or `no_op`, with the corresponding `_with_warnings` result (including `no_op_with_warnings`) for degraded synchronization. Before locate/create/bind, the task branch must be proven pushed and its remote branch SHA must equal the expected local `HEAD`. Missing or drifting remote refs, a mismatched PR head SHA, and bind-time races are hard failures, never success warnings.
+
 ## Boundary / Critical Rules
 
 Version stamp rule: when creating or updating `task.md` frontmatter, read `.agents/rules/version-stamp.md` first and write or refresh `agent_infra_version`.
@@ -64,31 +66,37 @@ Read the PR template through `.agents/rules/issue-pr-commands.md`, review recent
 
 ### 4. Check Remote Branch State
 
-Use `agent-infra-internal git-workflow inspect` for upstream/remote facts and `git-workflow push` for a verified push.
+Use `agent-infra-internal git-workflow inspect` for already-delivered upstream/remote facts. `create-pr` never performs the first push; a missing remote branch or a remote SHA that differs from local HEAD fails and points back to `commit`/push-only. Core rechecks the remote branch SHA before and immediately before bind, and requires exact repository/ref, base, and `head.sha` identity. A post-POST race never deletes the created PR or remote branch; the next retry recovers only by resource identity.
 
 ### 5. Create or Recover the PR
 
-Read `.agents/rules/issue-pr-commands.md`, write the title and body to temporary files, then invoke its `platform-pr create` intent. Under the task lock and before any Create PR started entry, POST, or reuse-bind, core checks commit finalization. An active intent, open Commit, missing review anchor, or tree drift returns a stable code and directs the caller to rerun commit/review-code; create-pr never repairs Commit state. Only after the gate passes does core perform exact head/base lookup: one existing PR is reused and bound, zero creates, and multiple matches fail deterministically. Replays must not create duplicate PRs.
+Read `.agents/rules/issue-pr-commands.md`, write the title and body to temporary files, then invoke its `platform-pr create` intent. Under the task lock, core uses remote branch and exact head/base/PR identity facts: one existing PR is reused and bound, zero creates, and multiple matches fail deterministically. Review artifacts and task sync records are not create-pr prerequisites, and replays must not create duplicate PRs.
 
 If `{task-id}` is available and the related task provides `issue_number`, keep `Closes #{issue-number}` in the PR body.
 
 ### 6. Sync PR Metadata
 
-Run `agent-infra-internal platform-pr sync {task-id} --agent {standard-agent-token} --metadata --closing-issue`. The core copies type / `in:` labels, assignee, and a specific milestone from the Issue and maintains the closing association. Permission-bound items degrade independently, and the Issue is never updated in reverse.
+Capture the `result` field from `platform-pr create` (`pr_created`, `pr_reused`, or `no_op`), then run `agent-infra-internal platform-pr sync {task-id} --agent {standard-agent-token} --metadata --closing-issue --result {primary-result}`. The core copies type / `in:` labels, assignee, and a specific milestone from the Issue and maintains the closing association. Permission-bound items degrade independently, and the Issue is never updated in reverse. After the PR identity is bound, metadata or summary sync failures produce `pr_created_with_warnings`, `pr_reused_with_warnings`, or `no_op_with_warnings` from that primary result, preserve the primary-action fact, and retry only unfinished sync steps.
+
+### 7. Generate the PR Code Change Report
+
+After creating or uniquely reusing the PR, run `agent-infra-internal platform-pr inspect {task-id}` to obtain the authoritative base/head SHAs, then follow `reference/change-report.md` to classify the complete PR additions/deletions, renames, and potentially unnecessary changes. Read that reference before this step.
+
+The report is part of the reviewer summary below and must also appear in the final user response. Do not provide only a grand total or inspect only the last commit.
 
-### 7. Publish the Review Summary
+### 8. Publish the Review Summary
 
 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 and maintain a single idempotent summary comment via the hidden marker.
+Aggregate a reviewer-facing summary from those artifacts, append the `### PR Code Changes` section generated in step 7, and maintain a single idempotent summary comment via the hidden marker. Pass 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.
 
-### 8. Confirm Task Status
+### 9. Confirm Task Status
 
 After a PR is created or uniquely recovered, `platform-pr create` atomically updates `pr_number`, `pr_status`, canonical time/version metadata, and the Create PR completion log through the task write core. The caller verifies the structured result and does not edit those fields again.
 
-### 9. Verification Gate
+### 10. Verification Gate
 
 If this operation is associated with `{task-id}`, run the verification gate to confirm task metadata and sync state. If there is no task context, skip this step.
 
@@ -103,13 +111,13 @@ Handle the result as follows:
 
 Keep the gate output in your reply as fresh evidence. Do not claim completion without output from this run.
 
-### 10. Inform User
+### 11. Inform User
 
 > Execute this step only after the verification gate passes.
 
 > Before rendering next steps, read `.agents/rules/next-step-output.md`, invoke the shared helper only for the selected scenario, and insert its stdout at `{next-step-commands}`.
 
-Explain the created PR URL, summarize metadata sync and summary-comment results, and recommend watching the PR's checks next (render `{task-ref}` as the short id `NN` per `.agents/rules/next-step-output.md`):
+Explain the created PR URL, summarize metadata sync and summary-comment results, show the complete step 7 category table and necessity conclusion, and recommend watching the PR's checks next (render `{task-ref}` as the short id `NN` per `.agents/rules/next-step-output.md`):
 
 Populate `{next-step-commands}` for this scenario by running `agent-infra-internal agent-client next-steps --skill watch-pr --task-ref {task-ref}`.