@tea-agent/loop-agent 0.13.0-alpha.0 → 0.13.0

package/AGENTS.md

@@ -52,6 +52,8 @@
 9. 查看最近提交、相关执行计划、progress/report，确认当前上下文。
 10. 检查 `git status --short --branch`。
 11. 运行本次任务相关的最小基线验证。
+12. 如果用户提到"后端测试"、"接口测试"、"pytest"、"自动化测试"，在任务 `task.json` 中设置 `taskKind: "backend-test"` 再 `dag run-task`；不要用 `--profile backend-test`（CLI 不接受该值，专用模板只走 taskKind）。知识回写用 `taskKind: "knowledge-sync"`（须 `featureId`），图谱开荒用 `taskKind: "knowledge-graph-bootstrap"`。`--profile` 仅表示治理强度：`auto|minimal|standard|reviewed|supervised`。
+13. 如果用户提到"看板"、"observe"、"监控面板"、"启动看板"，使用 `agent-worker observe serve --repo . --port 8787` 命令启动。
 
 ## 会话协议
 
@@ -83,6 +85,8 @@
 - 保留无关的用户改动，不要回退自己没有做的修改。
 - 优先沿用现有 helper、目录边界和局部模式，再考虑新增抽象。
 - 长期决策写入 `docs/`，不要只留在聊天里。
+- 后端测试、接口/API 测试、pytest 或明确的后端自动化测试，必须把 `.harness/tasks/<task-id>/task.json` 的 `taskKind` 设置为 `"backend-test"`，不得保留默认 `standard`。`backend-test` 是 `taskKind`，不是 `--profile` 的可选值；`dag run-task` 继续使用 `--profile auto` 选择治理等级。仅说“自动化测试”且前后端不明时，先根据任务源和项目技术栈判断，禁止无条件路由。
+- 本地只读运行看板：`agent-worker observe serve --repo . --port 8787`，访问 `http://127.0.0.1:8787/`；看板只读，默认只绑定本机 `127.0.0.1`，不要直接暴露到公开网络。
 - 面向使用者的新增、修改、删除或修复，应同步更新根目录 `CHANGELOG.md`；保持版本级摘要即可，不写过细技术细节。
 - 面向用户的中文更新日志、README 和说明文档应使用自然、结果导向的表达：先说明用户能获得什么或问题如何改善，保留必要的命令和产品术语，避免逐字翻译、内部实现细节和无意义的中英混杂。
 - 涉及 `loop-agent init` 或目标项目投影的改动，必须同步考虑目标项目生成物：`AGENTS.md`、`README.md`、`harness.json`、`ai_workspace/loop-agent/`、`scripts/`、`.agents/skills/`、`.harness/prompts`、`.gitignore`（loop-agent runtime managed block）和 npm 包内置 assets；目标项目根 `docs/` 和根 `skills/` 的旧投影需要由 `init update --apply-safe` 安全迁移或退役。

package/CHANGELOG.md

@@ -2,66 +2,70 @@
 
 这里记录每个版本对使用者有影响的变化。命令名和配置字段保持原样，其余内容尽量用日常语言说明。
 
-## [Unreleased]
+## [0.13.0] - 2026-07-18
 
-## [0.13.0] - Unreleased
+### 重点更新
+
+- 前端实现流程更完整：会先确认需求范围和项目能力，再按风险选择执行路径；验证失败时可进行一次有边界的修复，并保留需求、改动和验证结果之间的追踪关系。
+- 后端自动化测试流程更可靠：在生成 pytest 前确认环境和执行范围，检查需求覆盖，并区分产品缺陷、测试问题与环境问题，减少误报和无效重跑。
+- Observe 看板刷新更稳定：轮询时只更新发生变化的内容，保留卡片、焦点、滚动位置和当前节点；节点输出、执行过程和规范证据不会因切换或延迟响应串到其他节点。
+- 旧项目的初始化更新链路得到加强：`init check-update` 能发现新增模板、skills 和托管配置，`init update --apply-safe` 可安全补齐，不覆盖项目自己的内容。
 
 ### 新增
-
-- 前端 DAG 新增设计修订闭环：首轮 design review 输出 `request-revision` 时通过只读 `frontend-plan-revision-pi` 修订计划后经 `frontend-final-design-review-pi` 和 `frontend-final-design-gate-shell` 最终门禁，不再直接终止。只有最终 `VERDICT: pass` 才授权写入。
-- Observe 节点检查器新增「规范证据」页签，展示 skill 注入状态、已读取规范文件（基于 session event 中成功完成的 read 工具调用）、检索操作（grep/find/ls）以及知识库查询；证据不足时提供明确提示。
-- 规范证据接口强制要求通过 `toolCallId` 配对 `tool_execution_start` 与 `tool_execution_end` 事件；仅有 start 而无匹配成功 end、end 报错（`isError: true`）或缺失 complete 事件的 read 一律不计入已读取。
-
-### 变更
-
-- 前端 design gate shell 失败路由改为 `ContractMismatch` / `frontend-plan-revision-and-rerun`，不再路由为 `ProductBug` / `dev-fix`。
-- 前端实现、design review 和 review skill 要求显式执行并记录规范检索与读取，以便后续新 run 在 Observe 中生成可观察证据。
-
-### 破坏性变更
-
-- Task Pool 任务身份升级为 feature-scoped 复合键 `{ featureId, taskId }`（`TaskPoolTaskRef`，ADR 0004）。新 state 使用 `schemaVersion: 2`，canonical 路径为 `.harness/task-pool/states/<featureId>/<taskId>.json`；裸 `taskId` 不再是仓库全局唯一键。
-- `agent-worker task retry` 的 canonical 调用必须携带 `--feature-id`。跨 Feature 同名 Task 时省略 `--feature-id` 会 fail-closed，不会静默猜 Feature。
-- 扁平 legacy `states/<taskId>.json` 在写入 / Ready 路径 fail-closed，不会被静默解释为某个 Feature 的状态。
-
-### 迁移提示
-
-1. 运行 `agent-worker pool doctor --repo <repo> --json` 盘点 v2 / legacy inventory。
-2. 需要迁移时先 `agent-worker pool migrate-state --repo <repo>`（dry-run），确认映射后再 `--apply --owner <owner> --reason <reason>`。
-3. 更新脚本与文档中的 retry 示例为 `task retry <task-id> --feature-id <feature-id> ...`。
-4. Observe / 书签改用 `#/feature/:featureId/task/:taskId`；legacy `#/task/:taskId` 仅在 taskId 全库唯一时兼容。
-5. `runs.jsonl` / `events.jsonl` 不会被 migrate 重写；历史 `workerRunId` 仍可追溯。
-
-### 新增
-
-- `agent-worker pool doctor`：只读 Task Pool inventory 与迁移证据（exit 0 也可带 findings）。
-- `agent-worker pool migrate-state`：legacy → v2 显式迁移；默认 dry-run，apply 需 owner/reason，失败全回滚并保留审计 artifact。
-- `agent-worker batch plan-ready`：零写入预览 TaskSpec priority 驱动的 selected、deferred 与 blocked 计划。
-
-### 变更
-
-- Runner Ready Queue、Feature review/run、Follow-up、Delivery / Closeout、morning report / metrics 与 Observe read-model 均按 Feature 作用域消费 state，同名 Task 跨 Feature 不串线。
-- Observe canonical API：`GET /api/features/:featureId/tasks/:taskId[/runs]`；legacy bare task route 在歧义时返回 409 + `candidates`。
-- Feature dry-run / review / next-action、morning report、GlobalSnapshot、Observe 消费同一 Ready Planner projection；前端与投影层不得独立重选或重排 ready tasks。
+
+- 新增 `browser-tools` skill，可通过 Chrome DevTools Protocol 完成浏览器启动、导航、内容提取、元素选择、脚本执行、截图和 cookie 操作；`loop-agent init --profile full` 会将其安装到目标项目。
+- 新增前端浏览器测试用例生成能力，可根据需求生成逐条执行的中文用例、索引和清单，并明确标记缺失的接口、边界或测试数据。
+- 新增 Eval Replay 与 Candidate Registry，可重放已完成 DAG 的证据、比较候选结果，并记录候选与运行之间的关联；当前用于评估和审计，不会自动晋升候选。
+- 新增 `agent-worker pool doctor`、`pool migrate-state` 和 `batch plan-ready`，用于检查 Task Pool、预览迁移和查看下一批可执行任务。
+- 新增跨分支合并报告模板，统一记录双方功能、冲突处理、初始化影响、发布包变化、验证结果和回退入口。
+- 初始化后的项目支持更自然的“初始化”“检查初始化更新”“安全更新初始化”表达；检查操作保持只读，安全更新会先检查再应用可确定处理的变更。
+
+### 改进
+
+- 高置信度的前端实现需求可自动进入前端专用流程；后端、混合需求或证据不足的任务继续使用原治理流程，不会被误分类。
+- 前端 Mock 策略会优先复用项目已有能力，并明确区分“已用 Mock 验证”和“已完成真实接口联调”，避免把模拟结果误报为完整集成通过。
+- 受监督任务在计划需要调整时可自动完成一次只读修订和复审；写入范围不会因此扩大，最终仍需明确通过才能继续。
+- Task Pool、Ready Planner、Feature 评审、批次执行、报告和 Observe 统一按 Feature 识别任务，同名任务不会跨 Feature 串线。
+- `backend-test`、`frontend-implementation`、`knowledge-sync` 等专用流程统一通过 `task.json.taskKind` 选择；`--profile` 只表示治理强度。
+- Pi SDK 升级至 0.80.10，`doctor` 会检查实际运行能力，而不只是模块是否能够加载。
+- Windows 下的 Git Bash、路径处理、自举验证和 Git 密集测试更稳定。
 
 ### 修复
 
-- Windows 下发布/测试更稳：路径断言对齐 `realpathSync`（避免短路径与长路径比较失败）、Git Bash 解析与生产 `shell-executor` 一致（支持 `LOOP_AGENT_BASH` / `GIT_BASH` 与多候选路径），并放宽 self-host canary、Ring 1 materialize 与 Git-backed Delivery 集成测试在重负载下的超时上限。
-- 前端实现 skill 会完整注入增长后的必需节点契约，不再因单引用预算仍停留在旧上限而截断设计修订闭环规则。
+- 修复 Observe 看板反复显示加载状态、整块重建页面、节点页签内容中断以及旧请求覆盖当前节点的问题。
+- 修复旧项目安全更新后缺少可靠初始化记录，导致后续版本无法继续判断哪些文件可安全更新的问题。
+- 修复前端需求覆盖检查读取旧计划、验证失败无法进入有界修复，以及存在阻塞证据时仍可能继续写入的问题。
+- 修复动态用例执行恢复后重复运行已完成用例或丢失 Token 预算状态的问题。
+- 修复受监督决策和修复结果在合法 Markdown、空白可选说明或格式轻微偏差下被误判的问题，同时继续拒绝不明确或不符合约束的结果。
+- 修复初始化后的 repo-local skills 安装本地依赖时污染目标仓库的问题；托管 `.gitignore` 现在忽略 `.agents/skills/*/node_modules/`。
+- 修复初始化项目缺少运行目录占位、知识库命令发布文件不完整，以及知识图谱晋升路径校验不足的问题。
+
+### 破坏性变更
 
-## [0.12.0] - 2026-07-16
+- Task Pool 任务现在使用 `{ featureId, taskId }` 作为身份。`agent-worker task retry` 应携带 `--feature-id`；存在同名任务时，省略该参数会拒绝执行，不再猜测所属 Feature。
+- 旧的扁平 Task Pool state 不会被自动解释或静默迁移，需要显式检查和迁移。
+
+### 迁移提示
+
+1. 运行 `agent-worker pool doctor --repo <repo> --json` 检查旧 Task Pool 状态。
+2. 先运行 `agent-worker pool migrate-state --repo <repo>` 预览迁移；确认后再添加 `--apply --owner <owner> --reason <reason>`。
+3. 将 retry 命令更新为 `agent-worker task retry <task-id> --feature-id <feature-id> ...`。
+4. 旧项目升级 controller 后，先运行 `loop-agent init check-update`，确认结果后再运行 `loop-agent init update --apply-safe`。
+
+## [0.12.0] - 2026-07-16
 
 ### 新增
 
 - 只读 Pi DAG 节点支持 opt-in 安全重试：仅 planner/scout/reviewer/verifier/closeout 角色且无写入能力的 Pi 节点可声明 `retryPolicy`，在同一 run 内重试模型连接中断（`network`）、provider 限流（`rate-limit`）、临时不可用（`unavailable`）或请求 timeout。生成模板默认总尝试 3 次，手工配置最多 5 次，并使用有上限的指数退避。每次 attempt 保留独立证据，节点耗时、Token 与事件数按尝试聚合；后一次成功不会覆盖前一次失败证据。`quota`、`auth`、`invalid-output`、`write-guard` 与未知失败不重试；supervisor、implementer、writer、dynamic、shell、static、docs-only、decision-gate 节点声明策略会在校验阶段失败。未声明策略的历史 DAG 不新增 attempt artifact，行为保持不变。
 - 新增 `taskKind: "backend-test"` 专用 DAG：从需求分析开始，生成并评审后端功能用例，再生成和执行 pytest 自动化，最后产出测试复盘报告；新 DAG 沿用当前 Pi-only runtime、版本化 runtime contract 与既有执行恢复机制。
-- 测试知识回写专用 DAG：`taskKind: "knowledge-sync"`。生成 collect→draft→validate→apply→pointer；**必须绑定 `featureId`**（`task.json.featureId` 或 hardConstraints / 需求中的 `F-…`），writeSet 收窄到 `features/<featureId>/…`。
-- 业务知识图谱开荒 DAG：`taskKind: "knowledge-graph-bootstrap"`（preflight→inventory→propose→validate→review→gate→promote→materialize）；AI 只写 `knowledge/bootstrap/staging/**`。
+- 测试知识回写专用 DAG：`taskKind: "knowledge-sync"`。生成 collect→draft→validate→**多视角审查（QA/领域/证据）**→apply→pointer；**必须绑定 `featureId`**（`task.json.featureId` 或 hardConstraints / 需求中的 `F-…`），writeSet 收窄到 `features/<featureId>/…`。
+- 业务知识图谱开荒 DAG：`taskKind: "knowledge-graph-bootstrap"`（preflight→inventory→propose→validate→**结构/证据/安全三视角审查+聚合门禁**→promote→materialize）；AI 只写 `knowledge/bootstrap/staging/**`。
 - 图谱辅助脚本与 CLI：`loop-agent knowledge query|graph-init|graph-materialize|graph-promote|graph-incremental-prepare`（薄封装 `scripts/kb-*`）；`knowledge curate` 仍只负责 repair guidance 提案。
-- B1 骨架、Phase A 查询（by_id / by_feature / search）、merge-new-only 晋升、增量 scope 准备与 materialize 索引；设计文档见 `docs/design/knowledge-*.md` 与 active plan `docs/exec-plans/active/2026-07-14-knowledge-sync-and-graph.md`。
+- B1 骨架、Phase A 查询（by_id / by_feature / search）、merge-new-only 晋升、增量 scope 准备与 materialize 索引；设计文档见 `ai_workspace/loop-agent/design/knowledge-*.md` 与 active plan `ai_workspace/loop-agent/exec-plans/active/2026-07-14-knowledge-sync-and-graph.md`。
 
 ### 修复
 
-- `loop-agent init check-update` / `init update --apply-safe` 漏检初始化投影文件：fresh `init --profile full` 通过目录复制把整个 `docs/templates/` 与 `skills/`（镜像到 `.agents/skills/`）投影到目标项目，但期望 init surface 只跟踪其中一个子集。旧版本（如 0.11.0）初始化的项目升级 controller 后，缺失的 backend-test 模板、agent-dag schema/prompt、`loop-agent` 必需 references 等文件无法被报告或补齐，`check-update` 会错误返回 `ok: true`。现在期望 surface 会自动发现包内 `docs/templates/` 与 `skills/` 的所有文件并纳入校验；`check-update` 会报告全部缺失/陈旧 surface；`apply-safe` 会确定性补齐缺失文件，对无法证明 ownership 的旧文件仍保持 fail-safe（给出 model merge / human decision，不覆盖用户内容）。`scripts/check-init-surface.sh` 新增 drift 门，阻止“fresh init 会复制、surface 却不跟踪”的漂移。
+- `loop-agent init check-update` / `init update --apply-safe` 漏检初始化投影文件：fresh `init --profile full` 通过目录复制把整个 `ai_workspace/loop-agent/templates/` 与 `.agents/skills/`（镜像到 `.agents/skills/`）投影到目标项目，但期望 init surface 只跟踪其中一个子集。旧版本（如 0.11.0）初始化的项目升级 controller 后，缺失的 backend-test 模板、agent-dag schema/prompt、`loop-agent` 必需 references 等文件无法被报告或补齐，`check-update` 会错误返回 `ok: true`。现在期望 surface 会自动发现包内 `ai_workspace/loop-agent/templates/` 与 `.agents/skills/` 的所有文件并纳入校验；`check-update` 会报告全部缺失/陈旧 surface；`apply-safe` 会确定性补齐缺失文件，对无法证明 ownership 的旧文件仍保持 fail-safe（给出 model merge / human decision，不覆盖用户内容）。`scripts/check-init-surface.sh` 新增 drift 门，阻止“fresh init 会复制、surface 却不跟踪”的漂移。
 
 ## [0.11.0] - 2026-07-15
 
@@ -78,23 +82,23 @@
 - 新增版本更新提醒。发现新版本时可以直接确认升级；忽略某个版本后不会重复提醒，后续新版本仍会正常提示。可用 `LOOP_AGENT_DISABLE_UPDATE_CHECK=1` 关闭检查。
 - 新增 `loop-agent plan create`、`plan complete` 和 `plan check`，统一维护执行计划及其索引，并在生成 DAG 前发现遗漏或不一致。
 - 目标项目可以选择复用本地 SDD skills，为需求、设计、实现和评审节点补充方法指引；未安装时保持原有流程。
-- 新增 `docs/architecture/` 全景、DAG 执行、Worker/Feature、运行态事实与演进五篇主题文档及目录索引，并在 npm package（不投影到 init）内可达。
+- 新增 `ai_workspace/loop-agent/architecture/` 全景、DAG 执行、Worker/Feature、运行态事实与演进五篇主题文档及目录索引，并在 npm package（不投影到 init）内可达。
 - Worker 和 DAG 运行会固定本次使用的 loop-agent 版本与 skill 配置，避免执行过程中因环境变化产生不一致结果。
 - 新增 `npm run self-host:canary -- --deterministic`，可在隔离环境中检查候选发布包是否能够接管常用 CLI、初始化和 DAG 流程。
 - 新增可选的 `agent-worker` skill，为 Feature、Task、交付和失败恢复提供统一的操作指引。
-- 文档站新增功能导览、架构导读与当前规划入口，并把文档收敛检查固化到 `skills/loop-agent`，减少站上文档与仓库治理文档漂移。
+- 文档站新增功能导览、架构导读与当前规划入口，并把文档收敛检查固化到 `.agents/skills/loop-agent`，减少站上文档与仓库治理文档漂移。
 - 前端 DAG 的 repo-local skills 补齐节点输入、输出、证据和失败规则；前端规范会优先查知识库，失败时回退到当前项目 `openSpec/`。
-- 目标项目旧布局迁移：`init check-update`（只读）报告旧根 `docs/` / `skills/` 可安全迁移的 loop-agent owned 文件、空目录和 `harness.json` 中已废弃的模型字段；`init update --apply-safe` 迁移确认未修改的文件、清理空目录并清理废弃字段，本地修改过、来源不明或目标冲突的文件只进入人工决策，不会被覆盖或删除。
+- 目标项目旧布局迁移：`init check-update`（只读）报告旧根 `ai_workspace/loop-agent/` / `.agents/skills/` 可安全迁移的 loop-agent owned 文件、空目录和 `harness.json` 中已废弃的模型字段；`init update --apply-safe` 迁移确认未修改的文件、清理空目录并清理废弃字段，本地修改过、来源不明或目标冲突的文件只进入人工决策，不会被覆盖或删除。
 
 ### 变更
 
 - `observe serve` 提高对外访问稳定性：HTTP keep-alive 默认约 65s（避免 Node 5s 默认导致连接池复用失败），SSE 增加 keepalive comment 与 `X-Accel-Buffering: no`；新增 `--debug` 在 stderr 打印请求来源/方法/路径/状态/耗时。
 - `observe serve` 允许显式绑定非 loopback 地址（如 `--host 0.0.0.0`）以便局域网访问；默认仍是 `127.0.0.1`，非本机绑定时会在 stderr 提示无鉴权风险。
-- 根 README 在「核心概念」后增加极简「仓库地图」，方便一眼区分 `src/`、`skills/`、`.harness/`、`docs/` 等职责；细节仍以 `AGENTS.md` 与 `docs/README.md` 为准。
-- 文档治理收敛：站上「当前规划」与 active plan 同步（无进行中计划时明确写出）；`docs/README` 只索引核心契约与产物目录入口，progress/report 全量列表下沉到子目录 README；Dynamic Workflow 路线图迁入 `docs/design/`；补齐 design 漏索引与 DAG recovery playbook 入口。
-- 活文档校准：Dynamic Workflow 路线图页首标明已落地 vs 设计输入（Pi-only）；六个月规划第 1–2 月改为 archive/reports 指针；`repository-analysis` 冻结为基线快照，新增 `docs/reports/current-capability-summary.md`；落地 ADR 0001–0003（Pi-only、Task Pool 根、双树/docs-converge）。
+- 根 README 在「核心概念」后增加极简「仓库地图」，方便一眼区分 `src/`、`.agents/skills/`、`.harness/`、`ai_workspace/loop-agent/` 等职责；细节仍以 `AGENTS.md` 与 `ai_workspace/loop-agent/README.md` 为准。
+- 文档治理收敛：站上「当前规划」与 active plan 同步（无进行中计划时明确写出）；`ai_workspace/loop-agent/README` 只索引核心契约与产物目录入口，progress/report 全量列表下沉到子目录 README；Dynamic Workflow 路线图迁入 `ai_workspace/loop-agent/design/`；补齐 design 漏索引与 DAG recovery playbook 入口。
+- 活文档校准：Dynamic Workflow 路线图页首标明已落地 vs 设计输入（Pi-only）；六个月规划第 1–2 月改为 archive/reports 指针；`repository-analysis` 冻结为基线快照，新增 `ai_workspace/loop-agent/reports/current-capability-summary.md`；落地 ADR 0001–0003（Pi-only、Task Pool 根、双树/docs-converge）。
 - 统一 Feature Packet 的推荐目录和中文说明，相关检查同时兼容现有产品线目录。
-- 目标项目初始化布局收敛：默认把 loop-agent 治理资料生成到 `ai_workspace/loop-agent/`，不再在目标项目根生成 `docs/`；`--profile full` 只把 repo-local skills 写到 `.agents/skills/`，不再生成根 `skills/`。
+- 目标项目初始化布局收敛：默认把 loop-agent 治理资料生成到 `ai_workspace/loop-agent/`，不再在目标项目根生成 `ai_workspace/loop-agent/`；`--profile full` 只把 repo-local skills 写到 `.agents/skills/`，不再生成根 `.agents/skills/`。
 - `new-task` 不再预种 L1 空报告模板（`分析报告.md` / `实现计划.md` / `复盘报告.md`）；任务 `artifacts/` 默认只保留 `修改记录.md` 与 `验证结果.md`，由 `promote-run` 从 completed run 回填。
 - 运行期间修改 skill 不会影响当前任务，新配置会从下一次运行开始生效。
 - Observe 自动刷新时会保留依赖图、检查器和日志的阅读位置，查看长时间任务时不再被频繁打断。
@@ -133,7 +137,7 @@
 
 ### 修改
 
-- `design/` 已并入 `docs/design/`，设计资料统一从治理文档目录查找。
+- `design/` 已并入 `ai_workspace/loop-agent/design/`，设计资料统一从治理文档目录查找。
 - Agent DAG 默认使用简体中文输出；可通过 `workflowPolicy.dag.outputLanguage: "en"` 切换为英文。
 - Observe 和 Dashboard 更集中地展示运行状态、风险、模型、耗时和下一步，并减少已经结束任务中的无关诊断信息。
 - 新增 `dag reconcile-run`，可在执行器已经停止后安全收尾历史失联的 DAG。
@@ -241,7 +245,7 @@
 ### 新增
 
 - 可以在 `harness.json` 中为 Pi 和 Cursor 配置默认模型及不同复杂度的模型选择。
-- 完整初始化会同时生成 `skills/` 和 `.agents/skills/`，方便不同 Agent 工具发现同一套项目指引。
+- 完整初始化会把包内 `skills/` 投影到目标项目 `.agents/skills/`，方便不同 Agent 工具发现同一套项目指引。
 
 ### 修改
 

package/README.md

@@ -45,6 +45,12 @@ loop-agent inspect
 
 ## 初始化目标项目
 
+用户可以用自然语言驱动初始化与维护（这三类入口与目标项目 `AGENTS.md` 的“自然语言入口路由”一致）：
+
+- **初始化**：“初始化 loop-agent”“loop agent 初始化”“loop agent初始化”“loop-agent 初始化” — 执行完整确定性初始化闭环，补全 README/验证矩阵并复查。
+- **更新校验**（只读）：“初始化更新校验”“loop agent初始化更新校验”“检查初始化更新” — 只读运行 `loop-agent init check-update --repo-root . --markdown`，汇报动作与风险，不自动写入。
+- **安全更新**（写入型）：“初始化安全更新”“loop agent初始化安全更新”“应用初始化更新” — 先 `check-update`，再 `loop-agent init update --apply-safe`；只执行确定性安全动作，human decisions 存在时停下等用户。
+
 在新项目中，最简单的用法是让当前 agent 执行初始化。需要更稳的执行约束时，可以使用下面这段完整提示词：
 
 ```text
@@ -67,7 +73,7 @@ loop-agent init --repo-root <target-repo> --profile full --merge
 loop-agent init doctor --repo-root <target-repo>
 ```
 
-`init instructions` 会输出给模型/Agent 执行完整初始化的指引包，不要求目标项目已有 `harness.json`。默认初始化会 merge 已有 `AGENTS.md`、`harness.json` 和 loop-agent 治理资料，生成语言无关的治理脚本矩阵、中文根 README 入口、`ai_workspace/loop-agent/` 目标项目治理资料、`.agents/skills/` repo-local skills、`harness.json` IDE schema 指引和 `.harness/` 骨架；不会在目标项目根目录生成 `skills/`，也不会把 loop-agent 生成的治理资料写到根 `docs/`。已有 README 会保留用户正文并插入/更新 loop-agent managed block。初始化还会向 `.gitignore` 合并一个 loop-agent managed block（`# LOOP_AGENT_INIT_START/END`），把 `.harness/tasks/*`、`.harness/dag-runs/*`、`.harness/runs/*`、`.harness/live/`、`.harness/cache/`、`.harness/init-surface.json`、`.harness/task-pool/*`、`.task-pool/`、`.worktrees/` 等个人/会话运行态事实忽略掉，同时保留 `.harness/prompts/` 和目录占位可共享，不会整目录忽略 `.harness/`，也不会覆盖用户已有的 ignore 规则。
+`init instructions` 会输出给模型/Agent 执行完整初始化的指引包，不要求目标项目已有 `harness.json`。默认初始化会 merge 已有 `AGENTS.md`、`harness.json` 和 loop-agent 治理资料，生成语言无关的治理脚本矩阵、中文根 README 入口、`ai_workspace/loop-agent/` 目标项目治理资料、`.agents/skills/` repo-local skills、`harness.json` IDE schema 指引和 `.harness/` 骨架；不会在目标项目根目录生成 `skills/`，也不会把 loop-agent 生成的治理资料写到根 `docs/`。已有 README 会保留用户正文并插入/更新 loop-agent managed block。初始化还会向 `.gitignore` 合并一个 loop-agent managed block（`# LOOP_AGENT_INIT_START/END`），把 `.harness/tasks/*`、`.harness/dag-runs/*`、`.harness/runs/*`、`.harness/live/`、`.harness/cache/`、`.harness/init-surface.json`、`.harness/task-pool/*`、`.task-pool/`、`.agents/skills/*/node_modules/`、`.worktrees/` 等个人/会话运行态事实和 repo-local skill 本地依赖忽略掉，同时保留 `.harness/prompts/` 和目录占位可共享，不会整目录忽略 `.harness/`，也不会覆盖用户已有的 ignore 规则。
 
 新初始化会写入 `.harness/init-surface.json`，记录当前 controller 版本、初始化投影文件 hash 和 manifest hash。已用旧版本初始化的目标项目，可以用下面的维护入口对齐新版本初始化能力：
 
@@ -95,7 +101,7 @@ loop-agent dag validate --dag <temp-dir>/<task-id>-dag.json --strict-models --st
 loop-agent run-dag --dag <temp-dir>/<task-id>-dag.json --cwd .
 ```
 
-当前 `dag run-task` 也支持按 `task.json.taskKind` 选择专用模板；`frontend-implementation` 会生成前端契约、design gate、静态验证、行为验证和 review gate 节点链，`backend-test` 会生成从需求分析、功能用例、pytest 自动化到测试复盘的专用节点链。
+`dag run-task` 会先尊重显式声明的专用 `taskKind`。对于默认 `standard` 任务，它会根据任务标题、`source/需求.md` 和结构化 `allowedPaths` 做保守、确定性的需求分类；只有高置信的前端实现需求才会自动进入前端专用节点链。只读 `frontend-mock-assess-pi` 在计划前读取 Mock/API/schema 证据，并通过确定性 contract gate 选择原生 Mock、浏览器拦截、请求适配层、`not-needed` 或明确阻塞；它只能使用 DAG 生成时已固化的验证入口。可选 `task.json.frontendMock` 可设置 `auto|required|disabled`、既有服务目录和专项验证命令；不安全或不完整的显式 required 合同不会生成 writer。真实请求始终是默认路径，唯一写节点仍是 `frontend-implement-pi`。自动分类不会覆盖显式 profile、`workflowPolicy` 或 supervised quality gate。后端、混合或证据不足的需求继续使用通用模板，也不会自动进入 `backend-test`。Mock 验证只证明前端状态与交互；未实际请求后端时，收尾保留 `Frontend status: mock-validated`、`Real integration: pending`，并给出 `<task-id>-real-api-integration-verify`。该复验任务不会自动创建或执行，需要在后端就绪后显式运行。
 
 测试结论写回与业务知识图谱（结构化 Git，非 RAG）：
 
@@ -191,8 +197,9 @@ Task Pool **state identity** 进一步固定为 feature-scoped 复合键 `{ feat
 ## 核心概念
 
 - **Agent DAG**：把一次任务拆成 contract、scout、plan、implement、verify、closeout 等可审查节点。
+- **任务源绑定与恢复**：新生成 DAG 会冻结任务源路径、SHA-256 和显式 `REQ/BR/AC`；前端计划漏号时会在 writer 前阻断。运行中断后应修复 task source 并重新生成完整 DAG，不要用二手摘要拼接 impl-only 后半段。
 - **`.harness/`**：记录 task、DAG run、one-shot run、cache 和 live state 等运行态事实。
-- **`harness.json`**：描述项目名、治理根目录、模型路由、executor 和验证脚本；`docs/templates/harness.schema.json` 为 IDE 提供补全和字段说明，运行时仍由 Zod schema 校验。
+- **`harness.json`**：描述项目名、治理根目录、模型路由、executor 和验证脚本；目标项目中的 `ai_workspace/loop-agent/templates/harness.schema.json` 为 IDE 提供补全和字段说明，运行时仍由 Zod schema 校验。
 - **repo-local skills**：目标项目本地 skills 统一放在 `.agents/skills/`，便于项目定制 agent 行为并让外部 agent 自动发现。DAG skill 解析顺序为：用户配置目录 → `.agents/skills/` → 发布包内置 `skills/`。
 - **可选 SDD skill 嵌入**：如果目标项目在 `.agents/skills/` 中提供 `SDD-requirement-analysis`、`SDD-design-analysis`、`SDD-implementation-test-review`，`dag run-task` 会把它们作为知识与方法补充追加到对应的 Contract、Plan、Implement/Repair、Verify、Review 节点。loop-agent 仍控制 DAG、状态、写入边界、验证和收口；不会自动运行 SDD 初始化/扫描 skill，也不会推进 `ai_workspace` 状态或归档。没有这些 repo-local skills 时，生成结果保持原有默认流程。
 - **run-owned skill snapshot**：新 DAG run 会在任何节点执行前，把本次实际注入 prompt 的 resolved skill profiles 冻结到 run 自己的 `.runtime/skill-snapshot.json`。后续节点、dynamic child、approve/resume 都使用同一份 hash-anchored snapshot；run 内修改 skill 只会从下一次 run 生效。
@@ -223,6 +230,8 @@ Task Pool **state identity** 进一步固定为 feature-scoped 复合键 `{ feat
 ## 能力概览
 
 - 生成、校验、执行和汇总 Agent DAG。
+- 通过 `eval replay` / `eval report` 对 completed DAG evidence 做 hash-anchored、deterministic 的只读重放比较；M1 不执行模型也不授权候选晋升。
+- 通过 `eval candidate register|show|list|transition` 管理不可变 Candidate Bundle 与 append-only lifecycle（M2 registry MVP）；不跑 live Pi/DAG，不移动 incumbent alias。
 - 从任务说明生成标准 DAG，并按依赖顺序运行规划、实现、验证和收口节点。
 - 维护 `loop` 长程任务状态，包括目标、轮次、信号、验证事实和收口草稿。
 - 通过 Pi executor 执行只读规划、评审、诊断和有边界写入（唯一受治理 Agent writer）。

package/dist/application/dag/generate-task-dag.js

@@ -1,4 +1,6 @@
-import { readFile } from "node:fs/promises";
+import { readFile, mkdir } from "node:fs/promises";
+import { randomUUID } from "node:crypto";
+import path from "node:path";
 import { resolveAutoRoutingProfile, requiresSupervisedQualityGate, } from "../../workflows/dag/governance-profile.js";
 import { resolveShellCommands } from "../../executors/shell-executor.js";
 import { parseDagSpec } from "../../workflows/dag/types.js";
@@ -6,7 +8,6 @@ import { pathMatchesPattern } from "../../shared/git-progress.js";
 import { loadHarnessManifest } from "../../governance/harness.js";
 import { assertExecPlanIndexConsistent } from "../../governance/exec-plans.js";
 import { defaultHybridDagOutputPath, initHybridDagFromTask, } from "../../workflows/dag/init-hybrid.js";
-import { loadTaskConfig } from "../../task/runtime.js";
 import { validateDagUseCase } from "./validate-dag.js";
 import { runDagUseCase } from "./run-dag.js";
 const PLACEHOLDER_WRITESET_MARKER = "REPLACE/WITH";
@@ -202,11 +203,6 @@ export async function generateTaskDagUseCase(input) {
     // before any expensive DAG generation or execution. Empty/consistent
     // repos stay compatible so the default DAG flow is unblocked.
     await assertExecPlanIndexConsistent(repoRoot);
-    const taskConfig = await loadTaskConfig(repoRoot, parsed.taskId);
-    const isFrontendImplementationTask = taskConfig.taskKind === "frontend-implementation";
-    const isBackendTestTask = taskConfig.taskKind === "backend-test";
-    const isKnowledgeSyncTask = taskConfig.taskKind === "knowledge-sync";
-    const isKnowledgeGraphBootstrapTask = taskConfig.taskKind === "knowledge-graph-bootstrap";
     const candidateResult = await initHybridDagFromTask(repoRoot, parsed.taskId, {
         outputPath: parsed.outputPath,
         template: "standard-dag",
@@ -219,12 +215,16 @@ export async function generateTaskDagUseCase(input) {
         codeChange: [],
         reasons: ["dag run-task validate did not report governanceProfile"],
     });
-    if (isFrontendImplementationTask) {
-        profileRouting.selectedTemplate = "frontend-implementation";
-        profileRouting.source = "taskKind";
-        profileRouting.routingReasons = [
-            'taskKind "frontend-implementation" selects the dedicated frontend DAG template',
-        ];
+    const hasExplicitSpecializedTaskKind = candidateResult.templateSelection.source === "taskKind";
+    const hasSafeAutomaticTaskSourceRoute = candidateResult.templateSelection.source === "task-source" &&
+        profileRouting.selectedByProfile !== "supervised" &&
+        profileRouting.selectedTemplate !== "supervised-implementation";
+    if (hasExplicitSpecializedTaskKind || hasSafeAutomaticTaskSourceRoute) {
+        profileRouting.selectedTemplate = candidateResult.template;
+        profileRouting.source = hasExplicitSpecializedTaskKind
+            ? "taskKind"
+            : "task-source";
+        profileRouting.routingReasons = candidateResult.templateSelection.reasons;
         if (parsed.profile === "auto") {
             profileRouting.selectedByProfile =
                 resolveAutoRoutingProfile(profileRouting.candidateProfile);
@@ -233,56 +233,14 @@ export async function generateTaskDagUseCase(input) {
             profileRouting.selectedByProfile = parsed.profile;
         }
     }
-    if (isBackendTestTask) {
-        profileRouting.selectedTemplate = "backend-test-dag";
-        profileRouting.source = "taskKind";
-        profileRouting.routingReasons = [
-            'taskKind "backend-test" selects the dedicated backend test DAG template',
-        ];
-        if (parsed.profile === "auto") {
-            profileRouting.selectedByProfile =
-                resolveAutoRoutingProfile(profileRouting.candidateProfile);
-        }
-        else if (parsed.profileExplicit) {
-            profileRouting.selectedByProfile = parsed.profile;
-        }
-    }
-    if (isKnowledgeSyncTask) {
-        profileRouting.selectedTemplate = "knowledge-sync-dag";
-        profileRouting.source = "taskKind";
-        profileRouting.routingReasons = [
-            'taskKind "knowledge-sync" selects the dedicated knowledge-sync DAG template',
-        ];
-        if (parsed.profile === "auto") {
-            profileRouting.selectedByProfile =
-                resolveAutoRoutingProfile(profileRouting.candidateProfile);
-        }
-        else if (parsed.profileExplicit) {
-            profileRouting.selectedByProfile = parsed.profile;
-        }
-    }
-    if (isKnowledgeGraphBootstrapTask) {
-        profileRouting.selectedTemplate = "knowledge-graph-bootstrap-dag";
-        profileRouting.source = "taskKind";
-        profileRouting.routingReasons = [
-            'taskKind "knowledge-graph-bootstrap" selects the dedicated knowledge-graph bootstrap DAG template',
-        ];
-        if (parsed.profile === "auto") {
-            profileRouting.selectedByProfile =
-                resolveAutoRoutingProfile(profileRouting.candidateProfile);
-        }
-        else if (parsed.profileExplicit) {
-            profileRouting.selectedByProfile = parsed.profile;
-        }
-    }
-    const initResult = profileRouting.selectedTemplate === "standard-dag"
+    const initResult = profileRouting.selectedTemplate === candidateResult.template
         ? candidateResult
         : await initHybridDagFromTask(repoRoot, parsed.taskId, {
             outputPath: parsed.outputPath,
             template: profileRouting.selectedTemplate,
         });
     const outputPath = initResult.outputPath;
-    const validateSummary = profileRouting.selectedTemplate === "standard-dag"
+    const validateSummary = profileRouting.selectedTemplate === candidateResult.template
         ? candidateValidateSummary
         : await validateDagUseCase(buildValidateInput(repoRoot, outputPath, parsed));
     const governanceProfile = validateSummary.governanceProfile ?? {
@@ -317,6 +275,17 @@ export async function generateTaskDagUseCase(input) {
         };
     }
     await assertSafeForExecution(outputPath);
+    // Mirror worker run-task layout so Observe can find dag-events.jsonl under
+    // .harness/task-pool/observability/runs/<runId>/ (CLI path, not Task Pool state).
+    const runId = parsed.runId ?? `dag-${Date.now()}-${randomUUID().slice(0, 8)}`;
+    const eventsJsonlPath = path.join(parsed.cwd, ".harness", "task-pool", "observability", "runs", runId, "dag-events.jsonl");
+    try {
+        await mkdir(path.dirname(eventsJsonlPath), { recursive: true });
+    }
+    catch (error) {
+        const message = error instanceof Error ? error.message : String(error);
+        throw new Error(`failed to create dag events directory for observe: ${path.dirname(eventsJsonlPath)}: ${message}`);
+    }
     const runSummary = await runDagUseCase({
         repoRoot,
         dagPath: outputPath,
@@ -324,7 +293,8 @@ export async function generateTaskDagUseCase(input) {
         initOnly: parsed.initOnly,
         dryRun: parsed.dryRun,
         maxConcurrent: parsed.maxConcurrent,
-        runId: parsed.runId,
+        runId,
+        eventsJsonlPath,
         canvasPath: parsed.canvasPath,
         canvasName: parsed.canvasName,
         canvasesDir: parsed.canvasesDir,

package/dist/application/evaluation/candidate-hash.js

@@ -0,0 +1,75 @@
+import { createHash } from "node:crypto";
+/** Deterministic JSON stringify: object keys sorted at every level. */
+export function stableStringify(value) {
+    return JSON.stringify(canonicalize(value));
+}
+function canonicalize(value) {
+    if (value === null || typeof value !== "object") {
+        return value;
+    }
+    if (Array.isArray(value)) {
+        return value.map((item) => canonicalize(item));
+    }
+    const obj = value;
+    const keys = Object.keys(obj).sort();
+    const out = {};
+    for (const key of keys) {
+        out[key] = canonicalize(obj[key]);
+    }
+    return out;
+}
+export function normalizeContentSha(value) {
+    const trimmed = value.trim();
+    const bare = trimmed.startsWith("sha256:")
+        ? trimmed.slice("sha256:".length)
+        : trimmed;
+    if (!/^[a-f0-9]{64}$/i.test(bare)) {
+        throw new Error(`invalid content sha256: ${value}`);
+    }
+    return bare.toLowerCase();
+}
+export function formatContentSha(hex) {
+    return `sha256:${normalizeContentSha(hex)}`;
+}
+export function normalizeContentRefs(refs) {
+    const normalized = refs.map((ref) => ({
+        path: ref.path.replace(/\\/g, "/"),
+        sha256: normalizeContentSha(ref.sha256),
+    }));
+    normalized.sort((a, b) => (a.path < b.path ? -1 : a.path > b.path ? 1 : 0));
+    const seen = new Set();
+    for (const ref of normalized) {
+        if (seen.has(ref.path)) {
+            throw new Error(`duplicate content ref path: ${ref.path}`);
+        }
+        seen.add(ref.path);
+    }
+    return normalized;
+}
+/**
+ * Canonical payload for bundleHash.
+ * Excludes candidateId, createdAt, description, bundleHash, absolute paths,
+ * registry location, and any mutable lifecycle state.
+ */
+export function buildCanonicalBundlePayload(manifest) {
+    return {
+        schemaVersion: 1,
+        candidateKind: manifest.candidateKind,
+        parentCandidateId: manifest.parentCandidateId ?? null,
+        contentRefs: normalizeContentRefs(manifest.contentRefs),
+    };
+}
+export function computeBundleHash(manifest) {
+    const payload = buildCanonicalBundlePayload(manifest);
+    const digest = createHash("sha256")
+        .update(stableStringify(payload))
+        .digest("hex");
+    return formatContentSha(digest);
+}
+export function sha256Hex(content) {
+    return createHash("sha256").update(content).digest("hex");
+}
+export function eventHashHex(payload) {
+    return createHash("sha256").update(stableStringify(payload)).digest("hex");
+}
+export const LIFECYCLE_GENESIS_HASH = "0".repeat(64);

package/dist/application/evaluation/candidate.js

@@ -0,0 +1,52 @@
+import { loadManifestInputFromPath, listCandidateIds, materializeManifest, readCandidateRecord, registerCandidateManifest, transitionCandidateLifecycle, } from "../../infrastructure/evaluation/candidate-store.js";
+export async function registerCandidate(input) {
+    const raw = await loadManifestInputFromPath(input.repoRoot, input.manifestPath);
+    const manifest = await materializeManifest(input.repoRoot, raw);
+    return registerCandidateManifest({
+        repoRoot: input.repoRoot,
+        manifest,
+        now: input.now,
+    });
+}
+export async function showCandidate(input) {
+    return readCandidateRecord(input.repoRoot, input.candidateId);
+}
+export async function listCandidates(input) {
+    const ids = await listCandidateIds(input.repoRoot);
+    const rows = [];
+    for (const candidateId of ids) {
+        const record = await readCandidateRecord(input.repoRoot, candidateId);
+        rows.push({
+            candidateId: record.manifest.candidateId,
+            bundleHash: record.manifest.bundleHash,
+            candidateKind: record.manifest.candidateKind,
+            status: record.status,
+            promotionApplied: false,
+        });
+    }
+    return rows;
+}
+export async function transitionCandidate(input) {
+    return transitionCandidateLifecycle(input);
+}
+export function formatCandidateMarkdown(record) {
+    const lines = [
+        `# Candidate: ${record.manifest.candidateId}`,
+        "",
+        `- status: \`${record.status}\``,
+        `- kind: \`${record.manifest.candidateKind}\``,
+        `- bundleHash: \`${record.manifest.bundleHash}\``,
+        `- parent: \`${record.manifest.parentCandidateId ?? "null"}\``,
+        `- promotionApplied: \`false\` (registry lifecycle only; no alias/incumbent)`,
+        "",
+        "## Content refs",
+        "",
+        ...record.manifest.contentRefs.map((ref) => `- \`${ref.path}\` — \`${ref.sha256}\``),
+        "",
+        "## Lifecycle",
+        "",
+        ...record.events.map((event) => `- #${event.seq} ${event.from ?? "∅"} → ${event.to}: ${event.reason} (${event.at})`),
+        "",
+    ];
+    return `${lines.join("\n")}\n`;
+}