@fitlab-ai/agent-infra 0.9.12 → 0.9.14

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

@@ -9,10 +9,15 @@ 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.
+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.
 
 ## Boundary / Critical Rules
 
+### Persisted Report Evidence
+
+Before generating the analysis report, read `.agents/rules/evidence-reporting.md`. Record the command, target scope, status or structured result, actual result, and uncovered parts for state checks and successful checks; include decisive raw excerpts only for failures, blocking conditions, or disputes.
+
+- When evaluating candidate qualification or `HD-N`, read `.agents/rules/decision-qualification.md`, audit normalized task constraints/candidates, and record the five qualification-audit tables in the analysis artifact; unknown or unconfirmed constraints must not automatically exclude a candidate
 - This skill only outputs a requirements analysis document (`analysis.md` or `analysis-r{N}.md`) and does not modify any business code
 - Base the analysis strictly on the existing task input, requirements, context, and source information in `task.md`
 - Before generating task or lifecycle Markdown that will be synchronized to an Issue, read `.agents/rules/sync-content-generation.md` and apply its producer-side constraints; the sync path does not parse or rewrite the body
@@ -25,7 +30,7 @@ Version stamp rule: when creating or updating `task.md` frontmatter, read `.agen
 
 After loading workflow / skill / rules instructions, and before any task-state judgment or user-visible conclusion, run the state check first. Reading instruction files does not count as an external-state action or conclusion.
 
-Run these commands and paste the raw output into this round's `## State Check` section:
+Run these commands and record the task/artifact scope, key result, and uncovered parts in this round's `## State Check` section; do not paste complete directory listings or task tails on normal success. Retain decisive raw lines only for failures, blocking conditions, identity mismatches, or disputes:
 
 ```bash
 agent-infra-internal task-snapshot {task-id} --format text
@@ -41,7 +46,7 @@ Before the state check is complete, do not make external-state assertions such a
 
 ## Step Start: Declare the started Event
 
-After resolving the artifact context and before this round's first artifact action, run `agent-infra-internal task-event {task-id} analyze.started --agent {standard-agent-token}` and verify the returned `artifactContext`.
+After resolving the artifact context and before this round's first artifact action, run `agent-infra-internal task-event {task-id} analyze.started --agent {standard-agent-token} --initiator {trigger-initiator} --request-id {request-id} --reason-code {reason-code}` and verify the returned `artifactContext`.
 
 ## Steps
 
@@ -129,6 +134,14 @@ Follow the `analysis` step in `.agents/workflows/feature-development.yaml`:
 
 ### 6. Output Analysis Document
 
+Before writing this round's `{analysis-artifact}`, create the controlled report skeleton:
+
+```bash
+agent-infra-internal task-artifact {task-id} init --family analysis --artifact {analysis-artifact} --locale en
+```
+
+The skeleton contains identity metadata, stable section markers, and required headings only; real analysis content is required before the completion gate can pass. If the finalizer returns one provably safe structural error, call `task-artifact {task-id} repair --family analysis --artifact {analysis-artifact} --expected-sha256 {artifact-sha256} --expected-semantic-digest {semantic-digest}`, then rerun the same finalizer.
+
 > Steps 6–9 are the **Scenario A (normal output)** path. **Scenario B (ask and early-exit)** already finished its state update, task-comment sync, and verification inside step 4 and STOPped, so it does not enter these steps.
 
 Create `.agents/workspace/active/{task-id}/{analysis-artifact}`.
@@ -143,7 +156,7 @@ Create `.agents/workspace/active/{task-id}/{analysis-artifact}`.
 
 ## State Check
 
-> Paste the raw Step 0 state-check command output; each command starts with `$ `.
+> Record the Step 0 state-check command, task/artifact scope, key result, and uncovered parts; each command starts with `$ `. Do not paste complete directory listings or task tails on normal success; retain decisive raw lines only for failures, blocking conditions, identity mismatches, or disputes.
 
 ## Requirement Source
 
@@ -203,7 +216,17 @@ Update `.agents/workspace/active/{task-id}/task.md`:
   - Overwrite the `priority` field in frontmatter with the new value
   - Append a `## Priority Re-estimate` section to this round's analysis artifact `{analysis-artifact}`, recording: `priority {old} → {new} (rationale: {short basis grounded in this analysis})`
   If the re-estimated value matches the current value, skip it: do not write the `## Priority Re-estimate` section. The Flow A sync that follows reads the possibly updated frontmatter and propagates the new value to the Issue automatically.
-After the business fields are updated, run `agent-infra-internal task-event {task-id} analyze.completed --agent {standard-agent-token} --artifact {analysis-artifact} {execution-flag}` so the core atomically records the link, stage, agent, metadata, and Activity Log.
+After writing the local artifact, run the pre-completion gate:
+
+```bash
+agent-infra-internal task-artifact {task-id} finalize-local --family analysis --artifact {analysis-artifact}
+```
+
+- On `status=passed`, save that result's `artifactSha256` and `semanticDigest`; the finalizer has recorded the matching one-shot local provenance intent.
+- On `status=failed` with `repairable=true`, apply only the diagnostic's `replace-line` operation once, then rerun the same command completely; count an attempt only after bytes change, up to 8 attempts.
+- The first repairable failure's `semanticDigest` is retained as the baseline; a retried `status=passed` result must match it. On baseline mismatch, any other failure, no progress, or a repeated diagnostic, 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.
   - {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,10 +9,15 @@ description: >
 # 分析任务
 > `--agent` 取值见 `.agents/rules/task-management.md`「合作者 token 规范」。
 
-若入口业务操作数包含 `--orchestrated`，绑定 `{execution-flag}` = `--orchestrated` 并原样转发给 completed 事件；否则绑定为空。不得从 `orchestration.json`、环境变量或历史产物推断该标记。
+若入口业务操作数包含 `--orchestrated`，绑定 `{execution-flag}` = `--orchestrated` 并原样转发给 completed 事件；否则绑定为空。不得从 `orchestration.json`、环境变量或历史产物推断该标记。生命周期事件还必须携带显式触发信息：编排调用使用 `{trigger-initiator}=orchestrator`，否则使用 `model`；`{request-id}` 是本任务与本轮产物的稳定单行标识，`{reason-code}` 使用 `user-request`、`new-requirement` 或 `upstream-fact-doubt`；started 与 completed 使用同一组值。
 
 ## 行为边界 / 关键规则
 
+### 持久化报告证据
+
+生成分析报告时，先读取 `.agents/rules/evidence-reporting.md`。状态核对和成功检查记录命令、目标范围、状态/结构化结果、实际结果和未覆盖部分；失败、阻塞或争议才附决定性原文摘录。
+
+- 涉及候选资格或 `HD-N` 判断时，先读取 `.agents/rules/decision-qualification.md`，基于 task.md 规范化约束/候选完成资格审计，并在分析产物记录五张资格审计表；不得把来源不明或未确认约束自动升级为排除条件
 - 本技能仅产出需求分析文档（`analysis.md` 或 `analysis-r{N}.md`）—— 不修改任何业务代码
 - 严格基于 `task.md` 中已有的任务输入、需求、上下文和来源信息展开分析
 - 生成会同步到 Issue 的任务或生命周期 Markdown 前，先读取 `.agents/rules/sync-content-generation.md` 并遵循其中的生成端约束；同步端不解析或改写正文
@@ -25,7 +30,7 @@ description: >
 
 在加载 workflow / skill / rules 指令之后、做任何任务状态判断或用户可见结论之前，必须先执行状态核对。指令类文件读取不算对外动作或结论。
 
-运行以下命令，并把原文粘贴到本轮产物的 `## 状态核对` 段：
+运行以下命令，并在本轮产物的 `## 状态核对` 段记录任务/产物范围、关键结果和未覆盖部分；正常成功不粘贴完整目录清单或 `task.md` 尾部。失败、阻塞、身份不一致或争议时，附决定性原文行：
 
 ```bash
 agent-infra-internal task-snapshot {task-id} --format text
@@ -44,7 +49,7 @@ agent-infra-internal task-snapshot {task-id} --format text
 确认前置条件和轮次后、本轮第一个产出动作之前执行：
 
 ```bash
-agent-infra-internal task-event {task-id} analyze.started --agent {standard-agent-token}
+agent-infra-internal task-event {task-id} analyze.started --agent {standard-agent-token} --initiator {trigger-initiator} --request-id {request-id} --reason-code {reason-code}
 ```
 
 ## 执行步骤
@@ -132,6 +137,14 @@ agent-infra-internal task-event {task-id} analyze.started --agent {standard-agen
 
 ### 6. 输出分析文档
 
+在首次写入本轮 `{analysis-artifact}` 前，先创建受控报告骨架：
+
+```bash
+agent-infra-internal task-artifact {task-id} init --family analysis --artifact {analysis-artifact}
+```
+
+骨架只包含身份元数据、稳定 section marker 和必需标题；必须填入真实分析内容后才能通过完成门禁。finalizer 返回可证明的单个结构错误时，使用其 SHA 和 semantic digest 调用 `task-artifact {task-id} repair --family analysis --artifact {analysis-artifact} --expected-sha256 {artifact-sha256} --expected-semantic-digest {semantic-digest}`，然后完整重跑 finalizer。
+
 > 步骤 6–9 属**场景 A（正常产出）**路径。**场景 B（提问早退）**已在步骤 4 内完成状态更新、task 评论同步与校验并 STOP，不进入这些步骤。
 
 创建 `.agents/workspace/active/{task-id}/{analysis-artifact}`。
@@ -146,7 +159,7 @@ agent-infra-internal task-event {task-id} analyze.started --agent {standard-agen
 
 ## 状态核对
 
-> 粘贴第 0 步状态核对命令原文；每条命令以 `$ ` 开头。
+> 记录第 0 步状态核对命令、任务/产物范围、关键结果和未覆盖部分；每条命令以 `$ ` 开头。正常成功不粘贴完整目录清单或 `task.md` 尾部，失败、阻塞、身份不一致或争议时附决定性原文行。
 
 ## 需求来源
 
@@ -173,6 +186,10 @@ agent-infra-internal task-event {task-id} analyze.started --agent {standard-agen
 ## 依赖关系
 - {需要的依赖和与其他模块的协调}
 
+## 资格审计
+
+> 按 `.agents/rules/decision-qualification.md` 填写约束依赖、候选资格、分类结果、上游关系、依赖快照五张表；没有 artifact 上游时保留空表头，不虚构关系。
+
 ## 假设
 
 > 如本次分析依赖某些假设，列在此处；没有则可省略本段。
@@ -204,7 +221,14 @@ agent-infra-internal task-event {task-id} analyze.started --agent {standard-agen
   - 用新值覆盖 frontmatter 的 `priority` 字段
   - 在本轮分析产物 `{analysis-artifact}` 中追加 `## 优先级重估` 段，记录一条：`priority {old} → {new} (rationale: {基于本轮分析的简短依据})`
   若重估值与当前值一致，跳过：不写入 `## 优先级重估` 段。后续 Flow A 同步会读取可能更新过的 frontmatter，并自动把新值同步到 Issue。
-- 完成业务内容更新后执行 `agent-infra-internal task-event {task-id} analyze.completed --agent {standard-agent-token} --artifact {analysis-artifact} {execution-flag}`，由核心原子登记链接、阶段、代理、时间、版本和 Activity Log。
+- 完成本地产物后，先执行本地完成前门禁：
+  ```bash
+  agent-infra-internal task-artifact {task-id} finalize-local --family analysis --artifact {analysis-artifact}
+  ```
+  - `status=passed`：保存本次返回的 `artifactSha256` 和 `semanticDigest`；finalizer 已记录对应的一次性本地 provenance intent。
+  - `status=failed` 且 `repairable=true`：仅按诊断中的 `replace-line` 操作做一次最小修改，然后完整重跑同一命令；实际字节发生变化才计一次 `repairAttempts`，最多 8 次。
+  - 首次可修复失败的 `semanticDigest` 由 finalizer 保留为基线；重试后的 `status=passed` 必须匹配该基线。基线不匹配、其他失败、无进展或重复诊断：停止，不发布 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。
 
 如果 task.md 中存在有效的 `issue_number`，执行以下同步操作（任一失败则跳过并继续）：
 - 调用 `agent-infra-internal platform-issue sync {task-id} --agent {standard-agent-token} --status pending-design-work --fields`

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

@@ -18,18 +18,7 @@
     },
     "artifact": {
       "file_pattern": "analysis.md|analysis-r{N}.md",
-      "required_sections": [
-        "Requirement Source",
-        "Requirement Understanding",
-        "Related Files",
-        "Impact Assessment",
-        "Technical Risks",
-        "Effort and Complexity Assessment",
-        "State Check"
-      ],
-      "required_patterns": [
-        "^\\$ "
-      ]
+      "schema": "analysis"
     },
     "activity-log": {
       "expected_action_pattern": "(Analyze Task|Requirement Analysis) \\(Round \\d+\\)"

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

@@ -18,18 +18,7 @@
     },
     "artifact": {
       "file_pattern": "analysis.md|analysis-r{N}.md",
-      "required_sections": [
-        "需求来源",
-        "需求理解",
-        "相关文件",
-        "影响评估",
-        "技术风险",
-        "工作量和复杂度评估",
-        "状态核对"
-      ],
-      "required_patterns": [
-        "^\\$ "
-      ]
+      "schema": "analysis"
     },
     "activity-log": {
       "expected_action_pattern": "(Analyze Task|Requirement Analysis) \\(Round \\d+\\)"

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

@@ -11,7 +11,7 @@ description: >
 ## Boundary / Critical Rules
 
 - This skill is **read-only** -- do not modify any files
-- Mechanical facts (frontmatter metadata, artifact grouping, git/platform state, and locating the task across the active, blocked, and completed directories) are delegated to the deterministic `ai task status` command. This skill only adds the semantic layer the CLI cannot produce: workflow-stage interpretation, review-verdict parsing, and the next-step recommendation.
+- Mechanical facts (frontmatter metadata, artifact grouping, git/platform state, and locating the task across the active, blocked, and completed directories) are delegated to the deterministic `ai task status` command. This skill only adds the semantic layer the CLI cannot produce: workflow-stage interpretation and review-verdict parsing; the next action comes directly from the CLI's canonical recommendation.
 
 ## Task Context Resolution
 
@@ -45,7 +45,7 @@ This is the semantic layer the CLI does not produce. Using the `Artifacts` group
   - `[pending]` - not started yet
   - `[blocked]` - blocked
   - `[skipped]` - skipped
-- For the latest review artifact of each stage (`review-analysis`, `review-plan`, `review-code`), read the report body and parse its conclusion: the overall verdict (Approved / Changes Requested / Rejected) and the blocker / major / minor counts. The CLI does not parse review bodies, so this reading is required to choose the next action in step 3.
+- For the latest review artifact of each stage (`review-analysis`, `review-plan`, `review-code`), read the report body and parse its conclusion: the overall verdict (Approved / Changes Requested / Rejected) and the blocker / major / minor counts. Use these conclusions only to explain stage status; do not recompute the next action from them.
 
 Present the workflow progress as an overlay on top of the CLI output, marking the latest round and the parsed review verdict, for example:
 
@@ -57,41 +57,20 @@ Workflow progress:
   [pending]    Plan Review
 ```
 
-### 3. Recommend Next Action
-
-Recommend the appropriate next skill based on the current workflow state.
-
-> **⚠️ CONDITION CHECK — you must choose the single matching row in the table below based on `status`, `current_step`, the latest artifacts, and the latest review result:**
->
-> - `status = blocked` -> choose "Task Blocked"
-> - `status = completed` -> choose "Task Completed"
-> - `current_step = requirement-analysis` and the latest analysis artifact is complete -> choose "Analysis Complete"
-> - `current_step = requirement-analysis-review` and the latest analysis review artifact is approved -> choose "Analysis Review Passed"
-> - `current_step = requirement-analysis-review` and the latest analysis review artifact exists but is not approved or has findings -> choose "Analysis Review Has Issues"
-> - `current_step = technical-design` and the latest plan artifact is complete -> choose "Plan Complete"
-> - `current_step = technical-design-review` and the latest plan review artifact is approved -> choose "Plan Review Passed"
-> - `current_step = technical-design-review` and the latest plan review artifact exists but is not approved or has findings -> choose "Plan Review Has Issues"
-> - The latest code artifact exists and there is still no latest code review artifact -> choose "Code Complete"
-> - `current_step = code-review` and the latest code review artifact exists, the verdict is `Approved`, and `Blocker = 0`, `Major = 0`, `Minor = 0` -> choose "Code Review Passed"
-> - `current_step = code-review` and the latest code review artifact exists, but any `Blocker`, `Major`, or `Minor` issue remains, or the verdict is not a clean approval -> choose "Code Review Has Issues"
->
-> **Important: if the latest review report contains any issue at all, do not use the corresponding review-passed row. Use the corresponding has-issues row instead.**
->
-> Before rendering the final output, read `.agents/rules/next-step-output.md`. After selecting an actionable row, invoke `agent-infra-internal agent-client next-steps --skill {next-skill} [--task-ref {task-ref}]` exactly once and render stdout verbatim as `{next-step-commands}`. Do not invoke the helper for `Task Blocked` or `Task Completed`. Append the `Completed at` trailing line last.
-
-| Current State              | next skill        | task ref |
-|----------------------------|-------------------|----------|
-| Analysis Complete          | `review-analysis` | required |
-| Analysis Review Passed     | `plan-task`       | required |
-| Analysis Review Has Issues | `analyze-task`    | required |
-| Plan Complete              | `review-plan`     | required |
-| Plan Review Passed         | `code-task`       | required |
-| Plan Review Has Issues     | `plan-task`       | required |
-| Code Complete              | `review-code`     | required |
-| Code Review Passed         | `commit`          | omitted  |
-| Code Review Has Issues     | `code-task`       | required |
-| Task Blocked               | —                 | —        |
-| Task Completed             | —                 | —        |
+### 3. Display the canonical recommendation
+
+Read only `Recommendation.action` from the `ai task status --task {task-id}` output and use it as the sole source of the next action. Do not recompute an action from `current_step`, the latest files, review prose, or the Activity Log.
+
+When the action is non-empty, perform only this literal action-to-skill conversion, then invoke the shared helper once:
+
+| Recommendation.action | next skill |
+|-----------------------|------------|
+| `analysis` | `analyze-task` |
+| `plan` | `plan-task` |
+| `code` | `code-task` |
+| any other action | same-named skill |
+
+When the action is empty, do not invoke the helper; state that no next skill is currently recommended. Before rendering the final output, read `.agents/rules/next-step-output.md`; invoke `agent-infra-internal agent-client next-steps --skill {next-skill} --task-ref {task-ref}` and render stdout verbatim as `{next-step-commands}`. Append the `Completed at` trailing line last.
 
 ## Notes
 

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

@@ -11,7 +11,7 @@ description: >
 ## 行为边界 / 关键规则
 
 - 本技能是**只读**操作 —— 不修改任何文件
-- 机械数据（frontmatter 元数据、产物分组、Git/Platform 状态，以及跨 active、blocked、completed 三目录定位任务）一律委托给确定性的 `ai task status` 命令。本技能只负责 CLI 无法产出的语义层：工作流阶段解读、审查结论解析、下一步建议。
+- 机械数据（frontmatter 元数据、产物分组、Git/Platform 状态，以及跨 active、blocked、completed 三目录定位任务）一律委托给确定性的 `ai task status` 命令。本技能只负责 CLI 无法产出的语义层：工作流阶段解读和审查结论解析；下一步 action 直接使用 CLI 的 canonical recommendation。
 
 ## 任务上下文解析
 
@@ -45,7 +45,7 @@ ai task status --task {task-id}
   - `[pending]` - 尚未开始
   - `[blocked]` - 被阻塞
   - `[skipped]` - 已跳过
-- 对各阶段最新的审查产物（`review-analysis`、`review-plan`、`review-code`），读取报告正文并解析结论：总体结论（通过 / 需要修改 / 拒绝）与阻塞项 / 主要问题 / 次要问题计数。CLI 不解析审查正文，因此这一步是步骤 3 选择下一步操作的必要输入。
+- 对各阶段最新的审查产物（`review-analysis`、`review-plan`、`review-code`），读取报告正文并解析结论：总体结论（通过 / 需要修改 / 拒绝）与阻塞项 / 主要问题 / 次要问题计数。这些结论只用于阶段状态展示和解释，不得用于重算下一步 action。
 
 把工作流进度作为 CLI 输出之上的叠加层呈现，标注最新轮次与解析出的审查结论，例如：
 
@@ -57,41 +57,20 @@ ai task status --task {task-id}
   [pending]    技术方案审查
 ```
 
-### 3. 建议下一步操作
-
-根据当前工作流状态，建议合适的下一个技能：
-
-> **⚠️ 条件判断 — 你必须先根据 `status`、`current_step`、最新产物和最新审查结果，选择下表中唯一匹配的一行：**
->
-> - `status = blocked` → 选择「任务被阻塞」
-> - `status = completed` → 选择「任务已完成」
-> - `current_step = requirement-analysis` 且最新分析产物已完成 → 选择「分析完成」
-> - `current_step = requirement-analysis-review` 且最新需求分析审查产物通过 → 选择「需求分析审查通过」
-> - `current_step = requirement-analysis-review` 且最新需求分析审查产物存在但未通过或有问题 → 选择「需求分析审查有问题」
-> - `current_step = technical-design` 且最新计划产物已完成 → 选择「计划完成」
-> - `current_step = technical-design-review` 且最新技术方案审查产物通过 → 选择「技术方案审查通过」
-> - `current_step = technical-design-review` 且最新技术方案审查产物存在但未通过或有问题 → 选择「技术方案审查有问题」
-> - 最新实现产物已存在，且尚无最新审查产物 → 选择「实现完成」
-> - `current_step = code-review` 且最新代码审查产物存在，且结论为 `Approved`，同时 `Blocker = 0`、`Major = 0`、`Minor = 0` → 选择「代码审查通过」
-> - `current_step = code-review` 且最新代码审查产物存在，但仍有任何 `Blocker`、`Major` 或 `Minor` 问题，或结论不是无问题通过 → 选择「代码审查有问题」
->
-> **特别注意：只要最新审查报告中存在任何问题，就不能使用对应「审查通过」行。必须改用对应「审查有问题」行。**
->
-> 渲染最终输出前先读取 `.agents/rules/next-step-output.md`。选中可执行行后只调用一次 `agent-infra-internal agent-client next-steps --skill {next-skill} [--task-ref {task-ref}]`，将 stdout 原样输出为 `{next-step-commands}`；`任务被阻塞` 与 `任务已完成` 不调用 helper。最后追加 `Completed at` 收尾行。
-
-| 当前状态           | next skill        | task ref |
-|--------------------|-------------------|----------|
-| 分析完成           | `review-analysis` | required |
-| 需求分析审查通过   | `plan-task`       | required |
-| 需求分析审查有问题 | `analyze-task`    | required |
-| 计划完成           | `review-plan`     | required |
-| 技术方案审查通过   | `code-task`       | required |
-| 技术方案审查有问题 | `plan-task`       | required |
-| 实现完成           | `review-code`     | required |
-| 代码审查通过       | `commit`          | omitted  |
-| 代码审查有问题     | `code-task`       | required |
-| 任务被阻塞         | —                 | —        |
-| 任务已完成         | —                 | —        |
+### 3. 展示 canonical recommendation
+
+只读取 `ai task status --task {task-id}` 输出中的 `Recommendation.action`，将其作为唯一下一步来源。不要根据 `current_step`、目录中的最新产物、审查正文或 Activity Log 再计算 action。
+
+当 action 非空时，仅做以下 action 到 skill 的字面转换，然后调用一次统一 helper：
+
+| Recommendation.action | next skill |
+|-----------------------|------------|
+| `analysis` | `analyze-task` |
+| `plan` | `plan-task` |
+| `code` | `code-task` |
+| 其他 action | 同名 skill |
+
+`action` 为空时不调用 helper，只说明当前没有可推荐的下一技能。渲染最终输出前先读取 `.agents/rules/next-step-output.md`；helper 命令为 `agent-infra-internal agent-client next-steps --skill {next-skill} --task-ref {task-ref}`，stdout 原样作为 `{next-step-commands}` 下一步命令。最后追加 `Completed at` 收尾行。
 
 ## 注意事项
 

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

@@ -23,7 +23,7 @@ The skill still owns the security-alert API. When a related task exists, Step 7
 
 ### 1. Retrieve Alert Information
 
-Read `.agents/rules/security-alerts.md` before this step, then run `bash .agents/scripts/security-alerts.sh read-codescan --number {alert-number}` and parse its JSON result to fetch the alert details.
+Read `.agents/rules/security-alerts.md` before this step, then run `agent-infra-internal platform-security read --kind code-scanning --number {alert-number}` and parse its JSON result to fetch the alert details.
 
 Verify that the alert is in the `open` state. If it is already dismissed or fixed, inform the user and exit.
 
@@ -71,7 +71,7 @@ Confirm? (y/N)
 
 ### 6. Execute the Dismissal
 
-Write the user's explanation to `{comment-file}`, then run `bash .agents/scripts/security-alerts.sh dismiss-codescan --number {alert-number} --reason {api-reason} --comment-file {comment-file}`. Parse the JSON result and continue only when the dismissal is `applied` or `no-op`.
+Write the user's explanation to `{comment-file}`, then run `agent-infra-internal platform-security dismiss --kind code-scanning --number {alert-number} --reason {api-reason} --comment-file {comment-file}`. Parse the JSON result and continue only when the dismissal is `applied` or `no-op`.
 
 **API reason mapping** (per the Code Scanning API):
 - False Positive -> `false positive`

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

@@ -23,7 +23,7 @@ description: >
 
 ### 1. 获取告警信息
 
-执行前先读取 `.agents/rules/security-alerts.md`，然后运行 `bash .agents/scripts/security-alerts.sh read-codescan --number {alert-number}`，解析其 JSON 结果获取告警详情。
+执行前先读取 `.agents/rules/security-alerts.md`，然后运行 `agent-infra-internal platform-security read --kind code-scanning --number {alert-number}`，解析其 JSON 结果获取告警详情。
 
 验证告警处于 `open` 状态。如果已被关闭/修复，告知用户并退出。
 
@@ -71,7 +71,7 @@ Code Scanning 告警 #{alert-number}
 
 ### 6. 执行关闭
 
-将用户说明写入 `{comment-file}`，然后运行 `bash .agents/scripts/security-alerts.sh dismiss-codescan --number {alert-number} --reason {api-reason} --comment-file {comment-file}`。解析 JSON 结果，仅当关闭状态为 `applied` 或 `no-op` 时继续。
+将用户说明写入 `{comment-file}`，然后运行 `agent-infra-internal platform-security dismiss --kind code-scanning --number {alert-number} --reason {api-reason} --comment-file {comment-file}`。解析 JSON 结果，仅当关闭状态为 `applied` 或 `no-op` 时继续。
 
 **API reason 映射**（按 Code Scanning API）：
 - 误报 -> `false positive`

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

@@ -23,7 +23,7 @@ The skill still owns the security-alert API. When a related task exists, Step 7
 
 ### 1. Retrieve Alert Information
 
-Read `.agents/rules/security-alerts.md` before this step, then run `bash .agents/scripts/security-alerts.sh read-dependabot --number {alert-number}` and parse its JSON result to fetch the alert details.
+Read `.agents/rules/security-alerts.md` before this step, then run `agent-infra-internal platform-security read --kind dependabot --number {alert-number}` and parse its JSON result to fetch the alert details.
 
 Verify that the alert is in the `open` state. If it is already dismissed or fixed, inform the user and exit.
 
@@ -77,7 +77,7 @@ Confirm? (y/N)
 
 ### 6. Execute the Dismissal
 
-Write the user's explanation to `{comment-file}`, then run `bash .agents/scripts/security-alerts.sh dismiss-dependabot --number {alert-number} --reason {api-reason} --comment-file {comment-file}`. Parse the JSON result and continue only when the dismissal is `applied` or `no-op`.
+Write the user's explanation to `{comment-file}`, then run `agent-infra-internal platform-security dismiss --kind dependabot --number {alert-number} --reason {api-reason} --comment-file {comment-file}`. Parse the JSON result and continue only when the dismissal is `applied` or `no-op`.
 
 **API reason mapping**:
 - False Positive -> `not_used` or `inaccurate`

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

@@ -23,7 +23,7 @@ description: >
 
 ### 1. 获取告警信息
 
-执行前先读取 `.agents/rules/security-alerts.md`，然后运行 `bash .agents/scripts/security-alerts.sh read-dependabot --number {alert-number}`，解析其 JSON 结果获取告警详情。
+执行前先读取 `.agents/rules/security-alerts.md`，然后运行 `agent-infra-internal platform-security read --kind dependabot --number {alert-number}`，解析其 JSON 结果获取告警详情。
 
 验证告警处于 `open` 状态。如果已被关闭/修复，告知用户并退出。
 
@@ -77,7 +77,7 @@ CVE：{cve-id}
 
 ### 6. 执行关闭
 
-将用户说明写入 `{comment-file}`，然后运行 `bash .agents/scripts/security-alerts.sh dismiss-dependabot --number {alert-number} --reason {api-reason} --comment-file {comment-file}`。解析 JSON 结果，仅当关闭状态为 `applied` 或 `no-op` 时继续。
+将用户说明写入 `{comment-file}`，然后运行 `agent-infra-internal platform-security dismiss --kind dependabot --number {alert-number} --reason {api-reason} --comment-file {comment-file}`。解析 JSON 结果，仅当关闭状态为 `applied` 或 `no-op` 时继续。
 
 **API reason 映射**：
 - 误报 -> `not_used` 或 `inaccurate`

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

@@ -9,16 +9,22 @@ 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.
+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.
 
 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
 
+### Persisted Report Evidence
+
+Before generating the implementation report, read `.agents/rules/evidence-reporting.md`. Successful tests record the command, target scope, status or structured result, actual result, and uncovered parts; failures, blocking conditions, or disputes retain a reproducible entry point, exact location, and decisive excerpt instead of complete successful stdout.
+
+- When evaluating candidate qualification or `HD-N`, read `.agents/rules/decision-qualification.md`, audit normalized task constraints/candidates, and record the five qualification-audit tables in the implementation report; unknown or unconfirmed constraints must not automatically exclude a candidate
 - Follow the latest plan artifact: `plan.md` or `plan-r{N}.md`
 - Before generating task or lifecycle Markdown that will be synchronized to an Issue, read `.agents/rules/sync-content-generation.md` and apply its producer-side constraints; the sync path does not parse or rewrite the body
 - Read `.agents/rules/compatibility-policy.md` before implementation. Implement only the compatibility budget explicitly approved by the plan; never retain old branches, result contracts, or migration shims merely to be “safe”
 - 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
+- Before `code.completed`, the implementation report must pass `task-artifact ... finalize-local --family code`; follow `.agents/rules/local-artifact-repair.md` for any provably safe minimal structural repair in that same report, and pass only that successful call's digests to the completion event
 - 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` and determine whether implementation is required, then run `decision-upsert --id {HD-N} --stage code --artifact {code-artifact} --needs-implementation {true|false}`. Do not scan ids, assemble ledger rows, ask mid-flow, or silently expand scope
 - Do not invoke the `commit` skill or push to a remote; after tests pass, call the shared commit core with `delivery: { mode: 'local' }` to create the local checkpoint. The durable intent must close only after the checkpoint and task state sync succeed; only then emit `code.completed`
 - Create a new code artifact for each round and never overwrite an older one
@@ -30,7 +36,7 @@ Version stamp rule: when creating or updating `task.md` frontmatter, read `.agen
 
 After loading workflow / skill / rules instructions, and before any task-state judgment or user-visible conclusion, run the state check first.
 
-Run these commands and paste the raw output into this round's `## State Check` section:
+Run these commands and record the task/artifact scope, key result, and uncovered parts in this round's `## State Check` section; do not paste complete directory listings or task tails on normal success. Retain decisive raw lines only for failures, blocking conditions, identity mismatches, or disputes:
 
 ```bash
 agent-infra-internal task-snapshot {task-id} --format text
@@ -44,7 +50,7 @@ agent-infra-internal task-snapshot {task-id} --format text
 
 ## Step Start: Write the started Marker
 
-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 {standard-agent-token}`. 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`.
+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 {standard-agent-token} --initiator {trigger-initiator} --request-id {request-id} --reason-code {reason-code}`. 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
 
@@ -60,7 +66,7 @@ Read `reference/branch-management.md`, ensure the current branch matches the tas
 
 **Mandatory; do not skip.** If task.md has a valid `issue_number`, run `agent-infra-internal platform-issue sync {task-id} --agent {standard-agent-token} --milestone specific`.
 
-> If the milestone remains `X.Y.x`, step 11 `task-verify code.completed` blocks through the typed milestone check.
+> If the milestone remains `X.Y.x`, step 12 `task-verify code.completed` blocks through the typed milestone check.
 
 ### 4. Determine Mode and Round
 
@@ -106,28 +112,54 @@ When triaging a test failure or unexpected behavior, first read `.agents/rules/d
 
 After tests pass, call the shared commit core with `agent-infra-internal git-workflow commit --input {checkpoint-input}`. Pass `delivery: { "mode": "local" }`, explicit paths, expected HEAD/tree, task ref, agent, and the code round. This creates only a local checkpoint and does not contact a remote. The core writes a durable intent before committing and removes it after task-writer synchronization; do not emit `code.completed` if either checkpoint or task synchronization fails.
 
+After the checkpoint succeeds, when task.md has an `issue_number`, run `agent-infra-internal platform-issue sync {task-id} --agent {standard-agent-token} --in-labels from-diff --base {delivery-base-ref}`. The task-bound `delivery_base_ref` is the only source for Issue `in:` evidence; record a warning and stop this round without emitting `code.completed` if this sync fails.
+
 ### 9. Write the Code Report
 
+Before writing this round's `{code-artifact}`, create the controlled report skeleton:
+
+```bash
+agent-infra-internal task-artifact {task-id} init --family code --artifact {code-artifact} --locale en
+```
+
+The skeleton contains identity metadata, stable section markers, and required headings only; real implementation and verification content is required before the completion gate can pass. If the finalizer returns one provably safe structural error, call `task-artifact {task-id} repair --family code --artifact {code-artifact} --expected-sha256 {artifact-sha256} --expected-semantic-digest {semantic-digest}`, then rerun the same finalizer.
+
 Create `.agents/workspace/active/{task-id}/{code-artifact}`.
 
 > Read `reference/report-template.md` before writing the report.
 
-### 10. Update Task Status
+### 10. Pre-completion Report Gate
+
+After writing the report and before publishing `code.completed`, read and follow `.agents/rules/local-artifact-repair.md` and run:
+
+```bash
+finalizer=$(agent-infra-internal task-artifact {task-id} finalize-local --family code --artifact {code-artifact})
+status=$?
+echo "$finalizer"
+```
+
+- `status=0` with `finalizer.status="passed"`: bind `{artifact-sha256}` and `{semantic-digest}` from this result.
+- `status=1` with `repairable=true` and a diagnostic explicitly describing a one-line replacement: confirm task, round, artifact, and provenance are unchanged; edit only that `code*.md` once, confirm the bytes changed, then rerun the same command completely.
+- For any other failure, lack of progress, repeated diagnostic, or eight actual report edits, stop without publishing `code.completed`.
+
+Do not rescan or manually write digest data; the completion event must include `--artifact-sha256 {artifact-sha256} --semantic-digest {semantic-digest}` from the successful finalizer result.
+
+### 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} --artifact {code-artifact} --files-modified {n} --tests-passed {n} {execution-flag}`; in fix mode use `--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} {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.
 
-If task.md has a valid `issue_number`, read `.agents/rules/issue-sync.md`, then:
+If task.md has a valid `issue_number`, read `.agents/rules/issue-sync.md`, then (status/comment failures follow the warning rules; an Issue `in:` evidence failure must not emit `code.completed`):
 - Run `agent-infra-internal platform-issue sync {task-id} --agent {standard-agent-token} --status in-progress`
 - Run `agent-infra-internal platform-comment sync {task-id} --kind task --agent {standard-agent-token}`
 - Run `agent-infra-internal platform-comment sync {task-id} --kind artifact --artifact {code-artifact} --agent {standard-agent-token}`
 
-### 11. Run Completion Gate
+### 12. Run Completion Gate
 
 ```bash
 agent-infra-internal task-verify {task-id} code.completed --artifact {code-artifact} --format text
 ```
 
-### 12. Tell the User
+### 13. Tell the User
 
 Use `reference/output-template.md` (or `reference/fix-mode.md` in fix mode) and render the selected next-step commands through the shared helper. Do not push, create a PR, or invoke the `commit` skill here.