@fitlab-ai/agent-infra 0.11.15 → 0.12.1

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

@@ -53,16 +53,23 @@ node -p "'v' + require('./package.json').version"
 
 ## 创建第一个任务
 
+先通过统一 resolver 取得宿主任务根，供以下示例使用：
+
+```bash
+TASK_WORKSPACE_ROOT=$(agent-infra-internal task-workspace resolve --boundary host | node -e 'let input="";process.stdin.setEncoding("utf8");process.stdin.on("data",chunk=>input+=chunk);process.stdin.on("end",()=>process.stdout.write(JSON.parse(input).root));')
+```
+
 1. 将任务模板复制到活跃工作区：
 
 ```bash
-cp .agents/templates/task.md .agents/workspace/active/task-001.md
+mkdir -p "$TASK_WORKSPACE_ROOT/active/TASK-20260101-120000"
+cp .agents/templates/task.md "$TASK_WORKSPACE_ROOT/active/TASK-20260101-120000/task.md"
 ```
 
 2. 填写任务元数据：
 
 ```yaml
-id: task-001
+id: TASK-20260101-120000
 type: feature          # feature | bugfix | refactor | docs | chore
 status: active         # active | blocked | completed
 assigned_to: claude    # claude | codex | antigravity | opencode | human
@@ -92,7 +99,7 @@ Claude Code 擅长代码库探索和理解文件间的复杂关系。
 agy
 
 # 示例提示：
-# "基于 .agents/workspace/active/task-001.md 中的分析结果，
+# "基于 $TASK_WORKSPACE_ROOT/active/TASK-20260101-120000/task.md 中的分析结果，
 #  创建技术设计方案。定义接口并概述实现思路。"
 ```
 
@@ -103,7 +110,7 @@ agy
 codex
 
 # 示例提示：
-# "实现 .agents/workspace/active/task-001.md 中描述的变更。
+# "实现 $TASK_WORKSPACE_ROOT/active/TASK-20260101-120000/task.md 中描述的变更。
 #  遵循设计部分。为此工作创建新分支。"
 ```
 
@@ -130,7 +137,8 @@ claude
 
 ```bash
 # 快速缺陷修复工作流
-cp .agents/templates/task.md .agents/workspace/active/bugfix-001.md
+mkdir -p "$TASK_WORKSPACE_ROOT/active/TASK-20260101-120000"
+cp .agents/templates/task.md "$TASK_WORKSPACE_ROOT/active/TASK-20260101-120000/task.md"
 # 编辑任务，然后：
 # 1. 使用 Claude Code 分析
 # 2. 使用 Codex/OpenCode 修复
@@ -144,7 +152,8 @@ cp .agents/templates/task.md .agents/workspace/active/bugfix-001.md
 3. **报告**：从模板生成审查报告。
 
 ```bash
-cp .agents/templates/review-report.md .agents/workspace/active/review-pr-42.md
+mkdir -p "$TASK_WORKSPACE_ROOT/active/TASK-20260101-120001"
+cp .agents/templates/review-report.md "$TASK_WORKSPACE_ROOT/active/TASK-20260101-120001/review-report.md"
 # 使用 Claude Code 填写审查内容
 ```
 
@@ -156,7 +165,8 @@ cp .agents/templates/review-report.md .agents/workspace/active/review-pr-42.md
 4. **验证**（Claude Code）：确保没有回归问题，运行测试。
 
 ```bash
-cp .agents/templates/task.md .agents/workspace/active/refactor-001.md
+mkdir -p "$TASK_WORKSPACE_ROOT/active/TASK-20260101-120002"
+cp .agents/templates/task.md "$TASK_WORKSPACE_ROOT/active/TASK-20260101-120002/task.md"
 # 按照 .agents/workflows/refactoring.yaml 中的重构工作流执行
 ```
 
@@ -165,7 +175,8 @@ cp .agents/templates/task.md .agents/workspace/active/refactor-001.md
 在 AI 工具之间切换时，创建交接文档：
 
 ```bash
-cp .agents/templates/handoff.md .agents/workspace/active/handoff-task-001-phase2.md
+mkdir -p "$TASK_WORKSPACE_ROOT/active/TASK-20260101-120003"
+cp .agents/templates/handoff.md "$TASK_WORKSPACE_ROOT/active/TASK-20260101-120003/handoff.md"
 ```
 
 填写：

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

@@ -35,24 +35,19 @@ This dual-config approach ensures every AI tool receives appropriate project con
     code-review.yaml            # Code review workflow
     refactoring.yaml            # Refactoring workflow
   rules/                        # Collaboration rule index (see rules/README.md)
-  workspace/                    # Runtime workspace (git-ignored)
-    active/                     # Currently active tasks
-    blocked/                    # Blocked tasks
-    completed/                  # Completed tasks
-    logs/                       # Collaboration logs
-
 .claude/                        # Claude Code specific config
   CLAUDE.md                     # Project instructions for Claude
   commands/                     # Slash commands
   settings.json                 # Claude settings
 ```
 
-The whole `.agents/workspace/` tree is runtime-only and git-ignored. `active/`
-contains current tasks, `blocked/` contains paused tasks, `completed/` contains
-finished tasks, and `archive/` stores archived history. Runtime logs and process
-evidence may also be created below this root. Do not place content here that must
-be shared through Git; collaboration rules, templates, and workflows belong in
-the version-controlled `.agents/` tree.
+The host task workspace root is `~/.agent-infra/task-workspaces/<project-key>`;
+the container root is `/task-workspace`. Resolve the current host root with
+`agent-infra-internal task-workspace resolve --boundary host` and a task's exact
+directory with `agent-infra-internal task-context resolve --task <task-id>`.
+`active/`, `blocked/`, `completed/`, `archive/`, and `active/.short-ids.json` live
+under that root and contain runtime data. The `<task-workspace>` placeholder used
+in these guides means the resolver's returned root; it is not a repository path.
 
 ## Collaboration Model
 
@@ -101,7 +96,7 @@ Each AI tool has different strengths. Use them accordingly:
 ## Quick Start
 
 1. **Read the quick start guide**: See `QUICKSTART.md` for step-by-step instructions.
-2. **Create a task**: Copy `.agents/templates/task.md` to `.agents/workspace/active/`.
+2. **Create a task**: Use the `create-task` workflow; the host writes task data to the project task root.
 3. **Assign to an AI**: Update the `assigned_to` field in the task metadata.
 4. **Run the workflow**: Follow the appropriate workflow in `.agents/workflows/`.
 5. **Hand off**: When switching AIs, create a handoff document from the template.
@@ -386,7 +381,7 @@ No. Claude Code reads from `.claude/CLAUDE.md`, and all other tools read from `A
 
 ### Q: How do tasks get passed between AI tools?
 
-Through handoff documents stored in `.agents/workspace/`. Each handoff includes context, progress, and next steps so the receiving AI can continue seamlessly.
+Through handoff documents stored in `<task-workspace>/`. Each handoff includes context, progress, and next steps so the receiving AI can continue seamlessly.
 
 ### Q: What if an AI tool doesn't support AGENTS.md?
 
@@ -398,4 +393,4 @@ It's not recommended. The workflow model is sequential -- one AI per phase. Para
 
 ### Q: Where are runtime files stored?
 
-In `.agents/workspace/`, which is git-ignored. Only templates and workflow definitions in `.agents/` are version-controlled.
+In `<task-workspace>/`, which is git-ignored. Only templates and workflow definitions in `.agents/` are version-controlled.

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

@@ -35,22 +35,18 @@
     code-review.yaml            # 代码审查工作流
     refactoring.yaml            # 重构工作流
   rules/                        # 协作规则索引（见 rules/README.md）
-  workspace/                    # 运行时工作区（已被 git ignore）
-    active/                     # 当前活跃任务
-    blocked/                    # 被阻塞的任务
-    completed/                  # 已完成的任务
-    logs/                       # 协作日志
-
 .claude/                        # Claude Code 专属配置
   CLAUDE.md                     # Claude 项目指令
   commands/                     # 斜杠命令
   settings.json                 # Claude 设置
 ```
 
-整个 `.agents/workspace/` 目录树都只保存运行时数据，并被 git ignore。`active/`
-保存当前任务，`blocked/` 保存暂停任务，`completed/` 保存已完成任务，`archive/`
-保存归档历史；运行时日志和过程证据也可能出现在该根目录下。不要在这里存放必须
-通过 Git 共享的内容；协作规则、模板和工作流应放在受版本控制的 `.agents/` 目录中。
+宿主任务根为 `~/.agent-infra/task-workspaces/<project-key>`，容器任务根为
+`/task-workspace`。使用 `agent-infra-internal task-workspace resolve --boundary host`
+取得当前项目的宿主根，使用 `agent-infra-internal task-context resolve --task <task-id>`
+取得某个任务的精确目录。`active/`、`blocked/`、`completed/`、`archive/` 和
+`active/.short-ids.json` 都位于任务根中；这些路径只保存运行时数据，不通过 Git
+共享。文中的 `<task-workspace>` 表示由上述 resolver 返回的根，不是仓库内目录。
 
 ## 协作模型
 
@@ -99,7 +95,7 @@
 ## 快速入门
 
 1. **阅读快速入门指南**：参见 `QUICKSTART.md` 获取分步说明。
-2. **创建任务**：将 `.agents/templates/task.md` 复制到 `.agents/workspace/active/`。
+2. **创建任务**：通过 `create-task` 工作流创建任务；任务数据由宿主写入项目任务根。
 3. **分配给 AI**：更新任务元数据中的 `assigned_to` 字段。
 4. **执行工作流**：按照 `.agents/workflows/` 中相应的工作流执行。
 5. **交接**：切换 AI 时，从模板创建交接文档。
@@ -384,7 +380,7 @@ agent-infra-internal task-verify {task-id} <verification-event> [--artifact <art
 
 ### Q：任务如何在 AI 工具之间传递？
 
-通过存储在 `.agents/workspace/` 中的交接文档。每份交接文档包含上下文、进度和后续步骤，让接收方 AI 能无缝接续。
+通过存储在 `<task-workspace>/` 中的交接文档。每份交接文档包含上下文、进度和后续步骤，让接收方 AI 能无缝接续。
 
 ### Q：如果某个 AI 工具不支持 AGENTS.md 怎么办？
 
@@ -396,4 +392,4 @@ agent-infra-internal task-verify {task-id} <verification-event> [--artifact <art
 
 ### Q：运行时文件存储在哪里？
 
-在 `.agents/workspace/` 中，该目录已被 git ignore。只有 `.agents/` 中的模板和工作流定义受版本控制。
+在 `<task-workspace>/` 中，该目录已被 git ignore。只有 `.agents/` 中的模板和工作流定义受版本控制。

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

@@ -22,7 +22,7 @@ Comments use `platform-comment`; Issue resources use `platform-issue`:
 ```bash
 agent-infra-internal platform-comment list --issue <issue-token> [--cwd <path>]
 agent-infra-internal platform-comment recover --issue <issue-token> --task-id <TASK-id> \
-  --output <.agents/workspace/.restore-staging-*/task.md> [--cwd <path>]
+  --output <<task-workspace>/.restore-staging-*/task.md> [--cwd <path>]
 agent-infra-internal platform-issue inspect {task-id}
 agent-infra-internal platform-issue create {task-id} --agent {standard-agent-token}
 agent-infra-internal platform-issue bind {task-id} --issue {issue-token} --agent {standard-agent-token}

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

@@ -26,7 +26,7 @@
 agent-infra-internal platform-context resolve [--cwd <path>]
 agent-infra-internal platform-comment list --issue <issue-token> [--cwd <path>]
 agent-infra-internal platform-comment recover --issue <issue-token> --task-id <TASK-id> \
-  --output <.agents/workspace/.restore-staging-*/task.md> [--cwd <path>]
+  --output <<task-workspace>/.restore-staging-*/task.md> [--cwd <path>]
 agent-infra-internal platform-comment owner <task-ref>
 agent-infra-internal platform-comment sync <task-ref> \
   --kind task|artifact|summary|cancel --agent {standard-agent-token} \

package/templates/.agents/rules/lifecycle-orchestration.en.md

@@ -10,7 +10,7 @@
 
 ## Current Execution Records
 
-`orchestration.json` records stages, model policy, child identity, and actual outcomes. Records use the current structure; trusted local operators may correct them and rerun validation. Existing task write locks and atomic writes protect updates.
+`orchestration.json` records stages, model policy, child identity, and actual outcomes. Records use the current structure; trusted local operators may correct them and rerun validation. Stages for one task run sequentially; atomic writes and identity/state validation continue to protect state updates.
 
 ## Current Host
 

package/templates/.agents/rules/lifecycle-orchestration.zh-CN.md

@@ -10,7 +10,7 @@
 
 ## 当前执行记录
 
-`orchestration.json` 记录阶段、模型策略、child 身份及实际执行结果。记录必须符合当前结构；本地操作者可直接修正后重新校验。已有任务写锁与原子写入继续保护写操作。
+`orchestration.json` 记录阶段、模型策略、child 身份及实际执行结果。记录必须符合当前结构；本地操作者可直接修正后重新校验。同一任务的阶段按序调用；原子写入、身份校验和状态校验继续保护状态更新。
 
 ## 当前宿主
 

package/templates/.agents/rules/next-step-output.en.md

@@ -17,7 +17,7 @@ This file defines three **independent** rules for a skill's "notify-user / Next
 
 - **Next-step TUI commands** (`/analyze-task`, `/{{project}}:review-code`, `$create-pr`, etc., including commands inside Markdown table cells) → always use `{task-ref}` (short id).
 - **"Task info" / "Task status" structured field lines** → show full id and short id together: `- Task ID: {task-id} (short id {task-ref})`.
-- **Report titles** (`Task {task-id} ... completed`) and **artifact paths** (`.agents/workspace/active/{task-id}/...`) → keep the full `{task-id}` (physical path and archive key, must not change).
+- **Report titles** (`Task {task-id} ... completed`) and **artifact paths** (`<task-workspace>/active/{task-id}/...`) → keep the full `{task-id}` (physical path and archive key, must not change).
 
 ## Unified Client Command Rendering
 
@@ -39,7 +39,7 @@ agent-infra-internal agent-client next-steps \
 
 ## Obtaining the short id (`{task-ref}`)
 
-The single source of truth for short ids is the registry `.agents/workspace/active/.short-ids.json` (via `task-short-id.js`). **Never** read the `short_id` field from task.md frontmatter (that field is not authoritative).
+The single source of truth for short ids is the registry `<task-workspace>/active/.short-ids.json` (via `task-short-id.js`). **Never** read the `short_id` field from task.md frontmatter (that field is not authoritative).
 
 Once the full `$task_id` is resolved, use the snippet below to look up the short id; it returns bare `NN` on hit and falls back to the full `TASK-id` on miss:
 

package/templates/.agents/rules/next-step-output.zh-CN.md

@@ -17,7 +17,7 @@
 
 - **下一步 TUI 命令**（`/analyze-task`、`/{{project}}:review-code`、`$create-pr` 等，含 Markdown 表格单元格内的命令）→ 一律用 `{task-ref}`（短号）。
 - **「任务信息」/「任务状态」结构化字段行** → 完整 ID 与短号同显：`- 任务 ID：{task-id}（短号 {task-ref}）`。
-- **报告标题**（`任务 {task-id} ... 完成`）与**产出文件路径**（`.agents/workspace/active/{task-id}/...`）→ 保持完整 `{task-id}`（物理路径与归档键，不可改）。
+- **报告标题**（`任务 {task-id} ... 完成`）与**产出文件路径**（`<task-workspace>/active/{task-id}/...`）→ 保持完整 `{task-id}`（物理路径与归档键，不可改）。
 
 ## 统一客户端命令渲染
 
@@ -39,7 +39,7 @@ agent-infra-internal agent-client next-steps \
 
 ## 取短号（`{task-ref}`）
 
-短号唯一真源是注册表 `.agents/workspace/active/.short-ids.json`（经 `task-short-id.js`）。**禁止**读取 task.md frontmatter 的 `short_id` 字段（该字段不可信）。
+短号唯一真源是注册表 `<task-workspace>/active/.short-ids.json`（经 `task-short-id.js`）。**禁止**读取 task.md frontmatter 的 `short_id` 字段（该字段不可信）。
 
 在已解析出完整 `$task_id` 后，用以下片段反查短号；命中返回裸数字 `NN`，未命中自动回退完整 `TASK-id`：
 

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

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

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

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

package/templates/.agents/rules/release-commands.en.md

@@ -19,6 +19,9 @@ The result contains `history`, `pullRequests`, `closingIssues`, and commit `auth
 - Render an identity as `@login` only when `resolution` is `platform-user` or `platform-noreply` and `login` is non-empty.
 - Exclude `resolution: unresolved` identities from the release-note contributor list. Never infer a login from a name, email address, domain, brand, or same-named platform account, and never substitute a guessed personal or organization account.
 - Do not publish unresolved identity emails or identity-verification TODOs in Release notes. Record any required investigation outside the release workflow without creating a platform mention.
+- Use plain-text `@login` mentions in Release notes; do not wrap mentions in Markdown links.
+- **Dependabot-specific normalization**: Typed context may return the same Dependabot automation account as `app/dependabot` or `dependabot[bot]`. For these resolved identities, render release-note items and Contributors as plain-text `@dependabot`, and merge counts under the normalized `@dependabot`. Do not output `@app/dependabot` or `@dependabot[bot]`, and do not turn `@dependabot` into a Markdown link.
+- This Dependabot mapping is an explicit exception for this project's Release notes. Use the typed `login` for all other identities; do not infer mappings from brands or similar names.
 
 ## Stage Release Notes
 

package/templates/.agents/rules/release-commands.zh-CN.md

@@ -19,6 +19,9 @@ agent-infra-internal platform-release-notes context \
 - 只有 `resolution` 为 `platform-user` 或 `platform-noreply` 且 `login` 非空的身份可以渲染为 `@login`。
 - `resolution: unresolved` 的身份不得进入发布说明的贡献者列表；不得从 Name、邮箱、域名、品牌或同名平台账号推断 login，也不得替换成推测的个人或组织账号。
 - 不得把未解析身份的邮箱或身份确认 TODO 写入可发布的 Release notes。需要调查时仅在发布流程外记录，不得产生平台 mention。
+- Release notes 中的 mention 使用纯文本 `@login`，不要用 Markdown 链接包装 mention。
+- **Dependabot 专用规范化**：typed context 可能将同一 Dependabot 自动化账号返回为 `app/dependabot` 或 `dependabot[bot]`。对于 `resolution` 已解析的这些身份，发布说明条目和 Contributors 统一使用纯文本 `@dependabot`；按规范化后的 `@dependabot` 合并计数。不要输出 `@app/dependabot` 或 `@dependabot[bot]`，也不要把 `@dependabot` 改成 Markdown 链接。
+- 该 Dependabot 映射是本项目发布说明的明确例外；其他身份继续使用 typed `login`，不得按品牌或相似名称类推。
 
 ## Stage Release notes
 

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

@@ -86,8 +86,6 @@ Other skills continue past deferrable writes according to their local delivery g
 
 **Human counts** (`ai task log`): review step rows fold two human counts into the NOTE verdict text, comma-separated, right after `blockers/major/minor`, with fixed English labels `Manual-validation: {e}, Human-decision: {h}`. `Human-decision` (`{h}`) maps canonical step prefixes (`Review Analysis` / `Review Plan` / `Review Code`) to `analysis` / `plan` / `code`, then counts current pending rows in `## Review Disagreement Ledger` / `## 审查分歧账本` for that stage with `status = needs-human-decision`, excluding rows already marked `human-decided`. `Manual-validation` (`{e}`) parses the `Manual-validation: {n}` source field from the review done note (normalized to the same field when displayed), defaulting to `0`. Non-review rows carry no human counts.
 
-**Gate** (`checkActivityLog`): when computing the "latest action / freshness" it skips `[started]` lines (ascending-order and format checks still cover every line), so a started marker never satisfies a skill's `expected_action_pattern`.
-
 **Skills that write started**: every workflow skill that **appends entries to a task's `## Activity Log`** writes started, so the STARTED column stays uniformly complete across the whole `ai task log` table. Two forms, depending on whether task.md already exists:
 
 - **Standard form (task.md already exists)** — append the started line when that round's real work begins (after prerequisites, before the first artifact action) and the done line on completion:

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

@@ -89,8 +89,6 @@
 
 **人工计数**（`ai task log`）：审查步骤行把两项人工计数并入 NOTE 的 verdict 文本，逗号分隔、紧随 `blockers/major/minor`，固定英文标签 `Manual-validation: {e}, Human-decision: {h}`。`Human-decision`（`{h}`）按 canonical 步骤名前缀（`Review Analysis` / `Review Plan` / `Review Code`）映射到 `analysis` / `plan` / `code`，统计 `## 审查分歧账本` 中对应阶段 `status = needs-human-decision` 的当前待裁决数量，不包含已 `human-decided` 的行；`Manual-validation`（`{e}`）解析 review done note 中的 `Manual-validation: {n}` 源字段（展示时归一化为同一字段），缺失为 `0`。非审查步骤不附加人工计数。
 
-**gate**（`checkActivityLog`）：计算「最新 action / freshness」时跳过 `[started]` 行（升序与格式校验仍覆盖全部行），故 started 标记不会污染各 SKILL 的 `expected_action_pattern`。
-
 **写 started 的 SKILL**：所有**会向某个任务的 `## 活动日志` 追加条目**的工作流 SKILL 都写 started，保证 `ai task log` 整张表的 STARTED 列一致完整。两种写法按技能是否已有 task.md 区分：
 
 - **常规写法（task.md 已存在）**——在「该轮实质工作开始时」（前置条件确认后、第一个产出动作前）追加 started 行，完成时写 done 行：

package/templates/.agents/rules/task-short-id.en.md

@@ -87,9 +87,9 @@ fi
 ## Storage
 
 Short ids are pure local state, persisted only in the registry
-`.agents/workspace/active/.short-ids.json`; task.md does not hold the short id:
+`<task-workspace>/active/.short-ids.json`; task.md does not hold the short id:
 
-- Path: `<repo-root>/.agents/workspace/active/.short-ids.json`
+- Path: `<task-workspace>/active/.short-ids.json`
 - Schema: `{ "version": 1, "ids": { "01": "TASK-20260609-192644", "02": "TASK-…" } }`
 - Keys are zero-padded decimal strings of `task.shortIdLength` digits; values are
   full `TASK-…` task ids.

package/templates/.agents/rules/task-short-id.zh-CN.md

@@ -75,9 +75,9 @@ fi
 
 ## 存储位置
 
-短号是纯本地状态，唯一持久化在注册表 `.agents/workspace/active/.short-ids.json`，task.md 不持有短号：
+短号是纯本地状态，唯一持久化在注册表 `<task-workspace>/active/.short-ids.json`，task.md 不持有短号：
 
-- 路径：`<repo-root>/.agents/workspace/active/.short-ids.json`
+- 路径：`<task-workspace>/active/.short-ids.json`
 - Schema：`{ "version": 1, "ids": { "01": "TASK-20260609-192644", "02": "TASK-…" } }`
 - key 是零填充到 `task.shortIdLength` 位的字符串，value 是完整 `TASK-…` task id
 - 自动 git ignore（active 工作区整体 ignore；无需新增 ignore 条目）

package/templates/.agents/scripts/task-short-id.js

@@ -57,22 +57,16 @@ if (args.includes("--help") || args.includes("-h")) {
 }
 const repoRoot = findRepoRoot(process.cwd());
 const forwarded = [...args];
-if (!forwarded.includes("--active-dir")) {
-  if (!repoRoot) {
-    fs.writeSync(2, "Error: cannot determine active task directory\n");
-    process.exit(1);
-  }
-  forwarded.push("--active-dir", path.join(repoRoot, ".agents", "workspace", "active"));
-}
 if (!forwarded.includes("--short-id-length")) {
   forwarded.push("--short-id-length", String(configuredWidth(repoRoot)));
 }
 const sourceCli = findSourceCli();
 const installedCli = resolveCommand("agent-infra-internal");
 const child = sourceCli
-  ? spawnSync(process.execPath, ["--experimental-strip-types", sourceCli, "task-short-id", ...forwarded], { encoding: "utf8" })
+  ? spawnSync(process.execPath, ["--experimental-strip-types", sourceCli, "task-short-id", ...forwarded], { cwd: repoRoot || process.cwd(), encoding: "utf8" })
   : spawnSync(installedCli, ["task-short-id", ...forwarded], {
       encoding: "utf8",
+      cwd: repoRoot || process.cwd(),
       shell: process.platform === "win32" && /\.(?:bat|cmd)$/i.test(installedCli)
     });
 if (child.error) {

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

@@ -57,7 +57,7 @@ After resolving the artifact context and before this round's first artifact acti
 ### 1. Verify Prerequisites
 
 Check required files:
-- `.agents/workspace/active/{task-id}/task.md` - Task file
+- `<task-workspace>/active/{task-id}/task.md` - Task file
 
 Note: `{task-id}` format is `TASK-{yyyyMMdd-HHmmss}`, for example `TASK-20260306-143022`
 
@@ -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\)' .agents/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 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).
   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.
 
@@ -148,7 +148,7 @@ The skeleton contains identity metadata, stable section markers, and required he
 
 > 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}`.
+Create `<task-workspace>/active/{task-id}/{analysis-artifact}`.
 
 ## Output Template
 
@@ -221,7 +221,7 @@ Create `.agents/workspace/active/{task-id}/{analysis-artifact}`.
 
 ### 7. Update Task Status
 
-Update `.agents/workspace/active/{task-id}/task.md`:
+Update `<task-workspace>/active/{task-id}/task.md`:
 - Record the analysis artifact for this round: `{analysis-artifact}` (Round `{analysis-round}`)
 - If the task template contains a `## Analysis` section, update it to link to `{analysis-artifact}`
 - Mark requirement-analysis as complete in workflow progress and include the actual round when the task template supports it
@@ -290,7 +290,7 @@ Summary:
 - Risk level: {assessment}
 
 Output file:
-- Analysis report: .agents/workspace/active/{task-id}/{analysis-artifact}
+- Analysis report: <task-workspace>/active/{task-id}/{analysis-artifact}
 
 Next step - continue on the selected path:
 {next-step-commands}
@@ -299,7 +299,7 @@ Next step - continue on the selected path:
 ## Completion Checklist
 
 - [ ] Read and understood the task file and source information
-- [ ] Created analysis document `.agents/workspace/active/{task-id}/{analysis-artifact}`
+- [ ] Created analysis document `<task-workspace>/active/{task-id}/{analysis-artifact}`
 - [ ] Updated `current_step` to requirement-analysis in task.md
 - [ ] Updated `updated_at` to the current time in task.md
 - [ ] Updated `assigned_to` in task.md

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

@@ -60,7 +60,7 @@ agent-infra-internal task-event {task-id} analyze.started --agent {standard-agen
 ### 1. 验证前置条件
 
 检查必要文件：
-- `.agents/workspace/active/{task-id}/task.md` - 任务文件
+- `<task-workspace>/active/{task-id}/task.md` - 任务文件
 
 注意：`{task-id}` 格式为 `TASK-{yyyyMMdd-HHmmss}`，例如 `TASK-20260306-143022`
 
@@ -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\)' .agents/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`，预期通过）；并保留 `rg -n 'Analyze Task \(Brainstorming\)' <task-workspace>/active/{task-id}/task.md` 与 task 评论同步证据。**不**跑 artifact gate，也不跑 `check activity-log` / `check platform-sync`（二者绑定分析产物路径）。
   5. 用户输出：只展示当前**单个问题** + 如何回答/继续（再次触发 `analyze-task {task-ref}` 并附答案）。
   6. **STOP**，等待回答。下一次触发回到本步骤。
 
@@ -151,7 +151,7 @@ agent-infra-internal task-artifact {task-id} init --family analysis --artifact {
 
 > 步骤 6–9 属**场景 A（正常产出）**路径。**场景 B（提问早退）**已在步骤 4 内完成状态更新、task 评论同步与校验并 STOP，不进入这些步骤。
 
-创建 `.agents/workspace/active/{task-id}/{analysis-artifact}`。
+创建 `<task-workspace>/active/{task-id}/{analysis-artifact}`。
 
 ## 输出模板
 
@@ -228,7 +228,7 @@ agent-infra-internal task-artifact {task-id} init --family analysis --artifact {
 
 ### 7. 更新任务状态
 
-更新 `.agents/workspace/active/{task-id}/task.md`：
+更新 `<task-workspace>/active/{task-id}/task.md`：
 - 仅更新优先级、Brainstorming、审查响应等本技能拥有的业务内容；产物链接、阶段与完成日志由 completed 事件统一登记
 - 在追加工作流 Activity Log 条目之前，基于分析结果（业务影响、风险、依赖、阻塞条件）重估 `priority`。若重估值与 `task.md` 当前值不一致：
   - 用新值覆盖 frontmatter 的 `priority` 字段
@@ -288,7 +288,7 @@ agent-infra-internal task-verify {task-id} analyze.completed --artifact {analysi
 - 风险等级：{评估}
 
 产出文件：
-- 分析报告：.agents/workspace/active/{task-id}/{analysis-artifact}
+- 分析报告：<task-workspace>/active/{task-id}/{analysis-artifact}
 
 下一步 - 按所选路径继续：
 {next-step-commands}
@@ -297,7 +297,7 @@ agent-infra-internal task-verify {task-id} analyze.completed --artifact {analysi
 ## 完成检查清单
 
 - [ ] 阅读并理解了任务文件和来源信息
-- [ ] 创建了分析文档 `.agents/workspace/active/{task-id}/{analysis-artifact}`
+- [ ] 创建了分析文档 `<task-workspace>/active/{task-id}/{analysis-artifact}`
 - [ ] 更新了 task.md 中的 `current_step` 为 requirement-analysis
 - [ ] 更新了 task.md 中的 `updated_at` 为当前时间
 - [ ] 更新了 task.md 中的 `assigned_to`

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

@@ -21,7 +21,6 @@
       "schema": "analysis"
     },
     "activity-log": {
-      "expected_action_pattern": "(Analyze Task|Requirement Analysis) \\(Round \\d+\\)"
     },
     "platform-sync": {
       "when": "platform_issue_identity_exists"

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

@@ -21,7 +21,6 @@
       "schema": "analysis"
     },
     "activity-log": {
-      "expected_action_pattern": "(Analyze Task|Requirement Analysis) \\(Round \\d+\\)"
     },
     "platform-sync": {
       "when": "platform_issue_identity_exists"

package/templates/.agents/skills/archive-tasks/SKILL.en.md

@@ -7,16 +7,16 @@ description: >
 
 # Archive Completed Tasks
 
-Archive completed tasks from `.agents/workspace/completed/` into `.agents/workspace/archive/YYYY/MM/DD/TASK-xxx/local/` and rebuild a three-level archive index. Local task materials live in `local/` with a path-sorted `contents.sha256`; the TASK root contains no ordinary files.
-- root manifest: `.agents/workspace/archive/manifest.md`
-- yearly manifest: `.agents/workspace/archive/YYYY/manifest.md`
-- monthly manifest: `.agents/workspace/archive/YYYY/MM/manifest.md`
+Archive completed tasks from `<task-workspace>/completed/` into `<task-workspace>/archive/YYYY/MM/DD/TASK-xxx/local/` and rebuild a three-level archive index. Local task materials live in `local/` with a path-sorted `contents.sha256`; the TASK root contains no ordinary files.
+- root manifest: `<task-workspace>/archive/manifest.md`
+- yearly manifest: `<task-workspace>/archive/YYYY/manifest.md`
+- monthly manifest: `<task-workspace>/archive/YYYY/MM/manifest.md`
 
 ## Execution Flow
 
 ### 1. Verify the environment
 
-Confirm that `.agents/workspace/completed/` exists, then choose one of these four invocation modes:
+Confirm that `<task-workspace>/completed/` exists, then choose one of these four invocation modes:
 - no arguments: archive every completed task
 - `--days N`: keep the most recent `N` days and archive older tasks
 - `--before YYYY-MM-DD`: archive only tasks completed before the given date