coding-agent-harness 1.0.5 → 1.0.6

package/docs-release/guides/parent-control-repository-pattern.en-US.md

@@ -30,13 +30,13 @@ product-control-repo/
   docs/
     01-GOVERNANCE/
     02-PRODUCT/
-    03-ARCHITECTURE/
-    04-DEVELOPMENT/
-    05-TEST-QA/
-    06-INTEGRATIONS/
-    09-PLANNING/
-    10-WALKTHROUGH/
-    11-REFERENCE/
+    coding-agent-harness/context/architecture/
+    coding-agent-harness/context/development/
+    coding-agent-harness/governance/regression/
+    coding-agent-harness/context/integrations/
+    coding-agent-harness/planning/
+    coding-agent-harness/planning/tasks/<task>/
+    coding-agent-harness/governance/standards/
   tools/
     check-harness.mjs
     internal-ci.mjs
@@ -59,16 +59,16 @@ The parent repository is the control plane.
 It should contain:
 
 - `AGENTS.md`: the single agent startup entrypoint and reading matrix.
-- `docs/03-ARCHITECTURE/repository-topology.md`: repository topology, owners, boundaries, dependency direction.
-- `docs/04-DEVELOPMENT/local-development.md`: cross-repo local startup, integration workflow, dependency setup.
-- `docs/06-INTEGRATIONS/`: cross-service APIs, events, SDKs, databases, permissions, and external contracts.
-- `docs/Harness-Ledger.md`: generated global task lifecycle index from task files.
-- `docs/09-PLANNING/Delivery-SSoT.md`: cross-repo feature blocks, dependencies, and release orchestration.
-- `docs/09-PLANNING/TASKS/`: cross-repo task contracts.
-- `docs/05-TEST-QA/Regression-SSoT.md`: cross-repo regression gates.
-- `docs/05-TEST-QA/Cadence-Ledger.md`: which changes trigger which checks.
-- `docs/10-WALKTHROUGH/`: cross-repo closeout and human confirmation.
-- `docs/11-REFERENCE/`: local standards for using Harness in this project.
+- `coding-agent-harness/context/architecture/repository-topology.md`: repository topology, owners, boundaries, dependency direction.
+- `coding-agent-harness/context/development/local-development.md`: cross-repo local startup, integration workflow, dependency setup.
+- `coding-agent-harness/context/integrations/`: cross-service APIs, events, SDKs, databases, permissions, and external contracts.
+- `coding-agent-harness/governance/generated/Harness-Ledger.md`: generated global task lifecycle index from task files.
+- `coding-agent-harness/planning/Delivery-SSoT.md`: cross-repo feature blocks, dependencies, and release orchestration.
+- `coding-agent-harness/planning/tasks/`: cross-repo task contracts.
+- `coding-agent-harness/governance/regression/Regression-SSoT.md`: cross-repo regression gates.
+- `coding-agent-harness/governance/regression/Cadence-Ledger.md`: which changes trigger which checks.
+- `coding-agent-harness/planning/tasks/<task>/`: cross-repo closeout and human confirmation.
+- `coding-agent-harness/governance/standards/`: local standards for using Harness in this project.
 
 The parent repository should also provide a check command, for example:
 
@@ -138,7 +138,7 @@ Do not let agents start cross-repo tasks from random child repositories. They wi
 Cross-repo tasks should be created in the parent repository:
 
 ```text
-docs/09-PLANNING/TASKS/2026-05-22-example-cross-repo-feature/
+coding-agent-harness/planning/tasks/2026-05-22-example-cross-repo-feature/
   brief.md
   task_plan.md
   execution_strategy.md
@@ -164,7 +164,7 @@ In the parent-control model, the parent repository must document more external c
 
 ### Architecture
 
-`docs/03-ARCHITECTURE/` explains how the system is split across repositories:
+`coding-agent-harness/context/architecture/` explains how the system is split across repositories:
 
 - Repo topology.
 - Service boundaries.
@@ -175,7 +175,7 @@ In the parent-control model, the parent repository must document more external c
 
 ### Development
 
-`docs/04-DEVELOPMENT/` explains cross-repo development:
+`coding-agent-harness/context/development/` explains cross-repo development:
 
 - How to clone or initialize all child repositories.
 - How to install dependencies.
@@ -185,7 +185,7 @@ In the parent-control model, the parent repository must document more external c
 
 ### Integration
 
-`docs/06-INTEGRATIONS/` explains how repositories connect:
+`coding-agent-harness/context/integrations/` explains how repositories connect:
 
 - API contract.
 - SDK contract.
@@ -241,10 +241,10 @@ Avoid:
 To adopt the parent-control model, start with:
 
 - Parent `AGENTS.md` states that this is the control repository.
-- `docs/03-ARCHITECTURE/repository-topology.md` lists all child repositories.
-- `docs/Harness-Ledger.md` is generated from task files as the global task lifecycle index.
-- `docs/09-PLANNING/Delivery-SSoT.md` is maintained only when cross-repo release or block orchestration is needed.
-- `docs/05-TEST-QA/Regression-SSoT.md` defines local, contract, integration, and release gates.
+- `coding-agent-harness/context/architecture/repository-topology.md` lists all child repositories.
+- `coding-agent-harness/governance/generated/Harness-Ledger.md` is generated from task files as the global task lifecycle index.
+- `coding-agent-harness/planning/Delivery-SSoT.md` is maintained only when cross-repo release or block orchestration is needed.
+- `coding-agent-harness/governance/regression/Regression-SSoT.md` defines local, contract, integration, and release gates.
 - Each child repository has only a short local `AGENTS.md`.
 - New cross-repo tasks are created only in the parent repository.
 - Child commits, PRs, and test output are recorded as parent task evidence.

package/docs-release/guides/parent-control-repository-pattern.md

@@ -30,13 +30,13 @@ product-control-repo/
   docs/
     01-GOVERNANCE/
     02-PRODUCT/
-    03-ARCHITECTURE/
-    04-DEVELOPMENT/
-    05-TEST-QA/
-    06-INTEGRATIONS/
-    09-PLANNING/
-    10-WALKTHROUGH/
-    11-REFERENCE/
+    coding-agent-harness/context/architecture/
+    coding-agent-harness/context/development/
+    coding-agent-harness/governance/regression/
+    coding-agent-harness/context/integrations/
+    coding-agent-harness/planning/
+    coding-agent-harness/planning/tasks/<task>/
+    coding-agent-harness/governance/standards/
   tools/
     check-harness.mjs
     internal-ci.mjs
@@ -59,16 +59,16 @@ product-control-repo/
 它应该包含：
 
 - `AGENTS.md`：Agent 的唯一启动入口和读文件矩阵。
-- `docs/03-ARCHITECTURE/repository-topology.md`：仓库拓扑、owner、边界、依赖方向。
-- `docs/04-DEVELOPMENT/local-development.md`：跨仓本地启动、联调、依赖安装。
-- `docs/06-INTEGRATIONS/`：跨服务 API、事件、SDK、数据库、权限、外部系统契约。
-- `docs/Harness-Ledger.md`：由任务文件生成的全局任务生命周期索引。
-- `docs/09-PLANNING/Delivery-SSoT.md`：跨仓 feature block、依赖和 release 编排。
-- `docs/09-PLANNING/TASKS/`：跨仓任务合同。
-- `docs/05-TEST-QA/Regression-SSoT.md`：跨仓 regression gates。
-- `docs/05-TEST-QA/Cadence-Ledger.md`：哪些变更触发哪些检查。
-- `docs/10-WALKTHROUGH/`：跨仓 closeout 和人工确认。
-- `docs/11-REFERENCE/`：本项目使用 Harness 的本地标准。
+- `coding-agent-harness/context/architecture/repository-topology.md`：仓库拓扑、owner、边界、依赖方向。
+- `coding-agent-harness/context/development/local-development.md`：跨仓本地启动、联调、依赖安装。
+- `coding-agent-harness/context/integrations/`：跨服务 API、事件、SDK、数据库、权限、外部系统契约。
+- `coding-agent-harness/governance/generated/Harness-Ledger.md`：由任务文件生成的全局任务生命周期索引。
+- `coding-agent-harness/planning/Delivery-SSoT.md`：跨仓 feature block、依赖和 release 编排。
+- `coding-agent-harness/planning/tasks/`：跨仓任务合同。
+- `coding-agent-harness/governance/regression/Regression-SSoT.md`：跨仓 regression gates。
+- `coding-agent-harness/governance/regression/Cadence-Ledger.md`：哪些变更触发哪些检查。
+- `coding-agent-harness/planning/tasks/<task>/`：跨仓 closeout 和人工确认。
+- `coding-agent-harness/governance/standards/`：本项目使用 Harness 的本地标准。
 
 父仓库还应该有一个检查命令，例如：
 
@@ -138,7 +138,7 @@ npm test
 跨仓任务应该在父仓库创建：
 
 ```text
-docs/09-PLANNING/TASKS/2026-05-22-example-cross-repo-feature/
+coding-agent-harness/planning/tasks/2026-05-22-example-cross-repo-feature/
   brief.md
   task_plan.md
   execution_strategy.md
@@ -164,7 +164,7 @@ docs/09-PLANNING/TASKS/2026-05-22-example-cross-repo-feature/
 
 ### Architecture
 
-`docs/03-ARCHITECTURE/` 说明系统如何被拆成多个仓库：
+`coding-agent-harness/context/architecture/` 说明系统如何被拆成多个仓库：
 
 - repo topology。
 - 服务边界。
@@ -175,7 +175,7 @@ docs/09-PLANNING/TASKS/2026-05-22-example-cross-repo-feature/
 
 ### Development
 
-`docs/04-DEVELOPMENT/` 说明如何跨仓工作：
+`coding-agent-harness/context/development/` 说明如何跨仓工作：
 
 - 如何 clone 或初始化所有子仓库。
 - 如何安装依赖。
@@ -185,7 +185,7 @@ docs/09-PLANNING/TASKS/2026-05-22-example-cross-repo-feature/
 
 ### Integration
 
-`docs/06-INTEGRATIONS/` 说明仓库之间如何对接：
+`coding-agent-harness/context/integrations/` 说明仓库之间如何对接：
 
 - API contract。
 - SDK contract。
@@ -241,10 +241,10 @@ Agent 不需要在启动时读 100 个仓库的所有文档。它先读父任务
 采用主控仓库模式时，先做到这些：
 
 - 父仓库 `AGENTS.md` 写清楚它是 control repo。
-- `docs/03-ARCHITECTURE/repository-topology.md` 列出所有子仓库。
-- `docs/Harness-Ledger.md` 由任务文件生成全局任务生命周期索引。
-- `docs/09-PLANNING/Delivery-SSoT.md` 只在需要跨仓 release / block 编排时维护。
-- `docs/05-TEST-QA/Regression-SSoT.md` 定义局部、契约、集成、发布 gate。
+- `coding-agent-harness/context/architecture/repository-topology.md` 列出所有子仓库。
+- `coding-agent-harness/governance/generated/Harness-Ledger.md` 由任务文件生成全局任务生命周期索引。
+- `coding-agent-harness/planning/Delivery-SSoT.md` 只在需要跨仓 release / block 编排时维护。
+- `coding-agent-harness/governance/regression/Regression-SSoT.md` 定义局部、契约、集成、发布 gate。
 - 每个子仓库只有短的局部 `AGENTS.md`。
 - 新跨仓任务只在父仓库创建。
 - 子仓库 commit、PR、test output 都作为父任务 evidence。

package/docs-release/guides/preset-development.md

@@ -78,7 +78,7 @@ task:
 entrypoints:
   newTask:
     type: template
-    writes: [docs/09-PLANNING/TASKS/**]
+    writes: [coding-agent-harness/planning/tasks/**]
     audit: true
     templates:
       taskPlanAppend: templates/task_plan.append.md
@@ -106,7 +106,7 @@ audit:
   evidenceFiles: [preset-audit.json, preset-manifest.json, write-scope.json]
 writeScopes:
   taskDocs:
-    path: docs/09-PLANNING/TASKS/**
+    path: coding-agent-harness/planning/tasks/**
     access: write
 ```
 

package/docs-release/guides/repository-operating-models.en-US.md

@@ -14,9 +14,9 @@ This guide explains three common models:
 
 | Model | Fits | Does not fit | Harness source of truth |
 | --- | --- | --- | --- |
-| Single repo | One product, one code repository, clear team boundary | A system already split across independently released repositories | Current repo `AGENTS.md` + `docs/` |
-| Independent multi-repo | Frontend, backend, SDK, or services evolve independently and cross-repo work is rare | Frequent cross-repo features and one shared release plan | Each repo's own `AGENTS.md` + `docs/` |
-| Parent-control repo | Microservices, many subsystems, shared roadmap, cross-repo releases, agents need one startup point | Small projects or short-lived script repositories | Parent repo `AGENTS.md` + `docs/` |
+| Single repo | One product, one code repository, clear team boundary | A system already split across independently released repositories | Current repo `AGENTS.md` + `coding-agent-harness/` |
+| Independent multi-repo | Frontend, backend, SDK, or services evolve independently and cross-repo work is rare | Frequent cross-repo features and one shared release plan | Each repo's own `AGENTS.md` + `coding-agent-harness/` |
+| Parent-control repo | Microservices, many subsystems, shared roadmap, cross-repo releases, agents need one startup point | Small projects or short-lived script repositories | Parent repo `AGENTS.md` + `coding-agent-harness/` |
 
 ## Single-Repo Model
 
@@ -26,12 +26,12 @@ The single-repo model is the simplest. Code, plans, regression state, and walkth
 product-repo/
   AGENTS.md
   docs/
-    03-ARCHITECTURE/
-    04-DEVELOPMENT/
-    05-TEST-QA/
-    09-PLANNING/
-    10-WALKTHROUGH/
-    11-REFERENCE/
+    coding-agent-harness/context/architecture/
+    coding-agent-harness/context/development/
+    coding-agent-harness/governance/regression/
+    coding-agent-harness/planning/
+    coding-agent-harness/planning/tasks/<task>/
+    coding-agent-harness/governance/standards/
   src/
   tests/
 ```
@@ -82,10 +82,10 @@ Independent multi-repo mode is not just "copy the template into every repo." If
 
 Each repository should document its external boundary in:
 
-- `docs/03-ARCHITECTURE/`: where this repository sits in the overall system.
-- `docs/04-DEVELOPMENT/`: sibling repo dependencies and local integration startup.
-- `docs/06-INTEGRATIONS/`: APIs, events, SDKs, queues, databases, auth, and other contracts.
-- `docs/05-TEST-QA/Regression-SSoT.md`: which checks cover this repository only and which require integration across repositories.
+- `coding-agent-harness/context/architecture/`: where this repository sits in the overall system.
+- `coding-agent-harness/context/development/`: sibling repo dependencies and local integration startup.
+- `coding-agent-harness/context/integrations/`: APIs, events, SDKs, queues, databases, auth, and other contracts.
+- `coding-agent-harness/governance/regression/Regression-SSoT.md`: which checks cover this repository only and which require integration across repositories.
 - `AGENTS.md`: whether agents should stop, switch repositories, or ask humans when a task crosses repository boundaries.
 
 ### Risk
@@ -106,13 +106,13 @@ The parent-control model puts the harness in a parent repository. Child reposito
 product-control-repo/
   AGENTS.md
   docs/
-    03-ARCHITECTURE/
-    04-DEVELOPMENT/
-    05-TEST-QA/
-    06-INTEGRATIONS/
-    09-PLANNING/
-    10-WALKTHROUGH/
-    11-REFERENCE/
+    coding-agent-harness/context/architecture/
+    coding-agent-harness/context/development/
+    coding-agent-harness/governance/regression/
+    coding-agent-harness/context/integrations/
+    coding-agent-harness/planning/
+    coding-agent-harness/planning/tasks/<task>/
+    coding-agent-harness/governance/standards/
   tools/
   frontend/   -> child repository
   backend/    -> child repository
@@ -164,7 +164,7 @@ See `docs-release/guides/parent-control-repository-pattern.en-US.md` for the ful
 
 ### Single Repo To Multi-Repo
 
-When a single repository splits into frontend, backend, or SDK repositories, do not copy the same `docs/` tree into every repository.
+When a single repository splits into frontend, backend, or SDK repositories, do not copy the same `coding-agent-harness/` tree into every repository.
 
 Decide first:
 

package/docs-release/guides/repository-operating-models.md

@@ -14,9 +14,9 @@ Coding Agent Harness 可以落在不同的仓库组织方式里。选择错了
 
 | 模式 | 适合 | 不适合 | Harness 事实源 |
 | --- | --- | --- | --- |
-| 单仓模式 | 单产品、单代码仓库、团队边界清楚 | 已经拆成多个独立发布仓库 | 当前仓库 `AGENTS.md` + `docs/` |
-| 多仓独立模式 | 前端、后端、SDK 等仓库长期独立迭代，跨仓任务少 | 大量跨仓 feature 和统一 release 计划 | 每个仓库自己的 `AGENTS.md` + `docs/` |
-| 主控仓库模式 | 微服务、多子系统、多仓统一路线图、跨仓 release、Agent 需要从一个地方启动 | 小项目，或只有一个短期脚本仓库 | 父仓库 `AGENTS.md` + `docs/` |
+| 单仓模式 | 单产品、单代码仓库、团队边界清楚 | 已经拆成多个独立发布仓库 | 当前仓库 `AGENTS.md` + `coding-agent-harness/` |
+| 多仓独立模式 | 前端、后端、SDK 等仓库长期独立迭代，跨仓任务少 | 大量跨仓 feature 和统一 release 计划 | 每个仓库自己的 `AGENTS.md` + `coding-agent-harness/` |
+| 主控仓库模式 | 微服务、多子系统、多仓统一路线图、跨仓 release、Agent 需要从一个地方启动 | 小项目，或只有一个短期脚本仓库 | 父仓库 `AGENTS.md` + `coding-agent-harness/` |
 
 ## 单仓模式
 
@@ -26,12 +26,12 @@ Coding Agent Harness 可以落在不同的仓库组织方式里。选择错了
 product-repo/
   AGENTS.md
   docs/
-    03-ARCHITECTURE/
-    04-DEVELOPMENT/
-    05-TEST-QA/
-    09-PLANNING/
-    10-WALKTHROUGH/
-    11-REFERENCE/
+    coding-agent-harness/context/architecture/
+    coding-agent-harness/context/development/
+    coding-agent-harness/governance/regression/
+    coding-agent-harness/planning/
+    coding-agent-harness/planning/tasks/<task>/
+    coding-agent-harness/governance/standards/
   src/
   tests/
 ```
@@ -82,10 +82,10 @@ sdk-repo/
 
 每个仓库至少要在这些位置写清楚外部边界：
 
-- `docs/03-ARCHITECTURE/`：本仓库在整体系统中的位置。
-- `docs/04-DEVELOPMENT/`：依赖哪些 sibling repo、本地联调怎么启动。
-- `docs/06-INTEGRATIONS/`：API、事件、SDK、队列、数据库、鉴权等外部契约。
-- `docs/05-TEST-QA/Regression-SSoT.md`：哪些检查只覆盖本仓库，哪些需要跨仓联调。
+- `coding-agent-harness/context/architecture/`：本仓库在整体系统中的位置。
+- `coding-agent-harness/context/development/`：依赖哪些 sibling repo、本地联调怎么启动。
+- `coding-agent-harness/context/integrations/`：API、事件、SDK、队列、数据库、鉴权等外部契约。
+- `coding-agent-harness/governance/regression/Regression-SSoT.md`：哪些检查只覆盖本仓库，哪些需要跨仓联调。
 - `AGENTS.md`：遇到跨仓任务时，Agent 应该停下来、切仓库，还是交给人协调。
 
 ### 风险
@@ -106,13 +106,13 @@ sdk-repo/
 product-control-repo/
   AGENTS.md
   docs/
-    03-ARCHITECTURE/
-    04-DEVELOPMENT/
-    05-TEST-QA/
-    06-INTEGRATIONS/
-    09-PLANNING/
-    10-WALKTHROUGH/
-    11-REFERENCE/
+    coding-agent-harness/context/architecture/
+    coding-agent-harness/context/development/
+    coding-agent-harness/governance/regression/
+    coding-agent-harness/context/integrations/
+    coding-agent-harness/planning/
+    coding-agent-harness/planning/tasks/<task>/
+    coding-agent-harness/governance/standards/
   tools/
   frontend/   -> child repository
   backend/    -> child repository
@@ -164,7 +164,7 @@ product-control-repo/
 
 ### 单仓到多仓
 
-当一个单仓拆出前端、后端、SDK 时，不要直接复制 `docs/` 到每个仓库。
+当一个单仓拆出前端、后端、SDK 时，不要直接复制 `coding-agent-harness/` 到每个仓库。
 
 先决定：
 

package/docs-release/guides/task-state-machine.en-US.md

@@ -8,7 +8,7 @@ Coding Agent Harness does not model task state as a single field. The Dashboard
 - `review.md` stores Agent Review Submission, material findings, and review evidence.
 - `INDEX.md` stores Task Audit Metadata, including task creation and human review confirmation audit fields.
 - `lesson_candidates.md` records lesson candidate decisions and sedimentation routing.
-- `10-WALKTHROUGH/Closeout-SSoT.md` records closeout status and links walkthrough evidence.
+- `coding-agent-harness/governance/generated/Closeout-Index.md` records closeout status and links walkthrough evidence.
 - Tombstone / supersede metadata records whether a task was soft-deleted, merged, archived, or replaced.
 - The scanner derives `lifecycleState`, `reviewStatus`, `closeoutStatus`, `taskQueues[]`, `queueReasons[]`, and `repairPrompt` from those files.
 
@@ -58,7 +58,7 @@ flowchart TB
   Index["INDEX.md<br/>Task Audit Metadata"]
   Review["review.md<br/>Agent Review Submission + findings + evidence"]
   Lessons["lesson_candidates.md<br/>decision + sedimentation route"]
-  Closeout["Closeout-SSoT.md<br/>closeout row + walkthrough"]
+  Closeout["Closeout-Index.md<br/>closeout row + walkthrough"]
   Tombstone["tombstone / supersede metadata"]
   Scanner["scanner"]
 
@@ -81,7 +81,7 @@ flowchart TB
 | --- | --- | --- |
 | `task.state` | `progress.md` | Raw execution stage. |
 | `reviewStatus` | `INDEX.md` Task Audit Metadata + `review.md` findings/submission | Separates missing review, agent-submitted review, blockers, and human confirmation. |
-| `closeoutStatus` | `Closeout-SSoT.md` | Separates missing, pending, and closed closeout. |
+| `closeoutStatus` | `Closeout-Index.md` | Separates missing, pending, and closed closeout. |
 | `lifecycleState` | scanner-derived | Main Dashboard lifecycle meaning. |
 | `taskQueues[]` | scanner-derived | Which lifecycle queues include the task. A task can be visible in more than one governance queue. |
 | `queueReasons[]` | scanner-derived | Why the task entered a queue, including source file, field, and repair action. |
@@ -153,11 +153,11 @@ Global governance tables only keep index, state, route, and audit summary. They
 
 | Layer | Should record | Should not record |
 | --- | --- | --- |
-| Global tables: Harness Ledger, Closeout SSoT, Regression SSoT, Cadence Ledger, Delivery SSoT | Current state, owner, task/module/detail links, regression gate, delivery sequence, closeout or audit summary | Module-internal steps, undecided lesson candidates, full command output, long evidence paragraphs, review transcripts, temporary repair prompts |
+| Global tables: Harness Ledger, Closeout Index, Regression SSoT, Cadence Ledger, Delivery SSoT | Current state, owner, task/module/detail links, regression gate, delivery sequence, closeout or audit summary | Module-internal steps, undecided lesson candidates, full command output, long evidence paragraphs, review transcripts, temporary repair prompts |
 | Module layer: Module Registry, `module_plan.md` | Module boundary, module steps, handoff, current blockers, and local evidence indexes | Final promoted lesson body or cross-module release audit ledger |
 | Task layer: `brief.md`, `task_plan.md`, `progress.md`, `review.md`, `lesson_candidates.md`, `lessons/LC-*.md`, `artifacts/INDEX.md` | Execution detail, evidence, agent review, candidate lessons, task-local lesson detail, repair prompts, and raw artifact routing | Cross-task ledgers or promoted lesson detail bodies |
 
-The checker enforces this boundary for new global table rows. Overloaded rows that already existed before 2026-05-24 are surfaced in Dashboard migration advice as `legacy-report-only`; they are not automatically deleted or bulk-rewritten. New rows that continue placing task/module-local detail in global tables are reported as `governance-table-entropy` failures. Lesson candidates stay in `lesson_candidates.md`; candidates that enter `needs-promotion` must link a task-local `lessons/LC-*.md` detail artifact, and accepted reusable lessons live in `docs/01-GOVERNANCE/lessons/*.md`. The fix is to keep the global summary row and move detail into module/task/detail documents linked from that row.
+The checker enforces this boundary for new global table rows. Overloaded rows that already existed before 2026-05-24 are surfaced in Dashboard migration advice as `legacy-report-only`; they are not automatically deleted or bulk-rewritten. New rows that continue placing task/module-local detail in global tables are reported as `governance-table-entropy` failures. Lesson candidates stay in `lesson_candidates.md`; candidates that enter `needs-promotion` must link a task-local `lessons/LC-*.md` detail artifact, and accepted reusable lessons live in `coding-agent-harness/governance/lessons/*.md`. The fix is to keep the global summary row and move detail into module/task/detail documents linked from that row.
 
 ## Human Confirmation Loop
 

package/docs-release/guides/task-state-machine.md

@@ -8,7 +8,7 @@ Coding Agent Harness 的任务状态不是一个单字段。Dashboard 里看到
 - `review.md` 记录 Agent Review Submission、material findings 和审查证据。
 - `INDEX.md` 记录任务审计元数据，包括任务创建和人工确认审计字段。
 - `lesson_candidates.md` 记录 lesson candidate 的人工判定和后续沉淀路由。
-- `10-WALKTHROUGH/Closeout-SSoT.md` 记录任务是否完成收口，并链接 walkthrough。
+- `coding-agent-harness/governance/generated/Closeout-Index.md` 记录任务是否完成收口，并链接 walkthrough。
 - Tombstone / supersede 信息记录任务是否被软删除、合并、归档或替代。
 - Scanner 从这些文件推导 `lifecycleState`、`reviewStatus`、`closeoutStatus`、`taskQueues[]`、`queueReasons[]` 和 `repairPrompt`。
 
@@ -58,7 +58,7 @@ flowchart TB
   Index["INDEX.md<br/>Task Audit Metadata"]
   Review["review.md<br/>Agent Review Submission + findings + evidence"]
   Lessons["lesson_candidates.md<br/>decision + sedimentation route"]
-  Closeout["Closeout-SSoT.md<br/>closeout row + walkthrough"]
+  Closeout["Closeout-Index.md<br/>closeout row + walkthrough"]
   Tombstone["tombstone / supersede metadata"]
   Scanner["scanner"]
 
@@ -81,7 +81,7 @@ flowchart TB
 | --- | --- | --- |
 | `task.state` | `progress.md` | 原始执行阶段。 |
 | `reviewStatus` | `INDEX.md` Task Audit Metadata + `review.md` findings/submission | 区分缺审查、Agent 已提交审查、阻塞、人工确认。 |
-| `closeoutStatus` | `Closeout-SSoT.md` | 区分收口缺失、待处理、已关闭。 |
+| `closeoutStatus` | `Closeout-Index.md` | 区分收口缺失、待处理、已关闭。 |
 | `lifecycleState` | scanner 派生 | Dashboard 的主生命周期语义。 |
 | `taskQueues[]` | scanner 派生 | 任务属于哪些生命周期队列。一个任务可同时在多个治理队列中可见。 |
 | `queueReasons[]` | scanner 派生 | 为什么进入队列，以及对应源文件、字段和修复动作。 |
@@ -154,7 +154,7 @@ Review 队列只等人确认。缺材料、阻塞、lesson 沉淀、已确认待
 
 | 层级 | 应该记录什么 | 不应该记录什么 |
 | --- | --- | --- |
-| 全局表：Harness Ledger、Closeout SSoT、Regression SSoT、Cadence Ledger、Delivery SSoT | 当前状态、负责人、任务/模块/详情文档链接、回归 gate、交付顺序、收口或审计摘要 | 模块内步骤、未判定 lesson candidate、完整命令输出、长证据段落、review transcript、临时 repair prompt |
+| 全局表：Harness Ledger、Closeout Index、Regression SSoT、Cadence Ledger、Delivery SSoT | 当前状态、负责人、任务/模块/详情文档链接、回归 gate、交付顺序、收口或审计摘要 | 模块内步骤、未判定 lesson candidate、完整命令输出、长证据段落、review transcript、临时 repair prompt |
 | 模块层：Module Registry、`module_plan.md` | 模块边界、模块内步骤、handoff、当前阻塞和局部证据索引 | 已 promotion 的全局 lesson 正文、跨模块发布审计总账 |
 | 任务层：`brief.md`、`task_plan.md`、`progress.md`、`review.md`、`lesson_candidates.md`、`lessons/LC-*.md`、`artifacts/INDEX.md` | 执行细节、证据、agent review、候选 lesson、task-local lesson 详情、修复提示和 raw artifact 路由 | 跨任务总账或 promoted lesson 详情正文 |
 
@@ -163,7 +163,7 @@ Checker 对新增全局表行执行该边界。2026-05-24 之前已经存在的
 新增行如果把 task/module 局部细节继续塞进全局表，会作为 `governance-table-entropy`
 失败项报告。Lesson candidate 留在 `lesson_candidates.md`；进入 `needs-promotion`
 的候选必须链接任务本地 `lessons/LC-*.md` 详情文件，已接受的经验再写入
-`docs/01-GOVERNANCE/lessons/*.md` promoted 详情文档。修复方式是保留必要全局摘要行，
+`coding-agent-harness/governance/lessons/*.md` promoted 详情文档。修复方式是保留必要全局摘要行，
 把细节移动到 module/task/detail 文档并在全局表中链接过去。
 
 ## 人工确认闭环

package/docs-release/guides/typescript-runtime-migration-closeout.md

@@ -0,0 +1,96 @@
+# TypeScript Runtime Migration Closeout
+
+This closeout records the public package rule after the progressive JavaScript to
+TypeScript runtime migration. The package now executes committed
+`dist/**/*.mjs` artifacts, while `scripts/**/*.mts` and `tests/**/*.mts` are the
+source ownership surfaces. Historical checked-in `scripts/**/*.mjs` and
+`tests/**/*.mjs` shims have been removed after the dist observation gates passed.
+
+## Current State
+
+All Node runtime and test sources under `scripts/` and `tests/` are now
+TypeScript-first:
+
+- `scripts/**/*.mts` builds to committed `dist/**/*.mjs` artifacts.
+- `tests/**/*.mts` runs through the built test runner.
+- `dist/**/*.mjs` is the package runtime surface for npm bin, npm scripts, and
+  postinstall.
+- `scripts/**/*.mjs` and `tests/**/*.mjs` have a final inventory of zero.
+
+The npm package publishes `dist/` and no longer publishes `scripts/` or `tests/`.
+This keeps installed execution independent from TypeScript source files and from
+the deleted historical shims.
+
+## Final Closeout Evidence
+
+The TS-first runtime closeout is based on the PR-28 deletion gate plus the PR-29
+final inventory:
+
+- final `scripts/` and `tests/` JavaScript shim inventory is zero;
+- packed package file inventory includes `dist/` and excludes `scripts/` and
+  `tests/`;
+- Node 24 tarball smoke proved installed `harness` commands execute from
+  `dist/` with a temporary `HOME` and PATH isolated to the temp consumer
+  `node_modules/.bin`;
+- source-package and target-project checks pass through `dist/harness.mjs`;
+- snapshot matrix reported no blocking drift after shim deletion.
+
+That means remaining package-included JavaScript is not unfinished CLI/test
+runtime migration work. The remaining files are the documented preset and
+dashboard exceptions below.
+
+## Runtime Contract
+
+The package is an ESM package and its current public runtime contract points at
+the committed dist build output:
+
+- `package.json` maps the `harness` executable to `dist/harness.mjs`.
+- npm postinstall runs `dist/postinstall.mjs`.
+- npm helper scripts such as `check`, `status`, and dashboard generation run
+  through `dist/harness.mjs`.
+- Runtime modules import sibling `.mjs` files inside `dist/`, so installed
+  package execution does not depend on TypeScript loaders.
+
+The PR-27 observation gate proved the package was dist-primary before deletion.
+The PR-28 deletion gate keeps that proof executable by requiring final inventory
+counts of zero for `scripts/**/*.mjs` and `tests/**/*.mjs`, package dry-run with
+no `scripts/**` or `tests/**`, snapshot matrix, and Node 24 tarball smoke.
+
+## Documented Exceptions
+
+The following package-included JavaScript files are not part of the Node runtime
+source-twin cleanup target.
+
+| Path | Reason To Keep |
+| --- | --- |
+| `presets/legacy-migration/checks/preset-check.mjs` | Preset executable hook. It belongs to the preset extension surface, not core runtime migration. |
+| `presets/legacy-migration/scripts/plan-work-queue.mjs` | Preset helper script loaded as packaged preset material. |
+| `presets/legacy-migration/scripts/scaffold-task-contracts.mjs` | Preset helper script loaded as packaged preset material. |
+| `templates/dashboard/assets/app-src/*.js` | Browser dashboard source assets. They are shipped as template assets, not Node runtime modules. |
+| `templates/dashboard/assets/app.js` | Built browser dashboard bundle. Keep until a separate dashboard asset pipeline replaces it. |
+| `templates/dashboard/assets/i18n.js` | Browser dashboard localization asset. |
+| `templates/dashboard/assets/markdown-reader.js` | Browser dashboard helper asset. |
+| `templates/dashboard/assets/mermaid-renderer.js` | Browser dashboard helper asset. |
+
+These files should not be deleted by a runtime `.mjs` cleanup PR. If they are
+migrated later, use a dedicated preset or dashboard asset migration plan with its
+own package and browser checks.
+
+## Future Cleanup Gate
+
+Any future PR that removes or migrates the remaining preset/dashboard JavaScript
+exceptions must prove all of the following for its own surface:
+
+- package `bin` and `postinstall` still work from a packed tarball;
+- installed package execution works with a temp `HOME` and PATH isolated to the
+  temp consumer `node_modules/.bin`;
+- `npm pack --dry-run --json` includes the intended runtime files and excludes
+  private, temporary, and test-only material;
+- snapshot matrix has no blocking drift;
+- real target smoke passes;
+- the PR is independently revertible without reverting the earlier dist runtime
+  cutover or the PR-28 historical shim deletion.
+
+`dist/**/*.mjs` remains the supported package execution surface. Preset `.mjs`
+hooks and dashboard browser `.js` assets remain documented exceptions, not
+unfinished CLI runtime migration work.

package/examples/minimal-project/AGENTS.md

@@ -1,4 +1,4 @@
 # Minimal Harness Example
 
-Use `docs/11-REFERENCE/` for project rules and `docs/09-PLANNING/TASKS/` for
-task execution records.
+Use `coding-agent-harness/governance/standards/` for project rules and
+`coding-agent-harness/planning/tasks/` for task execution records.

package/examples/minimal-project/coding-agent-harness/harness.yaml

@@ -0,0 +1,14 @@
+version: 2
+locale: en-US
+capabilities:
+  - core
+  - dashboard
+structure:
+  harnessRoot: coding-agent-harness
+  planningRoot: coding-agent-harness/planning
+  tasksRoot: coding-agent-harness/planning/tasks
+  modulesRoot: coding-agent-harness/planning/modules
+  externalRoot: coding-agent-harness/planning/external
+  governanceRoot: coding-agent-harness/governance
+  generatedRoot: coding-agent-harness/governance/generated
+  regressionRoot: coding-agent-harness/governance/regression

package/examples/minimal-project/coding-agent-harness/planning/tasks/demo-task/progress.md

@@ -0,0 +1,11 @@
+# Demo Task - Progress
+
+## Status
+
+in-progress
+
+## Updates
+
+| Date | Update | Evidence |
+| --- | --- | --- |
+| 2026-05-18 | Created example visual map | report:TARGET:coding-agent-harness/planning/tasks/demo-task/visual_map.md:example phase table |

package/examples/minimal-project/{docs/09-PLANNING/TASKS → coding-agent-harness/planning/tasks}/demo-task/review.md

@@ -14,7 +14,7 @@ No material finding for this example.
 
 | Evidence ID | Type | Path | Summary |
 | --- | --- | --- | --- |
-| E-001 | review | TARGET:docs/09-PLANNING/TASKS/demo-task/task_plan.md | Visual roadmap table exists |
+| E-001 | review | TARGET:coding-agent-harness/planning/tasks/demo-task/task_plan.md | Visual map table exists |
 
 ## Findings