coding-agent-harness 1.0.4 → 1.0.6

package/docs-release/guides/migration-playbook.md

@@ -15,7 +15,38 @@ English mirror: `docs-release/guides/migration-playbook.en-US.md`
 如果目标环境没有 `harness`，不得静默全局安装；先询问用户是否允许运行
 `npm install -g coding-agent-harness`。用户明确同意后才能安装。用户不同意或未回复时，
 用 `npx --yes coding-agent-harness <command>` 运行同一条 CLI。维护者在本源码仓调试时，
-可以把同一命令替换为 `node scripts/harness.mjs`。
+可以把同一命令替换为 `node dist/harness.mjs`。
+
+## 目标路径和 v2 结构
+
+v2 的默认活跃目录是目标项目里的 `coding-agent-harness/`，入口文件是
+`coding-agent-harness/harness.yaml`。但检查目标不要求这个目录一定在仓库根目录下使用固定名称。
+如果项目已经把 Harness 状态放在自定义目录，例如
+`.project-control/harness-state/`，需要在该目录的 `harness.yaml` 中声明：
+
+```yaml
+structure:
+  harnessRoot: .project-control/harness-state
+  planningRoot: .project-control/harness-state/planning
+  tasksRoot: .project-control/harness-state/planning/tasks
+  governanceRoot: .project-control/harness-state/governance
+  generatedRoot: .project-control/harness-state/governance/generated
+```
+
+之后可以从项目根运行：
+
+```bash
+harness status --json /path/to/project
+harness check --profile target-project /path/to/project
+```
+
+也可以直接指向 Harness 根目录：
+
+```bash
+harness status --json /path/to/project/.project-control/harness-state
+```
+
+如果一个项目下存在多个 `harness.yaml`，不要让 agent 猜；必须把目标 Harness 根目录作为命令参数传入。
 
 ## 迁移原则
 
@@ -35,6 +66,7 @@ English mirror: `docs-release/guides/migration-playbook.en-US.md`
 git -C /path/to/project status --short --branch
 harness status --json /path/to/project
 harness migrate-plan --json --limit 1000 /path/to/project
+harness migrate-structure --plan --json /path/to/project
 ```
 
 然后 agent 必须给用户一份迁移计划，并主动推荐迁移深度：
@@ -69,6 +101,20 @@ Agent 必须记录具体判断证据，例如 `AGENTS.md`、`CLAUDE.md`、`READM
 
 2. 运行迁移轨道：
 
+先把旧 `docs/` 布局迁到 v2 manifest 布局。`--plan` 是只读预览；用户确认后才运行
+`--apply`。默认迁移目标是 `coding-agent-harness/`，并会把旧 `docs/` 归档到
+`coding-agent-harness/governance/archive/legacy-docs/`。旧版本遗留的
+`planning/**/_task-template` 和 `planning/**/_module-template` 是 npm 包内模板的生成副本，
+迁移时会从目标项目中移除：
+
+```bash
+harness migrate-structure --plan --json /path/to/project
+harness migrate-structure --apply --json /path/to/project
+harness check --profile target-project /path/to/project
+```
+
+目录迁移通过后，再运行 session 迁移轨道：
+
 ```bash
 harness migrate-run \
   --locale zh-CN \
@@ -96,6 +142,18 @@ harness migrate-verify /tmp/cah-migration-project/session.json
 
 `migrate-verify` 会检查 capability registry、locale、dashboard HTML 路径、普通检查、strict deferred 元数据和 git index。它通过以后，才可以说迁移输出“可用”。
 
+4. 基于验证通过的 session 创建迁移任务：
+
+```bash
+harness new-task \
+  --budget complex \
+  --preset legacy-migration \
+  --from-session /tmp/cah-migration-project/session.json \
+  /path/to/project
+```
+
+`legacy-migration` preset 任务是后续迁移工作的可审计交接点。它会记录 session、证据包、preset audit、write scope 和 migration follow-up queue；不会自动重写历史任务正文。
+
 如果后续继续清理 warning 或补活跃任务合同，第一次 session 只能作为 baseline。最终交付前要重新运行 `migrate-run` 生成新 session/dashboard，或者明确列出 baseline session 与最终检查证据的差异。
 
 `migrate-verify` 通过不等于 full migration complete。完整迁移还必须满足：

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

@@ -28,6 +28,29 @@ and `harness install-user` seed them into the user preset root, while
 `harness preset seed` for the user root or `harness preset seed --project <target>`
 for the project root when a preset root is missing or incomplete.
 
+## Dashboard Management
+
+The Dashboard exposes a Presets view for the target project. Static dashboards
+show a read-only catalog of discovered project, user, and bundled presets,
+including source, purpose, compatible budgets, task kind, manifest path, and
+resource counts.
+
+Use the local dynamic Workbench when you want to manage presets from the web UI:
+
+```bash
+harness dev /path/to/project
+```
+
+In Workbench mode, the Presets view can check presets, install a local preset
+directory, `.zip` archive, or bundled preset id into the project or user scope,
+seed bundled presets into either scope, and uninstall project/user presets.
+Bundled package presets are immutable from the Dashboard: they can be inspected,
+checked, and used as install or seed sources, but not edited or deleted.
+
+The CLI and filesystem remain canonical. The Dashboard calls the same preset
+registry operations as `harness preset ...`; it does not store independent preset
+state.
+
 ## Package Layout
 
 ```text
@@ -55,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
@@ -83,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
 ```
 
@@ -184,13 +207,14 @@ Supported evidence types:
 ```bash
 harness preset check ./my-preset
 harness preset install ./my-preset
+harness preset install ./my-preset.zip
 harness preset install ./my-preset --project /path/to/project
 harness preset install legacy-migration --force
 harness preset seed
 harness preset seed --project /path/to/project
 harness preset list --json /path/to/project
 harness preset inspect custom-review --json /path/to/project
-harness new-task custom-review-task --preset custom-review --subject "API contracts" /path/to/project
+harness new-task --title "Custom review task" --preset custom-review --subject "API contracts" /path/to/project
 harness preset uninstall custom-review
 ```
 
@@ -199,7 +223,7 @@ harness preset uninstall custom-review
 For every preset, prove both the manifest and downstream task behavior:
 
 1. Run `harness preset check ./my-preset`.
-2. Install into an isolated HOME or disposable environment.
+2. Install the folder and, if distributing an archive, install the `.zip` into an isolated HOME or disposable environment.
 3. Create at least one task with `harness new-task --preset`.
 4. For reference bundles, create two different tasks from the same preset and verify both contain the same shared `references/` files and independent audit/evidence bundles.
 5. Run `harness status --json`, `harness task-index --json`, and `harness check --profile target-project <target>`.

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/` 到每个仓库。
 
 先决定：