@fitlab-ai/agent-infra 0.12.0 → 0.12.2

package/lib/task/verification.ts

@@ -17,8 +17,7 @@ type VerificationEvent =
   | 'create-pr.completed' | 'create-task.completed'
   | 'import-codescan.completed' | 'import-dependabot.completed'
   | 'import-issue.completed' | 'watch-pr.completed'
-  | 'review-pr.completed'
-  | 'run-task.paused' | 'run-task.completed';
+  | 'review-pr.completed';
 type VerificationSpec = {
   skill: string;
   expectedState: 'active' | 'blocked' | 'completed';
@@ -75,9 +74,7 @@ const VERIFICATION_CATALOG: Readonly<Record<VerificationEvent, VerificationSpec>
   'import-dependabot.completed': gate('import-dependabot', 'active'),
   'import-issue.completed': gate('import-issue', 'active'),
   'watch-pr.completed': gate('watch-pr', 'active'),
-  'review-pr.completed': gate('review-pr', 'active', 'pr-review'),
-  'run-task.paused': { skill: 'run-task', expectedState: 'active', mode: 'checks', checks: ['orchestration-state', 'orchestration-evidence'] },
-  'run-task.completed': { skill: 'run-task', expectedState: 'active', mode: 'checks', checks: ['orchestration-state', 'orchestration-evidence'] }
+  'review-pr.completed': gate('review-pr', 'active', 'pr-review')
 };
 
 function failure(request: { taskRef: string; event: string; artifact?: string }, code: string, message: string, extra: Partial<TaskVerificationResult> = {}): TaskVerificationResult {
@@ -161,6 +158,9 @@ function renderTaskVerification(result: TaskVerificationResult): string {
       && typeof message === 'string'
       && /\bhuman-decided (?:post-review )?exemption\b/i.test(message)
       && /\bPRC-\d+\s*:/.test(message);
+    if (Array.isArray(check.warnings)) {
+      for (const warning of check.warnings) if (typeof warning === 'string') lines.push(`Warning: ${id} - ${warning}`);
+    }
     if (effectiveStatus === 'pass' && !isSoftWarning && !isHumanExemptionNotice) continue;
     lines.push(isSoftWarning
       ? `Warning: ${id} (${rawStatus === 'blocked' ? `raw BLOCKED; ` : ''}${reason}) - ${message}; ${action}`

package/lib/task/write.ts

@@ -14,6 +14,7 @@ import type {
   TaskWorkspaceState
 } from './resolve-ref.ts';
 import { mutateTableRow, upsertSection } from './sections.ts';
+import { lifecycleExecutions, prReviewExecution, serializeLifecycleExecution } from './lifecycle-execution.ts';
 import { validateCurrentTaskContract } from './current-contract.ts';
 import type {
   TableRowDeleteMutation,
@@ -24,6 +25,7 @@ type FrontmatterMutation = {
   kind: 'frontmatter';
   set: Readonly<Record<string, FrontmatterScalar>>;
   remove?: readonly string[];
+  lifecycleExecutionDomain?: 'ordinary' | 'pr-review';
 };
 
 type SectionMutation = {
@@ -288,7 +290,16 @@ function writeTaskCore(request: TaskWriteRequest, options: TaskWriteOptions = {}
       }
       const before = candidate;
       if (mutation.kind === 'frontmatter') {
-        candidate = updateTaskFrontmatter(candidate, mutation.set, mutation.remove);
+        let set = mutation.set;
+        if (mutation.lifecycleExecutionDomain) {
+          const proposed = updateTaskFrontmatter(candidate, mutation.set);
+          const open = mutation.lifecycleExecutionDomain === 'ordinary'
+            ? lifecycleExecutions(proposed)
+            : lifecycleExecutions(candidate);
+          const pr = prReviewExecution(mutation.lifecycleExecutionDomain === 'pr-review' ? proposed : candidate);
+          set = { ...mutation.set, lifecycle_execution: serializeLifecycleExecution(open, undefined, pr) };
+        }
+        candidate = updateTaskFrontmatter(candidate, set, mutation.remove);
         operations.push({
           index,
           kind: 'frontmatter',

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@fitlab-ai/agent-infra",
-  "version": "0.12.0",
+  "version": "0.12.2",
   "description": "Bootstrap tool for AI multi-tool collaboration infrastructure — works with Claude Code, Codex, Antigravity CLI, and OpenCode",
   "license": "MIT",
   "type": "module",
@@ -55,7 +55,7 @@
     "@clack/prompts": "1.8.1",
     "@larksuiteoapi/node-sdk": "^1.68.0",
     "cross-spawn": "^7.0.6",
-    "fs-native-extensions": "1.5.1",
+    "fs-native-extensions": "1.5.2",
     "picocolors": "1.1.1",
     "semver": "^7.8.1",
     "smol-toml": "^1.6.1",

package/templates/.agents/README.en.md

@@ -222,16 +222,14 @@ Ordinary `managed` files keep their overwrite semantics. A small set of platform
 
 ## Agent Client Configuration
 
-Use the top-level `.agents/.airc.json` `agentClients` array to configure all five built-in clients (`claude-code`, `codex`, `antigravity-cli`, `opencode`, `traecli`). Each canonical entry has three required fields and one optional orchestration policy:
+Use the top-level `.agents/.airc.json` `agentClients` array to configure all five built-in clients (`claude-code`, `codex`, `antigravity-cli`, `opencode`, `traecli`). Each canonical entry has three required fields:
 
 | Field | Meaning |
 |-------|---------|
 | `id` | Built-in Agent Client id. The canonical array contains exactly one entry for each built-in client. |
 | `enabled` | Whether agent-infra writes and maintains that client's project integration and seed command. |
 | `installInSandbox` | Whether the sandbox image installs that client's CLI. This is independent from `enabled`. |
-| `orchestration` | Optional `run-task` default. It must include executor/reviewer `model` and host-native `reasoningEffort`; both roles may use the same model. |
 
-Explicit `run-task` model/effort flags are atomic: any one requires all four role fields and configuration never fills omissions. With no explicit policy, only the current client's `orchestration` is used. Query model-selection context with `agent-infra-internal agent-client model-selection --client <id>`; it labels results complete, partial, or interactive-only and never presents a local override list as a complete catalog.
 
 Manage these settings without hand-editing JSON:
 

package/templates/.agents/README.zh-CN.md

@@ -228,9 +228,7 @@ disable-model-invocation: true   # 可选；由支持该能力的 TUI 适配器
 | `id` | 内建 Agent Client id。规范数组为每个内建客户端保留且仅保留一个条目。 |
 | `enabled` | agent-infra 是否写入并维护该客户端的项目集成与种子命令。 |
 | `installInSandbox` | 沙箱镜像是否安装该客户端 CLI；此字段与 `enabled` 相互独立。 |
-| `orchestration` | `run-task` 可选默认策略；必须同时提供 executor/reviewer 的 `model` 与宿主原生 `reasoningEffort`，两个角色可以使用同一模型。 |
 
-`run-task` 的显式 model/effort 参数是原子输入：只要提供其中任一字段，就必须完整提供四个 role 字段，不能从配置补齐。完全没有显式策略时，只读取当前客户端的 `orchestration`。模型目录通过 `agent-infra-internal agent-client model-selection --client <id>` 查询，并明确标记 complete、partial 或 interactive-only；局部 override 列表不能当作完整目录。
 
 无需手工编辑 JSON，可使用：
 

package/templates/.agents/rules/README.en.md

@@ -31,7 +31,6 @@ so you can quickly find "which ones to read" without opening each file.
 ## Task Workflow
 
 - [`task-management.md`](task-management.md) — Task intent detection, workflow-command mapping, and skill blocking boundaries.
-- [`lifecycle-orchestration.md`](lifecycle-orchestration.md) — Fresh executor/reviewer, one-use receipt, pause/recovery, and safe endpoint rules for `run-task`.
 - [`review-handshake.md`](review-handshake.md) — Three-stage bidirectional review handshake: four-state disposition, symmetric evidence, disagreement ledger, convergence and post-review commit gate.
 - [`review-method.md`](review-method.md) — Shared three-stage review method: multi-pass review, risk lenses, traceability, and finding evidence.
 - [`local-artifact-repair.md`](local-artifact-repair.md) — Pre-completion local artifact validation for analysis/plan/code and model-per-case repair, safety gates, and convergence for failed review artifacts.

package/templates/.agents/rules/README.zh-CN.md

@@ -30,7 +30,6 @@
 ## 任务工作流
 
 - [`task-management.md`](task-management.md) — 任务语义识别、工作流命令映射与技能阻塞边界。
-- [`lifecycle-orchestration.md`](lifecycle-orchestration.md) — `run-task` 的 fresh executor/reviewer、一次性 receipt、暂停恢复与安全终点规则。
 - [`review-handshake.md`](review-handshake.md) — 三阶段双向审查握手协议：四态处置、对称证据、分歧账本、收敛与 post-review commit 门禁。
 - [`review-method.md`](review-method.md) — 三阶段共享检视方法：多遍检视、风险镜头、追踪与 finding 证据契约。
 - [`local-artifact-repair.md`](local-artifact-repair.md) — analysis/plan/code completed 前的本地产物校验、review artifact 失败后的模型逐例修复、机械安全门与收敛契约。

package/templates/.agents/rules/commit-and-pr.en.md

@@ -10,7 +10,7 @@
 ## Commit Execution Boundary
 
 - Do not run `git add` or `git commit` directly. All automatic commits must use the shared `agent-infra-internal git-workflow commit` core and follow the paths, HEAD/tree, and delivery-mode constraints of the applicable skill.
-- The active workflow defines whether a commit is required. Completing `code-task` requires a local checkpoint through the shared core after tests and report preflight pass. This applies to direct calls and `run-task` orchestration; no extra commit authorization or user confirmation is required.
+- The active workflow defines whether a commit is required. Completing `code-task` requires a local checkpoint through the shared core after tests and report preflight pass. The current code-task invocation calls the shared core.
 - A `code-task` checkpoint never pushes to a remote. Other skills may call the shared core only when their workflow explicitly requires it. The standalone `commit` skill still requires an explicit user invocation and follows its push-delivery flow.
 - Do not create a commit when the workflow does not require one. When a separate user commit is needed, remind the user to use the appropriate TUI command.
 

package/templates/.agents/rules/commit-and-pr.zh-CN.md

@@ -10,7 +10,7 @@
 ## 提交执行边界
 
 - 不直接执行 `git add` 或 `git commit`；所有自动提交都必须通过 `agent-infra-internal git-workflow commit` 共享 core，并遵守对应技能提供的 paths、HEAD/tree 和交付模式约束。
-- 提交由当前工作流定义。`code-task` 完成实现必须在测试和实现报告 preflight 通过后，通过共享 core 创建一个本地 checkpoint；该要求适用于直接调用和 `run-task` 编排，不需要额外的提交授权或用户确认。
+- 提交由当前工作流定义。`code-task` 完成实现必须在测试和实现报告 preflight 通过后，通过共享 core 创建一个本地 checkpoint；该要求由当前 code-task 调用共享 core 完成。
 - `code-task` 的本地 checkpoint 不推送远端。其他技能只有在其流程明确要求时才可调用共享 core；独立 `commit` 技能仍须由用户显式调用，并遵循其 push delivery 流程。
 - 工作流没有要求提交时，不要自行创建提交；需要用户执行独立提交时，再提示对应 TUI 命令。
 

package/templates/.agents/rules/no-mid-flow-questions.en.md

@@ -49,14 +49,6 @@ SKILLs currently covered by this exemption:
 - `create-release-note`: may confirm publish after presenting exact staged notes and their digest
 - `post-release`: may confirm a normal push after preparing the local post commit and presenting the complete `postConfirmation` and digest
 
-### Exemption 5: Complete model policy missing at lifecycle start
-
-Only when `run-task` receives `ORCHESTRATION_MODEL_POLICY_REQUIRED` before any run, baseline, receipt, or child is created may it show model-selection context with its completeness label and ask once for complete executor/reviewer model + reasoning effort. Partial explicit policy, a missing client, active delegation, and other pause causes do not qualify. No answer means no run is created.
-
-SKILLs currently covered by this exemption:
-
-- `run-task`: may collect only the atomic model policy explicitly required by core
-
 ### Exemption 6: Necessary facts or security accountability that cannot be inferred
 
 Only when the executor has checked the current task, configuration, code, Git, and platform records and still cannot safely infer a user-specific fact or security-accountability information required to proceed may it ask the user for that missing information. Keep the question limited to the missing fact itself. Do not ask for ordinary implementation preferences that existing evidence can resolve, and do not turn an exhausted recovery budget into general permission to ask.
@@ -105,8 +97,6 @@ A mandatory human review checkpoint means:
 
 If a key decision needs human judgment during execution, follow the rule above and register the detail identity through the structured `decision-next-id` / `decision-upsert` commands for the user to address at the review checkpoint; ordinary open questions still go to `## Open Questions` / `未决问题`.
 
-The `run-task` orchestrator may continue after a child skill artifact only when core mechanical state permits it; this does not bypass human decisions. When core reports a human decision, manual validation, or another stable pause condition, the orchestrator must stop without asking mid-flow or approving it itself.
-
 ## Error diagnosis and recovery order
 
 When a tool, gate, platform, or local operation fails, read the complete error and structured result first. Determine state from the operation identity, acceptance status, side effects, receipt, and explicit retryability. Do not infer network failure, non-execution, or a need for user intervention from an exit code, wording, or temporary lack of output alone.

package/templates/.agents/rules/no-mid-flow-questions.zh-CN.md

@@ -49,14 +49,6 @@
 - `create-release-note`：展示 stage 后的精确 notes 与摘要后确认是否 publish
 - `post-release`：完成本地 post commit 并展示完整 `postConfirmation` 与摘要后确认是否普通 push
 
-### 例外 5：生命周期启动缺少完整模型策略
-
-仅当 `run-task` 在创建任何 run、baseline、receipt 或 child 之前收到核心错误 `ORCHESTRATION_MODEL_POLICY_REQUIRED` 时，可展示带完整性标签的模型选择上下文，并一次询问 executor/reviewer 的完整 model + reasoning effort。部分显式策略、缺少 client、active delegation 或其他暂停原因不适用；用户未回答时不得创建 run。
-
-当前归入本例外的 SKILL：
-
-- `run-task`：仅补齐核心明确要求的原子模型策略
-
 ### 例外 6：无法推导的必要事实或安全责任信息
 
 仅当已检查当前任务、配置、代码、Git 与平台记录后，仍无法安全推导继续执行所必需的用户专属事实或安全责任信息时，才可请求用户提供缺失内容。问题必须限定在缺失事实本身；不得询问可由现有证据决定的普通实现偏好，也不得把恢复预算耗尽泛化为提问许可。
@@ -105,8 +97,6 @@
 
 如果在执行过程中发现需要用户裁定的关键决策，按上文「关键设计决策标记与落账」处理：通过 `decision-next-id` / `decision-upsert` 结构化命令登记详情块与账本身份，由用户在审查检查点统一回应；普通未决问题仍写 `## 未决问题` / `Open Questions`。
 
-`run-task` 总控可以在子技能产出后依据核心机械状态继续到下一阶段；这不构成绕过人工裁决。只要核心返回人工裁决、人工验证或其他稳定暂停条件，总控必须停止，不能向用户中途提问，也不能自行批准。
-
 ## 错误诊断与恢复顺序
 
 遇到工具、校验、平台或本地操作失败时，先读取完整错误与结构化结果，再按当前操作的身份、是否接纳、已发生副作用、receipt 和明确的 retryability 判断状态。不得仅凭退出码、错误措辞或暂时无输出推断网络故障、操作未执行或需要用户介入。

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

@@ -25,7 +25,7 @@ agent-infra-internal platform-pr summary-sync {task-id} \
   --result {primary-result}
 ```
 
-Use only canonical inputs returned by the context command. The precheck must contain file evidence for six fixed checks; `formalReview` is always false and `needs-review` routes to `review-code`. Write the plain body with exactly one `<!-- canonical-pr-change-report -->` placeholder, without a report heading/JSON, marker, or SHA. The core validates the task-intent digest, bound PR identity, complete patch SHA, and mechanical totals before rendering the report, then owns `<!-- sync-pr:{task-id}:summary -->`, authoritative `<!-- last-commit: ... -->`, create/update/no-op behavior, and duplicate-marker conflicts. Missing, stale, invalid, or bypassed report input never publishes; summary failure never rolls back a PR or commit.
+Use only canonical inputs returned by the context command. The precheck must contain file evidence for six fixed checks; `formalReview` is always false and `needs-review` routes to `review-code`. Generate a typed JSON payload with `overview:string`, `tests:{state,detail}`, `review:{state,detail}`, `manualValidation:{state,detail}`, `humanDecisions:{open,resolved,detail}`, and `risks:string`. Detail fields are non-empty, counts are non-negative integers, and structure checks do not assess semantic quality. The body file contains only these semantic fields; do not add a Markdown envelope, control markers, or the canonical report placeholder. The core renders the sections and inserts the placeholder, summary marker, and authoritative HEAD. Use `not-started`/`pending` for tests that have not started, `none`/`not-observed`/`not-published` for absent or unobserved remote Reviews, and `pending` for manual validation that has not run. Human-decision counts come from the task ledger. The core validates the task-intent digest, bound PR identity, complete patch SHA, and mechanical totals before rendering the report, then owns create/update/no-op behavior.
 
 The canonical comment envelope produced by the core is:
 
@@ -40,7 +40,9 @@ The canonical comment envelope produced by the core is:
 ### PR Code Changes
 ```
 
-Canonical inputs include `manual-validation.md`. The manual-validation section is one of `### ✅ Manual Validation Passed`, `### ⚠️ Manual Verification Required`, or `### ✅ No Manual Verification Needed`; `complete-manual-validation` refreshes the same summary in place. The PR code-change section uses authoritative base/head facts from `platform-pr inspect` and the complete `git diff --find-renames --numstat base...head`, reconciles runtime, test, skill/rule, template, documentation, and other categories, and explains renames, mechanical mirrors, and potentially unnecessary changes. The caller supplies the placeholder; the core renderer supplies the canonical `### PR Code Changes` section.
+Canonical inputs include `manual-validation.md`. The manual-validation `state` can be `required`, `pending`, `passed`, `none`/`not-required`, or `not-observed`. English headings such as `### ⚠️ Manual Verification Required`, `### ✅ Manual Validation Passed`, and `### ✅ No Manual Verification Needed` are documentation labels; the current renderer emits Chinese headings. `complete-manual-validation` refreshes the same summary in place. The PR code-change section uses authoritative base/head facts from `platform-pr inspect` and the complete `git diff --find-renames --numstat base...head`, reconciles runtime, test, skill/rule, template, documentation, and other categories, and explains renames, mechanical mirrors, and potentially unnecessary changes. The core renderer supplies the canonical `### PR Code Changes` section. After publishing, the core reads comments back and requires one summary marker with a body that exactly matches the canonical rendered body; mismatch or read failure uses the existing coordinator/recovery path.
+
+Examples include `required`, `pending`, `passed`, `none`/`not-required`, and `not-observed`; this list is illustrative, not exhaustive. The renderer also accepts `unavailable` and other non-empty states through its existing fallback. English headings below are documentation labels; the current renderer emits the stated Chinese headings. `required` retains each item, location, and reason under `### ⚠️ 需人工校验`. `pending` means validation has not started or remains incomplete and renders as `### ⏳ 人工验证待收尾`. `passed` (`### ✅ Manual Validation Passed` in this documentation; `### ✅ 人工验证已通过` from the renderer) is publishable only through the final `complete-manual-validation` coordinator after it writes a valid receipt. Preserve the receipt marker bound to the transaction, receipt, evidence, and current PR head; never infer passed status from summary text or another state. `none`/`not-required` renders as `### ✅ 无需人工校验` only when no manual item is required and carries no passed receipt. `not-observed` means the state has not been read and renders as `### ℹ️ 尚未读取人工校验状态`.
 
 ```bash
 agent-infra-internal task-warning {task-id} add --step {step} --severity WARNING \

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

@@ -18,17 +18,14 @@ PR 摘要的语义聚合由模型完成；任务意图 digest、完整三点 dif
 agent-infra-internal platform-pr summary-context {task-id}
 ```
 
-只使用返回的 canonical latest `plan*`、`review-plan*`、`code*`、`review-code*`、`manual-validation*`（包括 `manual-validation.md`）。模型据此生成 reviewer 摘要正文，至少包含：
+只使用返回的 canonical latest `plan*`、`review-plan*`、`code*`、`review-code*`、`manual-validation*`（包括 `manual-validation.md`）。模型生成 PR 专属 JSON payload：`overview:string`、`tests:{state,detail}`、`review:{state,detail}`、`manualValidation:{state,detail}`、`humanDecisions:{open,resolved,detail}`、`risks:string`。说明字段为非空字符串，计数为非负整数；结构校验不评价内容语义。body file 只包含这些语义字段；不要写入 Markdown envelope、控制 marker 或 canonical report placeholder。core 负责渲染章节并插入 placeholder、summary marker 和权威 HEAD。
 
-- 变更摘要与实现范围
-- 测试结果
-- 审查历程与当前结论
-- 人工校验三态：`### ⚠️ 需人工校验`、`### ✅ 人工验证已通过` 或 `### ✅ 无需人工校验`
-- 变更摘要、实现范围、测试结果、审查历程和人工校验三态
-- 一个 `<!-- canonical-pr-change-report -->` 占位符；`### PR 代码增减` 由 core renderer 基于权威 diff 生成，调用方不自行写标题或统计
+测试尚未启动用 `not-started`/`pending`，暂无远端 Review 用 `none`/`not-observed`/`not-published`，待人工校验用 `pending`，不得渲染为通过或零值。决策计数来自当前任务账本。renderer 固定生成完整章节并加入一个 canonical 报告占位符；代码增减仍由现有 report renderer 输出。
 
 保留人工校验项时，每条写明校验内容、定位和只能人工完成的原因。
 
+例如可见状态包括 `required`、`pending`、`passed`、`none`/`not-required` 和 `not-observed`；这些是示例而非穷举。renderer 也接受 `unavailable` 及其他非空状态，并按现有 fallback 渲染。英文标题是文档标签；当前 renderer 输出下列中文标题：`required` 使用 `### ⚠️ 需人工校验` 并保留每项内容、定位和原因；`pending` 使用 `### ⏳ 人工验证待收尾`；`passed` 使用 `### ✅ 人工验证已通过`，但仅允许 `complete-manual-validation` 的 final coordinator 写入有效 receipt 后发布，并保留绑定 transaction、receipt、evidence 和当前 PR head 的凭据标记；不得根据摘要文字或其他状态推断通过。`none`/`not-required` 仅在无需人工校验时使用 `### ✅ 无需人工校验`，不附加通过凭据；`not-observed` 使用 `### ℹ️ 尚未读取人工校验状态`。
+
 core 最终包装出的 canonical 评论结构为：
 
 ```markdown
@@ -54,7 +51,7 @@ precheck 必须覆盖六项固定检查并提供文件证据；`formalReview`
 
 ## 发布
 
-把聚合后的纯正文写入 `{summary-body-file}`，不要自行添加 marker 或 commit SHA：
+把聚合后的 JSON payload 写入 `{summary-body-file}`，不要自行添加 marker 或 commit SHA：
 
 ```bash
 agent-infra-internal platform-pr summary-sync {task-id} \
@@ -63,7 +60,7 @@ agent-infra-internal platform-pr summary-sync {task-id} \
   --result {primary-result}
 ```
 
-正文必须恰好包含一次 `<!-- canonical-pr-change-report -->`，不得自行拼接报告标题/JSON、marker 或 last-commit。core 会重新校验任务意图 digest、绑定 PR identity、完整 patch SHA 和机械统计，由 renderer 生成报告段，再包装唯一 `<!-- sync-pr:{task-id}:summary -->` 和权威 `<!-- last-commit: ... -->`，分页查找 PR 普通评论：不存在则创建、正文变化则原地更新、无差异则 no-op、重复 marker 或报告失配则稳定失败。正文通过文件输入，调用方不得拼 shell/heredoc。
+core 校验结构后插入报告占位符，重新校验任务意图 digest、PR identity、完整 patch SHA 和机械统计，生成报告段，再包装 marker 与权威 HEAD。发布后使用 `comments.list` 回读并要求唯一 marker 和正文完全匹配；不符或读取失败沿用现有 coordinator/recovery。payload 通过文件输入，调用方不得拼 shell/heredoc。
 
 ## 结果回传
 

package/templates/.agents/rules/task-management.en.md

@@ -27,7 +27,7 @@ Map user intent to the corresponding workflow command:
 - Long-name mapping (normalized to the short token before writing): `claude-code` -> `claude`, `antigravity-cli` -> `antigravity`
 - Manual-step exception: no matter which agent is used, a human-made decision is always declared as `human`
 
-The seven internal commands (`task-event` / `task-lifecycle` / `task-finalization` / `platform-issue` / `platform-comment` / `platform-pr` / `task-orchestration`) hard-validate `--agent` against a whitelist: they accept a short token, a long name, or `human`, and reject non-standard values with the matching `*_PAYLOAD_INVALID` error; long names are normalized to the short token before being persisted or forwarded. The `ai task log` renderer keeps unknown tokens grouped as `human` but appends a visible `(unknown)` marker.
+The six internal commands (`task-event` / `task-lifecycle` / `task-finalization` / `platform-issue` / `platform-comment` / `platform-pr`) hard-validate `--agent` against a whitelist: they accept a short token, a long name, or `human`, and reject non-standard values with the matching `*_PAYLOAD_INVALID` error; long names are normalized to the short token before being persisted or forwarded. The `ai task log` renderer keeps unknown tokens grouped as `human` but appends a visible `(unknown)` marker.
 
 ## State Snapshot and Completion Verification Entrypoints
 
@@ -71,7 +71,7 @@ Other skills continue past deferrable writes according to their local delivery g
 
 `analyze-task`, `review-analysis`, `plan-task`, `review-plan`, `code-task`, and `review-code` must declare business events through `agent-infra-internal task-event`. The event core generates `current_step`, `assigned_to`, `updated_at`, `agent_infra_version`, and the log text below. Other lifecycle skills not yet migrated continue to follow this textual protocol.
 
-> This section is authoritative for skills, the renderer, and typed verification checks.
+> This section defines log formatting. Structured facts govern business state; when the log cannot be appended safely, preserve the business result and report a diagnostic.
 
 **Line grammar is unchanged** and shared by the log renderer and verification activity parser.
 
@@ -79,7 +79,7 @@ Other skills continue past deferrable writes according to their local delivery g
   `- {time} — **{base} [started]** by {agent} — started`
 - **done line** (written when the step completes, unchanged from today): the action is the base itself:
   `- {time} — **{base}** by {agent} — {completion summary}`
-- **Commit execution boundary**: the commit skill must not hand-write task Activity Log, review anchors, receipts, or checkpoints. Task-bound direct and orchestrated modes both call the single `commit-operation.execute`; taskless direct is allowed only for `TASK_CONTEXT_NOT_FOUND` and creates no task-state side effects.
+- **Commit execution boundary**: the commit skill must not hand-write task Activity Log, review anchors, receipts, or checkpoints. Commit core uses direct execution; task-bound callers select local checkpoint or push delivery. Taskless direct is allowed only for `TASK_CONTEXT_NOT_FOUND` and creates no task-state side effects.
 - `{base}` is that skill's existing done action text, including `(Round {N})` (e.g. `Plan Task (Round 1)`). started and done must share the same `{base}` to pair.
 
 **Pairing and rendering** (`ai task log`): a started entry pairs with the next same-`{base}` done entry onto one row (repeated executions of the same base pair FIFO by ascending time). The STARTED column shows the start time, DONE the completion time; started with no done = in progress (DONE shows `(in progress)`); done with no started (legacy logs) = a standalone completed row. All three shapes are valid and never error.

package/templates/.agents/rules/task-management.zh-CN.md

@@ -27,7 +27,7 @@
 - 长名映射（写入前归一化为短名）：`claude-code` → `claude`、`antigravity-cli` → `antigravity`
 - 人工步骤例外：无论使用哪个 Agent，只要是人做的决定，统一声明 `human`
 
-七个内部命令（`task-event` / `task-lifecycle` / `task-finalization` / `platform-issue` / `platform-comment` / `platform-pr` / `task-orchestration`）对 `--agent` 做白名单硬校验：接受短名、长名或 `human`，非标准值返回对应 `*_PAYLOAD_INVALID` 错误；长名在落库/透传前归一化为短名。渲染端 `ai task log` 对无法识别的 token 保留 `human` 归类并附加 `(unknown)` 标记。
+六个内部命令（`task-event` / `task-lifecycle` / `task-finalization` / `platform-issue` / `platform-comment` / `platform-pr`）对 `--agent` 做白名单硬校验：接受短名、长名或 `human`，非标准值返回对应 `*_PAYLOAD_INVALID` 错误；长名在落库/透传前归一化为短名。渲染端 `ai task log` 对无法识别的 token 保留 `human` 归类并附加 `(unknown)` 标记。
 
 ## 状态快照与完成验证入口
 
@@ -71,7 +71,7 @@
 
 `analyze-task`、`review-analysis`、`plan-task`、`review-plan`、`code-task`、`review-code` 必须通过 `agent-infra-internal task-event` 声明业务事件；事件核心统一生成 `current_step`、`assigned_to`、`updated_at`、`agent_infra_version` 和下述日志文本。其余尚未迁移的生命周期 SKILL 继续遵循本节文本协议。
 
-> 本节是 started/done 双标记的唯一权威定义。各 SKILL、渲染器与 typed verification check 都以本节为准。
+> 本节定义日志行的格式。业务状态以结构化事实为准；日志不可安全追加时保留业务结果并报告诊断。
 
 **行语法不变**：started 与 done 都沿用既有条目语法
 `- {YYYY-MM-DD HH:mm:ss±HH:MM} — **{action}** by {agent} — {note}`，因此解析正则
@@ -81,7 +81,7 @@
   `- {time} — **{基名} [started]** by {agent} — started`
 - **done 行**（步骤完成时写，与现状一致）：action 即基名本身：
   `- {time} — **{基名}** by {agent} — {完成说明}`
-- **Commit 执行边界**：commit 技能不得手写 task Activity Log、review anchor、receipt 或 checkpoint。task-bound direct 与 orchestrated 都调用唯一 `commit-operation.execute`；taskless direct 只在 `TASK_CONTEXT_NOT_FOUND` 时允许，且不产生任务状态副作用。
+- **Commit 执行边界**：commit 技能不得手写 task Activity Log、review anchor、receipt 或 checkpoint。commit core 固定使用 direct execution；task-bound 调用方按 `local` checkpoint 或 `push` delivery 选择交付方式。taskless direct 只在 `TASK_CONTEXT_NOT_FOUND` 时允许，且不产生任务状态副作用。
 - `{基名}` 指该 SKILL 既有 done 条目的 action 文本，含 `(Round {N})`（如 `Plan Task (Round 1)`）。
   started 与 done 共用同一 `{基名}` 才能配对。
 

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

@@ -9,7 +9,7 @@ description: >
 # Analyze Task
 > `--agent` values are defined in `.agents/rules/task-management.md` under “Collaborator Token Specification”.
 
-If the entry operands contain `--orchestrated`, bind `{execution-flag}` to `--orchestrated` and forward it unchanged to the completed event; otherwise bind it to an empty value. Never infer it from `orchestration.json`, environment variables, or prior artifacts. Lifecycle events also require explicit trigger data: use `{trigger-initiator}=orchestrator` for orchestration and `model` otherwise; `{request-id}` is a stable single-line identifier for this task and artifact round, and `{reason-code}` is `user-request`, `new-requirement`, or `upstream-fact-doubt`. Reuse the same values for started and completed.
+Lifecycle events require explicit trigger data: ordinary skill invocation uses `model`; use `human` only when the user explicitly requests it. `{request-id}` is a stable single-line identifier for this task and artifact round, and `{reason-code}` use `user-request`, `new-requirement`, or `upstream-fact-doubt`. Reuse the same values for started and completed.
 
 ## Boundary / Critical Rules
 
@@ -119,7 +119,7 @@ Runs after Step 0 state check and Step 3 (questioning is an external-state actio
      - otherwise (no pending question) → pick the single highest-value question (acceptance criteria > scope > ambiguity) and write `## Brainstorming`: `status: asking`, `pending_question: <question>`, `question_count += 1`.
   2. If `start_date` is empty, write today (`date +%F`), then run `agent-infra-internal task-event {task-id} analyze.awaiting-input --agent {standard-agent-token} --question {question_count}` so the core updates base metadata and Activity Log.
   3. Issue sync (when a valid `platform_issue_identity` exists, skip on any failure): run `agent-infra-internal platform-comment sync {task-id} --kind task --agent {standard-agent-token}` to update only the **task comment**; keep the `status` label at `pending-design-work`; do **not** publish an analysis artifact comment.
-  4. Verification (replaces the step 8 artifact gate): `agent-infra-internal task-verify {task-id} analyze.awaiting-input --format text` (the early-exit set `current_step: requirement-analysis` and wrote `start_date`, so it should pass); also keep `rg -n 'Analyze Task \(Brainstorming\)' <task-workspace>/active/{task-id}/task.md` and the task-comment sync evidence. Do **not** run the artifact gate, nor `check activity-log` / `check platform-sync` (both bind to the analysis artifact path).
+  4. Verification (replaces the step 8 artifact gate): `agent-infra-internal task-verify {task-id} analyze.awaiting-input --format text` (the early-exit set `current_step: requirement-analysis` and wrote `start_date`, so it should pass); also retain any log diagnostic from the event result and the task-comment sync evidence. Do **not** run the artifact gate, nor `check activity-log` / `check platform-sync` (both bind to the analysis artifact path).
   5. User output: show only the current **single question** plus how to answer/continue (re-trigger `analyze-task {task-ref}` with the answer).
   6. **STOP** and wait for the answer. The next trigger returns to this step.
 
@@ -239,7 +239,7 @@ agent-infra-internal task-artifact {task-id} finalize-local --family analysis --
 - On `status=failed`, correct the formal artifact directly and rerun the finalizer completely; if the current diagnostic remains unresolved, continue to the next attempt.
 - On an external formal-artifact change, an unsafe repair, repeated diagnostics or fingerprints, no progress, or the shared edit limit, stop without publishing a completed event.
 
-Use the digests from that same `status=passed` result in `agent-infra-internal task-event {task-id} analyze.completed --agent {standard-agent-token} --initiator {trigger-initiator} --request-id {request-id} --reason-code {reason-code} --artifact {analysis-artifact} --artifact-sha256 {artifact-sha256} --semantic-digest {semantic-digest} {execution-flag}` so the core records the link, stage, agent, metadata, and Activity Log atomically.
+Use the digests from that same `status=passed` result in `agent-infra-internal task-event {task-id} analyze.completed --agent {standard-agent-token} --initiator {trigger-initiator} --request-id {request-id} --reason-code {reason-code} --artifact {analysis-artifact} --artifact-sha256 {artifact-sha256} --semantic-digest {semantic-digest}` so the core records the link, stage, agent, metadata, and Activity Log atomically.
   - {YYYY-MM-DD HH:mm:ss±HH:MM} — **Analyze Task (Round {N})** by {agent} — Analysis completed → {analysis-artifact}
   ```
 

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

@@ -9,7 +9,7 @@ description: >
 # 分析任务
 > `--agent` 取值见 `.agents/rules/task-management.md`「合作者 token 规范」。
 
-若入口业务操作数包含 `--orchestrated`，绑定 `{execution-flag}` = `--orchestrated` 并原样转发给 completed 事件；否则绑定为空。不得从 `orchestration.json`、环境变量或历史产物推断该标记。生命周期事件还必须携带显式触发信息：编排调用使用 `{trigger-initiator}=orchestrator`，否则使用 `model`；`{request-id}` 是本任务与本轮产物的稳定单行标识，`{reason-code}` 使用 `user-request`、`new-requirement` 或 `upstream-fact-doubt`；started 与 completed 使用同一组值。
+生命周期事件必须携带显式触发信息：普通技能调用使用 `model`；仅用户明确要求时使用 `human`。`{request-id}` 是本任务与本轮产物的稳定单行标识，`{reason-code}` 使用 `user-request`、`new-requirement` 或 `upstream-fact-doubt`；started 与 completed 使用同一组值。
 
 ## 行为边界 / 关键规则
 
@@ -122,7 +122,7 @@ agent-infra-internal task-event {task-id} analyze.started --agent {standard-agen
      - 否则（无待答问题）→ 选最高价值的一个问题（验收标准 > 范围 > 歧义），写入 `## Brainstorming`：`status: asking`、`pending_question: <问题>`、`question_count += 1`。
   2. 若 `start_date` 为空，写入当日日期（`date +%F`）；随后执行 `agent-infra-internal task-event {task-id} analyze.awaiting-input --agent {standard-agent-token} --question {question_count}`，由核心统一更新基础 frontmatter 和 Activity Log。
   3. Issue 同步（存在有效 `platform_issue_identity` 时，任一失败跳过）：调用 `agent-infra-internal platform-comment sync {task-id} --kind task --agent {standard-agent-token}` 更新 **task 评论**；`status` label 维持 `pending-design-work`；**不**发布分析产物评论。
-  4. 校验（替代步骤 8 的 artifact gate）：`agent-infra-internal task-verify {task-id} analyze.awaiting-input --format text`（早退已置 `current_step: requirement-analysis` 且已写入 `start_date`，预期通过）；并保留 `rg -n 'Analyze Task \(Brainstorming\)' <task-workspace>/active/{task-id}/task.md` 与 task 评论同步证据。**不**跑 artifact gate，也不跑 `check activity-log` / `check platform-sync`（二者绑定分析产物路径）。
+  4. 校验（替代步骤 8 的 artifact gate）：`agent-infra-internal task-verify {task-id} analyze.awaiting-input --format text`（早退已置 `current_step: requirement-analysis` 且已写入 `start_date`，预期通过）；并保留事件结果中的日志诊断（如有）与 task 评论同步证据。**不**跑 artifact gate，也不跑 `check activity-log` / `check platform-sync`（二者绑定分析产物路径）。
   5. 用户输出：只展示当前**单个问题** + 如何回答/继续（再次触发 `analyze-task {task-ref}` 并附答案）。
   6. **STOP**，等待回答。下一次触发回到本步骤。
 
@@ -241,7 +241,7 @@ agent-infra-internal task-artifact {task-id} init --family analysis --artifact {
   - `status=passed`：保存本次返回的 `artifactSha256` 和 `semanticDigest`；finalizer 已记录对应的一次性本地 provenance intent。
   - `status=failed`：直接修正正式产物并完整重跑 finalizer；若仍失败且诊断未解决，继续下一轮。
   - 当前正式产物发生外部变化、无法安全修复、诊断或指纹重复、无进展，或达到共享规则的编辑上限时停止，不发布 completed 事件。
-- 使用同一次 `status=passed` 返回的摘要执行 `agent-infra-internal task-event {task-id} analyze.completed --agent {standard-agent-token} --initiator {trigger-initiator} --request-id {request-id} --reason-code {reason-code} --artifact {analysis-artifact} --artifact-sha256 {artifact-sha256} --semantic-digest {semantic-digest} {execution-flag}`，由核心登记链接、阶段、代理、时间、版本和 Activity Log。
+- 使用同一次 `status=passed` 返回的摘要执行 `agent-infra-internal task-event {task-id} analyze.completed --agent {standard-agent-token} --initiator {trigger-initiator} --request-id {request-id} --reason-code {reason-code} --artifact {analysis-artifact} --artifact-sha256 {artifact-sha256} --semantic-digest {semantic-digest}`，由核心登记链接、阶段、代理、时间、版本和 Activity Log。
 
 如果 task.md 中存在有效的 `platform_issue_identity`，执行以下同步操作（任一失败则跳过并继续）：
 - 调用 `agent-infra-internal platform-issue sync {task-id} --agent {standard-agent-token} --status pending-design-work --fields`

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

@@ -80,10 +80,10 @@ Check whether `task.md` contains a valid `platform_issue_identity`. If not, skip
 
 If a valid `platform_issue_identity` exists, require `applied` / `no-op` without an error for every operation before declaring cancellation fully complete. On failure, retain the local terminal state and recovery record, then retry this skill for the same task after repair:
 - Run `agent-infra-internal platform-issue sync {task-id} --agent {standard-agent-token} --status {reason} --in-labels none --assignees none --milestone none --state closed --close-reason not_planned`
-- Write the cancellation body to a temporary file and run `agent-infra-internal platform-comment sync {task-id} --kind cancel --body-file {path} --agent {standard-agent-token}`
+- Write the cancellation comment JSON payload to a temporary file and run `agent-infra-internal platform-comment sync {task-id} --kind cancel --body-file {path} --agent {standard-agent-token}`
 - Run `agent-infra-internal platform-comment sync {task-id} --kind task --agent {standard-agent-token}`
 
-The cancellation comment must include at least:
+The cancellation comment JSON fields are `taskId`, `title`, `outcome:"cancelled"`, `reason`, `cancelledAt`, and `lastCompletedArtifact`. `taskId` must match the current task; the core fills missing values from the task.md title, cancellation reason/time metadata, and artifact registry (`lastCompletedArtifact` is `null` when no completed artifact exists), then renders the comment body. It must include at least:
 - the cancellation reason
 - the selected `status:` label
 

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

@@ -79,10 +79,10 @@ ls <task-workspace>/completed/{task-id}/task.md
 
 如果存在有效的 `platform_issue_identity`，以下操作均须取得 `applied` / `no-op` 且无错误后才能宣称取消全部完成；失败时保留本地终态和待恢复记录，修复后以同一任务重试本技能：
 - 调用 `agent-infra-internal platform-issue sync {task-id} --agent {standard-agent-token} --status {reason} --in-labels none --assignees none --milestone none --state closed --close-reason not_planned`
-- 将取消正文写入临时文件，调用 `agent-infra-internal platform-comment sync {task-id} --kind cancel --body-file {path} --agent {standard-agent-token}`
+- 将取消评论 JSON payload 写入临时文件，调用 `agent-infra-internal platform-comment sync {task-id} --kind cancel --body-file {path} --agent {standard-agent-token}`
 - 调用 `agent-infra-internal platform-comment sync {task-id} --kind task --agent {standard-agent-token}`
 
-取消评论至少包含：
+取消评论 JSON 字段为 `taskId`、`title`、`outcome:"cancelled"`、`reason`、`cancelledAt`、`lastCompletedArtifact`。`taskId` 必须匹配当前任务；core 从 task.md 标题、取消原因/时间元数据和 artifact registry 补齐缺省值，无已完成产物时 `lastCompletedArtifact` 为 `null`，然后渲染评论正文。取消评论至少包含：
 - 取消原因
 - 选定的 `status:` label
 

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

@@ -9,7 +9,7 @@ description: >
 # Code Task
 > `--agent` values are defined in `.agents/rules/task-management.md` under “Collaborator Token Specification”.
 
-If the entry operands contain `--orchestrated`, bind `{execution-flag}` to `--orchestrated` and forward it unchanged to the completed event; otherwise bind it to an empty value. Never infer it from `orchestration.json`, environment variables, or prior artifacts. Lifecycle events also require explicit trigger data: use `{trigger-initiator}=orchestrator` for orchestration and `model` otherwise; `{request-id}` is a stable single-line identifier for this task and artifact round, and `{reason-code}` is `user-request` for initial work and `review-finding` for fixes or decisions. Reuse the same values for started and completed.
+Lifecycle events require explicit trigger data: ordinary skill invocation uses `model`; use `human` only when the user explicitly requests it. `{request-id}` is a stable single-line identifier for this task and artifact round, and `{reason-code}` use `user-request` for initial work and `review-finding` for fixes or decisions. Reuse the same values for started and completed.
 
 Implement from the input selected by the lifecycle path and produce `code.md` or `code-r{N}.md`. This skill supports initial implementation, fix mode based on `review-code` feedback, and human-decision-driven implementation.
 
@@ -168,7 +168,7 @@ Do not rescan or manually write digest data; the completion event must include `
 
 ### 11. Update Task Status
 
-After requirement checkboxes are updated, run the initial event `agent-infra-internal task-event {task-id} code.completed --agent {standard-agent-token} --initiator {trigger-initiator} --request-id {request-id} --reason-code {reason-code} --artifact {code-artifact} --artifact-sha256 {artifact-sha256} --semantic-digest {semantic-digest} --files-modified {n} --tests-passed {n} {execution-flag}`; in fix mode add `--fix-for {review-artifact} --blockers {n} --major {n} --minor {n} --manual-validation {n} {execution-flag}` instead; in decision mode add `--implementation-input {input-id}` to the initial counts. The core atomically records the artifact link, stage, metadata, done log, and decision-input consumption.
+After requirement checkboxes are updated, run the initial event `agent-infra-internal task-event {task-id} code.completed --agent {standard-agent-token} --initiator {trigger-initiator} --request-id {request-id} --reason-code {reason-code} --artifact {code-artifact} --artifact-sha256 {artifact-sha256} --semantic-digest {semantic-digest} --files-modified {n} --tests-passed {n}`; in fix mode add `--fix-for {review-artifact} --blockers {n} --major {n} --minor {n} --manual-validation {n}` instead; in decision mode add `--implementation-input {input-id}` to the initial counts. The core atomically records the artifact link, stage, metadata, done log, and decision-input consumption.
 
 If task.md has a valid `platform_issue_identity`, read `.agents/rules/issue-sync.md`, then run these syncs. Record failures as warnings and continue the local workflow:
 - Run `agent-infra-internal platform-issue sync {task-id} --agent {standard-agent-token} --status in-progress`

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

@@ -9,7 +9,7 @@ description: >
 # 编码任务
 > `--agent` 取值见 `.agents/rules/task-management.md`「合作者 token 规范」。
 
-若入口业务操作数包含 `--orchestrated`，绑定 `{execution-flag}` = `--orchestrated` 并原样转发给 completed 事件；否则绑定为空。不得从 `orchestration.json`、环境变量或历史产物推断该标记。生命周期事件还必须携带显式触发信息：编排调用使用 `{trigger-initiator}=orchestrator`，否则使用 `model`；`{request-id}` 是本任务与本轮产物的稳定单行标识，`{reason-code}` 初次实现使用 `user-request`，修复或裁决使用 `review-finding`；started 与 completed 使用同一组值。
+生命周期事件必须携带显式触发信息：普通技能调用使用 `model`；仅用户明确要求时使用 `human`。`{request-id}` 是本任务与本轮产物的稳定单行标识，`{reason-code}` 初次实现使用 `user-request`，修复或裁决使用 `review-finding`；started 与 completed 使用同一组值。
 
 根据所选生命周期路径的实现输入编码任务，并产出 `code.md` 或 `code-r{N}.md`。本技能支持初次实现、基于 `review-code` 反馈的修复，以及人工裁决驱动实现三种模式。
 
@@ -211,9 +211,9 @@ echo "$finalizer"
 - 审查 `## 需求` 段落，仅把本轮已由代码实现且有测试通过支撑的条目从 `- [ ]` 勾为 `- [x]`
 - 产物链接、阶段与完成日志由 completed 事件统一登记
 - 完成业务内容更新后声明完成事件：
-  - 初次实现：`agent-infra-internal task-event {task-id} code.completed --agent {standard-agent-token} --initiator {trigger-initiator} --request-id {request-id} --reason-code {reason-code} --artifact {code-artifact} --artifact-sha256 {artifact-sha256} --semantic-digest {semantic-digest} --files-modified {n} --tests-passed {n} {execution-flag}`
-  - 修复模式：`agent-infra-internal task-event {task-id} code.completed --agent {standard-agent-token} --initiator {trigger-initiator} --request-id {request-id} --reason-code {reason-code} --artifact {code-artifact} --artifact-sha256 {artifact-sha256} --semantic-digest {semantic-digest} --fix-for {review-artifact} --blockers {n} --major {n} --minor {n} --manual-validation {n} {execution-flag}`
-  - 裁决模式：`agent-infra-internal task-event {task-id} code.completed --agent {standard-agent-token} --initiator {trigger-initiator} --request-id {request-id} --reason-code {reason-code} --artifact {code-artifact} --artifact-sha256 {artifact-sha256} --semantic-digest {semantic-digest} --implementation-input {input-id} --files-modified {n} --tests-passed {n} {execution-flag}`
+  - 初次实现：`agent-infra-internal task-event {task-id} code.completed --agent {standard-agent-token} --initiator {trigger-initiator} --request-id {request-id} --reason-code {reason-code} --artifact {code-artifact} --artifact-sha256 {artifact-sha256} --semantic-digest {semantic-digest} --files-modified {n} --tests-passed {n}`
+  - 修复模式：`agent-infra-internal task-event {task-id} code.completed --agent {standard-agent-token} --initiator {trigger-initiator} --request-id {request-id} --reason-code {reason-code} --artifact {code-artifact} --artifact-sha256 {artifact-sha256} --semantic-digest {semantic-digest} --fix-for {review-artifact} --blockers {n} --major {n} --minor {n} --manual-validation {n}`
+  - 裁决模式：`agent-infra-internal task-event {task-id} code.completed --agent {standard-agent-token} --initiator {trigger-initiator} --request-id {request-id} --reason-code {reason-code} --artifact {code-artifact} --artifact-sha256 {artifact-sha256} --semantic-digest {semantic-digest} --implementation-input {input-id} --files-modified {n} --tests-passed {n}`
 
 如果 task.md 中存在有效的 `platform_issue_identity`，执行以下同步操作（失败按规则记录 warning，继续本地流程；边界见 `.agents/rules/issue-sync.md`）：
 - 调用 `agent-infra-internal platform-issue sync {task-id} --agent {standard-agent-token} --status in-progress`

package/templates/.agents/skills/commit/SKILL.en.md

@@ -19,9 +19,9 @@ The entry point may omit the task ref; explicit task scope accepts only `--task
 
 - An explicit task-resolution failure stops the operation.
 - Without an explicit task scope, only `TASK_CONTEXT_NOT_FOUND` may enter taskless direct mode; detached HEAD, malformed candidates, and multiple matches fail closed.
-- If the literal `--orchestrated` is present in the business operands, fail with `ORCHESTRATED_COMMIT_REMOVED` because the standalone commit stage has been removed; otherwise use `mode=direct`. Never infer the mode from files or environment.
+- Execution mode is always `direct`; the caller selects delivery with `delivery=local|push`.
 - Taskless direct mode does not read, create, or complete task intent, receipt, checkpoint, or task.md records.
-- Task-bound direct mode does not require a delegation receipt; `code-task` calls the shared core for local checkpoints, while standalone `commit` continues to use push delivery.
+- `code-task` creates `delivery=local` checkpoints through the shared core; standalone `commit` uses `delivery=push`.
 - After resolution, use only the core-returned `taskId`; never infer task identity from the environment, branch, or filename.
 
 ## 1. Inspect local changes

package/templates/.agents/skills/commit/SKILL.zh-CN.md

@@ -19,9 +19,9 @@ commit core 只返回一个主结果：`committed`、`no_op`、`committed_with_w
 
 - 显式 task scope 解析失败时停止。
 - 未显式指定 task scope 时，只有 `TASK_CONTEXT_NOT_FOUND` 可进入 taskless direct；detached HEAD、损坏候选或多匹配必须 fail closed。
-- 入口业务操作数包含字面 `--orchestrated` 时直接失败并返回 `ORCHESTRATED_COMMIT_REMOVED`；普通入口使用 `mode=direct`，不得从 run 文件或环境推断模式。
+- 执行模式固定为 `direct`；调用方通过 `delivery=local|push` 指定交付方式。
 - taskless direct 不读取、创建或完成 task intent、receipt、checkpoint 或 task.md 收尾记录。
-- task-bound direct 不要求 delegation receipt；local checkpoint 由 `code-task` 直接调用共享 core，独立 `commit` 继续使用 push delivery。
+- `code-task` 通过共享 core 创建 `delivery=local` checkpoint；独立 `commit` 使用 `delivery=push`。
 - 解析成功后只使用 core 返回的 `taskId`；不得从环境、分支或文件名猜测任务身份。
 
 ## 1. 检查本地修改

package/templates/.agents/skills/commit/reference/commit-orchestration.en.md

@@ -1,15 +1,15 @@
 # Commit core boundary
 
-Commit, push, result mapping, and task finalization use one `commit-operation.execute`. The entry point only resolves task scope, explicit agent, and the literal `--orchestrated`; it never infers the source from state files.
+Commit, push, result mapping, and task finalization use one `commit-operation.execute`. The entry point resolves task scope, explicit agent, and call arguments. Execution mode is always `direct`; the caller explicitly selects delivery mode `local` or `push`.
 
-## Entry modes
+## Entry contract
 
-- `mode=direct`: explicit user invocation is the authorization. Task-bound direct may read task facts but does not require a delegation receipt; taskless direct is allowed only for `TASK_CONTEXT_NOT_FOUND` and skips task facts, review, checkpoint, and task.md finalization.
-- `mode=orchestrated` is removed: standalone commit is no longer a lifecycle delegation stage. This mode returns `ORCHESTRATED_COMMIT_REMOVED` without writing Git; the code stage closes through a local checkpoint.
+- Task-bound direct may read task facts. Taskless direct is allowed only for `TASK_CONTEXT_NOT_FOUND` and skips task facts, review, checkpoint, and task.md finalization.
+- `code-task` creates a local checkpoint through the shared core with `delivery=local`; standalone `commit` uses `delivery=push`. Both share the same validation and commit order.
 
 ## Shared order
 
-1. Direct commits execute serially at the caller boundary.
+1. Execute serially according to caller semantics.
 2. Validate the repository, current branch, explicit paths, sensitive paths, staged scope, expected HEAD/tree, remote, and full heads ref.
 3. Validate direct-mode authorization.
 4. Create at most one local commit; with no changes, allow push-only and never create an empty commit.
@@ -18,4 +18,4 @@ Commit, push, result mapping, and task finalization use one `commit-operation.ex
 
 ## Retry boundary
 
-Retries reread current HEAD, worktree, branch, and remote facts. A local commit that already exists is push-only and cannot produce a second commit. Taskless retries create no task record. Orchestration owns stage completion, sealing, and consumption of receipts; direct commits never fabricate them.
+Retries reread current HEAD, worktree, branch, and remote facts. A local commit that already exists is push-only and cannot produce a second commit. Taskless retries create no task record.

package/templates/.agents/skills/commit/reference/commit-orchestration.zh-CN.md

@@ -1,15 +1,15 @@
 # Commit Core 边界
 
-commit、push、结果映射和任务收尾使用同一个 `commit-operation.execute`。入口只负责解析 task scope、显式 agent 和字面 `--orchestrated`，不得从状态文件推断执行来源。
+commit、push、结果映射和任务收尾使用同一个 `commit-operation.execute`。入口解析 task scope、显式 agent 与调用参数；执行模式固定为 `direct`，交付模式由调用方明确指定为 `local` 或 `push`。
 
-## 入口模式
+## 入口契约
 
-- `mode=direct`：用户显式调用授权。task-bound direct 可读取 task facts，但不要求 delegation receipt；taskless direct 只在 `TASK_CONTEXT_NOT_FOUND` 时允许，并跳过 task facts、review、checkpoint 和 task.md 收尾。
-- `mode=orchestrated` 已移除：独立 commit 不再是生命周期 delegation stage；调用该模式返回 `ORCHESTRATED_COMMIT_REMOVED`，不写 Git。生命周期 code 阶段完成后由 local checkpoint 直接收口。
+- task-bound direct 可读取任务事实；taskless direct 只在 `TASK_CONTEXT_NOT_FOUND` 时允许，并跳过 task facts、review、checkpoint 和 task.md 收尾。
+- 本地 checkpoint 由 `code-task` 通过共享 core 以 `delivery=local` 执行；独立 `commit` 使用 `delivery=push`。两者共享同一校验与提交顺序。
 
 ## 共享执行顺序
 
-1. direct commit 按调用方串行执行。
+1. 按调用方语义串行执行。
 2. 验证 repository、当前 branch、明确 paths、敏感路径、staged scope、expected HEAD/tree、remote 和 full heads ref。
 3. 完成 direct 模式授权校验。
 4. 最多创建一个本地 commit；无修改时只允许 push-only，不创建空 commit。
@@ -18,4 +18,4 @@ commit、push、结果映射和任务收尾使用同一个 `commit-operation.exe
 
 ## 重试边界
 
-重跑重新读取当前 HEAD、worktree、branch 和 remote 事实。已有本地 commit 时只补 push，不创建第二个 commit；taskless 重跑不创建任何任务记录。生命周期 receipt 的 stage completion、seal 和 consume 由 orchestration core 负责；direct commit 不伪造生命周期 receipt。
+重跑重新读取当前 HEAD、worktree、branch 和 remote 事实。已有本地 commit 时只补 push，不创建第二个 commit；taskless 重跑不创建任何任务记录。

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

@@ -3,7 +3,7 @@
 Run only when `{task-id}` is valid and task.md has a `bound/verified` `pr_delivery_fact`.
 
 1. Run `agent-infra-internal platform-pr summary-context {task-id}` to obtain canonical inputs and report status; rebuild a stale/missing sidecar through the `change-report` flow for the current head.
-2. Generate the plain summary body per `.agents/rules/pr-sync.md`, with exactly one `<!-- canonical-pr-change-report -->` placeholder, and write it to a temporary file.
+2. Generate the complete PR summary JSON payload per `.agents/rules/pr-sync.md` and write it to a temporary file.
 3. Run `agent-infra-internal platform-pr summary-sync {task-id} --agent {standard-agent-token} --body-file {summary-body-file} --change-report-file <task-workspace>/active/{task-id}/pr-change-report.json --result no_op`. The commit path only synchronizes an existing PR summary and neither creates nor reuses a PR, so `no_op` explicitly represents the unchanged PR identity.
 
 Failure records a warning but never blocks or rolls back the completed commit. `no-op` maps to `summary skipped (no diff)`.