coding-agent-harness 1.0.4 → 1.0.6

package/presets/standard-task/preset.yaml

@@ -9,7 +9,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
@@ -27,5 +27,5 @@ audit:
   evidenceFiles: [preset-audit.json]
 writeScopes:
   taskDocs:
-    path: docs/09-PLANNING/TASKS/**
+    path: coding-agent-harness/planning/tasks/**
     access: write

package/references/adversarial-review-standard.md

@@ -13,7 +13,7 @@
 标准位置：
 
 ```text
-docs/09-PLANNING/TASKS/<YYYY-MM-DD-任务名>/review.md
+coding-agent-harness/planning/tasks/<YYYY-MM-DD-任务名>/review.md
 ```
 
 任务目录中的文件职责：
@@ -150,7 +150,7 @@ Review loop 的固定执行形态：
 - `progress.md` 记录审查发生的时间和处理结果摘要
 - `findings.md` 记录审查中产生的技术决策或研究发现
 - `Regression-SSoT.md` 记录新增或调整的 regression surface
-- `lesson_candidates.md` 和 `docs/01-GOVERNANCE/lessons/*.md` 记录可复用的流程、架构或标准改进建议
+- `lesson_candidates.md` 和 `coding-agent-harness/governance/lessons/*.md` 记录可复用的流程、架构或标准改进建议
 - `walkthrough` 收口时引用 `review.md` 的 material finding 状态和 no-finding 结论
 - `Harness Ledger` 记录本轮是否完成 review report
 

package/references/agents-md-pattern.md

@@ -28,40 +28,40 @@ AGENTS.md 只包含两类内容：
 ## Task-Type Reading Matrix
 
 - 架构 / adapter / runtime 相关任务：
-  先读 docs/11-REFERENCE/core-decoupling-standard.md
+  先读 coding-agent-harness/governance/standards/core-decoupling-standard.md
 
 - 测试 / scenario / 冒烟：
-  先读 docs/11-REFERENCE/testing-standard.md
+  先读 coding-agent-harness/governance/standards/testing-standard.md
 
 - 文档治理 / planning / walkthrough：
-  先读 docs/11-REFERENCE/docs-library-standard.md
+  先读 coding-agent-harness/governance/standards/docs-library-standard.md
 
 - Harness Ledger / 上下文回写：
-  先读 docs/11-REFERENCE/harness-ledger-standard.md
+  先读 coding-agent-harness/governance/standards/harness-ledger-standard.md
 
 - Walkthrough / Closeout / Lessons 收口：
-  先读 docs/11-REFERENCE/walkthrough-standard.md，然后读 docs/10-WALKTHROUGH/Closeout-SSoT.md、任务本地 lesson_candidates.md 和 docs/01-GOVERNANCE/lessons/
+  先读 coding-agent-harness/governance/standards/walkthrough-standard.md，然后读 coding-agent-harness/governance/generated/Closeout-Index.md、任务本地 lesson_candidates.md 和 coding-agent-harness/governance/lessons/
 
 - 开发执行 / 回写流程：
-  先读 docs/11-REFERENCE/execution-workflow-standard.md
+  先读 coding-agent-harness/governance/standards/execution-workflow-standard.md
 
 - Repo governance / PR / branch protection:
-  先读 docs/11-REFERENCE/repo-governance-standard.md
+  先读 coding-agent-harness/governance/standards/repo-governance-standard.md
 
 - CI/CD / required checks:
-  先读 docs/11-REFERENCE/ci-cd-standard.md
+  先读 coding-agent-harness/governance/standards/ci-cd-standard.md
 
 - 长程任务 / 连续执行 / 子代理审查：
-  先读 docs/11-REFERENCE/long-running-task-standard.md
+  先读 coding-agent-harness/governance/standards/long-running-task-standard.md
 
 - 对抗性 review / reviewer 报告：
-  先读 docs/11-REFERENCE/adversarial-review-standard.md
+  先读 coding-agent-harness/governance/standards/adversarial-review-standard.md
 
 - Reviewer / subagent / 外部审查路由：
-  先读 docs/11-REFERENCE/review-routing-standard.md
+  先读 coding-agent-harness/governance/standards/review-routing-standard.md
 
 - 前端 / UI 任务：
-  先读 docs/11-REFERENCE/frontend-standard.md
+  先读 coding-agent-harness/governance/standards/frontend-standard.md
 ```
 
 ### 推荐结构
@@ -72,7 +72,7 @@ AGENTS.md 只包含两类内容：
 ├── CLAUDE.md        ← 轻量 shim，指向 AGENTS.md
 └── docs/
     ├── Harness-Ledger.md
-    └── 11-REFERENCE/
+    └── coding-agent-harness/governance/standards/
         ├── testing-standard.md
         ├── execution-workflow-standard.md
         ├── repo-governance-standard.md
@@ -107,7 +107,7 @@ CLAUDE.md 控制在 **10-50 行**。它只做 Claude Code 兼容入口，不应
 ## 生成 AGENTS.md + CLAUDE.md 的步骤
 
 1. 确认项目的技术栈和主要模块
-2. 确认 `docs/11-REFERENCE/` 下有哪些标准文件
+2. 确认 `coding-agent-harness/governance/standards/` 下有哪些标准文件
 3. 用 `templates/AGENTS.md.template` 作为 AGENTS.md 起点
 4. 填写项目信息区（项目名、技术栈、仓库结构）
 5. 根据项目模块编写 Task-Type Reading Matrix

package/references/cadence-ledger.md

@@ -6,7 +6,7 @@
 
 ## Cadence Ledger 结构
 
-Cadence Ledger 是一个独立文件，放在 `docs/05-TEST-QA/Cadence-Ledger.md`。
+Cadence Ledger 是一个独立文件，放在 `coding-agent-harness/governance/regression/Cadence-Ledger.md`。
 
 包含两个部分：
 

package/references/ci-cd-standard.md

@@ -16,7 +16,7 @@ CI/CD design must connect the project's real stack to required merge evidence:
 ## 存放位置
 
 ```text
-docs/11-REFERENCE/ci-cd-standard.md
+coding-agent-harness/governance/standards/ci-cd-standard.md
 ```
 
 Workflow files usually live under:

package/references/delivery-operating-model-standard.md

@@ -11,13 +11,13 @@ delivery operating model：谁负责拆分工作、几个仓库/团队并行、a
 ## 存放位置
 
 ```text
-docs/11-REFERENCE/delivery-operating-model-standard.md
+coding-agent-harness/governance/standards/delivery-operating-model-standard.md
 ```
 
 如项目是多人或多仓交付，还应创建：
 
 ```text
-docs/09-PLANNING/Delivery-SSoT.md
+coding-agent-harness/planning/Delivery-SSoT.md
 ```
 
 ## 必填字段
@@ -40,7 +40,7 @@ Define who breaks roadmap work into feature blocks:
 |-------|-------|----------|------|
 | Roadmap | [owner] | [SSoT / issue tracker] | [how priority is chosen] |
 | Feature block | [owner] | `Delivery-SSoT.md` / generated Harness Ledger | [how blocks are bounded] |
-| Task | [owner] | `docs/09-PLANNING/TASKS/<task>/task_plan.md` | [who can start work] |
+| Task | [owner] | `coding-agent-harness/planning/tasks/<task>/task_plan.md` | [who can start work] |
 | Review | [owner] | `review.md` / PR review | [required reviewers] |
 | Integration | [owner] | PR / release branch / integration branch | [merge order] |
 
@@ -97,7 +97,7 @@ Use when work passes through formal stages: requirements, design, implementation
 
 - Stage entry/exit criteria must be explicit.
 - Agents cannot skip design/review gates just because code is ready.
-- Walkthrough and Closeout SSoT map to stage closeout, not only feature closeout.
+- Walkthrough and Closeout Index map to stage closeout, not only feature closeout.
 
 #### kanban-continuous
 

package/references/docs-directory-standard.md

@@ -1,168 +1,74 @@
-# docs/ 目录标准
+# Harness Directory Standard
 
-## 目的
+## Purpose
 
-定义项目文档目录的标准结构。所有文档按职责分层，agent 按 Task-Type Reading Matrix 按需加载。
+Define the v2 target-project Harness structure. Active Harness state lives under
+`coding-agent-harness/`; old numbered document roots are legacy migration input
+only and must be migrated with `harness migrate-structure --apply`.
 
-## 标准目录结构
-
-```
-docs/
-├── Harness-Ledger.md           ← CLI 生成的任务生命周期总账
-├── 00-RAW-PRDS/              ← 原始需求文档、PRD、用户故事
-│   └── _archive/              ← 本层历史文档归档（如该层会增长）
-├── 01-GOVERNANCE/             ← 项目治理规则、决策记录、经验沉淀
-│   ├── lessons/               ← promoted lesson 详情文档
-│   └── _archive/              ← 已处理条目归档
-├── 02-PRODUCT/                ← 产品设计、用户流程、功能规格
-│   └── _archive/              ← 本层历史文档归档（如该层会增长）
-├── 03-ARCHITECTURE/           ← 系统结构事实源：本仓架构、外部系统结构、服务地图、关键跨服务流、ADR
-│   └── _archive/              ← 本层历史文档归档（如该层会增长）
-├── 04-DEVELOPMENT/            ← 开发上下文输入包：本地开发、外部服务摘要、外部资料包、mock/stub、跨仓调试
-│   └── _archive/              ← 本层历史文档归档（如该层会增长）
-├── 05-TEST-QA/                ← 测试策略、Regression SSoT、Cadence Ledger
-│   └── _archive/              ← 废弃 regression gate / 旧 evidence pack 归档
-├── 06-INTEGRATIONS/           ← 接口合同层：API、event、webhook、SDK、第三方接入细节
-│   └── _archive/              ← 本层历史文档归档（如该层会增长）
-├── 07-OPERATIONS/             ← 部署、运维、监控、告警
-│   └── _archive/              ← 本层历史文档归档（如该层会增长）
-├── 08-SECURITY/               ← 安全策略、权限模型、审计日志
-│   └── _archive/              ← 本层历史文档归档（如该层会增长）
-├── 09-PLANNING/               ← 排期、任务计划
-│   ├── TASKS/                 ← 任务目录（每个任务一个子目录）
-│   │   └── _task-template/    ← 任务模板
-│   ├── MODULES/               ← 模块并行开发计划（启用时）
-│   │   └── _archive/          ← 已完成 / 暂停过久模块归档
-│   ├── _archive/              ← 历史任务、旧生命周期表明细、过期排期归档
-│   ├── Delivery-SSoT.md       ← 多人 / 多仓 / 传统流程下的交付排期和集成顺序
-├── 10-WALKTHROUGH/            ← Walkthrough 收口记录与 Closeout SSoT
-│   └── _archive/              ← 历史 walkthrough 批量归档（迁移 / 年度收束时）
-├── 11-REFERENCE/              ← 标准文件（agent 按需加载）
-│   └── _archive/              ← 旧版标准归档
-└── 99-TMP/                    ← 临时文件（定期清理）
-```
-
-## 裁剪规则
-
-不是每个项目都需要全部目录。根据诊断结果裁剪：
-
-| 目录 | 何时可省略 |
-|------|-----------|
-| 00-RAW-PRDS | 没有正式 PRD 流程的小项目 |
-| 01-GOVERNANCE | 仅实验性 Lite 项目且明确不启用 Lessons / 归档时 |
-| 02-PRODUCT | 纯技术项目（库、CLI 工具） |
-| 06-INTEGRATIONS | 没有第三方集成 |
-| 07-OPERATIONS | 没有部署需求（纯库） |
-| 08-SECURITY | 没有安全敏感场景 |
-| 99-TMP | 可选 |
-
-以下目录是 harness 的核心，不可省略：
-- 01-GOVERNANCE
-- 03-ARCHITECTURE
-- 05-TEST-QA
-- 09-PLANNING（含 TASKS/）
-- 10-WALKTHROUGH
-- 11-REFERENCE
-
-`docs/Harness-Ledger.md` 不是目录，但属于核心 harness 文件，不可省略。它是
-`docs/` 根目录允许存在的全局控制文件；普通过程文件仍然不得放在根目录。
-
-`docs/10-WALKTHROUGH/Closeout-SSoT.md` 是 closed task 的收口索引和硬门槛；
-每个 closed Harness Ledger row 必须在这里登记 walkthrough 或受控 skip reason。
-
-## 03 / 04 / 06 边界规则
-
-这三个目录共同承载项目和外部系统知识，但职责不能重叠：
+## Canonical Structure
 
 ```text
-03 = 它在系统里是什么
-04 = 我开发当前仓时怎么面对它
-06 = 我和它具体怎么对接
+coding-agent-harness/
+├── harness.yaml
+├── context/
+│   ├── architecture/
+│   ├── development/
+│   └── integrations/
+├── planning/
+│   ├── tasks/
+│   │   └── <task-id>/
+│   │       ├── INDEX.md
+│   │       ├── task_plan.md
+│   │       ├── progress.md
+│   │       ├── review.md
+│   │       ├── findings.md
+│   │       ├── visual_map.md
+│   │       ├── lesson_candidates.md
+│   │       └── walkthrough.md
+│   ├── modules/
+│   │   ├── Module-Registry.md
+│   │   └── <module-key>/
+│   │       ├── module_plan.md
+│   │       └── tasks/<task-id>/
+│   └── Delivery-SSoT.md
+└── governance/
+    ├── generated/
+    │   ├── Harness-Ledger.md
+    │   └── Closeout-Index.md
+    ├── regression/
+    ├── standards/
+    ├── lessons/
+    └── archive/
 ```
 
-| 目录 | 放什么 | 不放什么 | 必需机器字段 |
-| --- | --- | --- | --- |
-| `03-ARCHITECTURE/` | system map、service catalog、service responsibility、ownership、critical flows、ADR | endpoint payload、错误码、mock/stub、任务日志 | `Context Doc Type`, `Source Evidence`, `Last Verified`, `Confidence` |
-| `04-DEVELOPMENT/` | local setup、codebase map、external service development summary、external source packs、mocks/stubs、cross-repo debugging | 长期系统事实源、payload 合同、ADR、未经摘要的外部资料堆 | `Context Doc Type`, `Development Use`, `Do Not Assume`, `Mocks / Stubs`, `Source Evidence`, `Last Verified`, `Confidence` |
-| `06-INTEGRATIONS/` | endpoint、payload、错误码、auth、event schema、webhook、SDK、contract tests | 全局拓扑、service ownership catalog、开发调试笔记 | `Context Doc Type`, `Contract Type`, `Auth`, `Payload`, `Errors`, `Contract Tests`, `Source Evidence`, `Last Verified`, `Confidence` |
-
-示例：
-
-- `03-ARCHITECTURE/service-catalog.md` 可以写“Billing API: owner=payments, interface=/v1/invoices, link=06-INTEGRATIONS/billing-api-contract.md”。
-- `06-INTEGRATIONS/billing-api-contract.md` 才写 `/v1/invoices` 的 payload、错误码、鉴权和 contract test。
-- `04-DEVELOPMENT/external-context/billing.md` 写本仓开发时如何 mock Billing、如何排查 Billing 失败、哪些 Billing 假设不安全。
-- `04-DEVELOPMENT/external-source-packs/payments/` 只存外部团队资料的索引、摘要和投影状态；最终事实仍要回写到 `03/04/06`。
-
-## 外部资料摄取规则
-
-当项目属于微服务、多仓、前后端分仓或依赖外部团队文档时，Agent 在 Diagnose / Decide 阶段必须询问用户是否有外部资料。资料少时直接作为 `Source Evidence`；资料多、跨主题或持续增长时，按 `external-source-intake-standard.md` 创建 source pack。
-
-外部资料的固定处理顺序：
-
-```text
-Inventory -> Classify -> Sanitize -> Digest -> Project -> Verify -> Residual
+## Rules
+
+- `harness.yaml` is the structure manifest and resolver source of truth.
+- Root task packages live in `planning/tasks/<task-id>/`.
+- Module task packages live in `planning/modules/<module-key>/tasks/<task-id>/`.
+- `walkthrough.md` is task-local; global closeout state is generated into
+  `governance/generated/Closeout-Index.md`.
+- `Harness-Ledger.md` is generated into `governance/generated/`; do not edit it
+  as a hand-written global table.
+- Context docs are split by role:
+  - `context/architecture/`: system facts, ownership, service catalog, ADRs.
+  - `context/development/`: local setup, mocks, stubs, external source packs.
+  - `context/integrations/`: API, event, webhook, SDK, auth, payload contracts.
+- Regression and cadence tables live in `governance/regression/`.
+- Long-lived operating standards live in `governance/standards/`.
+- Reusable lessons live in `governance/lessons/`.
+- Historical migrated material belongs under `governance/archive/`.
+
+## Migration Boundary
+
+Legacy directories are not active runtime locations. The only normal command
+that should read them is migration planning/application:
+
+```bash
+harness migrate-structure --plan /path/to/project
+harness migrate-structure --apply /path/to/project
 ```
 
-未经过 digest 和 projection 的原始资料不能进入执行事实层。
-
-Checker 规则：
-
-- 新增 `03/04/06` 文档必须声明 `Context Doc Type`。
-- 结构事实必须有 `Source Evidence`、`Last Verified` 和 `Confidence`。
-- `04-DEVELOPMENT/external-context/*.md` 必须包含 `Development Use`、`Do Not Assume`、`Mocks / Stubs`。
-- `06-INTEGRATIONS/*.md` 必须包含 `Contract Type`、`Auth`、`Payload`、`Errors`、`Contract Tests`。
-- 旧项目 safe-adoption 可先收到 warning；declared canonical 项目应修到 clean。
-
-## 通用归档规则
-
-归档是目录级基础设施，不是单张表的特例。任何会持续增长的目录都应该有同级
-`_archive/` 目录；如果目录本身不会增长，可以暂不创建，但第一次归档前必须创建。
-
-### 硬规则
-
-- Active 文件只保存当前事实和最近需要操作的事实。
-- 历史事实移入同级 `_archive/`，不要长期堆在 Active 表底部。
-- 归档不改变原始 ID，不删除 task plan、walkthrough、SSoT 或 Ledger 的可追溯引用。
-- 归档后 Active 文件必须留下归档索引或指针，说明历史在哪里。
-- 归档文件必须按时间或范围命名：`<name>-archive-YYYY-QN.md`、`<name>-phase-1-11.md`、`YYYY-MM-DD-<name>.md`。
-- 新增归档规则时，同步更新 `docs-library-standard.md` 和对应 checker。
-
-### 推荐触发条件
-
-| 对象 | 触发条件 | 归档位置 |
-|------|----------|----------|
-| Legacy Feature / Private Feature 生命周期表 | 迁移到 ledger-only 版本 | `09-PLANNING/_archive/` |
-| Delivery SSoT | 集成 wave 结束或 completed/superseded blocks 超过 20 条 | `09-PLANNING/_archive/` |
-| Module Registry / module_plan | 模块 completed 或 paused 超过 60 天 | `09-PLANNING/MODULES/_archive/<key>/` |
-| Regression SSoT | gate 废弃或长期不再运行 | `05-TEST-QA/_archive/` |
-| Lesson detail docs | merged/rejected/superseded 详情文档超过 20 条 | `01-GOVERNANCE/_archive/` |
-| Harness Ledger | closed/superseded 超过 50 条 | `01-GOVERNANCE/_archive/` |
-| Walkthrough | 年度/阶段迁移或目录过大 | `10-WALKTHROUGH/_archive/` |
-
-## Reference 标准文件清单
-
-`docs/11-REFERENCE/` 下的标准文件，按项目需要选择：
-
-| 文件 | 职责 | 必需？ |
-|------|------|--------|
-| testing-standard.md | 测试规范、框架选择、覆盖率要求 | 是 |
-| execution-workflow-standard.md | 开发执行流程、commit 规范、PR 流程 | 是 |
-| delivery-operating-model-standard.md | 工程组织形态、feature block 拆分、跨仓/团队协作模型 | 是 |
-| repo-governance-standard.md | repo platform、branch protection、PR policy、required checks、worktree concurrency | 是 |
-| pull-request-standard.md | PR 描述结构、中英双语要求、版本影响、验证、审查证据、残余风险和引用 | 是 |
-| ci-cd-standard.md | CI/CD profile、workflow、required checks、release/CD residual | 是 |
-| long-running-task-standard.md | 长程任务合同、连续执行权限、review loop、停止条件 | 是 |
-| adversarial-review-standard.md | 对抗性 review 报告、finding 分级、no-finding 结论、residual 路由 | 是 |
-| review-routing-standard.md | reviewer / subagent / external agent / human review 触发和路由规则 | 是 |
-| docs-library-standard.md | 文档治理规范、命名规则、归档规则 | 是 |
-| external-source-intake-standard.md | 外部资料摄取、过滤、摘要和投影规则 | 是 |
-| harness-ledger-standard.md | Harness Ledger 写入规范、closeout 检查 | 是 |
-| regression-ssot-governance.md | Regression SSoT 治理规范 | Standard+ |
-| walkthrough-standard.md | Walkthrough 写作规范 | 是 |
-| worktree-standard.md | Worktree 命名、分支、清理规范 | Standard+ |
-| engineering-standard.md | 工程规范、代码风格、架构约束 | 推荐 |
-| frontend-standard.md | 前端规范（如有前端） | 按需 |
-| api-standard.md | API 设计规范（如有 API） | 按需 |
-| security-standard.md | 安全规范（如有安全需求） | 按需 |
-| deployment-standard.md | 部署规范（如有部署需求） | 按需 |
-| debugging-playbook.md | 调试经验手册 | 推荐 |
+After migration, `status`, `check`, `dashboard`, and task lifecycle commands
+must use the v2 manifest paths above.

package/references/external-source-intake-standard.md

@@ -7,10 +7,10 @@
 ## 核心模型
 
 ```text
-外部原始资料 -> source pack 索引 -> digest 摘要 -> 03/04/06 执行投影
+外部原始资料 -> source pack 索引 -> digest 摘要 -> context/{architecture,development,integrations} 执行投影
 ```
 
-`03-ARCHITECTURE`、`04-DEVELOPMENT`、`06-INTEGRATIONS` 不承载外部资料堆。它们只保存已经提炼、可验证、能指导当前仓库开发的事实。
+`coding-agent-harness/context/architecture`、`coding-agent-harness/context/development`、`coding-agent-harness/context/integrations` 不承载外部资料堆。它们只保存已经提炼、可验证、能指导当前仓库开发的事实。
 
 ## Diagnose / Decide 必问条件
 
@@ -32,15 +32,15 @@
 
 | 场景 | 存储方式 |
 | --- | --- |
-| 只有 1-4 个稳定外部文档 | 不必建独立 source pack；在对应 `03/04/06` 的 `Source Evidence` 中链接 |
-| 外部资料超过 5 份、跨多个主题、或会持续增长 | 创建 `docs/04-DEVELOPMENT/external-source-packs/<source-key>/` |
+| 只有 1-4 个稳定外部文档 | 不必建独立 source pack；在对应 `context/{architecture,development,integrations}` 的 `Source Evidence` 中链接 |
+| 外部资料超过 5 份、跨多个主题、或会持续增长 | 创建 `coding-agent-harness/context/development/external-source-packs/<source-key>/` |
 | 资料含敏感信息、密钥、客户数据或不能进仓 | 不复制原文；只记录外部路径、owner、访问条件和摘要 |
 | 资料可入仓 | 可放 `raw/`，但必须经过 digest 后才能投影到执行文档 |
 
 推荐结构：
 
 ```text
-docs/04-DEVELOPMENT/external-source-packs/<source-key>/
+coding-agent-harness/context/development/external-source-packs/<source-key>/
 ├── README.md
 ├── digests/
 ├── raw/
@@ -53,7 +53,7 @@ docs/04-DEVELOPMENT/external-source-packs/<source-key>/
 2. Classify：按 architecture、development、integration、security、operations、product、unknown 分类。
 3. Sanitize：检查密钥、token、客户数据、隐私、内部账号和不可公开链接。
 4. Digest：提炼事实、疑问、不安全假设和证据。
-5. Project：把稳定事实投影到 `03/04/06`。
+5. Project：把稳定事实投影到 `context/{architecture,development,integrations}`。
 6. Verify：尽可能用代码、接口测试、owner 确认或运行证据验证。
 7. Residual：不能确认的内容留在 source pack 或 `Do Not Assume`，不进入执行事实。
 
@@ -61,14 +61,14 @@ docs/04-DEVELOPMENT/external-source-packs/<source-key>/
 
 | 资料内容 | 投影位置 |
 | --- | --- |
-| 服务职责、上下游、owner、数据归属、系统拓扑 | `03-ARCHITECTURE/service-catalog.md` 或 `services/<service-key>.md` |
-| 本仓开发时如何 mock、stub、启动、联调、排查 | `04-DEVELOPMENT/external-context/<service-key>.md` |
-| endpoint、payload、auth、error、event、webhook、SDK、contract test | `06-INTEGRATIONS/<contract>.md` |
+| 服务职责、上下游、owner、数据归属、系统拓扑 | `coding-agent-harness/context/architecture/service-catalog.md` 或 `services/<service-key>.md` |
+| 本仓开发时如何 mock、stub、启动、联调、排查 | `coding-agent-harness/context/development/external-context/<service-key>.md` |
+| endpoint、payload、auth、error、event、webhook、SDK、contract test | `coding-agent-harness/context/integrations/<contract>.md` |
 | 未确认、来源冲突、过期或背景参考 | 留在 source pack README / digest |
 
 ## 禁止事项
 
-- 不把几十份外部文档直接复制到 `03-ARCHITECTURE`、`04-DEVELOPMENT` 或 `06-INTEGRATIONS` 根目录。
+- 不把几十份外部文档直接复制到 `coding-agent-harness/context/architecture`、`coding-agent-harness/context/development` 或 `coding-agent-harness/context/integrations` 根目录。
 - 不把 digest 当成已验证事实。
 - 不在执行文档里保留大段原文、聊天流水或历史会议记录。
 - 不把密钥、token、客户数据、个人隐私或不可公开资料提交进仓。

package/references/harness-ledger.md

@@ -11,10 +11,10 @@ Harness Ledger 是任务生命周期的全局生成索引。它把任务目录
 ## 文件位置
 
 ```text
-docs/Harness-Ledger.md
+coding-agent-harness/governance/generated/Harness-Ledger.md
 ```
 
-放在 `docs/` 根目录，因为它横跨 planning、review、walkthrough、lessons 和模块索引。
+放在 `coding-agent-harness/` 根目录，因为它横跨 planning、review、walkthrough、lessons 和模块索引。
 
 ## 职责边界
 
@@ -48,7 +48,7 @@ Harness Ledger 不记录：
 触发任务生命周期变化时，优先使用 CLI：
 
 ```bash
-harness new-task <task-id>
+harness new-task --title "<title>"
 harness task-start <task-id>
 harness task-phase <task-id> <phase-id> --state done
 harness task-review <task-id>
@@ -63,7 +63,7 @@ Agent 不应手写或机械更新 Ledger 的任务行。如果发现生成结果
 - Delivery SSoT 仍管理交付 block、跨仓顺序、owner 和依赖。
 - Regression SSoT 仍管理回归面、证据深度和 residual。
 - Cadence Ledger 仍管理周期性验证节奏。
-- Closeout SSoT 仍管理 walkthrough、closeout status 和受控 skip reason。
+- Closeout Index 仍管理 walkthrough、closeout status 和受控 skip reason。
 - Module Registry 仍管理模块边界、owner、worktree 和写入范围。
 
 这些表不是任务生命周期小表。本版本只移除 `Feature-SSoT.md` / `Private-Feature-SSoT.md` 这类生命周期投影，不删除尚无等价 scanner/generator 的治理表。
@@ -73,7 +73,7 @@ Agent 不应手写或机械更新 Ledger 的任务行。如果发现生成结果
 旧生命周期表切换时归档到：
 
 ```text
-docs/09-PLANNING/_archive/<timestamp>/
+coding-agent-harness/planning/_archive/<timestamp>/
 ```
 
 归档不改变历史证据，也不要求迁移 Agent 删除旧快照。确认 Dashboard、`task-list`、`task-index` 和新 Ledger 都能表达当前任务后，项目 owner 再决定是否清理归档。
@@ -88,7 +88,7 @@ docs/09-PLANNING/_archive/<timestamp>/
 4. 回写 Repo Governance / CI-CD 状态（如适用）。
 5. 回写 Regression SSoT / Cadence Ledger / Delivery SSoT 等本轮实际触达的非生命周期治理表（如适用）。
 6. 写 walkthrough。
-7. 更新 Closeout SSoT。
+7. 更新 Closeout Index。
 8. 执行 Lessons 检查；新任务先更新 `lesson_candidates.md`，如人工确认沉淀，再由维护命令写详情文档。
 9. 运行 Harness CLI 生成或刷新 Harness Ledger。
 

package/references/legacy-12-phase-bootstrap.md

@@ -16,7 +16,7 @@ This document preserves the legacy bootstrap sequence used before the v1.0 capab
 4. Optional module registration: identify independent modules, write scopes, module registry rows, and module plans.
 5. Directory structure: create or adapt `docs/` according to the docs directory standard.
 6. AGENTS.md and CLAUDE.md: generate the root agent entrypoint and Claude Code shim.
-7. Reference standards: generate project-specific reference files under `docs/11-REFERENCE/`.
+7. Reference standards: generate project-specific reference files under `coding-agent-harness/governance/standards/`.
 8. Repository governance and CI/CD: define PR policy, required checks, branch protection, CI, and worktree concurrency.
 9. Planning loop: create task templates and task directories.
 10. Long-running task protocol: add long-running task standard and contract template.
@@ -31,7 +31,7 @@ This document preserves the legacy bootstrap sequence used before the v1.0 capab
 | Task directory with only `task_plan.md` | Add `brief.md`, `execution_strategy.md`, `visual_map.md`, `progress.md`, `findings.md`, and `review.md` only for active tasks. |
 | Embedded roadmap in `task_plan.md` | Move active roadmap rows into standalone `visual_map.md`; leave historical tasks untouched unless they are reopened. |
 | Single-line progress status | Normalize active tasks through `harness task-start`, `task-block`, `task-log`, and `task-complete`. |
-| Broad reference bundle | Declare only capabilities that are actually adopted in `.harness-capabilities.json`. |
+| Broad reference bundle | Declare only capabilities that are actually adopted in `coding-agent-harness/harness.yaml`. |
 | Long-running task artifacts | Add or declare `long-running-task` only when active work needs continuous autonomous execution. |
 | Informal module lists | Adopt `module-parallel` only after modules have owners, write scopes, dependency rules, and registry maintenance. |
 | Historical review notes | Do not rewrite all old review files. Upgrade active release-blocking reviews to the v1 review schema first. |

package/references/lessons-governance.md

@@ -8,23 +8,23 @@ Lessons 不再使用一张手工维护的全局表。原因很简单：lesson ca
 
 | 层级 | 文件 | 职责 |
 | --- | --- | --- |
-| 任务本地队列 | `docs/09-PLANNING/**/lesson_candidates.md` | 记录候选、拒绝、无候选、排队 promotion 和人工判定 |
-| 任务本地详情 | `docs/09-PLANNING/**/lessons/LC-*.md` | 在源任务上下文还新鲜时写完整 lesson 正文，供后续沉淀任务读取 |
-| Promoted lesson 详情 | `docs/01-GOVERNANCE/lessons/L-YYYY-MM-DD-NNN-<slug>.md` | 记录已接受、可复用、需要后续治理合入的经验 |
+| 任务本地队列 | `coding-agent-harness/planning/**/lesson_candidates.md` | 记录候选、拒绝、无候选、排队 promotion 和人工判定 |
+| 任务本地详情 | `coding-agent-harness/planning/**/lessons/LC-*.md` | 在源任务上下文还新鲜时写完整 lesson 正文，供后续沉淀任务读取 |
+| Promoted lesson 详情 | `coding-agent-harness/governance/lessons/L-YYYY-MM-DD-NNN-<slug>.md` | 记录已接受、可复用、需要后续治理合入的经验 |
 
-`docs/Harness-Ledger.md` 和 `docs/10-WALKTHROUGH/Closeout-SSoT.md` 只记录 closeout 结果：
+`coding-agent-harness/governance/generated/Harness-Ledger.md` 和 `coding-agent-harness/governance/generated/Closeout-Index.md` 只记录 closeout 结果：
 `checked-candidate:<LC-ID>`、`queued-promotion:<LC-ID>`、`checked-created:<L-ID>` 或历史兼容的 `checked-none:<reason>`。
 
 ## 目录结构
 
 ```text
-docs/01-GOVERNANCE/
+coding-agent-harness/governance/
 ├── lessons/                     ← promoted lesson 详情文档
 │   ├── L-2026-05-07-001-xxx.md
 │   └── ...
 └── _archive/                    ← 已合入或废弃的历史详情归档
 
-docs/09-PLANNING/TASKS/<task-id>/
+coding-agent-harness/planning/tasks/<task-id>/
 ├── lesson_candidates.md          ← 候选索引和人工路由状态
 └── lessons/
     └── LC-YYYYMMDD-NNN.md        ← task-local detail artifact
@@ -50,7 +50,7 @@ docs/09-PLANNING/TASKS/<task-id>/
 - `promoted`：维护命令已经创建 promoted lesson 详情文档，并回写源 candidate。
 - `rejected`：候选已带理由拒绝。
 
-`needs-promotion` 不阻塞任务 closeout，但必须在 Closeout SSoT / Harness Ledger 中记录 `queued-promotion: LC-YYYYMMDD-NNN`，并由后续维护任务处理。模块级候选还必须填写 `Module Key`，避免沉淀任务丢失模块边界。`promoted` 或人工直接创建详情文档时记录 `checked-created: L-YYYY-MM-DD-NNN`。如果没有候选，记录 `checked-candidate: LC-...` 或 `checked-none: <reason>`；`checked-none` 只用于旧任务兼容或没有 candidate 文件的历史收口。
+`needs-promotion` 不阻塞任务 closeout，但必须在 Closeout Index / Harness Ledger 中记录 `queued-promotion: LC-YYYYMMDD-NNN`，并由后续维护任务处理。模块级候选还必须填写 `Module Key`，避免沉淀任务丢失模块边界。`promoted` 或人工直接创建详情文档时记录 `checked-created: L-YYYY-MM-DD-NNN`。如果没有候选，记录 `checked-candidate: LC-...` 或 `checked-none: <reason>`；`checked-none` 只用于旧任务兼容或没有 candidate 文件的历史收口。
 
 ## Promotion 执行
 
@@ -60,13 +60,13 @@ promotion 只写 promoted 详情文档和源 candidate，不写共享 Lessons
 2. 选择 `templates/lessons/` 下的对应模板，或由 `lesson-promote --apply` 创建 promoted 详情文档。
 3. promoted 详情文档写清背景、现状问题、建议改动、影响范围和冲突声明。
 4. 回写源任务 `lesson_candidates.md`：对应候选标记为 `promoted`，并记录 `promoted:<L-ID>`。
-5. 在 Closeout SSoT / Harness Ledger 中记录 `checked-created:<L-ID>` 或 `queued-promotion:<LC-ID>`。
+5. 在 Closeout Index / Harness Ledger 中记录 `checked-created:<L-ID>` 或 `queued-promotion:<LC-ID>`。
 
 `lesson-promote --apply` 是 CLI-owned 机械写入：目标仓库必须是干净 Git root，
 命令会加 governance lock，只允许提交新 lesson detail 和源任务 `lesson_candidates.md`。
 如果存在 unrelated dirty diff，命令必须拒绝，让 coordinator 先提交、归属或记录 no-commit reason。
 
-如果四个问题的答案全是“没有”，也不能静默跳过。新任务必须在 `lesson_candidates.md` 中使用 `no-candidate-accepted` 并填写 No-Candidate Reason；旧任务可在 Closeout SSoT 和 Harness Ledger 中记录 `checked-none: <一句话原因>`。
+如果四个问题的答案全是“没有”，也不能静默跳过。新任务必须在 `lesson_candidates.md` 中使用 `no-candidate-accepted` 并填写 No-Candidate Reason；旧任务可在 Closeout Index 和 Harness Ledger 中记录 `checked-none: <一句话原因>`。
 
 ## Closeout 判定
 
@@ -79,10 +79,10 @@ promotion 只写 promoted 详情文档和源 candidate，不写共享 Lessons
 
 以下状态不合格：
 
-- 只在 walkthrough 或 progress 中说“无 lessons”，但 Closeout SSoT / Harness Ledger 没有记录。
+- 只在 walkthrough 或 progress 中说“无 lessons”，但 Closeout Index / Harness Ledger 没有记录。
 - 新任务跳过 `lesson_candidates.md`，只用 `checked-none` 代替 candidate 判定。
 - 用 `n/a` 代替检查结果，除非任务是纯只读分析且没有 closed ledger row。
-- `checked-created:<L-ID>` 指向的 `docs/01-GOVERNANCE/lessons/*.md` 不存在。
+- `checked-created:<L-ID>` 指向的 `coding-agent-harness/governance/lessons/*.md` 不存在。
 
 ## 沉淀类型
 
@@ -101,7 +101,7 @@ Agent 在产出任何 promoted lesson 之前，必须查看：
 
 - 任务本地 `lesson_candidates.md`
 - 任务本地 `lessons/LC-*.md`
-- `docs/01-GOVERNANCE/lessons/*.md`
+- `coding-agent-harness/governance/lessons/*.md`
 - 目标 reference / template / checker
 
 目的是确认是否已有同一 target、同一问题或冲突建议。
@@ -146,14 +146,14 @@ pending governance integration -> approved -> merged
 
 ## 归档机制
 
-当 `docs/01-GOVERNANCE/lessons/` 中已合入或废弃的详情文档过多时，可以把 `merged`、`rejected`、`superseded` 的文档移入 `docs/01-GOVERNANCE/_archive/`。不要归档仍被 Closeout SSoT 或 Harness Ledger 当前行引用的文档，除非同步更新引用。
+当 `coding-agent-harness/governance/lessons/` 中已合入或废弃的详情文档过多时，可以把 `merged`、`rejected`、`superseded` 的文档移入 `coding-agent-harness/governance/_archive/`。不要归档仍被 Closeout Index 或 Harness Ledger 当前行引用的文档，除非同步更新引用。
 
 ## 人的审批工作流
 
 1. 打开 dashboard 的 Lessons 队列，或搜索任务本地 `lesson_candidates.md` 中的 `needs-promotion`。
 2. 查看候选行的 `Detail Artifact`，确认任务本地详情正文足够完整。
 3. 需要提升时创建后续 sedimentation task，或批准 `lesson-promote --apply`。
-4. 查看生成的 `docs/01-GOVERNANCE/lessons/*.md`。
+4. 查看生成的 `coding-agent-harness/governance/lessons/*.md`。
 5. 有冲突的 lesson 一起审。
 6. 批准后由维护任务更新目标 reference / template / checker。
 
@@ -166,4 +166,4 @@ pending governance integration -> approved -> merged
 - `arch-change`：按建议更新架构文档。
 - `process-change`：按建议更新流程文档或 CLI/checker。
 
-合入任务收口时，必须在 `docs/Harness-Ledger.md` 的当前任务 row 中记录 `checked-created:<L-ID>`、`queued-promotion:<LC-ID>` 或 `checked-candidate:<LC-ID>`。
+合入任务收口时，必须在 `coding-agent-harness/governance/generated/Harness-Ledger.md` 的当前任务 row 中记录 `checked-created:<L-ID>`、`queued-promotion:<LC-ID>` 或 `checked-candidate:<LC-ID>`。