@fitlab-ai/agent-infra 0.9.8 → 0.9.9

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,23 +66,23 @@ 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. 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 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.
 

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

@@ -11,6 +11,8 @@ description: >
 
 创建 Pull Request，并在与任务关联时立即补齐核心元数据和 reviewer 摘要。
 
+`platform-pr create` 返回唯一的 `result` / `warnings` 字段；成功结果为 `pr_created`、`pr_reused` 或 `no_op`，同步降级时为对应的 `_with_warnings` 结果（包括 `no_op_with_warnings`）。创建前必须证明任务分支已推送，远端 branch SHA 与本地预期 `HEAD` 一致；缺失、漂移、PR head SHA 不一致或 bind 前竞态都属于 hard failure，不得用 warning 继续绑定。
+
 ## 行为边界 / 关键规则
 
 版本戳规则：创建或更新 `task.md` frontmatter 时，先读取 `.agents/rules/version-stamp.md`，并写入或刷新 `agent_infra_version`。
@@ -64,23 +66,23 @@ description: >
 
 ### 4. 检查远程分支状态
 
-调用 `agent-infra-internal git-workflow inspect` 检查 upstream/remote branch；必要时通过 `git-workflow push` 推送并复核。
+调用 `agent-infra-internal git-workflow inspect` 检查已交付的 upstream/remote branch；`create-pr` 不执行首次 push，远端 branch 缺失或 SHA 与本地 HEAD 不一致时直接失败并指向 `commit`/push-only。随后在 locate/create/bind 前后再次读取远端 branch SHA，并要求 PR 的精确 repository/ref、base 和 `head.sha` 全部匹配；POST 后的竞态不自动删除已创建 PR 或远端 branch，下一次只按资源身份恢复。
 
 ### 5. 创建或恢复 PR
 
-执行前先读取 `.agents/rules/issue-pr-commands.md`，把标题和正文写入临时文件，并调用其中的 `platform-pr create` intent。core 在任务锁内、任何 Create PR started / POST / reuse-bind 之前检查 commit finalization；active intent、open Commit、审查锚点缺失或 tree 漂移时返回稳定 code 并指向重跑 commit/review-code，不自动恢复。门禁通过后才按 head/base 精确定位：唯一既有 PR 会复用并绑定，零个才创建，多个稳定失败；重放不得产生重复 PR。
+执行前先读取 `.agents/rules/issue-pr-commands.md`，把标题和正文写入临时文件，并调用其中的 `platform-pr create` intent。core 在任务锁内按 remote branch、head/base 和 PR 身份事实执行：唯一既有 PR 会复用并绑定，零个才创建，多个稳定失败；review 或 task sync 记录不作为创建 PR 的前置门禁，重放不得产生重复 PR。
 
 如果获取到 `{task-id}` 且对应任务提供了 `issue_number`，必须在 PR 正文中保留 `Closes #{issue-number}`。
 
 ### 6. 同步 PR 元数据
 
-调用 `agent-infra-internal platform-pr sync {task-id} --agent {standard-agent-token} --metadata --closing-issue`。core 从 Issue 复制 type / `in:` labels、assignee 和具体 milestone，并维护 Development 关联；逐项权限不足返回 degraded，不反向更新 Issue。
+记录 `platform-pr create` 结构化结果中的 `result`（`pr_created`、`pr_reused` 或 `no_op`），并调用 `agent-infra-internal platform-pr sync {task-id} --agent {standard-agent-token} --metadata --closing-issue --result {primary-result}`。core 从 Issue 复制 type / `in:` labels、assignee 和具体 milestone，并维护 Development 关联；逐项权限不足返回 degraded，不反向更新 Issue。PR 已成功绑定后，metadata/summary 同步失败只产生与 primary result 对应的 `pr_created_with_warnings`、`pr_reused_with_warnings` 或 `no_op_with_warnings`，保留主动作事实，重试只执行未完成的同步步骤。
 
 ### 7. 发布审查摘要
 
 读取最新的上下文产物：`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 摘要，并使用隐藏标记维护唯一且幂等的摘要评论。
+基于这些产物聚合 reviewer 摘要，并使用隐藏标记维护唯一且幂等的摘要评论。调用 `summary-sync` 时继续传递同一个 `--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/comment-publish.en.md

@@ -6,7 +6,7 @@ Write the plain summary body to a temporary file, then run:
 
 ```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} --result {primary-result}
 ```
 
-The caller does not add markers, HEAD metadata, or comment API parameters. A summary failure records the existing `create-pr` warning and does not roll back the PR.
+The caller does not add markers, HEAD metadata, or comment API parameters. `--result` is required and must be passed unchanged from `platform-pr create`; `no_op` maps to `no_op_with_warnings` if summary synchronization degrades. Summary failures do not roll back a created or reused PR.

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

@@ -6,7 +6,7 @@
 
 ```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} --result {primary-result}
 ```
 
-调用方不添加 marker、HEAD 或评论 API 参数。摘要失败沿用 `create-pr` 错误处理并记录 warning，不回滚已创建 PR。结果映射沿用 `.agents/rules/pr-sync.md`。
+调用方不添加 marker、HEAD 或评论 API 参数。`--result` 是必填的，必须把 `platform-pr create` 的 `result` 原样传入；摘要失败沿用该 primary result 映射 warning（`no_op` 对应 `no_op_with_warnings`），不回滚已创建或复用的 PR。结果映射沿用 `.agents/rules/pr-sync.md`。

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

@@ -10,12 +10,12 @@ description: >
 The orchestrator delegates only and never executes a stage skill itself. First read `.agents/rules/no-mid-flow-questions.md`, `.agents/rules/lifecycle-orchestration.md`, and `reference/host-validation.md`.
 
 1. Resolve the canonical task ID, current Agent Client, and optional atomic policy flags, then run `task-snapshot`. If one explicit role field is present, all four are required.
-2. Before `begin-or-resume`, Codex selects a host. Without `AGENT_INFRA_CONTROL_TOKEN`, use direct-host. With task-bound control authority but no `AGENT_INFRA_CODEX_CONTROLLER_CONTEXT`, only run `codex-sandbox-controller run --task-id {task-id} --task-ref {task-ref}` with the complete policy and wait; the outer loop must not create a run, baseline, or receipt. With a context, run `verify-context --task-id {task-id}` first. Stop on any bootstrap, bundle, source/profile discovery, or context failure.
-3. Run `task-orchestration {task-id} begin-or-resume --client {client}` with the complete explicit policy. With no explicit policy, core reads that client's configured policy; existing v2/v3 runs use persisted policy. Stop on paused/completed results.
+2. Before `begin-or-resume`, Codex selects a host. Without `AGENT_INFRA_CONTROL_TOKEN`, use direct-host. With task-bound control authority but no `AGENT_INFRA_CODEX_CONTROLLER_CONTEXT`, only run `codex-sandbox-controller run` with the complete policy and wait; the outer loop must not create a run, baseline, or receipt. With a context, run `verify-context` first. Stop on any bootstrap, bundle, source/profile discovery, or context failure.
+3. Run `task-orchestration {task-id} begin-or-resume --client {client}` with the complete explicit policy. With no explicit policy, core reads that client's configured policy; existing runs use persisted policy. Disk state outside the complete current structure fails closed without rewriting; finish or clear active runs before upgrading. Stop on paused/completed results.
 4. Run `route`. On `completed`, run `agent-infra-internal task-verify {task-id} run-task.completed --format text` and stop. Only a `running` result with non-null `next` supplies action, role, round, artifact, requested model, and requested effort.
-5. Codex runs `codex-lifecycle capability-arm --task-id {task-id}` once. The current loop's real PostToolUse must attest that ordinary tool response. Pass only its marker token to `prepare --client {client} --capability-token {token}`. Before snapshotting, core atomically consumes it, verifies task, hook source, build, contract, and controller binding, and persists the capability session, turn, and tool-use origin. Activation then verifies that spawn belongs to the same session and turn and uses a distinct tool-use. Other clients use the same prepare without a token. Failure creates no baseline, receipt, or child.
-6. After prepare, run `task-orchestration <task-ref> dispatch` immediately before calling the fresh native child, then use route's exact model/effort and only the short task ref, skill, `--orchestrated`, and stage identity. The trusted hook-spawn first-observation time must fall between dispatch and the deadline. Its first provenance-sensitive command must be `await-activation --stage ... --round ... --artifact ... --role ...`; before `running`, it must not snapshot, emit stage-started, write business files, or start commit. Only explicit `recover-prepared` may clear an expired orphan when the task fingerprint is exact, no commit intent exists, and no matching unconsumed active lifecycle evidence remains.
-7. Codex uses SubagentStart/Stop and App Server actual evidence to activate, consume, and seal one v3 receipt; trusted parent fallback must produce the same provenance. Timed-out waits do nothing. Advance only a sealed receipt and repeat step 4 only while running.
+5. Codex runs `codex-lifecycle capability-arm --task-id {task-id}` once. The current loop's real PostToolUse must attest that ordinary tool response. Pass its marker token, the exact routed model, and the exact routed reasoning effort to `prepare --client {client} --requested-model {requestedModel} --requested-reasoning-effort {requestedReasoningEffort} --capability-token {token}`. Core first validates the exact routed model/effort, capability provenance, and controller binding, then captures a read-only snapshot, builds an in-memory prepared receipt, atomically consumes the token, and saves the prepared state with the capability session, turn, and tool-use origin. Activation then verifies that spawn belongs to the same session and turn and uses a distinct tool-use. Other clients use the same prepare without a token. Failure creates no baseline, receipt, or child.
+6. After prepare, run `task-orchestration <task-ref> dispatch` immediately before calling the fresh native child, then use route's exact model/effort and only the short task ref, skill, `--orchestrated`, and stage identity. The trusted hook-spawn first-observation time must fall between dispatch and the deadline. Its first provenance-sensitive command must be `await-activation --stage ... --round ... --artifact ... --role ...`; before `running`, it must not snapshot, emit stage-started, write business files, or start commit. Only explicit `recover-prepared` may clear an expired orphan when the task fingerprint is exact and no matching unconsumed active lifecycle evidence remains.
+7. Codex uses SubagentStart/Stop and App Server actual evidence to activate, consume, and seal one receipt; trusted parent fallback must produce the same complete provenance. Timed-out waits do nothing. Advance only a sealed receipt and repeat step 4 only while running.
 8. Create a fresh child each round and never follow up with an old reviewer. Each requested/actual mismatch needs its own host fallback reason. Capability, hook, source, controller, build, identity, ledger, or fingerprint failure pauses and fails closed.
 9. On pause or completion, run the matching typed verification and report the structured endpoint.
 

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

@@ -10,12 +10,12 @@ description: >
 总控只编排，不直接执行任何阶段技能。执行前先读取 `.agents/rules/no-mid-flow-questions.md`、`.agents/rules/lifecycle-orchestration.md` 与 `reference/host-validation.md`。
 
 1. 解析规范任务 ID、当前 Agent Client，以及可选的原子策略 `--executor-model`、`--executor-reasoning-effort`、`--reviewer-model`、`--reviewer-reasoning-effort`，并执行 `agent-infra-internal task-snapshot {task-id} --format text`。任一显式策略字段出现时四个 role 字段必须完整，不得与配置拼接；两个角色可以使用同一模型。
-2. Codex 在 `begin-or-resume` 前选择宿主：没有 `AGENT_INFRA_CONTROL_TOKEN` 时使用 direct-host；有 task-bound control authority 但没有 `AGENT_INFRA_CODEX_CONTROLLER_CONTEXT` 时，只调用 `agent-infra-internal codex-sandbox-controller run --task-id {task-id} --task-ref {task-ref}`（转发完整显式策略）并等待其终态，外层不得创建 run、baseline 或 receipt；已有 context 时先调用 `verify-context --task-id {task-id}`。controller 的 bootstrap、bundle、source/profile discovery 或 context 任一校验失败即停止。
-3. 调用 `agent-infra-internal task-orchestration {task-id} begin-or-resume --client {client}` 并转发完整显式策略。完全没有显式策略时由核心读取当前 client 的 `agentClients[].orchestration`；已有 v2/v3 run 使用持久化策略。仅当核心返回 `ORCHESTRATION_MODEL_POLICY_REQUIRED` 时，先用 `agent-client model-selection` 展示 complete/partial/interactive-only 来源，再一次收集完整策略；未回答则不创建 run。若为 paused/completed，按结构化结果停止。
+2. Codex 在 `begin-or-resume` 前选择宿主：没有 `AGENT_INFRA_CONTROL_TOKEN` 时使用 direct-host；有 task-bound control authority 但没有 `AGENT_INFRA_CODEX_CONTROLLER_CONTEXT` 时，只调用 `agent-infra-internal codex-sandbox-controller run`（转发完整显式策略）并等待其终态，外层不得创建 run、baseline 或 receipt；已有 context 时先调用 `verify-context`。controller 的 bootstrap、bundle、source/profile discovery 或 context 任一校验失败即停止。
+3. 调用 `agent-infra-internal task-orchestration {task-id} begin-or-resume --client {client}` 并转发完整显式策略。完全没有显式策略时由核心读取当前 client 的 `agentClients[].orchestration`；existing run 使用持久化策略。磁盘状态不符合当前完整结构时核心失败关闭且不改写；升级前必须完成或清空 active run。仅当核心返回 `ORCHESTRATION_MODEL_POLICY_REQUIRED` 时，先用 `agent-client model-selection` 展示 complete/partial/interactive-only 来源，再一次收集完整策略；未回答则不创建 run。若为 paused/completed，按结构化结果停止。
 4. 调用 `route` 并读取结构化结果。若返回 `completed`，立即运行 `agent-infra-internal task-verify {task-id} run-task.completed --format text` 并停止；仅当返回 `running` 且 `next` 非空时读取唯一 action、role、round、artifact、`requestedModel` 和 `requestedReasoningEffort`，不得自行推断。
-5. Codex 先调用一次 `agent-infra-internal codex-lifecycle capability-arm --task-id {task-id}`。该普通工具调用必须由当前 loop 的真实 PostToolUse 回写 attestation；仅把返回的 marker 中 token 传给 `prepare --client {client} --capability-token {token}`。核心在快照前原子消费 token，校验 task、hook source、build、contract 与 controller binding，并持久化 capability 的 session、turn、tool-use 来源。activation 再校验 spawn 与该来源属于同一 session/turn，且 spawn 使用独立的 tool-use。其他客户端直接调用同一 prepare（无 token）。任一失败不得创建 baseline、receipt 或 child。
-6. prepare 成功后，在调用 fresh 原生子 Agent 的紧邻前一步执行 `task-orchestration <task-ref> dispatch`，再显式覆盖 route 返回的 model/effort；只传短任务引用、skill 名、`--orchestrated` 与 stage/round/artifact/role。可信 hook-spawn 首次观察时间必须位于 dispatch 与 deadline 之间。child 的第一条 provenance-sensitive 命令必须是 `await-activation --stage ... --round ... --artifact ... --role ...`；返回 running 前禁止 snapshot、阶段 started、业务写入或 commit-start。超时由核心暂停；崩溃遗留 prepared receipt 只能在 exact workspace fingerprint、无 commit intent、无匹配的未消费 active lifecycle evidence 且 deadline 已过时显式 `recover-prepared`。
-7. Codex 用 SubagentStart/Stop 与 App Server actual evidence 激活、消费并封存唯一 receipt；受信 parent fallback 仍必须形成相同 v3 provenance。timed-out wait 无动作；只有 empty turns 或协议 `inProgress` 可等待，malformed、身份/传输错误或异常 terminal 均暂停。子 Agent 返回后只对 sealed receipt 调用 `advance`；只有 `running` 才重复步骤 4。
+5. Codex 先调用一次 `agent-infra-internal codex-lifecycle capability-arm --task-id {task-id}`。该普通工具调用必须由当前 loop 的真实 PostToolUse 回写 attestation；把 route 返回的精确 model、effort 和 marker 中 token 一并传给 `prepare --client {client} --requested-model {requestedModel} --requested-reasoning-effort {requestedReasoningEffort} --capability-token {token}`。核心先校验精确的 model/effort、capability provenance 与 controller binding，再只读捕获快照、构造内存中的 prepared receipt，最后原子消费 token 并保存 prepared 状态，同时持久化 capability 的 session、turn、tool-use 来源。activation 再校验 spawn 与该来源属于同一 session/turn，且 spawn 使用独立的 tool-use。其他客户端直接调用同一 prepare（无 token）。任一失败不得创建 baseline、receipt 或 child。
+6. prepare 成功后，在调用 fresh 原生子 Agent 的紧邻前一步执行 `task-orchestration <task-ref> dispatch`，再显式覆盖 route 返回的 model/effort；只传短任务引用、skill 名、`--orchestrated` 与 stage/round/artifact/role。可信 hook-spawn 首次观察时间必须位于 dispatch 与 deadline 之间。child 的第一条 provenance-sensitive 命令必须是 `await-activation --stage ... --round ... --artifact ... --role ...`；返回 running 前禁止 snapshot、阶段 started、业务写入或 commit。超时由核心暂停；崩溃遗留 prepared receipt 只能在 exact workspace fingerprint、无匹配的未消费 active lifecycle evidence 且 deadline 已过时显式 `recover-prepared`。
+7. Codex 用 SubagentStart/Stop 与 App Server actual evidence 激活、消费并封存唯一 receipt；受信 parent fallback 仍必须形成相同的完整 provenance。timed-out wait 无动作；只有 empty turns 或协议 `inProgress` 可等待，malformed、身份/传输错误或异常 terminal 均暂停。子 Agent 返回后只对 sealed receipt 调用 `advance`；只有 `running` 才重复步骤 4。
 8. 每轮创建新 child；禁止 follow-up 复用 reviewer。actual model/effort 与 requested 不同时必须有各自的宿主降级理由。任何 capability、hook、source、controller、build、身份、账本或 fingerprint 异常都调用 `pause` 并失败关闭。
 9. 完成或暂停后运行对应 typed verification，并把结构化 run 摘要、暂停原因、commit 终点或 clean completion evidence 告知用户。
 

package/templates/.agents/skills/watch-pr/reference/monitor-and-heal.en.md

@@ -31,7 +31,7 @@ For each failing check, decide "self-heal" vs "ask for help" in this order:
    - Before fixing, run `git status -s` to record the working tree and ensure only changes related to this failure are included.
    - Locate and make a minimal fix per the logs (touch only code / tests / config related to that failure).
    - Run the relevant tests: prefer the local command for the failing job; otherwise read the project `test` skill and select its declared core or full validation command. If neither command is known, ask for help. **Do not commit or push before tests pass.**
-   - After tests pass, call `git-workflow commit` and `git-workflow push`, then verify the remote SHA.
+   - After tests pass, put the paths, message, expected HEAD, expected tree, and push policy (remote, full refs, automatic) into one intent JSON; call `git-workflow commit` once and verify the remote SHA. If the remote push fails, retry the same commit intent with empty `paths` through the push-only path.
    - Append the fix commit SHA to this run's `repairCommits`, increment the fix count, and return to SKILL step 2. When checks turn green, an empty list routes to `complete-task`; a non-empty list routes to `review-code`.
    - Never make unrelated "drive-by" optimizations; never loosen / skip the failing assertion to "make it green".
 

package/templates/.agents/skills/watch-pr/reference/monitor-and-heal.zh-CN.md

@@ -31,7 +31,7 @@ unknown: help
    - 自愈前先 `git status -s` 记录当前工作树，确保后续只纳入与本次失败相关的改动。
    - 在本地按日志定位并最小化修复（只动与该失败相关的代码 / 测试 / 配置）。
    - 运行对应测试：优先失败 job 对应的本地命令；否则读取项目 `test` skill，选择其中声明的 core 或 full 验证命令。两者均未知时进入求助出口。**测试通过前不得提交或推送。**
-   - 测试通过后发布修复：把相关路径、message 与 expected HEAD 写入 intent JSON，调用 `git-workflow commit`，再调用 `git-workflow push` 并复核远端 SHA。
+   - 测试通过后发布修复：把相关路径、message、expected HEAD、expected tree 和 push policy（remote、完整 refs、automatic）写入同一个 intent JSON，调用一次 `git-workflow commit` 并复核远端 SHA；远端失败时使用相同 commit intent 的空 `paths` push-only 重试。
    - 将本次修复的 commit SHA 追加到当前运行的 `repairCommits`，修复计数 +1，回到 SKILL 步骤 2 重新监控；全绿时列表为空走 `complete-task`，非空走 `review-code`。
    - 绝不执行与失败无关的「顺手优化」；不放宽 / 跳过失败的断言来「修绿」。