coding-agent-harness 1.0.7 → 1.1.0

package/docs-release/architecture/document-contract-kernel/products/full-skill-overlay.md

@@ -0,0 +1,29 @@
+# Full Skill Overlay Source
+
+Compatibility matrix version: `document-contract-kernel-v0.5`.
+
+The Full Skill keeps all Document Contract Kernel concepts and adds Full-only
+automation, governance, migration, and runtime surfaces. Full must not copy or
+fork the shared task semantics by hand.
+
+## Shared Kernel Dependency
+
+Full task packages, context documents, progress evidence, reviews,
+walkthroughs, regression records, and lessons must stay compatible with the
+Document Contract Kernel compatibility matrix.
+
+## Full-only Surfaces
+
+Full-only sections may describe package installation, CLI commands, Dashboard,
+Workbench, Preset behavior, generated ledger files, Module Registry, lifecycle
+commands, runtime checks, and source package requirements.
+
+These sections must remain explicitly Full-only so later Lite generation can
+exclude them without weakening Full's audit requirements.
+
+## Coverage Rule
+
+When a Full Skill edit changes the semantics of AGENTS, context, task package,
+progress evidence, review, walkthrough, regression, or lessons, classify it as a
+Kernel change and update the shared contract plus the Lite overlay in the same
+task.

package/docs-release/architecture/document-contract-kernel/products/lite-forbidden-surfaces.txt

@@ -0,0 +1,26 @@
+# Lines are regex patterns matched case-insensitively against Lite product source.
+# The guard scans Lite source and generated Lite Skill files, not this list.
+literal:npm install
+regex:\bnpx\s+(?:--yes\s+)?coding-agent-harness\b
+regex:\bharness\s+init\b
+regex:\bharness\s+dev\b
+regex:\bharness\s+check\b
+regex:\bharness\s+(?:new-task|task-start|task-log|task-block|task-review|review-confirm|task-complete|lesson-promote|task-list)\b
+literal:harness.yaml
+literal:Dashboard
+literal:Workbench
+literal:Preset
+literal:preset-creator
+regex:generated\s+ledger
+regex:generated\s+governance
+regex:generated\s+indexes?
+literal:Closeout-Index
+literal:Module-Registry
+literal:Module Registry
+regex:lifecycle\s+CLI\s+commands?
+regex:CLI\s+(?:checks?|commands?|operation|automation)
+literal:Node.js version requirement
+regex:node\s+version\s+requirement
+regex:\bTaskRepository\b
+regex:\bTaskOperations\b
+regex:\bHarnessTransaction\b

package/docs-release/architecture/document-contract-kernel/products/lite-skill-overlay.md

@@ -0,0 +1,37 @@
+# Lite Skill Overlay Source
+
+Compatibility matrix version: `document-contract-kernel-v0.5`.
+
+This source is for a future document-only Lite Skill. Lite keeps the shared
+Document Contract Kernel concepts and removes runtime product surfaces.
+
+## Positioning
+
+Lite helps an agent set up and maintain a small project work protocol through
+plain repository documents. It is document-only: the agent reads, writes, and
+reviews project files directly.
+
+## Required Lite Surfaces
+
+- `AGENTS.md` as the agent entry protocol.
+- `context/` for stable project facts.
+- `tasks/` for reviewable task packages.
+- `brief.md`, `task_plan.md`, `progress.md`, and `walkthrough.md` in each task.
+- Optional `review.md`, `visual_map.md`, `regression.md`, and `lessons.md` when
+  the project needs them.
+
+## Lite Operating Rules
+
+- Keep all state human-readable and hand-maintainable.
+- Do not require a project manifest.
+- Do not require machine-produced project state.
+- Treat missing review or visual material as adoption-needed if the project
+  later moves to the larger product.
+- Keep upgrade notes short and link back to the compatibility matrix version.
+
+## Upgrade Note
+
+If the project later needs the larger Full Coding Agent Harness product, keep the
+Lite documents as migration input. The shared document semantics are preserved so
+an agent can map Lite task packages and context into the Full structure during an
+explicit migration task.

package/docs-release/architecture/overview.md

@@ -118,7 +118,7 @@ flowchart LR
   CLI --> Status["status / check<br/>derive health and failures"]
   CLI --> Dashboard["dashboard / dev<br/>render human-readable state"]
   CLI --> Migration["migrate-plan / migrate-run / migrate-verify<br/>legacy project adoption"]
-  CLI --> Task["new-task / task-* / review-confirm<br/>task lifecycle operations"]
+  CLI --> Task["new-task / task-*<br/>task lifecycle operations"]
   CLI --> UserSkill["install-user / doctor-user<br/>local skill setup"]
 
   Status --> Scanner["task scanner + check profiles"]
@@ -168,7 +168,7 @@ stateDiagram-v2
   active --> in_review: task-review
   in_review --> review_blocked: open P0-P2 finding
   review_blocked --> in_review: finding closed or routed
-  in_review --> closing: review-confirm + task-complete
+  in_review --> closing: Workbench confirmation + task-complete
   closing --> closed: closeout evidence linked
   closed --> [*]
 ```

package/docs-release/architecture/overview.zh-CN.md

@@ -105,7 +105,7 @@ flowchart LR
   CLI --> Status["status / check<br/>推导健康状态与失败项"]
   CLI --> Dashboard["dashboard / dev<br/>渲染可读状态"]
   CLI --> Migration["migrate-plan / migrate-run / migrate-verify<br/>旧项目迁移"]
-  CLI --> Task["new-task / task-* / review-confirm<br/>任务生命周期操作"]
+  CLI --> Task["new-task / task-*<br/>任务生命周期操作"]
   CLI --> UserSkill["install-user / doctor-user<br/>本机 Skill 设置"]
 
   Status --> Scanner["任务扫描器 + check profiles"]
@@ -153,7 +153,7 @@ stateDiagram-v2
   active --> in_review: task-review
   in_review --> review_blocked: 存在 P0-P2 finding
   review_blocked --> in_review: finding 关闭或路由
-  in_review --> closing: review-confirm + task-complete
+  in_review --> closing: Workbench 人工确认 + task-complete
   closing --> closed: 收口证据已链接
   closed --> [*]
 ```

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