@fitlab-ai/agent-infra 0.8.4 → 0.9.0

package/templates/.agents/skills/close-dependabot/SKILL.en.md

@@ -13,15 +13,9 @@ Dismiss the specified Dependabot security alert and record a justified reason.
 
 > If `{task-id}` matches `^[#]?[0-9]+$` (bare numeric or `#`-prefixed), follow the "SKILL parameter resolver" section of `.agents/rules/task-short-id.md`; treat `{task-id}` as the resolved full `TASK-YYYYMMDD-HHMMSS` form for every downstream command.
 
-## Step Start: Write the started Marker
+## Step Start: Local Lifecycle Boundary
 
-After prerequisites pass and before this step's first artifact action, append a started marker to task.md `## Activity Log` (same base action as this step's done entry plus a ` [started]` suffix, note `started`):
-
-```
-- {YYYY-MM-DD HH:mm:ss±HH:MM} — **Close Dependabot [started]** by {agent} — started
-```
-
-`ai task log` pairs it with the done entry written on completion onto one row (in progress → done). See the "Activity Log started / done dual-marker convention" in `.agents/rules/task-management.md`.
+The skill still owns the security-alert API. When a related task exists, Step 7 declares exactly one local lifecycle intent that commits base metadata, the log pair, archival placement, and short-id handling.
 
 ## Execution Flow
 
@@ -93,27 +87,17 @@ Dismiss the alert by following the Dependabot dismiss command in `.agents/rules/
 ### 7. Record in the Task (If Any)
 
 If a related task exists (search for `security_alert_number: <alert-number>`):
-Get the current time:
 
 ```bash
-date "+%Y-%m-%d %H:%M:%S%z" | sed 's/\([+-][0-9][0-9]\)\([0-9][0-9]\)$/\1:\2/'
+agent-infra-internal task-lifecycle {task-id} close-dependabot --agent {agent} \
+  --alert-number {alert-number} --reason "{reason}"
 ```
 
-- Add the dismissal record to task.md
-- **Append** to `## Activity Log` (do NOT overwrite previous entries):
-  ```
-  - {YYYY-MM-DD HH:mm:ss±HH:MM} — **Close Dependabot** by {agent} — Dependabot alert #{alert-number} dismissed: {reason}
-  ```
-- Archive the task
-- **Release short id** (after the archive `mv` succeeded; the script is idempotent):
-
-  ```bash
-  node .agents/scripts/task-short-id.js release "$task_id" || true
-  ```
+Only `status=applied|no-op` means local archival completed. If the API dismissal succeeded but lifecycle returns `failed`, explicitly report that remote is dismissed while local recovery remains, show recovery steps, and retry the same intent. Do not hand-edit task.md, move directories, or release the short id.
 
 ### 8. Inform User
 
-> **IMPORTANT**: All TUI command formats listed below must be output in full. Do not show only the format for the current AI agent. If `.agents/.airc.json` configures custom TUIs (via `customTUIs`), read each tool's `name` and `invoke`, then add the matching command line in the same format (`${skillName}` becomes the skill name and `${projectName}` becomes the project name). Before rendering the final output, read `.agents/rules/next-step-output.md` and apply both of its rules: (1) render `{task-ref}` in the "Next steps" commands as the short id `#NN` (falling back to the full TASK-id when unallocated or released); (2) append the `Completed at` line as the very last line of the user-facing output (this applies to every user-facing output — success, error, and early-return paths alike, not only the success path).
+> **IMPORTANT**: All TUI command formats listed below must be output in full. Do not show only the format for the current AI agent. If `.agents/.airc.json` configures custom TUIs (via `customTUIs`), read each tool's `name` and `invoke`, then add the matching command line in the same format (`${skillName}` becomes the skill name and `${projectName}` becomes the project name). Before rendering the final output, read `.agents/rules/next-step-output.md` and apply both of its rules: (1) render `{task-ref}` in the "Next steps" commands as the short id `NN` (falling back to the full TASK-id when unallocated or released); (2) append the `Completed at` line as the very last line of the user-facing output (this applies to every user-facing output — success, error, and early-return paths alike, not only the success path).
 
 > **Optional sandbox-cleanup hint (gated)**: Render the "Optional: clean up this task's sandbox" block — placed after the "Note:" line and before "Next step" in the output below — only when ALL of (1) `.agents/.airc.json` has a `sandbox` field, (2) step 7 located a related task by the alert number, and (3) that related task's task.md `branch` field exists and is not `main` / `master`; otherwise omit the whole block. `{branch}` is the `branch` value from the related task.md located in step 7. This block is independent of "Next step" semantics.
 
@@ -153,5 +137,3 @@ Next step - complete and archive the task if a related task exists:
 - Already closed: output "Alert #{number} is already {state}"
 - Permission error: output "No permission to modify alerts"
 - User canceled: output "Cancellation acknowledged"
-
-

package/templates/.agents/skills/close-dependabot/SKILL.zh-CN.md

@@ -13,15 +13,9 @@ description: >
 
 > 如果 `{task-id}` 入参匹配 `^[#]?[0-9]+$`（裸数字或带 `#` 前缀），先读取 `.agents/rules/task-short-id.md` 的「SKILL 入参解析」段执行解析；后续命令视 `{task-id}` 为解析后的全长 `TASK-YYYYMMDD-HHMMSS` 形式。
 
-## 步骤开始：写入 started 标记
+## 步骤开始：本地生命周期边界
 
-确认前置条件后、本步骤第一个产出动作之前，向 task.md `## 活动日志` 追加一条 started 标记（与本步骤 done 条目同基名 + ` [started]` 后缀，note 用 `started`）：
-
-```
-- {YYYY-MM-DD HH:mm:ss±HH:MM} — **Close Dependabot [started]** by {agent} — started
-```
-
-`ai task log` 会把它与完成时写入的 done 条目配对成一行（进行中 → 已完成）。约定见 `.agents/rules/task-management.md` 的「Activity Log started / done 双标记约定」。
+安全告警 API 仍由本技能处理；若存在关联任务，步骤 7 只声明一个本地 lifecycle intent，由核心统一提交基础元数据、日志、归档目录和短号。
 
 ## 执行流程
 
@@ -93,27 +87,17 @@ CVE：{cve-id}
 ### 7. 记录到任务（如存在）
 
 如果有关联任务（搜索 `security_alert_number: <alert-number>`）：
-获取当前时间：
 
 ```bash
-date "+%Y-%m-%d %H:%M:%S%z" | sed 's/\([+-][0-9][0-9]\)\([0-9][0-9]\)$/\1:\2/'
+agent-infra-internal task-lifecycle {task-id} close-dependabot --agent {agent} \
+  --alert-number {alert-number} --reason "{reason}"
 ```
 
-- 添加关闭记录到 task.md
-- **追加**到 `## Activity Log`（不要覆盖之前的记录）：
-  ```
-  - {YYYY-MM-DD HH:mm:ss±HH:MM} — **Close Dependabot** by {agent} — Dependabot alert #{alert-number} dismissed: {reason}
-  ```
-- 归档任务
-- **释放短号**（归档目录已 mv 成功，再 release；脚本幂等）：
-
-  ```bash
-  node .agents/scripts/task-short-id.js release "$task_id" || true
-  ```
+仅 `status=applied|no-op` 视为本地归档完成。若 API 已关闭但 lifecycle 返回 `failed`，必须明确报告“远端已关闭、本地待恢复”，展示 recovery steps，并以同一 intent 重试；不得手工更新 task.md、移动目录或释放短号。
 
 ### 8. 告知用户
 
-> **重要**：以下「下一步」中列出的所有 TUI 命令格式必须完整输出，不要只展示当前 AI 代理对应的格式。如果 `.agents/.airc.json` 中配置了自定义 TUI（`customTUIs`），读取每个工具的 `name` 和 `invoke`，按同样格式补充对应命令行（`${skillName}` 替换为技能名，`${projectName}` 替换为项目名）。 渲染最终输出前，先读取 `.agents/rules/next-step-output.md` 并落实其两类规则：(1) 「下一步」命令把 `{task-ref}` 渲染为短号 `#NN`（未分配/已释放时回退完整 TASK-id）；(2) 在面向用户输出的绝对最后一行追加 `Completed at` 收尾行（成功、错误、早退等任何面向用户输出都适用，不限于校验通过的成功态）。
+> **重要**：以下「下一步」中列出的所有 TUI 命令格式必须完整输出，不要只展示当前 AI 代理对应的格式。如果 `.agents/.airc.json` 中配置了自定义 TUI（`customTUIs`），读取每个工具的 `name` 和 `invoke`，按同样格式补充对应命令行（`${skillName}` 替换为技能名，`${projectName}` 替换为项目名）。 渲染最终输出前，先读取 `.agents/rules/next-step-output.md` 并落实其两类规则：(1) 「下一步」命令把 `{task-ref}` 渲染为短号 `NN`（未分配/已释放时回退完整 TASK-id）；(2) 在面向用户输出的绝对最后一行追加 `Completed at` 收尾行（成功、错误、早退等任何面向用户输出都适用，不限于校验通过的成功态）。
 
 > **可选沙箱清理提示（门控渲染）**：仅当同时满足 (1) `.agents/.airc.json` 存在 `sandbox` 字段、(2) 第 7 步按告警号定位到了关联任务、(3) 该关联任务 task.md 的 `branch` 字段存在且不是 `main` / `master` 时，才渲染下方输出中「注意：…」之后、「下一步」之前的「可选：清理本任务的沙箱」块；任一不满足则整段省略。`{branch}` 取第 7 步定位到的关联任务 task.md 的 `branch` 值。该块独立于「下一步」语义。
 
@@ -153,5 +137,3 @@ ai sandbox rm {branch}
 - 已关闭：提示 "Alert #{number} is already {state}"
 - 权限错误：提示 "No permission to modify alerts"
 - 用户取消：提示 "Cancellation acknowledged"
-
-

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

@@ -3,17 +3,18 @@ name: code-task
 description: >
   Implement code from the technical plan and output a report.
   Use when an approved technical plan needs implementing, or code review found issues to fix.
+  Only invoke this skill automatically when the conversation includes a resolvable task reference.
 ---
 
 # Code Task
 
-Implement the approved plan and produce `code.md` or `code-r{N}.md`. This skill supports initial implementation and fix mode based on `review-code` feedback.
+Implement the approved plan 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.
 
 ## Boundary / Critical Rules
 
 - Follow the latest plan artifact: `plan.md` or `plan-r{N}.md`
 - Fix mode verifies each finding of the latest `review-code` one by one: fix it if it holds, or rebut it and record it under unresolved if it is unfounded/hallucinated; do not expand to issues the review did not list; manual-validation items are out of scope
-- If implementation encounters a key design decision not covered by the plan, per `.agents/rules/no-mid-flow-questions.md` write its detail block into the implementation report's `## 人工裁决待办` (Pending Human Decisions) section as `### HD-N：<title> [needs-human-decision]` (`HD-N` is globally unique, see `.agents/rules/review-handshake.md`) and write the matching `HD-` ledger row, instead of asking mid-flow or expanding scope silently
+- If implementation encounters a key design decision not covered by the plan, run `agent-infra-internal task-ledger {task-id} decision-next-id`, write the returned `HD-N` detail block per `.agents/rules/human-decision-context.md`, then run `decision-upsert --id {HD-N} --stage code --artifact {code-artifact}`. Do not scan ids, assemble ledger rows, ask mid-flow, or silently expand scope
 - Never auto-run `git add` or `git commit`
 - Create a new code artifact for each round and never overwrite an older one
 - After executing this skill, you **must** immediately update task.md
@@ -27,24 +28,18 @@ After loading workflow / skill / rules instructions, and before any task-state j
 Run these commands and paste the raw output into both the user-facing reply and this round's `## State Check` section:
 
 ```bash
-git status -s
-ls -la .agents/workspace/active/{task-id}/
-tail .agents/workspace/active/{task-id}/task.md
+agent-infra-internal task-snapshot {task-id} --format text
 ```
 
-## Task id short ref
+## Task Context Resolution
 
-> If `{task-id}` matches `^[#]?[0-9]+$` (bare numeric or `#`-prefixed), follow the "SKILL parameter resolver" section of `.agents/rules/task-short-id.md`; treat `{task-id}` as the resolved full `TASK-YYYYMMDD-HHMMSS` form for every downstream command.
+> The entry point may omit the task ref and also accepts a legacy positional ref or `--task <ref>` / `-t <ref>`. Separate task scope from the full arguments while preserving every business operand, then call `agent-infra-internal task-context resolve {task-scope}` where `{task-scope}` is empty, one positional ref, or one task flag. Read only `taskId` from the structured result and bind `{task-id}` to that full `TASK-YYYYMMDD-HHMMSS` for downstream commands. Pass through resolution failures without scanning tasks locally.
 
-## Step Start: Write the started Marker
-
-After prerequisites (step 1) and mode/round (step 4) are confirmed and before this round's first artifact action, append a started marker to task.md `## Activity Log` (same base action as this round's done entry plus a ` [started]` suffix, note `started`):
+> Resolve the task reference, then confirm that the task is in a state or directory supported by this skill and that `task.md` exists; if it cannot be located, handle it as a missing task and stop.
 
-```
-- {YYYY-MM-DD HH:mm:ss±HH:MM} — **Code Task (Round {N}) [started]** by {agent} — started
-```
+## Step Start: Write the started Marker
 
-In fix mode the base must match this round's done entry, i.e. `Code Task (Round {N}, fix for {review-artifact}) [started]`. `ai task log` pairs it with the done entry written on completion (step 10) onto one row (in progress → done). Format and pairing rules: see the "Activity Log started / done dual-marker convention" in `.agents/rules/task-management.md`.
+After prerequisites and mode are confirmed and before this round's first artifact action, run `agent-infra-internal task-event {task-id} code.started --agent {agent}`. Append `--fix-for {review-artifact}` in fix mode or `--implementation-input {input-id}` in decision mode. The core derives and validates the round and input identity; record the returned `artifactContext`.
 
 ## Steps
 
@@ -58,16 +53,16 @@ Read `reference/branch-management.md`, ensure the current branch matches the tas
 
 ### 3. Narrow the Milestone
 
-**Mandatory; do not skip.** If task.md has a valid `issue_number`, read `.agents/rules/issue-sync.md` first (upstream + permission detection), then `.agents/rules/milestone-inference.md` Phase 2 for `code-task` to narrow the Issue milestone. If `has_triage=false`, keep the existing milestone.
+**Mandatory; do not skip.** If task.md has a valid `issue_number`, run `agent-infra-internal platform-issue sync {task-id} --agent {agent} --milestone specific`.
 
-> If this step is skipped or the Issue milestone is still a release line `X.Y.x` afterward, the step-11 `validate-artifact` gate will block the `code-task` round via `verify_milestone_specific` and require narrowing to a specific version (e.g. `0.7.1`) before proceeding.
+> If the milestone remains `X.Y.x`, step 11 `task-verify code.completed` blocks through the typed milestone check.
 
 ### 4. Determine Mode and Round
 
 Run mode detection and preserve its exit code:
 
 ```bash
-result=$(node .agents/skills/code-task/scripts/detect-mode.js .agents/workspace/active/{task-id})
+result=$(agent-infra-internal task-artifact {task-id} inspect --family code)
 status=$?
 echo "$result"
 ```
@@ -76,18 +71,19 @@ Dispatch by `$status` and `result.mode`:
 
 - `0` + `"init"`: initial implementation; record `{code-artifact}` and `{code-round}`
 - `0` + `"fix"`: fix mode; record `{code-artifact}`, `{code-round}`, and `{review-artifact}`
+- `0` + `"decision"`: decision implementation mode; record `{code-artifact}`, `{code-round}`, `{input-id}`, `{decision-id}`, and `{decision-evidence}`
 - `1` + `"refused"`: print `result.message`, stop, and do not write an artifact or Activity Log entry
 - `2` + `"error"`: print `result.message`, stop, and do not write an artifact or Activity Log entry
 
 > Read `reference/dual-mode.md` before this step.
 
-### 5. Determine the Input Plan
+### 5. Read Structured Inputs
 
-Read the highest-round plan artifact and use the `{code-artifact}` selected in step 4. In fix mode, also read `{review-artifact}`.
+Use only the structured result from step 4: read the selected plan artifact and, in fix mode, the selected review artifact. Use `next.name` as `{code-artifact}` and `next.round` as `{code-round}`. In decision mode, take the unified identity from `implementation_input`, `decision_id`, and `decision_evidence`; do not rescan or construct identities in the skill.
 
 ### 6. Read the Technical Plan
 
-Extract implementation steps, files, test strategy, constraints, risks, and approved tradeoffs.
+Extract implementation steps, files, test strategy, constraints, risks, and approved tradeoffs. In decision mode, also read the `{input-id}` row and its `{decision-evidence}` record in task.md, and implement only that ruling's requested behavior change.
 
 ### 7. Implement the Code
 
@@ -111,30 +107,21 @@ Create `.agents/workspace/active/{task-id}/{code-artifact}`.
 
 ### 10. Update Task Status
 
-Get the current time:
-
-```bash
-date "+%Y-%m-%d %H:%M:%S%z" | sed 's/\([+-][0-9][0-9]\)\([0-9][0-9]\)$/\1:\2/'
-```
-
-Set `current_step` to `code`, refresh task metadata, and append one Activity Log entry:
-
-- initial implementation: `Code Task (Round {N})`
-- fix mode: `Code Task (Round {N}, fix for {review-artifact})`
+After requirement checkboxes are updated, run the initial event `agent-infra-internal task-event {task-id} code.completed --agent {agent} --artifact {code-artifact} --files-modified {n} --tests-passed {n}`; in fix mode use `--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 `issue_number`, read `.agents/rules/issue-sync.md`, then:
-- Set `status: in-progress` according to issue-sync.md
-- Create or update the task comment marker defined in `.agents/rules/issue-sync.md`
-- Publish the `{code-artifact}` comment
+- Run `agent-infra-internal platform-issue sync {task-id} --agent {agent} --status in-progress`
+- Run `agent-infra-internal platform-comment sync {task-id} --kind task --agent {agent}`
+- Run `agent-infra-internal platform-comment sync {task-id} --kind artifact --artifact {code-artifact} --agent {agent}`
 
 ### 11. Run Completion Gate
 
 ```bash
-node .agents/scripts/validate-artifact.js gate code-task .agents/workspace/active/{task-id} {code-artifact} --format text
+agent-infra-internal task-verify {task-id} code.completed --artifact {code-artifact} --format text
 ```
 
 ### 12. Tell the User
 
 Use `reference/output-template.md` (or `reference/fix-mode.md` in fix mode) and show all TUI command formats.
 
-> Before rendering the final output, read `.agents/rules/next-step-output.md` and apply both of its rules: (1) render `{task-ref}` in the "Next steps" commands as the current task's short id `#NN` (see that file for lookup and fallback), while other `{task-id}` placeholders (report titles, paths) keep the full TASK-id form; (2) append the `Completed at` line as the very last line of the user-facing output (this applies to every user-facing output — success, error, and early-return paths alike, not only the success path).
+> Before rendering the final output, read `.agents/rules/next-step-output.md` and apply both of its rules: (1) render `{task-ref}` in the "Next steps" commands as the current task's short id `NN` (see that file for lookup and fallback), while other `{task-id}` placeholders (report titles, paths) keep the full TASK-id form; (2) append the `Completed at` line as the very last line of the user-facing output (this applies to every user-facing output — success, error, and early-return paths alike, not only the success path).

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

@@ -3,17 +3,18 @@ name: code-task
 description: >
   根据技术方案编码任务并输出报告。
   当技术方案已批准需要落地实现，或代码审查发现问题需要修复时使用。
+  仅当对话包含可解析的任务引用时才可自动调用本技能。
 ---
 
 # 编码任务
 
-根据已批准的技术方案编码任务，并产出 `code.md` 或 `code-r{N}.md`。本技能支持初次实现和基于 `review-code` 反馈的修复双模式。
+根据已批准的技术方案编码任务，并产出 `code.md` 或 `code-r{N}.md`。本技能支持初次实现、基于 `review-code` 反馈的修复，以及人工裁决驱动实现三种模式。
 
 ## 行为边界 / 关键规则
 
 - 严格遵循最新方案产物：`plan.md` 或 `plan-r{N}.md`
 - 修复模式逐条核实最新 `review-code` 的发现：成立则修复，判定为不成立/幻觉则在报告中反驳并记入 unresolved；不擅自扩大到审查未列出的问题；manual-validation 项不在修复范围
-- 实现中遇到方案未覆盖的关键设计决策时，按 `.agents/rules/no-mid-flow-questions.md` 判据，把详情块写入实现报告的 `## 人工裁决待办` 段 `### HD-N：<标题> [needs-human-decision]`（`HD-N` 全局唯一，见 `.agents/rules/review-handshake.md`）并回写 `HD-` 账本行，不中途提问或擅自扩范围
+- 实现中遇到方案未覆盖的关键设计决策时，先调用 `agent-infra-internal task-ledger {task-id} decision-next-id` 取得 `HD-N`，按 `.agents/rules/human-decision-context.md` 写入实现报告的 `## 人工裁决待办` 详情块，再调用 `decision-upsert --id {HD-N} --stage code --artifact {code-artifact}`；不得扫描编号、手写账本行、中途提问或擅自扩范围
 - 绝不自动执行 `git add` 或 `git commit`
 - 每轮实现都创建新的实现产物，不覆盖旧文件
 - 执行本技能后，你**必须**立即更新 task.md
@@ -39,26 +40,20 @@ description: >
 运行以下命令，并把原文粘贴到回复正文和本轮产物的 `## 状态核对` 段：
 
 ```bash
-git status -s
-ls -la .agents/workspace/active/{task-id}/
-tail .agents/workspace/active/{task-id}/task.md
+agent-infra-internal task-snapshot {task-id} --format text
 ```
 
 状态核对完成前，禁止任何关于外部状态的断言（例如“代码没变”“测试已通过”“没有其他引用”），包括思考阶段。本门禁只提供结构下限；逐条证据配对和真实性仍需按报告模板与审查要求核对。
 
-## 任务入参短号别名
+## 任务上下文解析
 
-> 如果 `{task-id}` 入参匹配 `^[#]?[0-9]+$`（裸数字或带 `#` 前缀），先读取 `.agents/rules/task-short-id.md` 的「SKILL 入参解析」段执行解析；后续命令视 `{task-id}` 为解析后的全长 `TASK-YYYYMMDD-HHMMSS` 形式。
+> 入口允许省略 task ref，也接受旧位置 task ref 或 `--task <ref>` / `-t <ref>`。先从完整参数中分离 task scope 并原样保留其他业务操作数，再调用 `agent-infra-internal task-context resolve {task-scope}`；`{task-scope}` 为空、位置 ref 或 task flag 之一。只读取结构化结果的 `taskId`，后续把 `{task-id}` 绑定为该完整 `TASK-YYYYMMDD-HHMMSS`。解析失败时透传非零退出码，不自行扫描任务。
 
-## 步骤开始：写入 started 标记
+> 解析任务引用，并确认任务位于本技能支持的状态或目录且存在 `task.md`；无法定位时按未找到任务处理并停止。
 
-确认前置条件（步骤 1）与模式/轮次（步骤 4）后、本轮第一个产出动作之前，向 task.md `## 活动日志` 追加一条 started 标记（与本轮 done 条目同基名 + ` [started]` 后缀，note 用 `started`）：
+## 步骤开始：声明 started 事件
 
-```
-- {YYYY-MM-DD HH:mm:ss±HH:MM} — **Code Task (Round {N}) [started]** by {agent} — started
-```
-
-修复模式的基名须与本轮 done 一致，即 `Code Task (Round {N}, fix for {review-artifact}) [started]`。`ai task log` 会把它与步骤完成时（步骤 10）写入的 done 条目配对成一行（进行中 → 已完成）。格式与配对规则见 `.agents/rules/task-management.md` 的「Activity Log started / done 双标记约定」。
+确认前置条件与模式后、本轮第一个产出动作之前执行 `agent-infra-internal task-event {task-id} code.started --agent {agent}`。修复模式追加 `--fix-for {review-artifact}`，裁决模式追加 `--implementation-input {input-id}`。核心根据 artifact context 推导并校验轮次与输入身份；以返回的 `artifactContext` 记录本轮身份。
 
 ## 执行步骤
 ### 1. 验证前置条件
@@ -84,16 +79,16 @@ tail .agents/workspace/active/{task-id}/task.md
 
 ### 3. 收窄里程碑
 
-**必须执行，不得跳过。** 如果 task.md 中存在有效的 `issue_number`，执行前先读取 `.agents/rules/issue-sync.md`，完成 upstream 仓库检测和权限检测；再读取 `.agents/rules/milestone-inference.md`，按其中的「阶段 2：`code-task`」收窄 Issue milestone；如果 `has_triage=false`，则保持原 milestone 不变。
+**必须执行，不得跳过。** 如果 task.md 中存在有效的 `issue_number`，调用 `agent-infra-internal platform-issue sync {task-id} --agent {agent} --milestone specific`；里程碑推断、权限降级与幂等写入由 internal core 处理。
 
-> 若此步骤被跳过或收窄后 Issue milestone 仍为 `X.Y.x` 版本线，步骤 11 的 `validate-artifact` gate 会通过 `verify_milestone_specific` 截停本轮 `code-task`，要求重新收窄到具体版本（如 `0.7.1`）后再继续。
+> 若跳过或收窄后仍为 `X.Y.x`，步骤 11 的 `task-verify code.completed` 会通过 typed milestone check 截停本轮。
 
 ### 4. 确定模式与轮次
 
-执行 mode detection 脚本，先保存 exit code 再处理输出：
+执行共享产物查询，先保存 exit code 再处理输出：
 
 ```bash
-result=$(node .agents/skills/code-task/scripts/detect-mode.js .agents/workspace/active/{task-id})
+result=$(agent-infra-internal task-artifact {task-id} inspect --family code)
 status=$?
 echo "$result"
 ```
@@ -104,6 +99,7 @@ echo "$result"
 |---|---|---|
 | 0 | `"init"` | 进入初次实现模式。记录 `{code-artifact}` = `result.next_artifact`、`{code-round}` = `result.next_round` |
 | 0 | `"fix"` | 进入修复模式。记录 `{code-artifact}` = `result.next_artifact`、`{code-round}` = `result.next_round`、`{review-artifact}` = `result.review_artifact` |
+| 0 | `"decision"` | 进入裁决实现模式。记录 `{code-artifact}`、`{code-round}`、`{input-id}`、`{decision-id}` 与 `{decision-evidence}` |
 | 1 | `"refused"` | 输出 `result.message` 给用户；立即停止；不写 Activity Log、不创建产物 |
 | 2 | `"error"` | 输出 `result.message` 给用户；立即停止；不写 Activity Log、不创建产物 |
 | 其他 | 任意 | 视为脚本异常，输出 `Mode detection failed: status={status}, output={result}` 并停止 |
@@ -112,12 +108,7 @@ echo "$result"
 
 ### 5. 确定输入方案
 
-扫描 `.agents/workspace/active/{task-id}/` 并记录：
-- 最高轮次的方案文件为 `{plan-artifact}`
-- 使用步骤 4 记录的 `{code-round}` 与 `{code-artifact}`
-- 若为修复模式，同时记录 `{review-artifact}`
-
-如果存在 `plan-r{N}.md`，读取最高轮次的方案文件；否则读取 `plan.md`。
+只使用步骤 4 的结构化结果：从 `inputs` 取得 `{plan-artifact}`，从 `next_round` / `next_artifact` 取得 `{code-round}` / `{code-artifact}`；修复模式从 `review_artifact` 取得 `{review-artifact}`；裁决模式从 `implementation_input`、`decision_id`、`decision_evidence` 取得统一输入身份。不得自行扫描轮次或拼装文件名。
 
 ### 6. 阅读技术方案
 
@@ -129,6 +120,8 @@ echo "$result"
 
 修复模式还必须读取 `{review-artifact}`，并只处理其中标记的问题。
 
+裁决模式还必须读取 task.md 中 `{input-id}` 对应行及 `{decision-evidence}` 指向的裁决记录，并只实现该裁决要求的行为变化。
+
 ### 7. 执行代码实现
 
 按照 `.agents/workflows/feature-development.yaml` 和方案顺序实施。
@@ -153,34 +146,25 @@ echo "$result"
 
 ### 10. 更新任务状态
 
-获取当前时间：
-
-```bash
-date "+%Y-%m-%d %H:%M:%S%z" | sed 's/\([+-][0-9][0-9]\)\([0-9][0-9]\)$/\1:\2/'
-```
-
 更新 `.agents/workspace/active/{task-id}/task.md`：
-- `current_step`：code
-- `assigned_to`：{当前代理}
-- `updated_at`：{当前时间}
-- `agent_infra_version`：按 `.agents/rules/version-stamp.md` 取值
 - 审查 `## 需求` 段落，仅把本轮已由代码实现且有测试通过支撑的条目从 `- [ ]` 勾为 `- [x]`
-- 记录 Round `{code-round}` 的 `{code-artifact}`
-- 追加：
-  - 初次实现：`- {YYYY-MM-DD HH:mm:ss±HH:MM} — **Code Task (Round {N})** by {agent} — Code implemented, {n} files modified, {n} tests passed → {code-artifact}`
-  - 修复模式：`- {YYYY-MM-DD HH:mm:ss±HH:MM} — **Code Task (Round {N}, fix for {review-artifact})** by {agent} — Fixed {n} blockers, {n} major, {n} minor issues[, skipped {n} manual-validation] → {code-artifact}`
+- 产物链接、阶段与完成日志由 completed 事件统一登记
+- 完成业务内容更新后声明完成事件：
+  - 初次实现：`agent-infra-internal task-event {task-id} code.completed --agent {agent} --artifact {code-artifact} --files-modified {n} --tests-passed {n}`
+  - 修复模式：`agent-infra-internal task-event {task-id} code.completed --agent {agent} --artifact {code-artifact} --fix-for {review-artifact} --blockers {n} --major {n} --minor {n} --manual-validation {n}`
+  - 裁决模式：`agent-infra-internal task-event {task-id} code.completed --agent {agent} --artifact {code-artifact} --implementation-input {input-id} --files-modified {n} --tests-passed {n}`
 
-如果 task.md 中存在有效的 `issue_number`，执行以下同步操作（任一失败则跳过并继续；执行前先读取 `.agents/rules/issue-sync.md`，完成 upstream 仓库检测和权限检测）：
-- 按 issue-sync.md 设置 `status: in-progress`
-- 创建或更新 `.agents/rules/issue-sync.md` 中定义的 task 评论标记（按 issue-sync.md 的 task.md 评论同步规则）
-- 发布 `{code-artifact}` 评论
+如果 task.md 中存在有效的 `issue_number`，执行以下同步操作（任一失败则记录 warning 并继续；Issue 元数据边界仍见 `.agents/rules/issue-sync.md`）：
+- 调用 `agent-infra-internal platform-issue sync {task-id} --agent {agent} --status in-progress`
+- 调用 `agent-infra-internal platform-comment sync {task-id} --kind task --agent {agent}`
+- 调用 `agent-infra-internal platform-comment sync {task-id} --kind artifact --artifact {code-artifact} --agent {agent}`
 
 ### 11. 完成校验
 
 运行完成校验，确认任务产物和同步状态符合规范：
 
 ```bash
-node .agents/scripts/validate-artifact.js gate code-task .agents/workspace/active/{task-id} {code-artifact} --format text
+agent-infra-internal task-verify {task-id} code.completed --artifact {code-artifact} --format text
 ```
 
 处理结果：
@@ -196,7 +180,7 @@ node .agents/scripts/validate-artifact.js gate code-task .agents/workspace/activ
 
 > **重要**：以下「下一步」中列出的所有 TUI 命令格式必须完整输出，不要只展示当前 AI 代理对应的格式。如果 `.agents/.airc.json` 中配置了自定义 TUI（`customTUIs`），读取每个工具的 `name` 和 `invoke`，按同样格式补充对应命令行（`${skillName}` 替换为技能名，`${projectName}` 替换为项目名）。输出格式见 `reference/output-template.md`；修复模式输出见 `reference/fix-mode.md`。
 
-> 渲染最终输出前先读取 `.agents/rules/next-step-output.md` 并落实其两类规则：(1) 「下一步」命令的 `{task-ref}` 渲染为当前任务短号 `#NN`（取值与回退见该文件），其他 `{task-id}` 占位（报告标题、路径）保持完整 TASK-id 形式；(2) 在面向用户输出的绝对最后一行追加 `Completed at` 收尾行（成功、错误、早退等任何面向用户输出都适用，不限于校验通过的成功态）。
+> 渲染最终输出前先读取 `.agents/rules/next-step-output.md` 并落实其两类规则：(1) 「下一步」命令的 `{task-ref}` 渲染为当前任务短号 `NN`（取值与回退见该文件），其他 `{task-id}` 占位（报告标题、路径）保持完整 TASK-id 形式；(2) 在面向用户输出的绝对最后一行追加 `Completed at` 收尾行（成功、错误、早退等任何面向用户输出都适用，不限于校验通过的成功态）。
 
 ## 完成检查清单
 

package/templates/.agents/skills/code-task/config/verify.en.json

@@ -18,6 +18,7 @@
     "artifact": {
       "file_pattern": "code.md|code-r{N}.md",
       "required_sections": [
+        "Implementation Input",
         "Modified Files",
         "Key Code Explanation",
         "Test Results",
@@ -26,14 +27,13 @@
         "State Check",
         "Evidence"
       ],
-      "freshness_minutes": 30,
       "required_patterns": [
         "^\\$ "
       ]
     },
+    "implementation-input": {},
     "activity-log": {
-      "expected_action_pattern": "(Code Task|Code) \\(Round \\d+(?:, fix for review-code(?:-r\\d+)?\\.md)?\\)",
-      "freshness_minutes": 30
+      "expected_action_pattern": "(Code Task|Code) \\(Round \\d+(?:(?:, fix for review-code(?:-r\\d+)?\\.md)|(?:, decision II-[1-9]\\d*))?\\)"
     },
     "review-ledger": {
       "stage_scope": ["analysis", "plan"]

package/templates/.agents/skills/code-task/config/verify.zh-CN.json

@@ -18,6 +18,7 @@
     "artifact": {
       "file_pattern": "code.md|code-r{N}.md",
       "required_sections": [
+        "实现输入",
         "变更文件",
         "关键代码说明",
         "测试结果",
@@ -26,14 +27,13 @@
         "状态核对",
         "证据原文"
       ],
-      "freshness_minutes": 30,
       "required_patterns": [
         "^\\$ "
       ]
     },
+    "implementation-input": {},
     "activity-log": {
-      "expected_action_pattern": "(Code Task|Code) \\(Round \\d+(?:, fix for review-code(?:-r\\d+)?\\.md)?\\)",
-      "freshness_minutes": 30
+      "expected_action_pattern": "(Code Task|Code) \\(Round \\d+(?:(?:, fix for review-code(?:-r\\d+)?\\.md)|(?:, decision II-[1-9]\\d*))?\\)"
     },
     "review-ledger": {
       "stage_scope": ["analysis", "plan"]

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

@@ -1,30 +1,31 @@
-# code-task dual mode
+# code-task three-mode decision
 
-This file documents `scripts/detect-mode.js`. The script is the source of truth; update this document whenever the script changes.
+This file documents the core artifact lifecycle's code-mode decision. The `task-artifact` command is the source of truth; update this document whenever the core decision changes.
 
 ## Input
 
 ```bash
-node .agents/skills/code-task/scripts/detect-mode.js .agents/workspace/active/{task-id}
+agent-infra-internal task-artifact {task-id} inspect --family code
 ```
 
-The script scans `plan.md` / `plan-r{N}.md`, `review-plan.md` / `review-plan-r{N}.md`, `code.md` / `code-r{N}.md`, and `review-code.md` / `review-code-r{N}.md` in the task directory.
+The core scans `plan.md` / `plan-r{N}.md`, `review-plan.md` / `review-plan-r{N}.md`, `code.md` / `code-r{N}.md`, and `review-code.md` / `review-code-r{N}.md` in the task directory.
 
-## Seven Branches
+## Eight Branches
 
 > Branches are evaluated top-down in this table; the first match returns and skips later rows.
 
 | Condition | mode | exit | Behavior |
 |---|---|---:|---|
-| no code artifact | `init` | 0 | initial implementation, output `code.md` |
-| latest review-plan is approved (`Approved` or `Approved-with-issues`, i.e. `Overall Verdict: Approved` regardless of findings counts), its "Review Input" / "审查输入" entry names the same plan file as the latest `plan(-r{N})?.md` in the task directory, and its mtime is newer than the latest code artifact | `init` | 0 | plan has been approved after the latest code; enter a new implementation round, `next_round = code_max + 1`, `next_artifact = code-r{next_round}.md`. This branch fires regardless of whether review-code exists or passes. Plan and review-plan rounds are independent counters (e.g. `plan-r5` may be approved by `review-plan-r4`); the link is established via the review-plan's "Review Input" entry, not by matching round numbers. |
+| no code artifact, and the latest review-plan is exactly `Approved` and references the latest plan | `init` | 0 | initial implementation, output `code.md`; a missing matching approval or `Approved-with-issues` returns an error |
+| latest review-plan is exactly `Approved`, references the latest plan, and is newer than the latest code | `init` | 0 | enter a new implementation round. `Approved-with-issues` remains parse-compatible for history but is not cross-stage approval |
 | `rev_max < code_max` | `error` | 2 | latest code round is unreviewed; run `review-code` first |
+| latest review-code is Approved and a pending implementation input was decided after that review completed | `decision` | 0 | select the earliest `II-N` and enter decision-driven implementation; false/not-required and consumed inputs do not trigger |
 | latest review-code is Approved with 0/0/0 | `refused` | 1 | already approved; do not run `code-task` again |
 | latest review-code is Approved with major/minor findings | `fix` | 0 | optional fix mode |
 | latest review-code is Changes Requested | `fix` | 0 | required fix mode |
 | latest review-code is Rejected | `refused` | 1 | re-plan instead of local fixing |
 
-> The four verdict branches above fire when `rev_max >= code_max`, decided by the latest `review-code-r{rev_max}` verdict:
+> The five review-code branches above fire when `rev_max >= code_max`, decided by the latest `review-code-r{rev_max}` verdict and implementation inputs:
 > - `rev_max == code_max`: AI fix round (`review-code` reviews the same-numbered code artifact produced by `code-task`).
 > - `rev_max > code_max`: human-supplemented review round — after a PR is opened a maintainer appends a `review-code-r{N}` round against the existing latest code. `fix` mode then uses `next_round = code_max + 1`.
 >
@@ -61,6 +62,9 @@ The script prints JSON:
   "next_round": 1,
   "next_artifact": "code.md",
   "review_artifact": null,
+  "implementation_input": null,
+  "decision_id": null,
+  "decision_evidence": null,
   "message": "..."
 }
 ```
@@ -69,6 +73,6 @@ In the replan-driven init branch (row #2), `review_artifact` points to the `revi
 
 exit code:
 
-- `0`: continue, `mode` is `init` or `fix`
+- `0`: continue, `mode` is `init`, `fix`, or `decision`
 - `1`: stop, `mode` is `refused`
 - `2`: inconsistent state, `mode` is `error`

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

@@ -1,30 +1,31 @@
-# code-task 双模式判定
+# code-task 三模式判定
 
-本文件说明 `scripts/detect-mode.js` 的行为。脚本是单点真相；修改脚本时必须同步更新本文档。
+本文件说明核心 artifact lifecycle 的 code 模式判定。`task-artifact` 命令是单点真相；修改核心判定时必须同步更新本文档。
 
 ## 输入
 
 ```bash
-node .agents/skills/code-task/scripts/detect-mode.js .agents/workspace/active/{task-id}
+agent-infra-internal task-artifact {task-id} inspect --family code
 ```
 
-脚本扫描任务目录中的 `plan.md` / `plan-r{N}.md`、`review-plan.md` / `review-plan-r{N}.md`、`code.md` / `code-r{N}.md` 和 `review-code.md` / `review-code-r{N}.md`。
+核心扫描任务目录中的 `plan.md` / `plan-r{N}.md`、`review-plan.md` / `review-plan-r{N}.md`、`code.md` / `code-r{N}.md` 和 `review-code.md` / `review-code-r{N}.md`。
 
-## 7 个分支
+## 8 个分支
 
 > 分支按表中自上而下的顺序评估，命中即返回；后续分支不再判定。
 
 | 条件 | mode | exit | 行为 |
 |---|---|---:|---|
-| 无 code 产物 | `init` | 0 | 初次实现，产物为 `code.md` |
-| 最新 review-plan 已批准（`通过` 或 `通过 + major/minor 建议`，即 `Approved` 或 `Approved-with-issues`），且其「审查输入」/「Review Input」字段引用的 plan 文件 == 任务目录中最新的 `plan(-r{N})?.md`，且最新 review-plan 的 mtime > 最新 code 的 mtime | `init` | 0 | plan 已在 code 之后被批准；进入新一轮实现，`next_round = code_max + 1`、`next_artifact = code-r{next_round}.md`。**不论 review-code 是否已审**，本分支均先命中。plan 与 review-plan 的轮次独立递增（如 `plan-r5` 可被 `review-plan-r4` 批准），通过 review-plan 的「审查输入」字段建立批准关系，不要求同号 |
+| 无 code 产物，且最新 review-plan 精确为 `Approved` 并引用最新 plan | `init` | 0 | 初次实现，产物为 `code.md`；缺少匹配审批或为 `Approved-with-issues` 时返回 error |
+| 最新 review-plan 精确为 `Approved`，且其「审查输入」/「Review Input」字段引用最新 plan，mtime 又晚于最新 code | `init` | 0 | plan 已在 code 之后获批；进入新一轮实现。`Approved-with-issues` 仅保留历史解析兼容，不构成跨阶段批准 |
 | `rev_max < code_max` | `error` | 2 | 最新代码未审查，先运行 `review-code` |
+| 最新 review-code 为 Approved 且存在审查完成后产生的 pending 实现输入 | `decision` | 0 | 选择最早 `II-N`，进入裁决驱动实现；false/not-required 与 consumed 输入不触发 |
 | 最新 review-code 为 Approved 且 0/0/0 | `refused` | 1 | 已通过，无需再次运行 `code-task` |
 | 最新 review-code 为 Approved 但有 major/minor | `fix` | 0 | 可选修复模式 |
 | 最新 review-code 为 Changes Requested | `fix` | 0 | 必需修复模式 |
 | 最新 review-code 为 Rejected | `refused` | 1 | 需要重新设计，不进入局部修复 |
 
-> 上表 4 个 verdict 分支在 `rev_max >= code_max` 时命中，均以最新 `review-code-r{rev_max}` 的结论决定：
+> 上表 5 个 review-code 分支在 `rev_max >= code_max` 时命中，均以最新 `review-code-r{rev_max}` 的结论及实现输入决定：
 > - `rev_max == code_max`：AI 修复轮（`code-task` 产出代码后由 `review-code` 审查同号产物）。
 > - `rev_max > code_max`：人工补审轮——PR 创建后维护者追加一轮 `review-code-r{N}` 审查既有最新代码。此时 `fix` 模式的 `next_round = code_max + 1`。
 >
@@ -61,6 +62,9 @@ manual-validation 计数不参与 mode 判定。
   "next_round": 1,
   "next_artifact": "code.md",
   "review_artifact": null,
+  "implementation_input": null,
+  "decision_id": null,
+  "decision_evidence": null,
   "message": "..."
 }
 ```
@@ -69,6 +73,6 @@ manual-validation 计数不参与 mode 判定。
 
 exit code：
 
-- `0`：可继续，`mode` 为 `init` 或 `fix`
+- `0`：可继续，`mode` 为 `init`、`fix` 或 `decision`
 - `1`：拒绝继续，`mode` 为 `refused`
 - `2`：状态异常，`mode` 为 `error`

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

@@ -4,7 +4,7 @@ Read this file before changing code during fix mode.
 
 ## Plan the Fixes
 
-**Verify each finding first (mandatory before editing)**: for every finding in `{review-artifact}`, Read/Grep the cited `file:line` and the corresponding `git diff` to confirm the issue is real, then dispose of it with one of the four states in `.agents/rules/review-handshake.md`, and write the disposition + commensurate evidence back to the matching row in the task.md disagreement ledger (stage=code, round +1; symmetric evidence — every state needs evidence, "accept" is not a zero-cost default):
+**Verify each finding first (mandatory before editing)**: for every finding in `{review-artifact}`, Read/Grep the cited `file:line` and corresponding `git diff`, then choose one of the four states in `.agents/rules/review-handshake.md`. Submit it through `agent-infra-internal task-ledger {task-id} finding-respond --id {ledger-id} --round {code-round} --status {state} --evidence {evidence}` (every state needs commensurate evidence; "accept" is not a zero-cost default):
 - `accepted` → include it in the classification and fixes below; evidence cites the fix `file:line`
 - `adjusted` → use an alternative fix, with rationale; awaits review-code confirmation
 - `refuted` → verification judged it unfounded / a wrong `file:line` / hallucinated → do not change code; give a counter-argument in the report's `## Per-Finding Verification` section; awaits review-code confirmation

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

@@ -4,7 +4,7 @@
 
 ## 规划修复
 
-**先逐条核实（动手前必做）**：对 `{review-artifact}` 的每一条发现，先 Read/Grep 其引用的 `file:line` 与对应 `git diff`，确认问题真实存在，再按 `.agents/rules/review-handshake.md` 的四态处置，并把处置 + 相称证据回写 task.md `## 审查分歧账本` 对应行（stage=code，round +1；对称证据：每态都要附证据，"接受"不是零成本默认）：
+**先逐条核实（动手前必做）**：对 `{review-artifact}` 的每一条发现，先 Read/Grep 其引用的 `file:line` 与对应 `git diff`，确认问题真实存在，再按 `.agents/rules/review-handshake.md` 的四态处置；完成相称证据后逐条调用 `agent-infra-internal task-ledger {task-id} finding-respond --id {ledger-id} --round {code-round} --status {四态} --evidence {相称证据}`（"接受"不是零成本默认）：
 - `accepted` → 纳入下方分类与修复，证据指向修复点 `file:line`
 - `adjusted` → 采用替代修法，附理由，待 review-code 复核确认
 - `refuted` → 核实判定不成立 / 基于错误 `file:line` / 幻觉 → 不改代码，在报告 `## 对审查发现的逐条核实` 给出反证，待 review-code 复核确认