coding-agent-harness 1.0.8 → 1.1.0

package/docs-release/architecture/system-explainer/01-system-overview.md

@@ -63,7 +63,7 @@ flowchart LR
   A -->|"scaffold + validate"| B
   B -->|"读取"| C
   C -->|"生成"| D
-  D -->|"review-confirm"| B
+  D -->|"workbench confirmation"| B
 ```
 
 - **Package**：你 `npm install` 的那个东西，包含 CLI、模板、标准文档、Preset 包
@@ -72,7 +72,7 @@ flowchart LR
 - **Human**：浏览器里看 Dashboard，在 Workbench 里做审查确认
 
 注意这个循环的方向：**Package 写入 Target Repo，Runtime 读取 Target Repo，
-Human 通过 review-confirm 再写回 Target Repo**。
+Human 通过 Workbench 人工确认再写回 Target Repo**。
 整个系统是一个以 Markdown 文件为中心的读写循环，没有任何隐藏状态。
 
 ---
@@ -87,7 +87,7 @@ flowchart TD
 
   PKG --> CLI["harness CLI\ndist/harness.mjs\n唯一命令入口"]
   PKG --> Lib["核心库\nscripts/lib/\n~30 个模块，6 个功能层"]
-  PKG --> Templates["任务模板\ntemplates/\n任务骨架文件（task_plan / visual_map 等）"]
+  PKG --> Templates["模板\ntemplates/\n任务骨架 + 模块根模板"]
   PKG --> References["操作标准\nreferences/\n可复制到目标仓库的规范文档"]
   PKG --> Presets["Preset 包\npresets/\n可复用任务方法（legacy-migration / module 等）"]
 ```
@@ -115,6 +115,9 @@ flowchart TD
 
 每个任务对应 `coding-agent-harness/planning/tasks/<task-id>/` 下的一个目录，
 里面有 `task_plan.md`、`progress.md`、`visual_map.md`、`review.md` 等文件。
+模块注册在 `harness.yaml` 的 `modules.items`；模块根目录默认只包含
+`brief.md` 和 `module_plan.md`，模块任务放在
+`coding-agent-harness/planning/modules/<key>/tasks/<task-id>/`。
 
 ### Runtime 做什么
 
@@ -142,6 +145,7 @@ Runtime 是**无状态的**——每次运行都从 Markdown 文件重新读取
 | **Budget** | 任务复杂度：`simple` / `standard` / `complex`，决定门禁严格程度 | `task_plan.md` |
 | **Phase** | Visual Map 中的执行阶段，有状态和完成度 | `visual_map.md` |
 | **Capability** | 可选功能模块，如 `dashboard`、`module-parallel` | `coding-agent-harness/harness.yaml` |
+| **Module** | YAML 注册的并行工作域，带 owner、scope、依赖和任务分组 | `harness.yaml modules.items` + `planning/modules/<key>/` |
 | **Review Gate** | 阻止任务完成的审查门禁，必须人工确认才能通过 | `INDEX.md` + `review.md` |
 | **Governance Sync** | 任务状态变更时自动更新全局账本的原子操作 | `coding-agent-harness/governance/generated/Harness-Ledger.md` |
 | **Preset** | 可复用的任务方法包，如 `legacy-migration`、`module` | `presets/<id>/` |
@@ -183,9 +187,9 @@ Agent 需要在本地文件系统上读写状态。SaaS 会引入网络依赖、
 破坏 Agent 的自主执行能力。npm 包让任何能运行 Node.js 的环境都能直接使用，
 无需账号或网络。`package.json` 的 `dependencies` 为空——零运行时依赖。
 
-### 为什么 review-confirm 必须是人工操作
+### 为什么人工确认必须只在 Workbench 里操作
 
-`review-confirm` 是整个系统里**唯一不能被 Agent 自动执行**的操作。
+人工确认是整个系统里**唯一不能由普通 CLI 暴露给 Agent 的操作**。
 
 原因：
 
@@ -193,7 +197,7 @@ Agent 需要在本地文件系统上读写状态。SaaS 会引入网络依赖、
 
 这个边界不是一开始就有的。最初 Dashboard workbench 的 review action 没有 Agent/Human 区分。
 后来通过竞品分析（Taskr competitive intake）识别出"Agent 自动确认 review"是 P0 风险，
-才引入了 Git 提交门禁：`review-confirm` 会把带有 Git `user.name` / `user.email` 的
+才引入了 Workbench 写入口和 Git 提交门禁：Dashboard workbench 会把带有 Git `user.name` / `user.email` 的
 人工确认审计字段写入任务 `INDEX.md`，并做两次 Git 原子提交——第一次提交确认字段，
 第二次提交包含第一个 commit SHA 的最终审计记录。这个 Git commit 是**可审计的人类签名**，
 证明有真实的人类看过这个任务。
@@ -204,7 +208,7 @@ Agent 需要在本地文件系统上读写状态。SaaS 会引入网络依赖、
 不写回 Markdown 文件。原因有三：
 
 1. **避免事实漂移**：如果派生状态也写回文件，就有了两份事实源，任何一份过期都会造成误报
-2. **防止绕过门禁**：如果 Agent 能直接修改派生字段，就能绕过 review-confirm 的门禁
+2. **防止绕过门禁**：如果 Agent 能直接修改派生字段，就能绕过人工确认门禁
 3. **治理规则即代码**：scanner 的推导规则本身就是治理规则的机器可读表达，每次运行重新计算等于每次都重新执行一遍治理检查
 
 ---

package/docs-release/architecture/system-explainer/02-module-dependency.md

@@ -22,7 +22,7 @@ flowchart TD
 
   Entry -->|"dashboard\ndev"| DashCmd["dist/commands/dashboard-command.mjs\nDashboard 生成 + 动态服务"]
   Entry -->|"migrate-plan\nmigrate-run\nmigrate-verify"| MigCmd["dist/commands/migration-command.mjs\n迁移三阶段命令"]
-  Entry -->|"new-task / task-start\ntask-phase / task-review\ntask-complete / review-confirm\ntask-tombstone"| TaskCmd["dist/commands/task-command.mjs\n任务生命周期命令"]
+  Entry -->|"new-task / task-start\ntask-phase / task-review\ntask-complete / task-tombstone"| TaskCmd["dist/commands/task-command.mjs\n任务生命周期命令"]
   Entry -->|"preset catalog\npreset install\npreset uninstall"| PresetCmd["dist/commands/preset-command.mjs\nPreset 管理命令"]
   Entry -->|"check / status / init\ngovernance / lesson-promote\n..."| Core["dist/lib/harness-core.mjs\n（直接调用）"]
 ```
@@ -176,7 +176,7 @@ flowchart TD
   TaskLifecycle["task-lifecycle.mjs\n生命周期命令实现\nnew-task / task-start / task-phase\ntask-review / task-complete"]
 
   TaskLifecycle --> ReviewGates["task-lifecycle/review-gates.mjs\n门禁验证逻辑\n（进入 review 前的检查）"]
-  TaskLifecycle --> ReviewConfirm["task-lifecycle/review-confirm.mjs\n人工确认执行\n（review-confirm 命令）"]
+  TaskLifecycle --> ReviewConfirm["task-lifecycle/review-confirm.mjs\n人工确认执行\n（Workbench 内部写入口）"]
   TaskLifecycle --> TextUtils["task-lifecycle/text-utils.mjs\n文本追加工具\n（向 Markdown 文件追加内容）"]
   TaskLifecycle --> GovSync["governance-sync.mjs\n状态变更时同步账本"]
   TaskLifecycle --> MigPreset["task-migration-preset.mjs\n迁移 preset 上下文注入"]
@@ -184,8 +184,8 @@ flowchart TD
   ReviewConfirm --> GitGate["review-confirm-git-gate.mjs\nGit 原子提交门禁\n（写入人工确认块 + commit）"]
 ```
 
-`review-confirm` 是整个生命周期层里最特殊的命令——它是唯一需要 Git 原子提交的操作，
-也是唯一不能被 Agent 自动执行的操作（见 [01-system-overview.md](01-system-overview.md) 的设计决策）。
+人工确认是整个生命周期层里最特殊的写操作——它只通过本地 Workbench 触发，并需要 Git 原子提交
+（见 [01-system-overview.md](01-system-overview.md) 的设计决策）。
 
 ---
 

package/docs-release/architecture/system-explainer/03-task-lifecycle.md

@@ -30,14 +30,14 @@ flowchart TD
 
   NS -->|"harness task-start"| IP
   IP -->|"harness task-review"| R
-  R -->|"harness review-confirm\n（人工操作）"| D
+  R -->|"Dashboard workbench\n人工确认"| D
   IP -->|"harness task-phase --blocked"| BL
   BL -->|"harness task-start"| IP
   R -->|"打回重做"| IP
 ```
 
-**关键点**：`review-confirm` 是整个系统里**唯一不能被 Agent 自动执行**的命令。
-它需要真实的人类操作，并会写入带有 Git `user.name` / `user.email` 的可审计确认块。
+**关键点**：人工确认不作为普通 CLI 命令暴露。它只能通过本地 Dashboard workbench 的写接口触发，
+并会写入带有 Git `user.name` / `user.email` 的可审计确认块。
 
 ---
 
@@ -53,7 +53,7 @@ Budget 是任务的复杂度等级，直接决定审查门禁有多严：
 | 需要关闭所有 blocking findings | ✗ | ✓ | ✓ |
 | 需要 Walkthrough 链接 | ✗ | ✓ | ✓ |
 | 需要 Lesson 决策完成 | ✗ | ✓ | ✓ |
-| 需要人工 review-confirm | ✗ | ✓ | ✓ |
+| 需要 Dashboard 人工确认 | ✗ | ✓ | ✓ |
 
 `simple` 任务可以直接从 `in_progress` 跳到 `done`，没有任何门禁。
 `standard` 和 `complex` 的门禁完全相同——区别在于 `complex` 任务通常需要 subagent 授权和对抗审查。
@@ -87,15 +87,17 @@ flowchart TD
 
 ---
 
-## Level 3 — review-confirm 的门禁细节
+## Level 3 — Dashboard 人工确认的门禁细节
 
-当人类执行 `harness review-confirm` 时，系统在**执行确认之前**做四项检查：
+当人类在本地 Dashboard workbench 点击确认时，系统在**执行确认之前**做四项检查：
 
 ```mermaid
 flowchart TD
-  Trigger["harness review-confirm task-123"]
+  Trigger["POST /api/tasks/review-complete\n(local Dashboard workbench)"]
 
-  Trigger --> C1{"确认文本与任务 ID 匹配?"}
+  Trigger --> A1{"Host / Origin / CSRF\n匹配本地 workbench?"}
+  A1 -->|"否"| EA["❌ 拒绝\n不是 workbench 请求"]
+  A1 -->|"是"| C1{"确认文本与任务 ID 匹配?"}
   C1 -->|"否"| E1["❌ 拒绝\n确认文本不对"]
   C1 -->|"是"| C2{"无阻塞性审查发现?\n（P0/P1/P2 open findings）"}
   C2 -->|"否"| E2["❌ 拒绝\n还有未关闭的 blocking findings"]
@@ -108,6 +110,9 @@ flowchart TD
   Commit1 --> Commit2["Git 提交 #2\nchore: record review confirmation audit task-123"]
 ```
 
+普通 CLI 不暴露人工确认命令；Agent 可以提交审查材料，但不能通过 CLI 直接写人工确认。
+Dashboard workbench 仍只绑定 `127.0.0.1`，并要求同源和 CSRF token。
+
 **两次提交策略**：第一次提交 `INDEX.md` 中的确认字段，第二次提交最终审计元数据。
 这样即使第二次提交失败，第一次提交也已经锁定了确认记录。
 
@@ -275,7 +280,7 @@ Tombstone 块追加到 `task_plan.md` 末尾（不替换原内容），保留历
 （Ledger、Closeout Index、其他任务的 `Supersedes` 字段都可能指向被删任务）。
 Tombstone 标记让 Soft-deleted / Superseded 队列可以只读追溯"为什么这个任务不在活跃队列里"。
 
-### 为什么 review-confirm 需要两次 Git 提交
+### 为什么 Dashboard 人工确认需要两次 Git 提交
 
 两次提交让 audit commit 的 SHA 成为不可篡改的时间戳。
 第一次提交确认本身，第二次提交包含第一个 commit SHA 的审计记录。
@@ -292,13 +297,13 @@ Git 自身的锁（`.git/index.lock`）只保护 index 操作，
 ### 为什么 simple budget 跳过所有门禁
 
 simple 任务对应 trivial 级别的改动（文档修正、配置调整），
-强制经过 `task-review → review-confirm → task-complete` 三步会让 overhead 超过任务本身的价值。
+强制经过 `task-review → Dashboard 人工确认 → task-complete` 三步会让 overhead 超过任务本身的价值。
 这是有意的快速路径，不是遗漏。
 
 ### Lesson 系统的设计意图
 
 Lesson 系统把任务执行中发现的可复用经验从"聊天里提到过"变成
 "可追踪、可审查、可沉淀到标准文档"的治理对象。
-Lesson candidate 决策必须在 `review-confirm` 之前完成，
-因为 `review-confirm` 是责任转移点——人工确认后，任务进入 finalization，
+Lesson candidate 决策必须在 Dashboard 人工确认之前完成，
+因为人工确认是责任转移点——确认后，任务进入 finalization，
 此时再要求 Agent 补 lesson 决策会造成责任归属混乱。

package/docs-release/architecture/system-explainer/05-data-flow.md

@@ -152,13 +152,13 @@ flowchart TD
 flowchart TD
   Collect["collectMarkdownDocuments()"]
 
-  Collect --> Fixed["固定路径（存在时收集）\nHarness-Ledger.md\ncoding-agent-harness/planning/modules/Module-Registry.md\ncoding-agent-harness/governance/regression/Regression-SSoT.md\ncoding-agent-harness/governance/generated/Closeout-Index.md"]
+  Collect --> Fixed["固定路径（存在时收集）\nHarness-Ledger.md\nharness.yaml modules.items\ncoding-agent-harness/planning/modules/Module-Registry.md\ncoding-agent-harness/governance/regression/Regression-SSoT.md\ncoding-agent-harness/governance/generated/Closeout-Index.md"]
 
   Collect --> Walkthrough["coding-agent-harness/planning/tasks/<task>/ 下所有 .md\n（排除 _archive/ 和 _ 开头文件）"]
 
   Collect --> TaskDocs["每个任务目录下：\nbrief / task_plan / execution_strategy\nvisual_map / lesson_candidates\nprogress / review / findings\nreferences/INDEX.md / artifacts/INDEX.md"]
 
-  Collect --> ModuleDocs["coding-agent-harness/planning/modules/ 下：\n每个模块的 module_plan.md\n每个模块的 brief.md"]
+  Collect --> ModuleDocs["coding-agent-harness/planning/modules/ 下：\n每个模块根 brief.md / module_plan.md\n每个模块 tasks/<task>/ 的任务合同"]
 
   Collect --> Lessons["01-GOVERNANCE/lessons/ 下所有 .md"]
 ```
@@ -191,12 +191,12 @@ flowchart LR
     DC["harness dev"]
     DC --> HTTP["本地 HTTP 服务\nlocalhost:PORT"]
     DC --> Watch["文件监听\n轮询模式，每 1 秒检查一次\n变化后延迟 250ms 重新生成"]
-    HTTP --> Browser["浏览器实时查看\n支持 review-confirm 等写操作"]
+    HTTP --> Browser["浏览器实时查看\n支持人工确认等写操作"]
   end
 ```
 
 **关键边界**：静态 Dashboard 是只读的，不能触发任何写操作。
-只有 `harness dev`（Workbench 模式）才能执行 `review-confirm`、`task-start` 等写操作。
+只有 `harness dev`（Workbench 模式）才能执行人工确认等写操作。
 
 ### Dashboard HTML 生成方式
 
@@ -255,8 +255,8 @@ app-src 里的 vanilla JS 组件（`DashboardShell`、`SidebarNav`、`TableView`
 ### 为什么 `harness dev` 和 `harness dashboard` 是两个命令
 
 `harness dashboard` 生成静态只读快照（适合 CI、迁移报告、离线证据）。
-`harness dev` 启动本地动态 Workbench server，支持文件 watch、自动刷新、
-review-confirm 写操作。两者的边界是：**静态快照可以分享，动态 Workbench 只能本地用**。
+`harness dev` 启动本地动态 Workbench server，支持文件 watch、自动刷新和人工确认写操作。
+两者的边界是：**静态快照可以分享，动态 Workbench 只能本地用**。
 
 ### 为什么文件监听用轮询而不是 fs.watch
 

package/docs-release/architecture/system-explainer/06-preset-and-migration.md

@@ -212,7 +212,7 @@ flowchart TD
 flowchart TD
   Core["core\n（必选，所有其他能力的基础）"]
 
-  Core --> ModParallel["module-parallel\n模块注册表 + 并行工作"]
+  Core --> ModParallel["module-parallel\nYAML 模块注册 + 并行工作"]
   Core --> AdvReview["adversarial-review\n对抗审查报告\n（别名：review-contract）"]
   Core --> LongRunning["long-running-task\n长时间运行任务合约"]
   Core --> Dashboard["dashboard\n本地 HTML Dashboard"]
@@ -224,7 +224,7 @@ flowchart TD
 | 能力 | 何时启用 |
 | --- | --- |
 | `core` | 始终，这是必选基础 |
-| `module-parallel` | 项目有 2 个以上独立模块需要并行所有权时 |
+| `module-parallel` | 项目有 2 个以上独立模块，需要在 `harness.yaml modules.items` 里维护 owner、scope、依赖和同步规则时 |
 | `subagent-worker` | 代码变更 subagent 需要在独立 worktree 工作并 commit 交接时 |
 | `adversarial-review` | 发布、架构、安全、数据或策略风险需要独立审查产物时 |
 | `long-running-task` | Agent 可能跨多个 loop 运行而无需每步用户确认时 |

package/docs-release/architecture/system-explainer/README.md

@@ -17,7 +17,7 @@
 - 为什么状态存在 Markdown 文件里，而不是数据库？
 - 为什么有三种 check profile，而不是一种？
 - `governance-sync` 和 `governance rebuild` 有什么区别，为什么要分开？
-- `review-confirm` 为什么必须是人工操作，不能自动化？
+- 人工确认为什么只能通过本地 Workbench，不能作为普通 CLI 命令暴露？
 
 这些问题的答案散落在设计决策、历史演进和操作规范里。
 这套文档把它们集中起来，让你不需要翻 git log 就能理解系统的"为什么"。

package/docs-release/architecture/system-explainer/en-US/01-system-overview.md

@@ -64,7 +64,7 @@ flowchart LR
   A -->|"scaffold + validate"| B
   B -->|"read"| C
   C -->|"generate"| D
-  D -->|"review-confirm"| B
+  D -->|"workbench confirmation"| B
 ```
 
 - **Package**: What you `npm install` — contains the CLI, templates, standards docs, and Preset packages
@@ -73,7 +73,7 @@ flowchart LR
 - **Human**: Views the Dashboard in a browser, performs review confirmation in the Workbench
 
 Note the direction of this loop: **Package writes to Target Repo, Runtime reads from Target Repo,
-Human writes back to Target Repo via review-confirm**.
+Human writes back to Target Repo through Workbench confirmation**.
 The whole system is a read-write loop centered on Markdown files, with no hidden state.
 
 ---
@@ -88,7 +88,7 @@ flowchart TD
 
   PKG --> CLI["harness CLI\ndist/harness.mjs\nSingle command entry point"]
   PKG --> Lib["Core library\nscripts/lib/\n~30 modules, 6 functional layers"]
-  PKG --> Templates["Task templates\ntemplates/\nTask scaffold files (task_plan / visual_map etc.)"]
+  PKG --> Templates["Templates\ntemplates/\nTask scaffolds + module-root templates"]
   PKG --> References["Operating standards\nreferences/\nSpec docs that can be copied to target repos"]
   PKG --> Presets["Preset packages\npresets/\nReusable task methods (legacy-migration / module etc.)"]
 ```
@@ -116,6 +116,9 @@ flowchart TD
 
 Each task corresponds to a directory under `coding-agent-harness/planning/tasks/<task-id>/`,
 containing files like `task_plan.md`, `progress.md`, `visual_map.md`, `review.md`, etc.
+Modules are registered in `harness.yaml` `modules.items`. A module root owns
+only `brief.md` and `module_plan.md` by default, while module tasks live under
+`coding-agent-harness/planning/modules/<key>/tasks/<task-id>/`.
 
 ### What the Runtime does
 
@@ -143,6 +146,7 @@ caching no intermediate state (except file watching in `harness dev`).
 | **Budget** | Task complexity: `simple` / `standard` / `complex`, determines gate strictness | `task_plan.md` |
 | **Phase** | An execution phase in the Visual Map, with state and completion | `visual_map.md` |
 | **Capability** | Optional feature module, e.g. `dashboard`, `module-parallel` | `coding-agent-harness/harness.yaml` |
+| **Module** | YAML-registered parallel work domain with owner, scope, dependencies, and task grouping | `harness.yaml modules.items` + `planning/modules/<key>/` |
 | **Review Gate** | A review gate that blocks task completion, requires human confirmation to pass | `review.md` |
 | **Governance Sync** | Atomic operation that auto-updates the global ledger on task state changes | `coding-agent-harness/governance/generated/Harness-Ledger.md` |
 | **Preset** | A reusable task method package, e.g. `legacy-migration`, `module` | `presets/<id>/` |
@@ -185,10 +189,10 @@ dependency, authentication, and latency, breaking Agents' autonomous execution c
 An npm package lets any environment that can run Node.js use it directly, with no account
 or network required. `package.json` `dependencies` is empty — zero runtime dependencies.
 
-### Why review-confirm must be a manual operation
+### Why human confirmation must stay in Workbench
 
-`review-confirm` is the **only operation in the entire system that cannot be automatically
-executed by an Agent**.
+Human confirmation is the **only operation in the system that is not exposed to Agents
+as a regular CLI command**.
 
 The reason:
 
@@ -197,7 +201,7 @@ The reason:
 This boundary wasn't there from the start. Initially the Dashboard workbench review action
 had no Agent/Human distinction. Later, through competitive analysis (Taskr competitive intake),
 "Agent auto-confirming review" was identified as a P0 risk, which led to introducing the
-Git commit gate: `review-confirm` writes human confirmation audit fields with Git
+Workbench write endpoint and Git commit gate: Dashboard workbench writes human confirmation audit fields with Git
 `user.name` / `user.email` to the task `INDEX.md`, and makes two atomic Git commits:
 the first commits the confirmation fields, and the second commits the final audit
 record containing the first commit's SHA.
@@ -211,7 +215,7 @@ recalculated on every run and never written back to Markdown files. Three reason
 1. **Avoid fact drift**: If derived state were also written to files, there would be two sources
    of truth, and either one going stale would cause false reports
 2. **Prevent gate bypass**: If Agents could directly modify derived fields, they could bypass
-   the review-confirm gate
+   the human confirmation gate
 3. **Governance rules as code**: The scanner's derivation rules are themselves a machine-readable
    expression of governance rules — recalculating on every run is equivalent to re-executing
    the governance check every time

package/docs-release/architecture/system-explainer/en-US/02-module-dependency.md

@@ -23,7 +23,7 @@ flowchart TD
 
   Entry -->|"dashboard\ndev"| DashCmd["dist/commands/dashboard-command.mjs\nDashboard generation + dynamic serving"]
   Entry -->|"migrate-plan\nmigrate-run\nmigrate-verify"| MigCmd["dist/commands/migration-command.mjs\nMigration three-phase commands"]
-  Entry -->|"new-task / task-start\ntask-phase / task-review\ntask-complete / review-confirm\ntask-tombstone"| TaskCmd["dist/commands/task-command.mjs\nTask lifecycle commands"]
+  Entry -->|"new-task / task-start\ntask-phase / task-review\ntask-complete / task-tombstone"| TaskCmd["dist/commands/task-command.mjs\nTask lifecycle commands"]
   Entry -->|"preset catalog\npreset install\npreset uninstall"| PresetCmd["dist/commands/preset-command.mjs\nPreset management commands"]
   Entry -->|"check / status / init\ngovernance / lesson-promote\n..."| Core["dist/lib/harness-core.mjs\n(called directly)"]
 ```
@@ -181,7 +181,7 @@ flowchart TD
   TaskLifecycle["task-lifecycle.mjs\nLifecycle command implementations\nnew-task / task-start / task-phase\ntask-review / task-complete"]
 
   TaskLifecycle --> ReviewGates["task-lifecycle/review-gates.mjs\nGate validation logic\n(checks before entering review)"]
-  TaskLifecycle --> ReviewConfirm["task-lifecycle/review-confirm.mjs\nHuman confirmation execution\n(review-confirm command)"]
+  TaskLifecycle --> ReviewConfirm["task-lifecycle/review-confirm.mjs\nHuman confirmation execution\n(Workbench internal write entry)"]
   TaskLifecycle --> TextUtils["task-lifecycle/text-utils.mjs\nText append utilities\n(appending content to Markdown files)"]
   TaskLifecycle --> GovSync["governance-sync.mjs\nSync ledger on state changes"]
   TaskLifecycle --> MigPreset["task-migration-preset.mjs\nMigration Preset context injection"]
@@ -189,9 +189,9 @@ flowchart TD
   ReviewConfirm --> GitGate["review-confirm-git-gate.mjs\nGit atomic commit gate\n(writes human confirmation block + commit)"]
 ```
 
-`review-confirm` is the most special command in the entire lifecycle layer — it's the only
-operation that requires a Git atomic commit, and the only one that cannot be automatically
-executed by an Agent (see design decisions in [01-system-overview.md](01-system-overview.md)).
+Human confirmation is the most special write operation in the lifecycle layer: it is triggered
+only through the local Workbench and requires Git atomic commit behavior
+(see design decisions in [01-system-overview.md](01-system-overview.md)).
 
 ---
 

package/docs-release/architecture/system-explainer/en-US/03-task-lifecycle.md

@@ -30,14 +30,14 @@ flowchart TD
 
   NS -->|"harness task-start"| IP
   IP -->|"harness task-review"| R
-  R -->|"harness review-confirm\n(manual operation)"| D
+  R -->|"Dashboard workbench\nhuman confirmation"| D
   IP -->|"harness task-phase --blocked"| BL
   BL -->|"harness task-start"| IP
   R -->|"sent back for rework"| IP
 ```
 
-**Key point**: `review-confirm` is the **only command in the entire system that cannot be
-automatically executed by an Agent**. It requires a real human operation and writes an
+**Key point**: human confirmation is not exposed as a regular CLI command. It can only
+be triggered through the local Dashboard workbench write endpoint, and it writes an
 auditable confirmation block with Git `user.name` / `user.email`.
 
 ---
@@ -54,7 +54,7 @@ Budget is the task's complexity level, and it directly determines how strict the
 | Requires all blocking findings closed | ✗ | ✓ | ✓ |
 | Requires Walkthrough link | ✗ | ✓ | ✓ |
 | Requires Lesson decision complete | ✗ | ✓ | ✓ |
-| Requires human review-confirm | ✗ | ✓ | ✓ |
+| Requires Dashboard human confirmation | ✗ | ✓ | ✓ |
 
 `simple` tasks can jump directly from `in_progress` to `done` with no gates.
 `standard` and `complex` have identical gates — the difference is that `complex` tasks
@@ -89,16 +89,18 @@ After entering review state, the Agent needs to write `review.md` and fill in th
 
 ---
 
-## Level 3 — Gate details for review-confirm
+## Level 3 — Gate details for Dashboard human confirmation
 
-When a human runs `harness review-confirm`, the system performs four checks
+When a human clicks confirm in the local Dashboard workbench, the system performs four checks
 **before executing the confirmation**:
 
 ```mermaid
 flowchart TD
-  Trigger["harness review-confirm task-123"]
+  Trigger["POST /api/tasks/review-complete\n(local Dashboard workbench)"]
 
-  Trigger --> C1{"Confirmation text matches task ID?"}
+  Trigger --> A1{"Host / Origin / CSRF\nmatch local workbench?"}
+  A1 -->|"no"| EA["❌ Rejected\nNot a workbench request"]
+  A1 -->|"yes"| C1{"Confirmation text matches task ID?"}
   C1 -->|"no"| E1["❌ Rejected\nWrong confirmation text"]
   C1 -->|"yes"| C2{"No blocking review findings?\n(P0/P1/P2 open findings)"}
   C2 -->|"no"| E2["❌ Rejected\nStill has unclosed blocking findings"]
@@ -111,6 +113,12 @@ flowchart TD
   Commit1 --> Commit2["Git commit #2\nchore: record review confirmation audit task-123"]
 ```
 
+Agent runtime detection is an accidental-self-approval guard, not cryptographic identity.
+If an agent and a human share the same OS user and the agent can mutate environment
+variables, files, and Git commits, the CLI cannot independently prove who operated it.
+Stronger isolation requires an external human approval service, OS keychain/passkey, or
+separate system-user boundary.
+
 **Two-commit strategy**: The first commit covers confirmation fields in `INDEX.md`; the second
 commits the final audit metadata. Even if the second commit fails, the first commit has
 already locked in the confirmation record.
@@ -287,7 +295,7 @@ orphan references (the Ledger, Closeout Index, and other tasks' `Supersedes` fie
 all point to the deleted task). Tombstone markers let the Soft-deleted / Superseded queue
 provide read-only traceability for "why isn't this task in the active queue".
 
-### Why review-confirm requires two Git commits
+### Why Dashboard human confirmation requires two Git commits
 
 Two commits make the audit commit's SHA an immutable timestamp. The first commit covers
 the confirmation itself; the second commit contains an audit record with the first commit's
@@ -306,7 +314,7 @@ sync operation", not a single git command.
 ### Why simple budget skips all gates
 
 Simple tasks correspond to trivial changes (doc corrections, config adjustments). Forcing
-them through `task-review → review-confirm → task-complete` would make the overhead exceed
+them through `task-review → Dashboard human confirmation → task-complete` would make the overhead exceed
 the value of the task itself. This is an intentional fast path, not an oversight.
 
 ### The design intent of the Lesson system
@@ -314,6 +322,6 @@ the value of the task itself. This is an intentional fast path, not an oversight
 The Lesson system transforms reusable knowledge discovered during task execution from
 "mentioned in chat" into a governance object that is "trackable, reviewable, and
 sedimentable into standard docs". Lesson candidate decisions must be completed before
-`review-confirm`, because `review-confirm` is the responsibility transfer point — once
+Dashboard human confirmation, because human confirmation is the responsibility transfer point — once
 human confirmation is done, the task enters finalization, and requiring the Agent to
 add lesson decisions at that point would create accountability confusion.

package/docs-release/architecture/system-explainer/en-US/05-data-flow.md

@@ -155,13 +155,13 @@ Which files `collectMarkdownDocuments()` collects:
 flowchart TD
   Collect["collectMarkdownDocuments()"]
 
-  Collect --> Fixed["Fixed paths (collected when they exist)\nHarness-Ledger.md\ncoding-agent-harness/planning/modules/Module-Registry.md\ncoding-agent-harness/governance/regression/Regression-SSoT.md\ncoding-agent-harness/governance/generated/Closeout-Index.md"]
+  Collect --> Fixed["Fixed paths (collected when they exist)\nHarness-Ledger.md\nharness.yaml modules.items\ncoding-agent-harness/planning/modules/Module-Registry.md\ncoding-agent-harness/governance/regression/Regression-SSoT.md\ncoding-agent-harness/governance/generated/Closeout-Index.md"]
 
   Collect --> Walkthrough["All .md files under coding-agent-harness/planning/tasks/<task>/\n(excluding _archive/ and files starting with _)"]
 
   Collect --> TaskDocs["Under each task directory:\nbrief / task_plan / execution_strategy\nvisual_map / lesson_candidates\nprogress / review / findings\nreferences/INDEX.md / artifacts/INDEX.md"]
 
-  Collect --> ModuleDocs["Under coding-agent-harness/planning/modules/:\nmodule_plan.md for each module\nbrief.md for each module"]
+  Collect --> ModuleDocs["Under coding-agent-harness/planning/modules/:\nroot brief.md / module_plan.md for each module\ntask contracts under tasks/<task>/"]
 
   Collect --> Lessons["All .md files under 01-GOVERNANCE/lessons/"]
 ```
@@ -197,12 +197,12 @@ flowchart LR
     DC["harness dev"]
     DC --> HTTP["Local HTTP server\nlocalhost:PORT"]
     DC --> Watch["File watching\nPolling mode, checks every 1 second\nRegenerates after 250ms delay on change"]
-    HTTP --> Browser["Live browser view\nSupports review-confirm and other write operations"]
+    HTTP --> Browser["Live browser view\nSupports human confirmation and other write operations"]
   end
 ```
 
 **Key boundary**: The static Dashboard is read-only and cannot trigger any write operations.
-Only `harness dev` (Workbench mode) can execute write operations like `review-confirm`
+Only `harness dev` (Workbench mode) can execute write operations like human confirmation
 and `task-start`.
 
 ### Dashboard HTML generation
@@ -266,7 +266,7 @@ a complete security validation chain.
 
 `harness dashboard` generates a static read-only snapshot (suitable for CI, migration
 reports, offline evidence). `harness dev` starts a local dynamic Workbench server with
-file watching, auto-refresh, and review-confirm write operations. The boundary is:
+file watching, auto-refresh, and human-confirmation write operations. The boundary is:
 **static snapshots can be shared; the dynamic Workbench is local-only**.
 
 ### Why file watching uses polling instead of fs.watch

package/docs-release/architecture/system-explainer/en-US/06-preset-and-migration.md

@@ -221,7 +221,7 @@ must be satisfied to pass.
 flowchart TD
   Core["core\n(required, foundation for all other capabilities)"]
 
-  Core --> ModParallel["module-parallel\nModule registry + parallel work"]
+  Core --> ModParallel["module-parallel\nYAML module registry + parallel work"]
   Core --> AdvReview["adversarial-review\nAdversarial review reports\n(alias: review-contract)"]
   Core --> LongRunning["long-running-task\nLong-running task contracts"]
   Core --> Dashboard["dashboard\nLocal HTML Dashboard"]
@@ -233,7 +233,7 @@ flowchart TD
 | Capability | When to enable |
 | --- | --- |
 | `core` | Always — this is the required foundation |
-| `module-parallel` | When the project has 2+ independent modules needing parallel ownership |
+| `module-parallel` | When the project has 2+ independent modules and needs `harness.yaml modules.items` to maintain owner, scope, dependencies, and sync rules |
 | `subagent-worker` | When code-change subagents need to work in isolated worktrees and commit handoffs |
 | `adversarial-review` | When release, architecture, security, data, or policy risks require independent review artifacts |
 | `long-running-task` | When Agents may run across multiple loops without per-step user confirmation |

package/docs-release/architecture/system-explainer/en-US/README.md

@@ -19,7 +19,7 @@ For example:
 - Why is state stored in Markdown files instead of a database?
 - Why are there three check profiles instead of one?
 - What's the difference between `governance-sync` and `governance rebuild`, and why are they separate?
-- Why must `review-confirm` be a manual operation — why can't it be automated?
+- Why must human confirmation go through the local Workbench instead of a regular CLI command?
 
 The answers to these questions are scattered across design decisions, historical evolution,
 and operating standards. These docs bring them together so you can understand the system's

package/docs-release/guides/agent-installation.en-US.md

@@ -8,7 +8,7 @@ This guide is written for coding agents that install or upgrade Harness inside a
 
 The main operator for this CLI is usually an agent inside the target project, not the end user. The agent should not ask the user to study command flags, template folders, or capability choices. Those decisions must happen during Diagnose / Decide and be explained in the delivery summary.
 
-Commands in this guide are written with an installed `harness` command. The agent must first check `command -v harness`. If the target environment does not have `harness`, do not silently install globally. Ask the user whether `npm install -g coding-agent-harness` is allowed. Run that global install only after explicit approval. If the user does not approve or does not respond, run the same CLI with `npx --yes coding-agent-harness <command>`. Maintainers debugging from the source checkout can replace the same command with `node dist/harness.mjs`.
+Commands in this guide are written with an installed `harness` command. The agent must first check `command -v harness`. If the target environment does not have `harness`, do not silently install globally. Ask the user whether `npm install -g coding-agent-harness` is allowed. Run that global install only after explicit approval. If the user does not approve or does not respond, run the same CLI with `npx --yes coding-agent-harness <command>`. Maintainers debugging from the source checkout can replace the same command with `node dist/harness.mjs` after `npm install` or `npm run build:runtime` has generated `dist/`.
 
 `harness init` does not add this npm package to the target project's dependencies. It only writes Harness docs, templates, and the registry. Delivery summaries must not imply that the target project now has an npm dependency installed. The first `npx` run downloads the package into npm cache; it is not a project dependency or a global command install. When CLI access is needed, keep using `npx --yes coding-agent-harness ...`, a user-approved global `harness`, or `node dist/harness.mjs` from the source checkout.
 
@@ -205,10 +205,8 @@ harness task-log <task-id-from-new-task-output> \
   --evidence "command:TARGET:npm-test:passed" \
   /path/to/project
 
-harness review-confirm <task-id-from-new-task-output> \
-  --reviewer "Human Reviewer" \
-  --confirm <task-id-from-new-task-output> \
-  /path/to/project
+# Human confirmation is only available from the local Dashboard workbench:
+harness dev /path/to/project
 
 harness task-complete <task-id-from-new-task-output> \
   --message "Verification loop completed" \
@@ -225,7 +223,7 @@ Rules:
 - Existing task directories are not overwritten. Renaming or continuing old tasks is a coordinator decision.
 - `task-start`, `task-block`, and `task-complete` only update lifecycle status and logs in `progress.md`.
 - `task-log` only appends execution records. Evidence uses `type:PATH:summary`, for example `command:TARGET:npm-test:passed`.
-- `review-confirm` writes human review confirmation audit fields to the task `INDEX.md` through gated commits. It must reject open P0/P1/P2 findings marked `Open: yes` or `Blocks Release: yes`.
+- Dashboard workbench writes human review confirmation audit fields to the task `INDEX.md` through gated commits. It must reject open P0/P1/P2 findings marked `Open: yes` or `Blocks Release: yes`. The regular CLI does not expose a human confirmation command.
 - CLI-owned lifecycle and lesson commands auto-commit allowlisted writes in a clean Git root. Dirty state appears in `status` / dashboard warnings and blocks those mechanical commits. Agent-owned manual edits still need proactive commits; deferred commits must record the no-commit reason, owner, and next step.
 - `status --json` keeps old `task.state` for compatibility and adds `lifecycleState`, `reviewStatus`, `closeoutStatus`, and `stateConflicts`. `done` means implementation finished; it does not mean `closed`.
 - For human operation, start the local HTML workbench with `harness dev /path/to/project`. It binds to `127.0.0.1`, chooses a port automatically, opens the browser, and refreshes when docs change. In headless or CI contexts, use `harness dev --no-open /path/to/project`.

package/docs-release/guides/agent-installation.md

@@ -15,7 +15,8 @@ English mirror: `docs-release/guides/agent-installation.en-US.md`
 如果目标环境没有 `harness` 命令，不得静默全局安装；先询问用户是否允许运行
 `npm install -g coding-agent-harness`。只有用户明确同意后才能修改全局 npm 环境。
 用户不同意或未回复时，用 `npx --yes coding-agent-harness <command>` 运行同一条 CLI。
-维护者在本源码仓调试时，可以把同一命令替换为 `node dist/harness.mjs`。
+维护者在本源码仓调试时，可以在 `npm install` 或 `npm run build:runtime`
+生成 `dist/` 后，把同一命令替换为 `node dist/harness.mjs`。
 
 `harness init` 不会把 npm 包写进目标项目依赖；它只写 Harness 文档、模板和 registry。
 因此 agent 交付时不能暗示目标项目已经安装了 npm dependency。`npx` 第一次运行会把包
@@ -91,7 +92,7 @@ Capability 要保守选择：
 | `dashboard` | 否 | 用户或 agent 需要本地状态页、静态证据快照，或本机动态 workbench。 |
 | `adversarial-review` | 否 | 发布、架构、安全、数据或策略风险需要独立 review artifact。 |
 | `long-running-task` | 否 | Agent 需要连续多轮执行，不能每步都询问用户。 |
-| `module-parallel` | 否 | 两个以上独立模块需要 owner、registry 和同步规则。 |
+| `module-parallel` | 否 | 两个以上独立模块需要 YAML 注册、owner、scope、依赖和同步规则。 |
 | `subagent-worker` | 否 | 会改代码的 subagent 需要独立 worktree 和 commit-backed handoff；依赖 `module-parallel`。 |
 
 `init` 的 JSON 输出会包含 `report`。交付 summary 必须包含：
@@ -195,7 +196,7 @@ harness new-task \
 - 已有项目事实只能 merge、append 或记录 residual；不能用泛化模板替换。
 - 历史合同缺口在普通模式下进入 `adoption-needed` warning。
 - `--strict` 必须仍然能因为旧 checker 失败或历史合同缺口而失败。
-- 旧全局表和模块索引先归档，再用 `harness governance rebuild --archive --apply` 重新生成；这些表是 Agent 索引，人看状态优先用 Dashboard。
+- 旧全局表和模块索引先归档，再用 `harness governance rebuild --archive --apply` 重新生成；这些表是 Agent 索引，人看状态优先用 Dashboard。模块注册表以根 `harness.yaml` 的 `modules.items` 为准，`Module-Registry.md` 是生成视图。
 - `migrate-verify` 必须通过，才能报告迁移输出可用；dashboard 路径必须是 HTML。
 - 必须基于验证通过的 `session.json` 创建 `legacy-migration` preset 任务。它记录 migration session、证据包、preset audit 和后续 work queue；不会自动重写历史任务正文。
 - 详细迁移策略见 `docs-release/guides/migration-playbook.md` 或英文镜像
@@ -224,10 +225,8 @@ harness task-log <new-task 输出的 task-id> \
   --evidence "command:TARGET:npm-test:passed" \
   /path/to/project
 
-harness review-confirm <new-task 输出的 task-id> \
-  --reviewer "Human Reviewer" \
-  --confirm <new-task 输出的 task-id> \
-  /path/to/project
+# 人工确认只能在本地 Dashboard workbench 中点击完成：
+harness dev /path/to/project
 
 harness task-complete <new-task 输出的 task-id> \
   --message "验证闭环完成" \
@@ -246,11 +245,15 @@ harness task-complete <new-task 输出的 task-id> \
   `execution_strategy.md`、`findings.md`、`lesson_candidates.md` 和 `review.md`。
 - `new-task --budget complex` 创建 standard 文件，并额外创建
   `references/INDEX.md` 和 `artifacts/INDEX.md`。
+- `module register` 只创建模块根 `brief.md`、`module_plan.md`，并把模块登记到
+  `harness.yaml modules.items`；`module scaffold` 只修复这两个模块根文档。
+- `new-task --module <key>` 在 `planning/modules/<key>/tasks/<task-id>/` 下创建任务，
+  任务目录内才包含 `execution_strategy.md`、`visual_map.md` 等执行合同。
 - 已存在的任务目录不会被覆盖；需要改名或继续旧任务时，由 coordinator 决定。
 - `task-start`、`task-block`、`task-complete` 只更新 `progress.md` 的生命周期状态和日志。
 - `task-log` 只追加执行记录；证据使用 `type:PATH:summary`，例如
   `command:TARGET:npm-test:passed`。
-- `review-confirm` 会通过受控提交把人工确认审计字段写入任务 `INDEX.md`；如果存在 `Open: yes` 或 `Blocks Release: yes` 的开放 P0/P1/P2 finding，必须拒绝确认。
+- Dashboard workbench 会通过受控提交把人工确认审计字段写入任务 `INDEX.md`；如果存在 `Open: yes` 或 `Blocks Release: yes` 的开放 P0/P1/P2 finding，必须拒绝确认。普通 CLI 不暴露人工确认命令。
 - CLI-owned lifecycle 和 lesson 命令会在干净 Git root 中自动提交 allowlisted 写入；dirty 状态会出现在 `status` / dashboard 的警告里，并阻塞这些机械化提交。Agent 手工改动仍要主动提交，不能提交时记录 no-commit reason、owner 和下一步。
 - `status --json` 保留旧 `task.state` 用于兼容，并新增 `lifecycleState`、`reviewStatus`、`closeoutStatus` 和 `stateConflicts`。`done` 只表示实现完成，不等于 `closed`。
 - 人工操作入口使用本地 HTML workbench：`harness dev /path/to/project`。它会启动只绑定 `127.0.0.1` 的动态页面、自动选择端口、打开浏览器并随 docs 变更刷新。无 GUI 或 CI 场景使用 `harness dev --no-open /path/to/project`。