@fitlab-ai/agent-infra 0.11.11 → 0.11.13

package/templates/.agents/skills/code-task/reference/code-rules.en.md

@@ -19,6 +19,10 @@ Follow the `code` step in `.agents/workflows/feature-development.yaml`.
 3. **Keep testing continuously**: run the **fast smoke subset** continuously as work progresses (see the `test` skill)
 4. **Keep it simple**: do not add unplanned features
 
+## Strategy Pattern
+
+Read `.agents/rules/strategy-pattern.md` before implementation. When behavior differs by platform, client, protocol, workflow, business rule, or algorithm, follow the interface selected in the plan and make the core flow depend on that interface rather than concrete classes. Add each behavior as a strategy and select or assemble it in one place. If branches identifying implementations are scattered across paths, centralize strategy selection before editing callers. Keep stable behavior direct when it has no meaningful alternatives; do not add interfaces mechanically.
+
 ## Run Test Verification
 
 During implementation:

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

@@ -19,6 +19,10 @@
 3. **持续测试**：实现过程中持续运行 **fast smoke 子集**（参见 `test` skill）
 4. **保持简单**：不要加入未计划的功能
 
+## 策略模式
+
+实现前读取 `.agents/rules/strategy-pattern.md`。当实现涉及平台、客户端、协议、工作流、业务规则或算法的不同实现时，沿用方案确定的接口，让主流程依赖接口而不是具体类；新增行为应作为策略实现，在统一位置选择或装配。若识别不同实现的分支已散落在多条路径，先收敛策略选择，再修改调用方。行为稳定且没有明确替代实现时，保留直接实现，不机械增加接口。
+
 ## 运行测试验证
 
 实现过程中：

package/templates/.agents/skills/complete-manual-validation/SKILL.en.md

@@ -129,7 +129,6 @@ Report:
 - Present the completion verification summary per `.agents/rules/validation-output.md`
 - Suggested next step: enter the final closing flow and run /complete-task --task {task-ref}
 
-Before rendering the final output, read `.agents/rules/next-step-output.md` and append `Completed at: YYYY-MM-DD HH:mm:ss` as the absolute last line.
 
 ## Completion Checklist
 

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

@@ -129,7 +129,6 @@ agent-infra-internal task-verify {task-id} manual-validation.completed --artifac
 - 按 `.agents/rules/validation-output.md` 展示当次完成校验摘要
 - 下一步建议：进入最终收尾流程，运行 /complete-task --task {task-ref}
 
-渲染最终输出前，先读取 `.agents/rules/next-step-output.md`，并在绝对最后一行追加 `Completed at: YYYY-MM-DD HH:mm:ss`。
 
 ## 完成检查清单
 

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

@@ -158,7 +158,7 @@ The core deduplicates the stable `step/code/target` tuple. Callers must not allo
 
 ### 5. Run the Active Pre-completion Hard Gate
 
-After platform writes succeed and before moving the directory or releasing the short id, run:
+After platform writes succeed and before moving the directory, run:
 
 ```bash
 agent-infra-internal task-verify {task-id} complete-task.preflight --format text
@@ -182,39 +182,16 @@ For an active task, finalization first recovers pending platform operations, the
 
 Finalization runs allowed artifact backfill -> lifecycle -> terminal task comment -> core verification -> warning task-comment update -> summary seal in a fixed order. Every backfill that actually runs must reach a successful terminal result before lifecycle starts; an ordinary replay with a complete receipt and no recovery fact does not rerun backfill, comments, verification, or summary. A completed recovery that may write a managed comment first persists a done summary as pending, then seals it only at the end. Summary seal always reads the durable staging record retained in the task directory; the platform entry point validates marker, owner, and digest, performs any required delete/recreate, and reads back final remote order. `result=completed` means the host safely completed the task from structured results and the receipt; if peripheral warnings or pending steps 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. A sandbox must not run `ls completed` or a local terminal verification against its historical mount to re-decide this result.
 
-### 7. Handle Finalization Retries and Results
+### 7. Handle the Finalization Result
 
-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 allowed artifact backfill, the terminal task comment, and completion verification, then repeats summary seal from the retained durable staging record; 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 backfill, the task comment, summary seal, or verification is blocked by the network, preserve the receipt, durable staging record, 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.
+The sandbox-local entry calls the existing finalization prepare/commit flow directly. Before lifecycle transfer, it stops this task's broker from accepting new requests and waits for accepted work to finish through its existing path. Transfer starts only after the broker owner exits. On success, use the structured result and receipt returned by this command. On failure or blocked status, preserve source data and the receipt, follow the returned error, and do not claim completion or manually rewrite terminal state.
 
-Consume the structured finalization result, receipt, and warning projection directly. Continue only for `completed` or `completed_with_warnings`. Treat `failed` and `blocked` as explicit host failure or blocked outcomes: preserve the receipt, stop the current flow, and follow the returned status and error; call finalization again only when the host state permits it and the cause has been fixed. If an `accepted=true` request is `unknown`, preserve the receipt and original request ID. Never resubmit task-finalization; query only the original request with `sandbox-control recover <same-request-id>`. Create a new request only when the request was rejected before acceptance and its error permits a retry. Do not run `ls completed` or `task-verify complete-task.completed` from a stale sandbox mount, and do not let that local result overrule the host result.
-
-### Recovering an accepted sandbox-control result
-
-When this skill runs in a sandbox and an accepted task-finalization request has
-no terminal result yet, the client automatically recovers under the same
-request ID. The five-minute total budget starts with the first unknown result;
-each recover call is limited to 30 seconds. While a published unknown response
-is present, the client rereads it every 25 ms during that call. When a recover
-call times out with unknown, the client continues immediately without an extra
-wait. The client prints `SANDBOX_CONTROL_REQUEST_ID: <request-id>` on stderr.
-
-If no terminal result arrives within five minutes, preserve the receipt and
-request ID and treat the result as pending/unknown. Do not resubmit
-task-finalization. Once the broker is healthy, continue querying only the
-original request ID:
-
-```bash
-agent-infra-internal sandbox-control recover <request-id>
-```
-
-Do not submit a new request for an accepted task finalization. If the request ID is missing or the receipt cannot be read, keep the result pending and recover the original ID only from stderr, a handoff, or the receipt; do not look it up by task key. The broker's `processing/<request-id>/result.json` is private transport evidence, not a task receipt, and cannot by itself prove completion. The finalization receipt and host completion gate remain authoritative. If recovery with the same ID still has no terminal result, inspect broker and host executor activity. Stop and preserve the original request ID while a request is active, the broker is busy, or status is unknown. Retry with a new request ID only after confirming that the original request never started or its executor has ended; the new request performs the full prepare and commit after broker admission. Only a request rejected before acceptance may be retried directly with a new request ID according to the error's retryability.
+Completion keeps the short-id mapping. Managed sandbox cleanup releases it only after the container is confirmed removed and cleanup succeeds. To clean up, pass the retained short id or full `{task-id}` to `ai sandbox rm`; do not release the short id separately during completion.
 
 ### 8. Inform User
 
 > Execute this step only after the verification gate passes.
 
-> 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. 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:
@@ -232,9 +209,8 @@ Deliverables:
 Optional: clean up this task's sandbox
 (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 {task-id}
+ai sandbox rm {task-id}  # or use the task's retained short id
 
-Completed at: {completion-time}
 ```
 
 

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

@@ -157,7 +157,7 @@ agent-infra-internal task-warning {task-id} add --step complete-task --severity
 
 ### 5. 运行 active 预完成硬门禁
 
-平台写入成功后、移动目录和释放短号之前运行：
+平台写入成功后、移动目录前运行：
 
 ```bash
 agent-infra-internal task-verify {task-id} complete-task.preflight --format text
@@ -181,36 +181,16 @@ active 任务的 finalization 先恢复账本中的待处理平台操作，并
 
 finalization 按允许的 artifact backfill → lifecycle → task 评论 → core verification → warning task 评论更新 → summary seal 的固定顺序执行。每项实际运行的 backfill 必须取得成功终态，否则不得进入 lifecycle；完整 receipt 且无恢复事实的普通重入不执行 backfill、评论、验证或 summary。任何可能写入 managed comment 的 completed 恢复会先把 done summary 持久化为 pending，恢复末尾才重新 seal。summary seal 始终读取任务目录中保留的 durable staging record；平台入口负责校验 marker、owner 和 digest，必要时删除并重建摘要，再复读最终远端顺序。`result=completed` 即表示宿主已依据结构化结果和 receipt 安全完成；若还有外围 warning 或 pending step，返回 `result=completed_with_warnings`、warnings 和 pending steps。`result=failed` 或 `result=blocked` 仅用于硬失败或 receipt/capability 失败，修复原因后以同一入口重试，不得宣称完成或手工补写局部状态。沙箱不得从旧挂载执行 `ls completed` 或本地终态校验来重新裁决该结果。
 
-### 7. 处理 finalization 重试与结果
+### 7. 处理 finalization 结果
 
-场景 A 与场景 B `finalization-retry` 都从宿主执行同一个 `task-finalization` 入口。receipt 只是重入提示，不是 canonical truth：每次重入都要重新核对允许的 artifact 回填、终态 task 评论、完成校验，并使用保留的 durable staging record 重做 summary seal；只有任务已处于 `completed` 且短号 registry 已释放时，才可跳过不可逆的 lifecycle。不得拆开调用旧的 lifecycle、评论同步或完成校验命令。若回填、task 评论、summary seal 或校验因网络问题返回 `blocked`，保留 receipt、durable staging record 和已完成状态，修复网络后重跑 complete-task；若生命周期仍未完成，任务保持 active 并从 receipt 的待处理步骤继续。
+sandbox-local 入口直接执行已有 finalization prepare/commit。lifecycle 移动前，它先停止本任务 broker 接收新请求，并等待已接收操作按原路径完成；只有 broker owner 退出后才开始迁移 task 目录。成功时消费本次命令返回的结构化结果和 receipt。失败或阻塞时保留源数据与 receipt，按返回的错误处理，不输出完成消息，也不手工改写终态。
 
-完成结果必须直接消费本次宿主 finalization 的结构化输出、receipt 和 warning projection。只有 `completed` 或 `completed_with_warnings` 允许继续。`failed` / `blocked` 是宿主明确返回的失败或阻塞结果：保留 receipt，停止当前流程，并按宿主返回的状态和错误处理；只有宿主状态允许且原因已修复时，才重新调用 finalization。若 `accepted=true` 的请求结果为 `unknown`，保留 receipt 和原 request ID；不得重发 task-finalization，只能通过 `sandbox-control recover <同一 request-id>` 查询原请求。只有请求在 accepted 之前被拒绝，且错误允许重试时，才可创建新请求。不要在沙箱旧挂载中另行运行 `ls completed` 或 `task-verify complete-task.completed`，也不要用其结果推翻宿主结果。
-
-### accepted 后的 sandbox-control 结果恢复
-
-如果本技能在沙箱内执行，且 task-finalization 请求已经 accepted 但暂时没有
-terminal result，client 会从首次 unknown 开始自动按同一个 request ID 恢复，
-总预算为 5 分钟，每次 recover 最多 30 秒；published unknown 会在当前调用中
-按 25ms 间隔重读，预算用尽后立即继续 recover，不额外等待。client 会在 stderr
-输出 `SANDBOX_CONTROL_REQUEST_ID: <request-id>`。
-
-5 分钟后仍没有 terminal result 时，必须保留 receipt 和 request ID，并将结果视为
-pending/unknown；不得重发 task-finalization。broker 恢复健康后，只能继续查询原
-request ID：
-
-```bash
-agent-infra-internal sandbox-control recover <request-id>
-```
-
-accepted 的 task finalization 不得提交新请求。若 request ID 缺失或 receipt 无法读取，保持 pending；只从 stderr、handoff 或 receipt 中恢复原 ID，不按 task key 查询。broker 的 `processing/<request-id>/result.json` 只是私有 transport evidence，不是 task receipt，单凭它不能证明任务完成；finalization receipt 和宿主完成校验仍是权威。若同 ID 恢复仍没有 terminal result，必须检查 broker 和宿主 executor 的活动状态：活动请求、`busy` 或状态未知时停止并保留原 request ID。只有确认原请求从未启动或 executor 已结束后，才可用新的 request ID 重试；新请求会在 broker 接纳后执行完整 prepare 和 commit。仅当请求在 accepted 之前已被拒绝时，才可直接依据错误的 retryability 决定是否提交新的 request ID.
+complete 保留短号映射。它只会在受管 sandbox 清理确认容器已删除且清理成功后释放。需要清理时可用保留短号或完整 `{task-id}` 调用 `ai sandbox rm`；不要在 complete 中单独释放短号。
 
 ### 8. 告知用户
 
 > 仅在校验通过后执行本步骤。
 
-> 完成时间收尾行（整段输出的最后一行）取值 `date "+%Y-%m-%d %H:%M:%S"`（本地时区、不带偏移），固定放在输出的绝对末尾，便于多窗口扫视。本 skill 不渲染「下一步」命令，但会在收尾行之前渲染一段**可选的沙箱清理提示**（见下方门控），且仍统一打印该收尾行。
-
 > **可选沙箱清理提示（门控渲染）**：仅当同时满足 (1) `.agents/.airc.json` 存在 `sandbox` 字段、(2) task.md 的 `branch` 字段存在且不是 `main` / `master` 时，才渲染下方输出中的「可选：清理本任务的沙箱」块；任一不满足则整段省略。清理时使用完整 `{task-id}`，不要改用 branch 名。该块独立于「下一步」语义，不是工作流后继命令。
 
 输出格式：
@@ -228,9 +208,8 @@ accepted 的 task finalization 不得提交新请求。若 request ID 缺失或
 可选：清理本任务的沙箱
 （任务已完成，沙箱容器和 per-branch 配置目录不会自动回收。如果不再需要可执行：）
 
-ai sandbox rm {task-id}
+ai sandbox rm {task-id}  # 或使用本任务仍保留的短号
 
-Completed at: {completion-time}
 ```
 
 

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

@@ -91,6 +91,8 @@ Use it to understand:
 
 ### 5. Design the Technical Plan
 
+Before designing, read `.agents/rules/strategy-pattern.md`. Identify shared flows and behavior differences by platform, client, protocol, workflow, business rule, or algorithm; make the core flow depend on interfaces and put differences in strategy implementations instead of adding a dedicated branch to every path.
+
 Follow the `technical-design` step in `.agents/workflows/feature-development.yaml`:
 
 **Required tasks**:
@@ -105,10 +107,11 @@ When this round introduces a new key design decision, first run `agent-infra-int
 
 **Design principles**:
 1. **Architectural soundness**: choose the structurally correct approach; diff size is not the primary criterion. Do not pile changes onto an unsound structure just to keep the diff small
-2. **Simplicity**: given a sound architecture, prefer the simplest approach and avoid over-engineering
-3. **Consistency**: follow existing code patterns and conventions
-4. **Testability**: design for straightforward testing
-5. **Reversibility**: prefer changes that are easy to roll back
+2. **Strategy Pattern**: identify shared flows and different behaviors; make the core flow depend on interfaces, not concrete implementations, and select or assemble strategies in one place
+3. **Simplicity**: given a sound architecture, prefer the simplest approach; do not add strategy interfaces mechanically when behavior is stable and has no meaningful alternatives
+4. **Consistency**: follow existing code patterns and conventions
+5. **Testability**: design for straightforward testing
+6. **Reversibility**: prefer changes that are easy to roll back
 
 ### 6. Output Plan Document
 

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

@@ -92,6 +92,8 @@ agent-infra-internal task-event {task-id} plan.started --agent {standard-agent-t
 
 ### 5. 设计技术方案
 
+设计方案前先读取 `.agents/rules/strategy-pattern.md`，识别各实现共用的流程及平台、客户端、协议、工作流、业务规则或算法方面的差异；优先让主流程依赖接口，并通过策略实现承载差异，避免为每条链路增加专用分支。
+
 仅当方案阶段实际判断候选资格、约束依赖或人工裁决资格时，才按 `.agents/rules/decision-qualification.md` 复核规范化约束和候选，并在方案产物记录完整资格审计；否则省略整个审计段。来源不明或未人工确认的约束不得自动排除候选。
 
 遵循 `.agents/workflows/feature-development.yaml` 中的 `technical-design` 步骤：
@@ -108,10 +110,11 @@ agent-infra-internal task-event {task-id} plan.started --agent {standard-agent-t
 
 **设计原则**：
 1. **架构合理性**：选择结构正确的方案，改动大小不是首要依据。不要为了减少 diff 而在不合理的结构上叠加
-2. **简洁性**：在架构合理的前提下，优先选择最简方案，避免过度设计
-3. **一致性**：遵循现有代码模式和规范
-4. **可测试性**：设计易于测试的方案
-5. **可逆性**：优先选择易于回退的变更
+2. **策略模式**：明确各实现共用的流程和不同的行为；主流程依赖接口，不依赖具体实现；策略在统一位置选择和装配
+3. **简洁性**：在架构合理的前提下，优先选择最简方案；行为稳定且没有明确替代实现时，不机械增加策略接口
+4. **一致性**：遵循现有代码模式和规范
+5. **可测试性**：设计易于测试的方案
+6. **可逆性**：优先选择易于回退的变更
 
 ### 6. 输出计划文档
 

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

@@ -117,4 +117,4 @@ Present the verification summary per `.agents/rules/validation-output.md`, retai
 
 Use the conclusion branch in `reference/output-templates.md` and render the selected next-step commands through the shared helper.
 
-> Before rendering the final output, read `.agents/rules/next-step-output.md` and apply both of its rules: (1) render `{task-ref}` in the "Next steps" commands as the current task's short id `NN` (see that file for lookup and fallback), while other `{task-id}` placeholders (report titles, paths) keep the full TASK-id form; (2) append the `Completed at` line as the very last line of the user-facing output (this applies to every user-facing output — success, error, and early-return paths alike, not only the success path).
+> Before rendering the final output, read `.agents/rules/next-step-output.md`; render `{task-ref}` in the "Next steps" commands as the current task's short id `NN` (see that file for lookup and fallback), while other `{task-id}` placeholders (report titles, paths) keep the full TASK-id form.

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

@@ -122,7 +122,7 @@ agent-infra-internal task-verify {task-id} review-analysis.completed --artifact
 
 按 `reference/output-templates.md` 的结论分支输出，并通过统一 helper 渲染已选场景的下一步命令。
 
-> 渲染最终输出前先读取 `.agents/rules/next-step-output.md` 并落实其两类规则：(1) 「下一步」命令的 `{task-ref}` 渲染为当前任务短号 `NN`（取值与回退见该文件），其他 `{task-id}` 占位（报告标题、路径）保持完整 TASK-id 形式；(2) 在面向用户输出的绝对最后一行追加 `Completed at` 收尾行（成功、错误、早退等任何面向用户输出都适用，不限于校验通过的成功态）。
+> 渲染最终输出前先读取 `.agents/rules/next-step-output.md`，并将「下一步」命令的 `{task-ref}` 渲染为当前任务短号 `NN`（取值与回退见该文件）；其他 `{task-id}` 占位（报告标题、路径）保持完整 TASK-id 形式。
 
 ## 完成检查清单
 

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

@@ -173,7 +173,7 @@ manual-validation counts do not influence branch selection; they are displayed o
 
 > The A/B/C output templates, selection rules, and prohibition clauses live in `reference/output-templates.md`. Read `reference/output-templates.md` before reporting the review result.
 
-> Before rendering the final output, read `.agents/rules/next-step-output.md` and apply both of its rules: (1) render `{task-ref}` in the "Next steps" commands as the current task's short id `NN` (see that file for lookup and fallback), while other `{task-id}` placeholders (report titles, paths) keep the full TASK-id form; (2) append the `Completed at` line as the very last line of the user-facing output (this applies to every user-facing output — success, error, and early-return paths alike, not only the success path).
+> Before rendering the final output, read `.agents/rules/next-step-output.md`; render `{task-ref}` in the "Next steps" commands as the current task's short id `NN` (see that file for lookup and fallback), while other `{task-id}` placeholders (report titles, paths) keep the full TASK-id form.
 
 Render only the selected scenario's commands returned by the shared helper. The helper builds custom tool commands from `sandbox.tools.ids` and `sandbox.tools.definitions`; do not reread configuration or manually append commands.
 

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

@@ -169,7 +169,7 @@ manual-validation 的数量不参与分支选择，只作为人工校验计数
 
 > 完整的 A/B/C 输出模板、判断规则和禁止条款见 `reference/output-templates.md`。向用户汇报审查结论前先读取 `reference/output-templates.md`。
 
-> 渲染最终输出前先读取 `.agents/rules/next-step-output.md` 并落实其两类规则：(1) 「下一步」命令的 `{task-ref}` 渲染为当前任务短号 `NN`（取值与回退见该文件），其他 `{task-id}` 占位（报告标题、路径）保持完整 TASK-id 形式；(2) 在面向用户输出的绝对最后一行追加 `Completed at` 收尾行（成功、错误、早退等任何面向用户输出都适用，不限于校验通过的成功态）。
+> 渲染最终输出前先读取 `.agents/rules/next-step-output.md`，并将「下一步」命令的 `{task-ref}` 渲染为当前任务短号 `NN`（取值与回退见该文件）；其他 `{task-id}` 占位（报告标题、路径）保持完整 TASK-id 形式。
 
 向用户只展示统一 helper 返回的已选场景命令。自定义工具命令由 helper 按 `sandbox.tools.ids` 和 `sandbox.tools.definitions` 生成；不得再次读取配置或手工追加命令。
 

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

@@ -117,4 +117,4 @@ Present the verification summary per `.agents/rules/validation-output.md`, retai
 
 Use the conclusion branch in `reference/output-templates.md` and render the selected next-step commands through the shared helper.
 
-> Before rendering the final output, read `.agents/rules/next-step-output.md` and apply both of its rules: (1) render `{task-ref}` in the "Next steps" commands as the current task's short id `NN` (see that file for lookup and fallback), while other `{task-id}` placeholders (report titles, paths) keep the full TASK-id form; (2) append the `Completed at` line as the very last line of the user-facing output (this applies to every user-facing output — success, error, and early-return paths alike, not only the success path).
+> Before rendering the final output, read `.agents/rules/next-step-output.md`; render `{task-ref}` in the "Next steps" commands as the current task's short id `NN` (see that file for lookup and fallback), while other `{task-id}` placeholders (report titles, paths) keep the full TASK-id form.

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

@@ -122,7 +122,7 @@ agent-infra-internal task-verify {task-id} review-plan.completed --artifact {rev
 
 按 `reference/output-templates.md` 的结论分支输出，并通过统一 helper 渲染已选场景的下一步命令。
 
-> 渲染最终输出前先读取 `.agents/rules/next-step-output.md` 并落实其两类规则：(1) 「下一步」命令的 `{task-ref}` 渲染为当前任务短号 `NN`（取值与回退见该文件），其他 `{task-id}` 占位（报告标题、路径）保持完整 TASK-id 形式；(2) 在面向用户输出的绝对最后一行追加 `Completed at` 收尾行（成功、错误、早退等任何面向用户输出都适用，不限于校验通过的成功态）。
+> 渲染最终输出前先读取 `.agents/rules/next-step-output.md`，并将「下一步」命令的 `{task-ref}` 渲染为当前任务短号 `NN`（取值与回退见该文件）；其他 `{task-id}` 占位（报告标题、路径）保持完整 TASK-id 形式。
 
 ## 完成检查清单
 

package/templates/.agents/skills/run-manual-validation/SKILL.en.md

@@ -48,7 +48,7 @@ Branch-only has no `{task-id}`: skip this step and record `not-applicable (branc
 5. Read `reference/report-template.md`, create `validation-run.md|validation-run-r{N}.md`, and record the input mode, discovered list, per-item results, CLI JSON allowlist, and sanitized summaries.
 6. Run `agent-infra-internal task-event {task-id} validation-run.completed --agent {standard-agent-token} --initiator {trigger-initiator} --request-id {request-id} --reason-code {reason-code} --artifact {artifact}`. When an Issue exists, run only `agent-infra-internal platform-comment sync {task-id} --kind task --agent {standard-agent-token}`; do not publish the validation artifact as an Issue comment.
 7. Run `agent-infra-internal task-verify {task-id} validation-run.completed --artifact {artifact} --format text`; fix failures and rerun it, then present the summary per `.agents/rules/validation-output.md` with necessary diagnostics.
-8. Report the evidence path, coverage gaps, and verification result; explicitly leave the decision to run `complete-manual-validation` to the maintainer. Read `.agents/rules/next-step-output.md` and end with `Completed at`.
+8. Report the evidence path, coverage gaps, and verification result; explicitly leave the decision to run `complete-manual-validation` to the maintainer.
 
 ## Scenario B: Branch-Only Fallback
 

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

@@ -48,7 +48,7 @@ branch-only 无 `{task-id}`，跳过本步，并在产物 `## 状态核对` 记
 5. 读取 `reference/report-template.md`，创建 `validation-run.md|validation-run-r{N}.md`；记录输入模式、发现清单、逐项结果、CLI JSON allowlist 与去敏摘要。
 6. 运行 `agent-infra-internal task-event {task-id} validation-run.completed --agent {standard-agent-token} --initiator {trigger-initiator} --request-id {request-id} --reason-code {reason-code} --artifact {artifact}`。存在 Issue 时仅运行 `agent-infra-internal platform-comment sync {task-id} --kind task --agent {standard-agent-token}`；验证 artifact 不发布为 Issue 评论。
 7. 运行 `agent-infra-internal task-verify {task-id} validation-run.completed --artifact {artifact} --format text`；未通过则修复后重跑，并按 `.agents/rules/validation-output.md` 展示摘要和必要诊断。
-8. 告知用户证据路径、覆盖缺口和验证结果；明确仍需维护者判断是否执行 `complete-manual-validation`。读取 `.agents/rules/next-step-output.md`，最后一行输出 `Completed at`。
+8. 告知用户证据路径、覆盖缺口和验证结果；明确仍需维护者判断是否执行 `complete-manual-validation`。
 
 ## 场景 B：branch-only 降级
 

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

@@ -19,7 +19,7 @@ The orchestrator delegates only and never executes a stage skill itself. First r
 4. 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.
 5. Run `route`. On `completed`, run `agent-infra-internal task-verify {task-id} run-task.completed --format text`, present its summary per `.agents/rules/validation-output.md` while retaining necessary diagnostics, and stop. Only a `running` result with non-null `next` supplies action, role, round, artifact, requested model, and requested effort.
 6. Call `prepare --client {client} --requested-model {requestedModel} --requested-reasoning-effort {requestedReasoningEffort}` with route's exact policy. The client adapter runs host preflight. Report actual task, policy, or host failures.
-7. 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. After prepare, forward the optional `adapterContext` unchanged to `agent-infra-internal agent-client launch-carrier --client {client} --adapter-context {adapterContext} --stage {stage} --round {round} --role {role} --format json`. The shared skill must not parse, rewrite, or validate this opaque value. The controlled entry point calls the current Agent Client adapter's `createLaunchCarrier` and returns a carrier for native spawn. Stop dispatch with the structured error if carrier support is unavailable or conversion fails. Then run `task-orchestration <task-ref> dispatch` with route's exact model/effort, passing the short task ref, skill, `--orchestrated`, stage/round/artifact/role, and the returned carrier unchanged to native spawn. 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.
 8. Record actual start and terminal results through the current host's native lifecycle events and result interfaces. 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 3 only while running.
 9. 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.
 10. On pause or completion, run the matching typed verification and report the structured endpoint.

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

@@ -19,7 +19,7 @@ description: >
 4. 调用 `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，按结构化结果停止。
 5. 调用 `route` 并读取结构化结果。若返回 `completed`，立即运行 `agent-infra-internal task-verify {task-id} run-task.completed --format text` 并停止；按 `.agents/rules/validation-output.md` 展示摘要并保留必要诊断。仅当返回 `running` 且 `next` 非空时读取唯一 action、role、round、artifact、`requestedModel` 和 `requestedReasoningEffort`，不得自行推断。
 6. 调用 `prepare --client {client} --requested-model {requestedModel} --requested-reasoning-effort {requestedReasoningEffort}`，使用 route 返回的精确策略。客户端适配器执行宿主 preflight；任务身份、策略或宿主检查失败时记录实际诊断。
-7. 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. prepare 成功后，原样转发返回的可选 `adapterContext`，调用 `agent-infra-internal agent-client launch-carrier --client {client} --adapter-context {adapterContext} --stage {stage} --round {round} --role {role} --format json`。共享技能不解析、重写或验证该不透明值；受控入口调用当前 Agent Client adapter 的 `createLaunchCarrier`，并返回可直接交给 native spawn 的 carrier。缺少 carrier 能力或转换失败时按结构化错误停止派发。随后执行 `task-orchestration <task-ref> dispatch`，显式指定 route 返回的 model/effort；传递短任务引用、skill 名、`--orchestrated` 与 stage/round/artifact/role，并把返回的 carrier 原样交给 native spawn。child 调用 `await-activation --stage ... --round ... --artifact ... --role ...`，确认当前阶段与实际 child 关联后执行。代码阶段通过 code-task 创建本地 checkpoint；禁止单独委派 commit 阶段或推送。保留已有写锁，不把实际 spawn 纳入新建锁协议。
 8. 通过当前宿主的原生生命周期事件和结果接口记录实际启动及终态。timed-out wait 不推断成功；身份、传输或异常终态失败如实暂停。阶段结果和 child 完成后调用 `advance`；只有 `running` 才重复步骤 3。
 9. 每轮创建新 child；禁止 follow-up 复用 reviewer。如实记录 actual model/effort 及宿主降级理由。检查当前身份、产物、账本与实际执行结果；用户裁决优先于历史方案派生要求。不得新增 child discovery、孤立 child 恢复或专用恢复协议。
 10. 完成或暂停后运行对应 typed verification，并把结构化 run 摘要、暂停原因、commit 终点或 clean completion evidence 告知用户。