@fitlab-ai/agent-infra 0.12.1 → 0.12.2

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`. 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. 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 renderer supplies fixed sections and the canonical report placeholder. The core validates the task-intent digest, bound PR identity, complete patch SHA, and mechanical totals before rendering the report, then owns markers, HEAD metadata, and create/update/no-op behavior.
+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:
 

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

@@ -18,7 +18,7 @@ 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`）。模型生成 PR 专属 JSON payload：`overview:string`、`tests:{state,detail}`、`review:{state,detail}`、`manualValidation:{state,detail}`、`humanDecisions:{open,resolved,detail}`、`risks:string`。说明字段为非空字符串，计数为非负整数；结构校验不评价内容语义。
+只使用返回的 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。
 
 测试尚未启动用 `not-started`/`pending`，暂无远端 Review 用 `none`/`not-observed`/`not-published`，待人工校验用 `pending`，不得渲染为通过或零值。决策计数来自当前任务账本。renderer 固定生成完整章节并加入一个 canonical 报告占位符；代码增减仍由现有 report renderer 输出。
 

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 JSON fields are `taskId`, `title`, `outcome:"cancelled"`, `reason`, `cancelledAt`, and `lastCompletedArtifact`, sourced from task identity, task.md, the recorded cancellation reason/time, and the current artifact registry (`null` when no completed artifact exists). It 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`，值来自任务身份、task.md、已记录取消原因与时间和当前 artifact registry；无已完成产物时用 `null`。取消评论至少包含：
+取消评论 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/plan-task/SKILL.en.md

@@ -9,7 +9,7 @@ description: >
 # Design Technical Plan
 > `--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
 
@@ -145,7 +145,7 @@ agent-infra-internal task-artifact {task-id} finalize-local --family plan --arti
 - 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} plan.completed --agent {standard-agent-token} --initiator {trigger-initiator} --request-id {request-id} --reason-code {reason-code} --artifact {plan-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} plan.completed --agent {standard-agent-token} --initiator {trigger-initiator} --request-id {request-id} --reason-code {reason-code} --artifact {plan-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} — **Plan Task (Round {N})** by {agent} — Plan completed, awaiting human review → {artifact-filename}
   ```
 

package/templates/.agents/skills/plan-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 使用同一组值。
 
 ## 行为边界 / 关键规则
 
@@ -143,7 +143,7 @@ agent-infra-internal task-artifact {task-id} init --family plan --artifact {plan
   - `status=passed`：保存本次返回的 `artifactSha256` 和 `semanticDigest`；finalizer 已记录对应的一次性本地 provenance intent。
   - `status=failed`：直接修正正式产物并完整重跑 finalizer；若仍失败且诊断未解决，继续下一轮。
   - 当前正式产物发生外部变化、无法安全修复、诊断或指纹重复、无进展，或达到共享规则的编辑上限时停止，不发布 completed 事件。
-- 使用同一次 `status=passed` 返回的摘要执行 `agent-infra-internal task-event {task-id} plan.completed --agent {standard-agent-token} --initiator {trigger-initiator} --request-id {request-id} --reason-code {reason-code} --artifact {plan-artifact} --artifact-sha256 {artifact-sha256} --semantic-digest {semantic-digest} {execution-flag}`，由核心登记链接、阶段、代理、时间、版本和 Activity Log。
+- 使用同一次 `status=passed` 返回的摘要执行 `agent-infra-internal task-event {task-id} plan.completed --agent {standard-agent-token} --initiator {trigger-initiator} --request-id {request-id} --reason-code {reason-code} --artifact {plan-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/review-analysis/SKILL.en.md

@@ -9,7 +9,7 @@ description: >
 # Requirement Analysis Review
 > `--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 both the summary finalizer and 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` or `review-finding`. 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` or `review-finding`. Reuse the same values for started and completed.
 
 Review the latest analysis artifact and produce `review-analysis.md` or `review-analysis-r{N}.md`.
 
@@ -87,7 +87,7 @@ Create `<task-workspace>/active/{task-id}/{review-artifact}`.
 
 ### 6. Update Task Status
 
-After the report, call `agent-infra-internal task-review {task-id} preflight --stage analysis --artifact {review-artifact} {execution-flag}` before any ledger write. On failure, correct the formal artifact directly and rerun it. Only after preflight passes, submit each new finding with `agent-infra-internal task-ledger {task-id} finding-upsert --stage analysis --review-artifact {review-artifact} --ordinal {n} --severity {blocker|major|minor} --evidence {review-artifact}#{anchor}` or prior-response dispositions with `finding-review --id {ledger-id} --status {confirmed|closed|open|needs-human-decision} --evidence {evidence}`. Do not scan ids or edit ledger rows. After all ledger writes, call `agent-infra-internal task-review {task-id} finalize-summary --stage analysis --artifact {review-artifact} {execution-flag}`; never treat an error type or `changed=false` as automatic authorization.
+After the report, call `agent-infra-internal task-review {task-id} preflight --stage analysis --artifact {review-artifact}` before any ledger write. On failure, correct the formal artifact directly and rerun it. Only after preflight passes, submit each new finding with `agent-infra-internal task-ledger {task-id} finding-upsert --stage analysis --review-artifact {review-artifact} --ordinal {n} --severity {blocker|major|minor} --evidence {review-artifact}#{anchor}` or prior-response dispositions with `finding-review --id {ledger-id} --status {confirmed|closed|open|needs-human-decision} --evidence {evidence}`. Do not scan ids or edit ledger rows. After all ledger writes, call `agent-infra-internal task-review {task-id} finalize-summary --stage analysis --artifact {review-artifact}`; never treat an error type or `changed=false` as automatic authorization.
 
 Bind and reuse this structured mapping from that one response:
 
@@ -97,7 +97,7 @@ Bind and reuse this structured mapping from that one response:
 {unresolved-minor} = stageStatus.unresolvedFindingCounts.minor
 ```
 
-The intent atomically finalizes the report summary and returns the same ledger snapshot. Do not call `stage-status`, replace placeholders manually, or rescan the finding list. After a failure, the model may edit the same controlled artifact and rerun the same intent only when the shared rule's mechanical gates pass; reassess convergence after every failure. The final complete result determines the verdict and counts from that same snapshot: `stageStatus.canAdvance=true` with an Approved conclusion permits cross-stage advancement; `stageStatus.canAdvance=false` still requires `agent-infra-internal task-event {task-id} review-analysis.completed --agent {standard-agent-token} --initiator {trigger-initiator} --request-id {request-id} --reason-code {reason-code} --artifact {review-artifact} --verdict {approved|changes-requested|rejected} --blockers {unresolved-blockers} --major {unresolved-major} --minor {unresolved-minor} --manual-validation {n} {execution-flag}`, using `changes-requested` and routing to same-stage revision/review (use `rejected` when the report explicitly rejects). On failure, model stop, lack of progress, or the emergency cap, do not publish a completion event or cross-stage command; use the `repair-stop` scenario in `reference/output-templates.md` to show existing summary/findings, the artifact, actual repair attempts, the last diagnostic, and the stop reason.
+The intent atomically finalizes the report summary and returns the same ledger snapshot. Do not call `stage-status`, replace placeholders manually, or rescan the finding list. After a failure, the model may edit the same controlled artifact and rerun the same intent only when the shared rule's mechanical gates pass; reassess convergence after every failure. The final complete result determines the verdict and counts from that same snapshot: `stageStatus.canAdvance=true` with an Approved conclusion permits cross-stage advancement; `stageStatus.canAdvance=false` still requires `agent-infra-internal task-event {task-id} review-analysis.completed --agent {standard-agent-token} --initiator {trigger-initiator} --request-id {request-id} --reason-code {reason-code} --artifact {review-artifact} --verdict {approved|changes-requested|rejected} --blockers {unresolved-blockers} --major {unresolved-major} --minor {unresolved-minor} --manual-validation {n}`, using `changes-requested` and routing to same-stage revision/review (use `rejected` when the report explicitly rejects). On failure, model stop, lack of progress, or the emergency cap, do not publish a completion event or cross-stage command; use the `repair-stop` scenario in `reference/output-templates.md` to show existing summary/findings, the artifact, actual repair attempts, the last diagnostic, and the stop reason.
 
 `manual-validation` is the data source for the `Manual-validation` count folded into review rows in `ai task log`; do not add a parallel manual-verification field.
 

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

@@ -9,7 +9,7 @@ description: >
 # 需求分析审查
 > `--agent` 取值见 `.agents/rules/task-management.md`「合作者 token 规范」。
 
-若入口业务操作数包含 `--orchestrated`，绑定 `{execution-flag}` = `--orchestrated` 并原样转发给 summary finalizer 与 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 使用同一组值。
 
 审查最新需求分析产物，并产出 `review-analysis.md` 或 `review-analysis-r{N}.md`。
 
@@ -90,7 +90,7 @@ agent-infra-internal task-artifact {task-id} init --family review-analysis --art
 
 ### 6. 更新任务状态
 
-报告完成后，先调用 `agent-infra-internal task-review {task-id} preflight --stage analysis --artifact {review-artifact} {execution-flag}`，不得先写入账本。失败后直接修正正式产物并重跑；只有 preflight 通过后，才逐条调用 `agent-infra-internal task-ledger {task-id} finding-upsert --stage analysis --review-artifact {review-artifact} --ordinal {n} --severity {blocker|major|minor} --evidence {review-artifact}#{anchor}`，或复核上一轮响应时调用 `finding-review --id {ledger-id} --status {confirmed|closed|open|needs-human-decision} --evidence {相称证据}`。不得扫描编号或手写账本行。全部账本写入完成后调用 `agent-infra-internal task-review {task-id} finalize-summary --stage analysis --artifact {review-artifact} {execution-flag}`；不能把失败类型或 `changed=false` 当作自动授权。
+报告完成后，先调用 `agent-infra-internal task-review {task-id} preflight --stage analysis --artifact {review-artifact}`，不得先写入账本。失败后直接修正正式产物并重跑；只有 preflight 通过后，才逐条调用 `agent-infra-internal task-ledger {task-id} finding-upsert --stage analysis --review-artifact {review-artifact} --ordinal {n} --severity {blocker|major|minor} --evidence {review-artifact}#{anchor}`，或复核上一轮响应时调用 `finding-review --id {ledger-id} --status {confirmed|closed|open|needs-human-decision} --evidence {相称证据}`。不得扫描编号或手写账本行。全部账本写入完成后调用 `agent-infra-internal task-review {task-id} finalize-summary --stage analysis --artifact {review-artifact}`；不能把失败类型或 `changed=false` 当作自动授权。
 
 从该次返回值绑定并复用以下结构化映射：
 
@@ -100,7 +100,7 @@ agent-infra-internal task-artifact {task-id} init --family review-analysis --art
 {unresolved-minor} = stageStatus.unresolvedFindingCounts.minor
 ```
 
-该 intent 原子最终化报告摘要并返回同一次账本快照；不得再调用 `stage-status`、手工替换占位符或扫描问题清单。失败后，模型只能在共享规则的机械安全门通过时修改同一个受控 artifact，并完整重跑相同 intent；每次失败都重新判断是否收敛。最终一次完整成功返回决定同一快照的 verdict 和计数：`stageStatus.canAdvance=true` 且结论为 Approved 时允许跨阶段推进；`stageStatus.canAdvance=false` 时仍须执行 `agent-infra-internal task-event {task-id} review-analysis.completed --agent {standard-agent-token} --initiator {trigger-initiator} --request-id {request-id} --reason-code {reason-code} --artifact {review-artifact} --verdict {approved|changes-requested|rejected} --blockers {unresolved-blockers} --major {unresolved-major} --minor {unresolved-minor} --manual-validation {n} {execution-flag}`，使用 `changes-requested` 并路由到同阶段修订/复审（报告明确拒绝时使用 `rejected`）。失败、模型停止、无进展或紧急熔断时，不发布完成事件或跨阶段命令，但必须按 `reference/output-templates.md` 的 `repair-stop` 场景展示已有 summary/findings、artifact、实际修复次数、最后诊断和停止原因。
+该 intent 原子最终化报告摘要并返回同一次账本快照；不得再调用 `stage-status`、手工替换占位符或扫描问题清单。失败后，模型只能在共享规则的机械安全门通过时修改同一个受控 artifact，并完整重跑相同 intent；每次失败都重新判断是否收敛。最终一次完整成功返回决定同一快照的 verdict 和计数：`stageStatus.canAdvance=true` 且结论为 Approved 时允许跨阶段推进；`stageStatus.canAdvance=false` 时仍须执行 `agent-infra-internal task-event {task-id} review-analysis.completed --agent {standard-agent-token} --initiator {trigger-initiator} --request-id {request-id} --reason-code {reason-code} --artifact {review-artifact} --verdict {approved|changes-requested|rejected} --blockers {unresolved-blockers} --major {unresolved-major} --minor {unresolved-minor} --manual-validation {n}`，使用 `changes-requested` 并路由到同阶段修订/复审（报告明确拒绝时使用 `rejected`）。失败、模型停止、无进展或紧急熔断时，不发布完成事件或跨阶段命令，但必须按 `reference/output-templates.md` 的 `repair-stop` 场景展示已有 summary/findings、artifact、实际修复次数、最后诊断和停止原因。
 
 `manual-validation` 是 `ai task log` 中 review 行「人工校验点」（EN `Manual-validation`）计数的数据源；不要新增并行人工验证字段。
 

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

@@ -9,7 +9,7 @@ description: >
 # Code Review
 > `--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 both the summary finalizer and 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` or `review-finding` for ordinary reviews. Only an explicitly requested supplemental human review uses `--initiator human --reason-code manual-review-supplement`. Reuse the same values for started and completed.
+Lifecycle events require explicit trigger data: ordinary review uses `model`; only an explicitly requested supplemental human review uses `--initiator human --reason-code manual-review-supplement`. `{request-id}` is a stable single-line identifier for this task and artifact round, and `{reason-code}` use `user-request` or `review-finding` for ordinary reviews. Reuse the same values for started and completed.
 
 Review the latest code round and produce `review-code.md` or `review-code-r{N}.md`.
 
@@ -114,9 +114,9 @@ Create `<task-workspace>/active/{task-id}/{review-artifact}`.
 ### 6. Update Task Status
 
 Update task.md:
-- After the report, call `agent-infra-internal task-review {task-id} preflight --stage code --artifact {review-artifact} {execution-flag}` before any ledger write. On failure, correct the formal artifact directly and rerun it.
+- After the report, call `agent-infra-internal task-review {task-id} preflight --stage code --artifact {review-artifact}` before any ledger write. On failure, correct the formal artifact directly and rerun it.
 - Only after preflight passes, submit each new finding with `agent-infra-internal task-ledger {task-id} finding-upsert --stage code --review-artifact {review-artifact} --ordinal {n} --severity {blocker|major|minor} --evidence {review-artifact}#{anchor}`; submit prior-response dispositions with `finding-review --id {ledger-id} --status {confirmed|closed|open|needs-human-decision} --evidence {evidence}`. When escalating to `needs-human-decision`, append `--needs-implementation true|false` using the judgment recorded in the detail block. Do not scan ids or edit ledger rows
-- After all ledger writes, call `agent-infra-internal task-review {task-id} finalize-summary --stage code --artifact {review-artifact} {execution-flag}`; never treat an error type or `changed=false` as automatic authorization
+- After all ledger writes, call `agent-infra-internal task-review {task-id} finalize-summary --stage code --artifact {review-artifact}`; never treat an error type or `changed=false` as automatic authorization
 
   Bind and reuse this structured mapping from that one response:
 
@@ -126,10 +126,10 @@ Update task.md:
   {unresolved-minor} = stageStatus.unresolvedFindingCounts.minor
   ```
 
-  The intent atomically finalizes the report summary and returns the same ledger snapshot. Do not call `stage-status`, replace placeholders manually, or rescan the finding list. After a failure, the model may edit the same controlled artifact and rerun the same intent only when the shared rule's mechanical gates pass; reassess convergence after every failure. The final complete result determines the verdict and counts from that same snapshot: `stageStatus.canAdvance=true` with an Approved conclusion permits cross-stage advancement; `stageStatus.canAdvance=false` still requires `agent-infra-internal task-event {task-id} review-code.completed --agent {standard-agent-token} --initiator {trigger-initiator} --request-id {request-id} --reason-code {reason-code} --artifact {review-artifact} --verdict {approved|changes-requested|rejected} --blockers {unresolved-blockers} --major {unresolved-major} --minor {unresolved-minor} --manual-validation {n} {execution-flag}`, using `changes-requested` and routing to same-stage revision/review (use `rejected` when the report explicitly rejects). On failure, model stop, lack of progress, or the emergency cap, do not publish a completion event or cross-stage command; use the `repair-stop` scenario in `reference/output-templates.md` to show existing summary/findings, the artifact, actual repair attempts, the last diagnostic, and the stop reason
+  The intent atomically finalizes the report summary and returns the same ledger snapshot. Do not call `stage-status`, replace placeholders manually, or rescan the finding list. After a failure, the model may edit the same controlled artifact and rerun the same intent only when the shared rule's mechanical gates pass; reassess convergence after every failure. The final complete result determines the verdict and counts from that same snapshot: `stageStatus.canAdvance=true` with an Approved conclusion permits cross-stage advancement; `stageStatus.canAdvance=false` still requires `agent-infra-internal task-event {task-id} review-code.completed --agent {standard-agent-token} --initiator {trigger-initiator} --request-id {request-id} --reason-code {reason-code} --artifact {review-artifact} --verdict {approved|changes-requested|rejected} --blockers {unresolved-blockers} --major {unresolved-major} --minor {unresolved-minor} --manual-validation {n}`, using `changes-requested` and routing to same-stage revision/review (use `rejected` when the report explicitly rejects). On failure, model stop, lack of progress, or the emergency cap, do not publish a completion event or cross-stage command; use the `repair-stop` scenario in `reference/output-templates.md` to show existing summary/findings, the artifact, actual repair attempts, the last diagnostic, and the stop reason
 - Only when `canAdvance=true`, the verdict is Approved, and `T == R^{tree}`, write `last_reviewed_commit: {R}`. Clear an old value for an Approved snapshot with uncommitted differences; otherwise preserve the existing value and do not advance it
 - For an Approved exit, use `reference/output-templates.md` to select one branch and its `agent-client next-steps` helper to generate the next command.
-- After handling `last_reviewed_commit`, run `agent-infra-internal task-event {task-id} review-code.completed --agent {standard-agent-token} --initiator {trigger-initiator} --request-id {request-id} --reason-code {reason-code} --artifact {review-artifact} --verdict {approved|changes-requested|rejected} --blockers {unresolved-blockers} --major {unresolved-major} --minor {unresolved-minor} --manual-validation {n} {execution-flag}`
+- After handling `last_reviewed_commit`, run `agent-infra-internal task-event {task-id} review-code.completed --agent {standard-agent-token} --initiator {trigger-initiator} --request-id {request-id} --reason-code {reason-code} --artifact {review-artifact} --verdict {approved|changes-requested|rejected} --blockers {unresolved-blockers} --major {unresolved-major} --minor {unresolved-minor} --manual-validation {n}`
 
 Always include the `Manual-validation: {n}` field in the done log, including when it is 0.
 `manual-validation` is the data source for the `Manual-validation` count folded into review rows in `ai task log`; do not add a parallel manual-verification field.