@fitlab-ai/agent-infra 0.11.0 → 0.11.2

package/templates/.agents/skills/review-plan/reference/report-template.en.md

@@ -4,6 +4,8 @@
 
 Use this template when writing `review-plan.md` or `review-plan-r{N}.md`.
 
+> The `Review Input` field provides reader-facing traceability. Lifecycle identity uses the input frozen by `review-plan.started` and the completion receipt; it is not parsed from this report body.
+
 ## Output Template
 
 ```markdown

package/templates/.agents/skills/review-plan/reference/report-template.zh-CN.md

@@ -4,6 +4,8 @@
 
 编写 `review-plan.md` 或 `review-plan-r{N}.md` 时使用本模板。
 
+> “审查输入”字段用于读者追溯。生命周期身份以 `review-plan.started` 冻结的输入和完成 receipt 为准，不从本报告正文解析。
+
 ## 输出模板
 
 ```markdown

package/templates/.agents/skills/review-pr/config/verify.en.json

@@ -24,14 +24,7 @@
       "expected_action_pattern": "Review PR \\(Round \\d+\\)"
     },
     "platform-sync": {
-      "when": "platform_issue_identity_exists",
-      "expected_comment_marker": "<!-- sync-issue:{task-id}:{artifact-stem} -->",
-      "verify_comment_content": true,
-      "verify_task_comment_content": true,
-      "verify_issue_type": false,
-      "verify_issue_fields": false,
-      "verify_milestone": false,
-      "expected_comment_marker_key": "artifact"
+      "when": "platform_issue_identity_exists"
     }
   }
 }

package/templates/.agents/skills/review-pr/config/verify.zh-CN.json

@@ -24,14 +24,7 @@
       "expected_action_pattern": "Review PR \\(Round \\d+\\)"
     },
     "platform-sync": {
-      "when": "platform_issue_identity_exists",
-      "expected_comment_marker": "<!-- sync-issue:{task-id}:{artifact-stem} -->",
-      "verify_comment_content": true,
-      "verify_task_comment_content": true,
-      "verify_issue_type": false,
-      "verify_issue_fields": false,
-      "verify_milestone": false,
-      "expected_comment_marker_key": "artifact"
+      "when": "platform_issue_identity_exists"
     }
   }
 }

package/templates/.agents/skills/run-manual-validation/config/verify.en.json

@@ -2,24 +2,49 @@
   "skill": "run-manual-validation",
   "checks": {
     "task-meta": {
-      "required_fields": ["id", "type", "workflow", "status", "created_at", "updated_at", "agent_infra_version", "current_step", "assigned_to"]
+      "required_fields": [
+        "id",
+        "type",
+        "workflow",
+        "status",
+        "created_at",
+        "updated_at",
+        "agent_infra_version",
+        "current_step",
+        "assigned_to"
+      ]
     },
     "artifact": {
       "file_pattern": "validation-run.md|validation-run-r{N}.md",
-      "required_sections": ["Input Mode", "State Check", "Validation Target", "Discovered Items", "Mode Decision", "Command Summary", "Structured Evidence", "Per-item Results", "Cleanup and Recovery", "Remaining Coverage", "Raw Evidence"],
-      "required_patterns": ["^\\$ "]
+      "required_sections": [
+        "Input Mode",
+        "State Check",
+        "Validation Target",
+        "Discovered Items",
+        "Mode Decision",
+        "Command Summary",
+        "Structured Evidence",
+        "Per-item Results",
+        "Cleanup and Recovery",
+        "Remaining Coverage",
+        "Raw Evidence"
+      ],
+      "required_patterns": [
+        "^\\$ "
+      ]
+    },
+    "activity-log": {
+      "expected_action_pattern": "Run Manual Validation \\(Round \\d+\\)"
+    },
+    "review-ledger": {
+      "stage_scope": [
+        "analysis",
+        "plan",
+        "code"
+      ]
     },
-    "activity-log": { "expected_action_pattern": "Run Manual Validation \\(Round \\d+\\)" },
-    "review-ledger": { "stage_scope": ["analysis", "plan", "code"] },
     "platform-sync": {
-      "when": "platform_issue_identity_exists",
-      "expected_comment_marker": "<!-- sync-issue:{task-id}:{artifact-stem} -->",
-      "verify_comment_content": true,
-      "verify_task_comment_content": true,
-      "verify_issue_type": true,
-      "verify_issue_fields": false,
-      "verify_milestone": true,
-      "expected_comment_marker_key": "artifact"
+      "when": "platform_issue_identity_exists"
     }
   }
 }

package/templates/.agents/skills/run-manual-validation/config/verify.zh-CN.json

@@ -2,24 +2,49 @@
   "skill": "run-manual-validation",
   "checks": {
     "task-meta": {
-      "required_fields": ["id", "type", "workflow", "status", "created_at", "updated_at", "agent_infra_version", "current_step", "assigned_to"]
+      "required_fields": [
+        "id",
+        "type",
+        "workflow",
+        "status",
+        "created_at",
+        "updated_at",
+        "agent_infra_version",
+        "current_step",
+        "assigned_to"
+      ]
     },
     "artifact": {
       "file_pattern": "validation-run.md|validation-run-r{N}.md",
-      "required_sections": ["输入模式", "状态核对", "验证目标", "发现清单", "模式判定", "命令摘要", "结构化证据", "逐项结果", "清理与恢复", "尚未覆盖", "证据原文"],
-      "required_patterns": ["^\\$ "]
+      "required_sections": [
+        "输入模式",
+        "状态核对",
+        "验证目标",
+        "发现清单",
+        "模式判定",
+        "命令摘要",
+        "结构化证据",
+        "逐项结果",
+        "清理与恢复",
+        "尚未覆盖",
+        "证据原文"
+      ],
+      "required_patterns": [
+        "^\\$ "
+      ]
+    },
+    "activity-log": {
+      "expected_action_pattern": "Run Manual Validation \\(Round \\d+\\)"
+    },
+    "review-ledger": {
+      "stage_scope": [
+        "analysis",
+        "plan",
+        "code"
+      ]
     },
-    "activity-log": { "expected_action_pattern": "Run Manual Validation \\(Round \\d+\\)" },
-    "review-ledger": { "stage_scope": ["analysis", "plan", "code"] },
     "platform-sync": {
-      "when": "platform_issue_identity_exists",
-      "expected_comment_marker": "<!-- sync-issue:{task-id}:{artifact-stem} -->",
-      "verify_comment_content": true,
-      "verify_task_comment_content": true,
-      "verify_issue_type": true,
-      "verify_issue_fields": false,
-      "verify_milestone": true,
-      "expected_comment_marker_key": "artifact"
+      "when": "platform_issue_identity_exists"
     }
   }
 }

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

@@ -1,7 +1,7 @@
 ---
 name: run-task
 description: >
-  Orchestrate lifecycle stages from the task's current state with fresh executors/reviewers and one-use provenance receipts.
+  Orchestrate lifecycle stages from the task's current state with fresh executors/reviewers and recorded execution results.
   Use when one entry should advance an existing task until a safe commit or stable pause.
 ---
 
@@ -14,13 +14,13 @@ The entry point may omit the task ref; explicit task scope accepts only `--task
 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` 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 protocol, task/controller/process, lease, or source/profile discovery failures. Package/build/contract or hook/profile content drift is delivered as a structured warning and tells the user to rebuild the sandbox.
+2. Use the current host's native child spawn, wait, and result interfaces. Task-bound sandboxes forward task operations through the existing broker; retain task binding and checks for real external process operations.
 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 its `capabilityRef` marker, the exact routed model, and the exact routed reasoning effort to `prepare --client {client} --requested-model {requestedModel} --requested-reasoning-effort {requestedReasoningEffort} --capability-ref {capabilityRef}`. Core accepts only the phase attestation issued by the current controller issuer: `orchestration.prepare` reserves the capability, then `artifact.finalize-local` and `task-event.completed` validate and consume their own phases; the underlying capability is terminally consumed only after the completed commit is confirmed. Without current controller proof, direct-host returns `LOCAL_EXECUTION_AUTHORITY_UNAVAILABLE` and creates no recovery intent, baseline, receipt, or child. 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 authority. 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, or write business files. The code stage may create a local checkpoint only through code-task's durable intent core; it must not delegate a separate commit stage or push. 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. Protocol, capability, receipt hook/evidence binding, source, controller, identity, ledger, or fingerprint failure pauses and fails closed; cross-root package/build/contract or hook/profile content drift is delivered as a warning instead of blocking natural evolution.
+5. Call `prepare --client {client} --requested-model {requestedModel} --requested-reasoning-effort {requestedReasoningEffort}` with route's exact policy. Codex runs current host preflight. Report actual task, policy, or host failures.
+6. After prepare, run `task-orchestration <task-ref> dispatch` before spawning a fresh native child with route's model/effort. Pass the short task ref, skill, `--orchestrated`, and stage identity. The child calls `await-activation --stage ... --round ... --artifact ... --role ...` to associate its actual identity before executing. Code-task creates the local checkpoint; do not delegate a separate commit stage or push. Retain existing write locks without introducing a new lock protocol around native spawn.
+7. Record actual start and terminal results through SubagentStart/Stop or parent spawn/wait and App Server observations. A timed-out wait does not imply success. Pause on actual identity, transport, or terminal failures. After the stage and child finish, call `advance`; repeat step 4 only while running.
+8. Create a fresh child each round and never reuse a reviewer. Record actual model/effort and host fallback reasons. Validate current identity, artifacts, ledger, and execution results. User rulings override derived historical plan requirements. Do not introduce child discovery, orphan recovery, or a dedicated recovery protocol.
 9. On pause or completion, run the matching typed verification and report the structured endpoint.
 
 ## Stop

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

@@ -1,7 +1,7 @@
 ---
 name: run-task
 description: >
-  从任务当前状态持续编排生命周期阶段，并用 fresh executor/reviewer 与一次性 receipt 验证隔离来源。
+  从任务当前状态持续编排生命周期阶段，使用 fresh executor/reviewer 并记录实际执行结果。
   当用户希望通过单一入口推进已有任务直到安全提交或稳定暂停时使用。
 ---
 
@@ -14,13 +14,13 @@ 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`（转发完整显式策略）并等待其终态，外层不得创建 run、baseline 或 receipt；已有 context 时先调用 `verify-context`。protocol、task/controller/process、lease 或 source/profile discovery 校验失败即停止；package/build/contract 或 hook/profile 内容漂移只输出结构化 warning，并提示用户重建 sandbox。
+2. 使用当前宿主的原生子 Agent 启动、等待与结果接口。task-bound sandbox 通过现有 broker 转发任务操作；保留任务绑定与真实外部进程操作检查。
 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；把 route 返回的精确 model、effort 和 marker 中的 `capabilityRef` 一并传给 `prepare --client {client} --requested-model {requestedModel} --requested-reasoning-effort {requestedReasoningEffort} --capability-ref {capabilityRef}`。核心只接受当前 controller issuer 根据 typed lifecycle authority request 签发的 phase attestation：`orchestration.prepare` 只 reserve capability，随后由 `artifact.finalize-local` 和 `task-event.completed` 各自独立校验并消费 phase；底层 capability 仅在 completed commit 已确认后 terminal consume。没有 current controller proof 时 direct-host 返回 `LOCAL_EXECUTION_AUTHORITY_UNAVAILABLE`，不得创建 recovery intent、baseline、receipt 或 child。activation 再校验 spawn 与该来源属于同一 session/turn，且 spawn 使用独立的 tool-use。其他客户端直接调用同一 prepare（无 authority）。任一失败不得创建 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 或业务写入；代码阶段的本地 checkpoint 只能通过 code-task 的持久化 intent 核心完成，禁止单独委派 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 不同时必须有各自的宿主降级理由。protocol、capability、receipt 内 hook/evidence binding、source、controller、身份、账本或 fingerprint 异常都调用 `pause` 并失败关闭；跨根 package/build/contract 或 hook/profile 内容漂移按 warning 交付，不把自然演进差异当成硬失败。
+5. 调用 `prepare --client {client} --requested-model {requestedModel} --requested-reasoning-effort {requestedReasoningEffort}`，使用 route 返回的精确策略。Codex 执行当前宿主 preflight；任务身份、策略或宿主检查失败时记录实际诊断。
+6. prepare 成功后，在调用 fresh 原生子 Agent 前执行 `task-orchestration <task-ref> dispatch`，显式指定 route 返回的 model/effort；传递短任务引用、skill 名、`--orchestrated` 与 stage/round/artifact/role。child 调用 `await-activation --stage ... --round ... --artifact ... --role ...`，确认当前阶段与实际 child 关联后执行。代码阶段通过 code-task 创建本地 checkpoint；禁止单独委派 commit 阶段或推送。保留已有写锁，不把实际 spawn 纳入新建锁协议。
+7. Codex 通过 SubagentStart/Stop 或 parent spawn/wait 与 App Server 记录实际启动及终态。timed-out wait 不推断成功；身份、传输或异常终态失败如实暂停。阶段结果和 child 完成后调用 `advance`；只有 `running` 才重复步骤 4。
+8. 每轮创建新 child；禁止 follow-up 复用 reviewer。如实记录 actual model/effort 及宿主降级理由。检查当前身份、产物、账本与实际执行结果；用户裁决优先于历史方案派生要求。不得新增 child discovery、孤立 child 恢复或专用恢复协议。
 9. 完成或暂停后运行对应 typed verification，并把结构化 run 摘要、暂停原因、commit 终点或 clean completion evidence 告知用户。
 
 ## 停止

package/templates/.agents/skills/run-task/reference/host-validation.en.md

@@ -10,7 +10,7 @@ Before publishing support for a client, prove the lifecycle evidence chain with
 - Explicit requested model/effort reaches each executor/reviewer. A fallback of either field reports the corresponding actual value and its own non-empty reason.
   > claude-code exception: requested reasoning effort does not yet support per-role dispatch to executor/reviewer — `.claude/agents/{executor,reviewer}.md` is a repository-level shared singleton, and writing it per role would race across concurrent tasks. This client only needs to honestly record the actual model/actual reasoning effort observed in native Start/Stop host events (`delegationEvidence.actualReasoningEffort` is declared `spawn-ack`); when not observed it is recorded as missing, which is not treated as a fallback requiring its own reason and does not fail closed. This exception does not apply to any other client.
 - Candidate-checkout and packed-install behavior match, with model policy, receipts, and verification results auditable in `orchestration.json`.
-- Direct-host and sandbox controller hooks/profiles must come from trusted sources. Cross-root build/contract/profile content drift emits an actionable warning, while controller/task/process/lease and the receipt's hook/evidence binding remain identical through prepare/start/stop/consume.
+- Use the hooks/profiles actually loaded by the current host and verify observed parent/child identity and terminal results. Prepare does not depend on historical capability or controller attestation.
 
 ## Validation Sequence
 
@@ -21,4 +21,4 @@ Before publishing support for a client, prove the lifecycle evidence chain with
 5. Commit only redacted summaries and non-sensitive fixtures. Remove or replace tokens, user-specific absolute paths, transcript content, and credentials.
 6. For sandbox, run at least ten cold executor starts and ten cold reviewer starts. Record monotonic prepared, spawn-dispatch, SubagentStart, and activation-completed timestamps plus p50/p95/max. Enable only when max plus 20% fits the deadline and symlink/config/plugin/lease/context/build failure injection and terminal cleanup audits pass.
 
-If any required field cannot be observed reliably from the real host, keep that client's orchestration capability `unsupported` and record the gap as manual validation. Codex may advertise `experimental`, but every `prepare` must still pass static preflight and either native start/stop or the parent spawn/completed-wait fallback must produce verifiable consumed host evidence. The fallback may wait only for empty turns or protocol `inProgress`; malformed, identity/transport errors, or abnormal terminals pause deterministically. The claude-code exception above is already scoped in the second bullet and does not change this rule's fail-closed requirement for any other field or client.
+If any required field cannot be observed reliably from the real host, keep that client's orchestration capability `unsupported` and record the gap as manual validation. Codex may advertise `experimental`, but every `prepare` must still pass static preflight and either native start/stop or the parent spawn/completed-wait fallback must record verifiable execution results. The fallback may wait only for empty turns or protocol `inProgress`; malformed, identity/transport errors, or abnormal terminals pause deterministically. The claude-code exception above is already scoped in the second bullet and does not change this rule's fail-closed requirement for any other field or client.

package/templates/.agents/skills/run-task/reference/host-validation.zh-CN.md

@@ -10,7 +10,7 @@
 - 显式 requested model/effort 能传给 executor/reviewer；宿主对任一字段回退时，事件能给出对应 actual 值与独立的非空 fallback reason。
   > claude-code 例外：requested reasoning effort 暂不支持按角色下发给 executor/reviewer——`.claude/agents/{executor,reviewer}.md` 是仓库级共享单例，动态写入存在跨任务竞态，解决该竞态超出本任务范围。该客户端只要求如实记录宿主原生 Start/Stop 事件中能观察到的 actual model/actual reasoning effort（`delegationEvidence.actualReasoningEffort` 声明为 `spawn-ack`）；观察不到时记录为缺失，不视为需要独立 fallback reason 的回退场景，也不构成 fail-closed 阻断。此例外不适用于其他客户端。
 - candidate checkout 与打包安装后的行为一致，且模型策略、receipt 与验证结果可从 `orchestration.json` 复核。
-- direct-host 与 sandbox controller 使用的 hook/profile 必须来自受信来源；build/contract/profile 内容在跨根比较中允许漂移并输出可操作 warning，但 controller/task/process/lease 与 receipt 内 hook/evidence binding 仍须在 prepare/start/stop/consume 全链路一致。
+- 使用当前宿主实际加载的 hook/profile，并核对实际 parent/child 身份与终态；prepare 不依赖历史 capability 或 controller attestation。
 
 ## 验证顺序
 
@@ -21,4 +21,4 @@
 5. 仅把去敏摘要与非敏感 fixture 纳入版本库；token、绝对用户路径、transcript 内容和凭证必须删除或替换。
 6. sandbox backend 另做至少 10 次 executor 与 10 次 reviewer 冷启动，记录 prepared、spawn dispatch、SubagentStart、activation completed 的单调时钟及 p50/p95/max；仅当 max 加 20% 余量不超过 deadline，并通过 symlink/config/plugin/lease/context/build 失败注入和终态清理审计时启用。
 
-任一字段无法从真实宿主稳定观察时，该客户端的 orchestration capability 保持 `unsupported`，并把缺口记录为人工验证项。Codex 可声明为 `experimental`，但每次 `prepare` 仍必须通过静态 preflight，且原生 start/stop 或 parent spawn/completed-wait fallback 必须形成可验证的 consumed host evidence。fallback 只允许 empty turns/协议 `inProgress` 等待；malformed、身份/传输错误或异常 terminal 都稳定暂停。上述关于 claude-code 的例外已在第 2 条单独说明，不改变本条对其余字段/客户端的 fail-closed 要求。
+任一字段无法从真实宿主稳定观察时，该客户端的 orchestration capability 保持 `unsupported`，并把缺口记录为人工验证项。Codex 可声明为 `experimental`，但每次 `prepare` 仍必须通过静态 preflight，且原生 start/stop 或 parent spawn/completed-wait fallback 必须记录可核对的实际执行结果。fallback 只允许 empty turns/协议 `inProgress` 等待；malformed、身份/传输错误或异常 terminal 都稳定暂停。上述关于 claude-code 的例外已在第 2 条单独说明，不改变本条对其余字段/客户端的 fail-closed 要求。