coding-agent-harness 1.0.2 → 1.0.5

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

@@ -19,6 +19,19 @@ read-only scan, skip Skill installation first and use `npx --yes coding-agent-ha
 / `migrate-plan` for the scan; install the Skill or run write commands only after the user
 confirms write access.
 
+This repository also publishes the nested `preset-creator` Skill for agents that author
+reusable Harness preset packages. Since the repository has both a root `SKILL.md` and a
+nested Skill, list or install it with `--full-depth`:
+
+```bash
+npx skills add FairladyZ625/coding-agent-harness --list --full-depth
+npx skills add FairladyZ625/coding-agent-harness --skill preset-creator --full-depth
+```
+
+Use `coding-agent-harness` to operate Harness in a target project. Use `preset-creator`
+only when the agent is designing a reusable preset for a repeatable task family with
+shared references, artifacts, evidence, or complex-task overlays.
+
 Use the v1.0 six-phase flow:
 
 1. Diagnose: scan project structure, language, existing docs, CI, collaboration model, external dependencies, and risk surfaces.
@@ -109,6 +122,17 @@ harness install-user --agent codex --global
 harness doctor-user --agent codex
 ```
 
+`npm install -g coding-agent-harness`, `harness install-user`, and `harness init`
+seed bundled presets:
+
+- User presets: `~/.coding-agent-harness/presets/<preset-id>/`
+- Project presets: `<target>/.coding-agent-harness/presets/<preset-id>/`
+
+Before initializing or taking over a task, agents must run
+`harness preset list --json [target]` and choose `--preset` only after checking
+the available presets. To repair missing bundled presets, run
+`harness preset seed` or `harness preset seed --project <target>`.
+
 Supported agent targets:
 
 | Agent | User directory |
@@ -125,7 +149,7 @@ Safety rules:
 - Interactive confirmation is the default. Non-interactive runs must pass `--yes` or first use `--dry-run`.
 - Existing files are not overwritten by default; only missing files are added.
 - Use `--force` only for explicit forced updates.
-- `doctor-user` checks that `SKILL.md`, templates, references, CLI scripts, and this guide exist.
+- `doctor-user` checks that `SKILL.md`, templates, references, bundled presets, CLI scripts, this guide, and the user-level preset seed exist.
 
 ## Legacy Harness Migration
 
@@ -140,11 +164,6 @@ harness migrate-run \
 
 harness migrate-verify \
   /tmp/cah-migration-project/session.json
-
-harness new-task \
-  --budget complex \
-  --preset legacy-migration \
-  --from-session /tmp/cah-migration-project/session.json
 ```
 
 Rules:
@@ -155,8 +174,8 @@ Rules:
 - Existing project facts may be merged, appended, or recorded as residuals. They must not be replaced with generic templates.
 - Historical contract gaps become `adoption-needed` warnings in normal mode.
 - `--strict` must still fail on legacy checker failures or unresolved historical contract gaps.
+- Archive old global tables and module indexes first, then regenerate them with `harness governance rebuild --archive --apply`; those tables are agent indexes, while humans should use the Dashboard for status.
 - `migrate-verify` must pass before the migration output is reported as usable, and the dashboard path must be HTML.
-- `new-task --preset legacy-migration --from-session` creates only the Complex Task scaffold and evidence bundle. It does not continue migration, rewrite history, stage files, or commit.
 - For detailed migration strategy, read `docs-release/guides/migration-playbook.md` or `docs-release/guides/migration-playbook.en-US.md`. If the user requires proof that the old project is fully migrated, also read `docs-release/guides/full-legacy-migration-subagent-strategy.md` or `docs-release/guides/full-legacy-migration-subagent-strategy.zh-CN.md`.
 
 The agent must read `session.json` and `migrate-plan.json`, then migrate active tasks, current reviews, and truly adopted capabilities step by step. Subagent review must prove dashboard brief coverage, strict check, and final session all pass.
@@ -166,37 +185,42 @@ The agent must read `session.json` and `migrate-plan.json`, then migrate active
 After initialization or migration, agents should not manually copy task folders. Use lifecycle commands:
 
 ```bash
-harness new-task phase-2-lifecycle \
+harness new-task \
   --title "Phase 2 task lifecycle" \
   --locale en-US \
   /path/to/project
 
-harness task-start phase-2-lifecycle \
+harness task-start <task-id-from-new-task-output> \
   --message "Start lifecycle slice implementation" \
   /path/to/project
 
-harness task-log phase-2-lifecycle \
+harness task-log <task-id-from-new-task-output> \
   --message "Completed CLI and template updates" \
   --evidence "command:TARGET:npm-test:passed" \
   /path/to/project
 
-harness review-confirm TASKS/phase-2-lifecycle \
+harness review-confirm <task-id-from-new-task-output> \
   --reviewer "Human Reviewer" \
-  --confirm phase-2-lifecycle \
+  --confirm <task-id-from-new-task-output> \
   /path/to/project
 
-harness task-complete phase-2-lifecycle \
+harness task-complete <task-id-from-new-task-output> \
   --message "Verification loop completed" \
   /path/to/project
 ```
 
 Rules:
 
-- `new-task` creates `brief.md`, `task_plan.md`, `execution_strategy.md`, `visual_map.md`, `findings.md`, `progress.md`, and `review.md`.
+- Do not manually copy task templates or create partial task folders. `harness check` enforces the file set created by `new-task`.
+- `new-task --title "..."` generates a default ID like `YYYY-MM-DD-phase-2-task-lifecycle-a1b2c3d4` to reduce collisions when multiple people or agents create tasks in the same repository. Pass an explicit `<task-id>` only when a coordinator needs a stable compatibility ID.
+- `new-task --budget simple` creates `brief.md`, `task_plan.md`, `visual_map.md`, and `progress.md`.
+- `new-task` defaults to `standard` and creates the simple files plus `execution_strategy.md`, `findings.md`, `lesson_candidates.md`, and `review.md`.
+- `new-task --budget complex` creates the standard files plus `references/INDEX.md` and `artifacts/INDEX.md`.
 - Existing task directories are not overwritten. Renaming or continuing old tasks is a coordinator decision.
 - `task-start`, `task-block`, and `task-complete` only update lifecycle status and logs in `progress.md`.
 - `task-log` only appends execution records. Evidence uses `type:PATH:summary`, for example `command:TARGET:npm-test:passed`.
-- `review-confirm` appends a human review confirmation to `review.md` and a log entry to `progress.md`. It must reject open P0/P1/P2 findings marked `Open: yes` or `Blocks Release: yes`.
+- `review-confirm` writes human review confirmation audit fields to the task `INDEX.md` through gated commits. It must reject open P0/P1/P2 findings marked `Open: yes` or `Blocks Release: yes`.
+- CLI-owned lifecycle and lesson commands auto-commit allowlisted writes in a clean Git root. Dirty state appears in `status` / dashboard warnings and blocks those mechanical commits. Agent-owned manual edits still need proactive commits; deferred commits must record the no-commit reason, owner, and next step.
 - `status --json` keeps old `task.state` for compatibility and adds `lifecycleState`, `reviewStatus`, `closeoutStatus`, and `stateConflicts`. `done` means implementation finished; it does not mean `closed`.
 - For human operation, start the local HTML workbench with `harness dev /path/to/project`. It binds to `127.0.0.1`, chooses a port automatically, opens the browser, and refreshes when docs change. In headless or CI contexts, use `harness dev --no-open /path/to/project`.
 - The lower-level compatible entry point remains `harness dashboard --workbench --out-dir /tmp/harness-workbench /path/to/project`. Static dashboard files remain read-only and must not host human confirmation actions.

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

@@ -29,6 +29,19 @@ English mirror: `docs-release/guides/agent-installation.en-US.md`
 `npx --yes coding-agent-harness status` / `migrate-plan` 完成扫描；等用户确认允许写入后
 再安装 Skill 或运行初始化/迁移写入命令。
 
+本仓库还发布嵌套的 `preset-creator` Skill，给需要制作可复用 Harness Preset 的 Agent
+使用。因为本仓库同时有根目录 `SKILL.md` 和嵌套 Skill，查看或安装它时要加
+`--full-depth`：
+
+```bash
+npx skills add FairladyZ625/coding-agent-harness --list --full-depth
+npx skills add FairladyZ625/coding-agent-harness --skill preset-creator --full-depth
+```
+
+`coding-agent-harness` 用于在目标项目中运行 Harness；`preset-creator` 只在 Agent
+需要为一类可重复任务设计 Preset 时使用，例如这些任务共享 Reference、Artifact、Evidence
+或 Complex Task 骨架叠加规则。
+
 使用 v1.0 六阶段流程：
 
 1. Diagnose：扫描项目结构、语言、现有文档、CI、协作方式、外部依赖和风险面。
@@ -124,6 +137,16 @@ harness install-user --agent codex --global
 harness doctor-user --agent codex
 ```
 
+`npm install -g coding-agent-harness`、`harness install-user` 和 `harness init`
+都会 seed 内置 Preset：
+
+- 用户级 Preset：`~/.coding-agent-harness/presets/<preset-id>/`
+- 项目级 Preset：`<target>/.coding-agent-harness/presets/<preset-id>/`
+
+Agent 初始化或接手任务前必须运行 `harness preset list --json [target]`，
+确认可用 Preset 后再选择 `--preset`。如需修复缺失的内置 Preset，运行
+`harness preset seed` 或 `harness preset seed --project <target>`。
+
 支持的 agent target：
 
 | Agent | 用户级目录 |
@@ -140,7 +163,7 @@ harness doctor-user --agent codex
 - 默认交互确认；非交互场景必须传 `--yes` 或先用 `--dry-run`。
 - 默认不覆盖已有文件，只补缺失文件。
 - 需要强制更新时显式传 `--force`。
-- `doctor-user` 会检查 `SKILL.md`、模板、references、CLI scripts 和本指南是否存在。
+- `doctor-user` 会检查 `SKILL.md`、模板、references、内置 Preset、CLI scripts、本指南，以及用户级 Preset seed 是否存在。
 
 ## 旧 Harness 迁移
 
@@ -156,11 +179,6 @@ harness migrate-run \
 
 harness migrate-verify \
   /tmp/cah-migration-project/session.json
-
-harness new-task \
-  --budget complex \
-  --preset legacy-migration \
-  --from-session /tmp/cah-migration-project/session.json
 ```
 
 规则：
@@ -172,8 +190,8 @@ harness new-task \
 - 已有项目事实只能 merge、append 或记录 residual；不能用泛化模板替换。
 - 历史合同缺口在普通模式下进入 `adoption-needed` warning。
 - `--strict` 必须仍然能因为旧 checker 失败或历史合同缺口而失败。
+- 旧全局表和模块索引先归档，再用 `harness governance rebuild --archive --apply` 重新生成；这些表是 Agent 索引，人看状态优先用 Dashboard。
 - `migrate-verify` 必须通过，才能报告迁移输出可用；dashboard 路径必须是 HTML。
-- `new-task --preset legacy-migration --from-session` 只创建 Complex Task 骨架和证据包；不会继续迁移、改写历史、stage 或 commit。
 - 详细迁移策略见 `docs-release/guides/migration-playbook.md` 或英文镜像
   `docs-release/guides/migration-playbook.en-US.md`。如果用户要求证明旧项目已经完整迁移，
   还必须读取 `docs-release/guides/full-legacy-migration-subagent-strategy.md` 或中文镜像
@@ -186,39 +204,48 @@ harness new-task \
 初始化或迁移完成后，agent 不应手工复制任务目录。使用生命周期命令创建和推进任务：
 
 ```bash
-harness new-task phase-2-lifecycle \
+harness new-task \
   --title "阶段二任务生命周期" \
   --locale zh-CN \
   /path/to/project
 
-harness task-start phase-2-lifecycle \
+harness task-start <new-task 输出的 task-id> \
   --message "开始实现生命周期切片" \
   /path/to/project
 
-harness task-log phase-2-lifecycle \
+harness task-log <new-task 输出的 task-id> \
   --message "完成 CLI 与模板更新" \
   --evidence "command:TARGET:npm-test:passed" \
   /path/to/project
 
-harness review-confirm TASKS/phase-2-lifecycle \
+harness review-confirm <new-task 输出的 task-id> \
   --reviewer "Human Reviewer" \
-  --confirm phase-2-lifecycle \
+  --confirm <new-task 输出的 task-id> \
   /path/to/project
 
-harness task-complete phase-2-lifecycle \
+harness task-complete <new-task 输出的 task-id> \
   --message "验证闭环完成" \
   /path/to/project
 ```
 
 规则：
 
-- `new-task` 创建 `brief.md`、`task_plan.md`、`execution_strategy.md`、
-  `visual_map.md`、`findings.md`、`progress.md` 和 `review.md`。
+- 不要手工复制任务模板，也不要创建不完整任务目录。`harness check` 会按
+  `new-task` 创建的预算文件集校验。
+- `new-task --title "..."` 默认生成类似 `YYYY-MM-DD-phase-2-task-lifecycle-a1b2c3d4`
+  的任务 ID，避免多人或多 agent 同仓协作时重名；只有需要固定兼容 ID 时才传显式 `<task-id>`。
+- `new-task --budget simple` 创建 `brief.md`、`task_plan.md`、`visual_map.md`
+  和 `progress.md`。
+- `new-task` 默认 `standard`，创建 simple 文件，并额外创建
+  `execution_strategy.md`、`findings.md`、`lesson_candidates.md` 和 `review.md`。
+- `new-task --budget complex` 创建 standard 文件，并额外创建
+  `references/INDEX.md` 和 `artifacts/INDEX.md`。
 - 已存在的任务目录不会被覆盖；需要改名或继续旧任务时，由 coordinator 决定。
 - `task-start`、`task-block`、`task-complete` 只更新 `progress.md` 的生命周期状态和日志。
 - `task-log` 只追加执行记录；证据使用 `type:PATH:summary`，例如
   `command:TARGET:npm-test:passed`。
-- `review-confirm` 会向 `review.md` 追加人工审查确认，并向 `progress.md` 追加日志；如果存在 `Open: yes` 或 `Blocks Release: yes` 的开放 P0/P1/P2 finding，必须拒绝确认。
+- `review-confirm` 会通过受控提交把人工确认审计字段写入任务 `INDEX.md`；如果存在 `Open: yes` 或 `Blocks Release: yes` 的开放 P0/P1/P2 finding，必须拒绝确认。
+- CLI-owned lifecycle 和 lesson 命令会在干净 Git root 中自动提交 allowlisted 写入；dirty 状态会出现在 `status` / dashboard 的警告里，并阻塞这些机械化提交。Agent 手工改动仍要主动提交，不能提交时记录 no-commit reason、owner 和下一步。
 - `status --json` 保留旧 `task.state` 用于兼容，并新增 `lifecycleState`、`reviewStatus`、`closeoutStatus` 和 `stateConflicts`。`done` 只表示实现完成，不等于 `closed`。
 - 人工操作入口使用本地 HTML workbench：`harness dev /path/to/project`。它会启动只绑定 `127.0.0.1` 的动态页面、自动选择端口、打开浏览器并随 docs 变更刷新。无 GUI 或 CI 场景使用 `harness dev --no-open /path/to/project`。
 - 底层兼容入口仍是 `harness dashboard --workbench --out-dir /tmp/harness-workbench /path/to/project`。静态 dashboard 文件仍然只读，不能承载人工确认动作。

package/docs-release/guides/contributing.md

@@ -0,0 +1,100 @@
+# Contributor Guide
+
+This guide is for external contributors working on the public Coding Agent Harness repository.
+
+## Working Model
+
+Coding Agent Harness is more than documentation. The public repository includes:
+
+- CLI implementation under `scripts/`
+- tests under `tests/`
+- installable templates under `templates/` and `templates-zh-CN/`
+- bundled presets under `presets/`
+- public documentation under `docs-release/`
+- examples under `examples/`
+- an optional GUI submodule under `harness-gui/`
+
+Keep pull requests focused on one change family when possible. Documentation, CLI behavior, target-project templates, presets, and GUI work have different verification paths.
+
+## Local Setup
+
+Use Node.js 18 or newer. CI runs Node.js 20.
+
+```bash
+npm install
+```
+
+If your change touches the GUI submodule:
+
+```bash
+cd harness-gui
+npm ci
+```
+
+## Required Checks
+
+Run the checks that match your change. For larger PRs or when you are unsure, run
+the full root suite.
+
+| Change type | Minimum local checks |
+| --- | --- |
+| Docs only | `git diff --check` |
+| CLI/runtime | `npm test`, `npm run check`, `git diff --check` |
+| Templates or examples | `npm test`, `node scripts/harness.mjs check --profile target-project examples/minimal-project`, `git diff --check` |
+| Dashboard | `npm test`, `npm run smoke:dashboard`, `git diff --check` |
+| Package surface | `npm test`, `npm run pack:dry-run`, `git diff --check` |
+| GUI submodule | `cd harness-gui && npm ci && npm run typecheck && npm test && npm run build` |
+
+Full root suite:
+
+```bash
+npm test
+npm run smoke:dashboard
+npm run check
+node scripts/harness.mjs check --profile target-project examples/minimal-project
+npm run pack:dry-run
+git diff --check
+```
+
+GUI submodule setup and checks:
+
+```bash
+cd harness-gui
+npm ci
+npm run typecheck
+npm test
+npm run build
+```
+
+If a check cannot be run locally, say why in the PR.
+
+## PR Requirements
+
+Use the repository PR template and fill in:
+
+- summary
+- what changed
+- version impact
+- verification evidence
+- review evidence
+- residual risk
+- related issue, task, or design reference when available
+
+For docs-only or CI-only changes, "no version change" is usually correct. Runtime, template, preset, or package-surface changes may need a version decision from a maintainer.
+
+## GUI Submodule Changes
+
+`harness-gui/` is a Git submodule. GUI changes should be committed in the GUI repository first, then the parent repository should update the submodule pointer. A parent PR that updates the pointer should link to the GUI PR and include the GUI verification output.
+
+## CI
+
+GitHub Actions runs the same broad gates contributors should run locally:
+
+- root package tests
+- source/package boundary check
+- minimal target project check
+- dashboard generation and smoke test
+- npm package dry run
+- GUI submodule typecheck, tests, and build
+
+Repository owners manage branch protection and required checks in GitHub. Contributors only need to keep their PRs focused, documented, and verified.

package/docs-release/guides/contributing.zh-CN.md

@@ -0,0 +1,99 @@
+# 贡献者指南
+
+这份指南面向参与公开 `coding-agent-harness` 仓库的外部贡献者。
+
+## 工作模型
+
+Coding Agent Harness 不只是文档仓库。公开仓库包含：
+
+- `scripts/` 下的 CLI 实现
+- `tests/` 下的测试
+- `templates/` 与 `templates-zh-CN/` 下的可安装模板
+- `presets/` 下的内置 preset
+- `docs-release/` 下的公开文档
+- `examples/` 下的示例项目
+- `harness-gui/` 下的可选 GUI 子模块
+
+PR 尽量聚焦在一类改动上。文档、CLI 行为、目标项目模板、preset 和 GUI 有不同的验证路径。
+
+## 本地准备
+
+使用 Node.js 18 或更高版本。CI 当前使用 Node.js 20。
+
+```bash
+npm install
+```
+
+如果改动涉及 GUI 子模块：
+
+```bash
+cd harness-gui
+npm ci
+```
+
+## 必要检查
+
+根据改动范围运行相关检查。较大的 PR 或不确定范围时，运行完整根仓检查。
+
+| 改动类型 | 最小本地检查 |
+| --- | --- |
+| 仅文档 | `git diff --check` |
+| CLI / runtime | `npm test`, `npm run check`, `git diff --check` |
+| 模板或示例 | `npm test`, `node scripts/harness.mjs check --profile target-project examples/minimal-project`, `git diff --check` |
+| Dashboard | `npm test`, `npm run smoke:dashboard`, `git diff --check` |
+| Package surface | `npm test`, `npm run pack:dry-run`, `git diff --check` |
+| GUI 子模块 | `cd harness-gui && npm ci && npm run typecheck && npm test && npm run build` |
+
+完整根仓检查：
+
+```bash
+npm test
+npm run smoke:dashboard
+npm run check
+node scripts/harness.mjs check --profile target-project examples/minimal-project
+npm run pack:dry-run
+git diff --check
+```
+
+GUI 子模块安装和检查：
+
+```bash
+cd harness-gui
+npm ci
+npm run typecheck
+npm test
+npm run build
+```
+
+如果某个检查无法在本地运行，请在 PR 中说明原因。
+
+## PR 要求
+
+使用仓库 PR 模板，并填写：
+
+- 摘要
+- 改动内容
+- 版本影响
+- 验证证据
+- 审查证据
+- 残余风险
+- 如有相关 issue、任务或设计材料，附上链接
+
+文档或 CI-only 改动通常可以写“不改版本”。运行时、模板、preset 或 package surface 改动可能需要维护者决定版本策略。
+
+## GUI 子模块改动
+
+`harness-gui/` 是 Git submodule。GUI 改动应先提交到 GUI 仓库，再由父仓更新 submodule pointer。更新 pointer 的父仓 PR 应链接 GUI PR，并附上 GUI 验证结果。
+
+## CI
+
+GitHub Actions 会运行贡献者本地也应覆盖的主要 gate：
+
+- 根包测试
+- source/package boundary 检查
+- minimal target project 检查
+- dashboard 生成与 smoke test
+- npm package dry run
+- GUI 子模块 typecheck、测试和 build
+
+GitHub branch protection 和 required checks 由仓库 owner 在 GitHub 上管理。贡献者只需要让 PR 聚焦、说明清楚并附上验证证据。

package/docs-release/guides/document-audience-and-surfaces.en-US.md

@@ -27,7 +27,7 @@ Release docs explain public methodology and product capability. They do not carr
 | `references/` | Agents and maintainers | Reusable standards such as testing, workflow, review, worktree rules | A project's current schedule |
 | `templates/` | CLI and agents | Files generated into target projects | Evidence from completed work |
 | Target `AGENTS.md` | Agents | Entrypoint, routing, hard rules, reading matrix | Long background essays |
-| Target `docs/09-PLANNING/` | Agents and project owners | Feature SSoT, task plans, current state | Generic marketing material |
+| Target `docs/09-PLANNING/` and `docs/Harness-Ledger.md` | Agents and project owners | Task plans, generated task lifecycle index, current state | Generic marketing material |
 | Target `docs/05-TEST-QA/` | Agents, QA, human reviewers | Regression SSoT, Cadence Ledger, quality gates | Requirement brainstorm drafts |
 | Target `docs/10-WALKTHROUGH/` | Reviewers and handoff agents | Closeout evidence, residuals, human confirmation | Unverified plans |
 
@@ -62,7 +62,8 @@ Agent-facing docs answer:
 Typical files:
 
 - `AGENTS.md`
-- `docs/09-PLANNING/Feature-SSoT.md`
+- `docs/Harness-Ledger.md`
+- `docs/09-PLANNING/TASKS/<task>/task_plan.md`
 - `docs/09-PLANNING/TASKS/<task>/task_plan.md`
 - `docs/09-PLANNING/TASKS/<task>/progress.md`
 - `docs/05-TEST-QA/Regression-SSoT.md`

package/docs-release/guides/document-audience-and-surfaces.md

@@ -27,7 +27,7 @@ Agent 读的文档定义事实、路径、门禁和下一步动作。
 | `references/` | Agent 和维护者 | 可复用标准，例如 testing、workflow、review、worktree | 某个项目的当前排期 |
 | `templates/` | CLI 和 Agent | 初始化目标项目时生成的文件 | 已经执行过的任务证据 |
 | 目标项目 `AGENTS.md` | Agent | 入口、路由、硬规则、读文件矩阵 | 大段背景叙事 |
-| 目标项目 `docs/09-PLANNING/` | Agent 和项目负责人 | Feature SSoT、任务计划、当前状态 | 通用营销材料 |
+| 目标项目 `docs/09-PLANNING/` 与 `docs/Harness-Ledger.md` | Agent 和项目负责人 | 任务计划、生成的任务生命周期索引、当前状态 | 通用营销材料 |
 | 目标项目 `docs/05-TEST-QA/` | Agent、QA、人审 | Regression SSoT、Cadence Ledger、质量门禁 | 需求讨论草稿 |
 | 目标项目 `docs/10-WALKTHROUGH/` | 人审、接手 Agent | 收口证据、残留项、人工确认 | 未验证的计划 |
 
@@ -62,7 +62,8 @@ Agent 读文档要回答：
 典型文件：
 
 - `AGENTS.md`
-- `docs/09-PLANNING/Feature-SSoT.md`
+- `docs/Harness-Ledger.md`
+- `docs/09-PLANNING/TASKS/<task>/task_plan.md`
 - `docs/09-PLANNING/TASKS/<task>/task_plan.md`
 - `docs/09-PLANNING/TASKS/<task>/progress.md`
 - `docs/05-TEST-QA/Regression-SSoT.md`

package/docs-release/guides/full-legacy-migration-subagent-strategy.md

@@ -120,7 +120,7 @@ Use small, bounded worker roles. These roles can run sequentially or in parallel
 | --- | --- | --- |
 | Task Contract Worker | `docs/09-PLANNING/TASKS/**/brief.md`, `execution_strategy.md`, `visual_map.md`, optional same-task `progress.md` log | Remove task contract failures; in a confirmed rewrite mode, rewrite weak old surfaces. |
 | Review/Capability Worker | `.harness-capabilities.json`, current strict review files | Declare real capabilities and normalize release-blocking review schema. |
-| Legacy Governance Worker | `AGENTS.md`, PR template or residual, `docs/11-REFERENCE/**`, Ledger, Closeout SSoT, Lessons SSoT, walkthrough template | Clear legacy checker failures. |
+| Legacy Governance Worker | `AGENTS.md`, PR template or residual, `docs/11-REFERENCE/**`, Ledger, Closeout SSoT, lesson candidates/detail docs, walkthrough template | Clear legacy checker failures. |
 | Brief Coverage Workers | disjoint task-date or module ranges, missing or explicitly weak `brief.md` files | Reach dashboard brief coverage 100 percent and remove empty templates. |
 | Quality Repair Worker | only files named by reviewer | Remove weak brief patterns and stale dashboard assumptions. |
 
@@ -235,7 +235,7 @@ Fix or route:
 - PR template exists or an explicit blocked-with-owner residual exists.
 - `Harness-Ledger.md` includes repo governance / CI-CD and Lessons Check columns.
 - `Closeout-SSoT.md` includes walkthrough, Lessons Check, and closeout status.
-- `Lessons-SSoT.md` includes ID, status, and detail doc columns.
+- Promoted lessons live in `docs/01-GOVERNANCE/lessons/*.md`; task-local candidates stay in `lesson_candidates.md`.
 - `_walkthrough-template.md` includes Lessons Reflection.
 
 Do not overwrite business facts. Merge missing columns or append a migration section when possible.

package/docs-release/guides/full-legacy-migration-subagent-strategy.zh-CN.md

@@ -120,7 +120,7 @@ harness migrate-verify /tmp/cah-migration-baseline/session.json
 | --- | --- | --- |
 | Task Contract Worker | `docs/09-PLANNING/TASKS/**/brief.md`、`execution_strategy.md`、`visual_map.md`、同任务 `progress.md` 可选追加 | 清掉 task contract failures；在已确认 rewrite 模式下重写薄弱旧表面。 |
 | Review/Capability Worker | `.harness-capabilities.json`、当前 strict review 文件 | 声明真实能力并规范 release-blocking review schema。 |
-| Legacy Governance Worker | `AGENTS.md`、PR template 或 residual、`docs/11-REFERENCE/**`、Ledger、Closeout SSoT、Lessons SSoT、walkthrough template | 清掉 legacy checker failures。 |
+| Legacy Governance Worker | `AGENTS.md`、PR template 或 residual、`docs/11-REFERENCE/**`、Ledger、Closeout SSoT、lesson candidates/detail docs、walkthrough template | 清掉 legacy checker failures。 |
 | Brief Coverage Workers | 按 task 日期段或模块拆分，写缺失或被点名薄弱的 `brief.md` | 达到 dashboard brief coverage 100%，并移除空模板。 |
 | Quality Repair Worker | 只写 reviewer 点名的文件 | 移除弱 brief、自动解析痕迹和 stale dashboard assumptions。 |
 
@@ -235,7 +235,7 @@ Task/review cleanup 后，strict cutover 仍可能因为旧 checker 要求 gover
 - PR template 存在，或有 explicit blocked-with-owner residual。
 - `Harness-Ledger.md` 包含 repo governance / CI-CD 和 Lessons Check 列。
 - `Closeout-SSoT.md` 包含 walkthrough、Lessons Check 和 closeout status。
-- `Lessons-SSoT.md` 包含 ID、status 和 detail doc 列。
+- Promoted lessons 位于 `docs/01-GOVERNANCE/lessons/*.md`；任务本地候选保留在 `lesson_candidates.md`。
 - `_walkthrough-template.md` 包含 Lessons Reflection。
 
 不要覆盖业务事实。尽量 merge 缺失列，或追加 migration section。

package/docs-release/guides/legacy-migration-agent-prompt.md

@@ -122,17 +122,6 @@ The command writes:
 - `status-strict.json`
 - `dashboard/index.html`
 
-After `migrate-verify` passes, create the migration task as a Complex Task preset:
-
-```bash
-harness new-task \
-  --budget complex \
-  --preset legacy-migration \
-  --from-session /tmp/cah-migration-project/session.json
-```
-
-This command only scaffolds the task and copies/references evidence. It does not run migration, rewrite history, stage files, or commit.
-
 Classify the output:
 
 | Output | Meaning | Action |

package/docs-release/guides/legacy-migration-agent-prompt.zh-CN.md

@@ -123,17 +123,6 @@ harness migrate-run \
 - `status-strict.json`
 - `dashboard/index.html`
 
-`migrate-verify` 通过后，把本次迁移变成 Complex Task preset：
-
-```bash
-harness new-task \
-  --budget complex \
-  --preset legacy-migration \
-  --from-session /tmp/cah-migration-project/session.json
-```
-
-这条命令只创建任务骨架并复制/引用证据，不会继续运行迁移、改写历史、stage 或 commit。
-
 输出分类：
 
 | Output | 含义 | 动作 |

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

@@ -94,17 +94,6 @@ harness migrate-verify /tmp/cah-migration-project/session.json
 
 If later cleanup repairs warnings or active task contracts, the first session is only the baseline. Before final delivery, rerun `migrate-run` for a fresh session/dashboard or explicitly label the differences between baseline session and final evidence.
 
-4. Create the Complex Task preset from the session:
-
-```bash
-harness new-task \
-  --budget complex \
-  --preset legacy-migration \
-  --from-session /tmp/cah-migration-project/session.json
-```
-
-This only creates the task scaffold and `evidence/<timestamp>/` bundle. It does not run more migration, rewrite historical tasks, stage files, or commit. The generated task records `Task Kind`, `Task Preset`, `Preset Version`, `Migration Target Level`, `Migration Achieved Level`, and `Evidence Bundle`; later agents should continue migration inside that Complex Task instead of inventing a second workflow.
-
 `migrate-verify` passing does not mean the full migration is complete. Full migration also requires:
 
 - `migrate-plan` is `declared-capability`.
@@ -115,7 +104,7 @@ This only creates the task scaffold and `evidence/<timestamp>/` bundle. It does
 - The task index opens and shows all tasks.
 - At least one adversarial subagent review round passes.
 
-5. Continue cleanup from the plan:
+4. Continue cleanup from the plan:
 
 - `MP-01`: confirm compatibility layer and locale; verify historical docs were not overwritten.
 - `MP-02`: choose capabilities; only declare capabilities that project facts support.
@@ -124,14 +113,14 @@ This only creates the task scaffold and `evidence/<timestamp>/` bundle. It does
 - `MP-05`: upgrade current release/architecture/security/data reviews; do not rewrite every historical review.
 - `MP-06`: only use strict as a gate after normal warnings have owner/action/status.
 
-6. Normal migration verification:
+5. Normal migration verification:
 
 ```bash
 harness check --profile target-project /path/to/project
 harness dashboard --out-dir /tmp/harness-dashboard /path/to/project
 ```
 
-7. Strict cutover verification:
+6. Strict cutover verification:
 
 ```bash
 harness check --profile target-project --strict /path/to/project
@@ -171,6 +160,16 @@ In baseline mode, only `current-active` tasks or tasks still referenced by SSoT
 
 In status-aware rewrite mode, an existing `brief.md`, `execution_strategy.md`, or `visual_map.md` is not automatically preserved. If evidence shows it is an old template, parser residue, wrong language, or too weak for a human to judge current state, rewrite it. Historical tasks may become readable index cards or residuals, but that decision must be evidence-backed.
 
+Global table and module index migration is not manual refilling. Current Harness versions generate task lifecycle summaries into `Harness-Ledger.md` only; legacy `Feature-SSoT.md` and `Private-Feature-SSoT.md` files are archived during cutover and are not regenerated. Module `module_plan.md` Steps tables and module `visual_map.md` topology tables are still generated from module task files. Humans should inspect current state through the Dashboard; agents can use `task-list` / `task-index` queries for fast lookup. Before cutting over an older project, archive the legacy lifecycle tables and rebuild current indexes from task files:
+
+```bash
+harness governance rebuild --dry-run --archive /path/to/project
+harness governance rebuild --archive --apply /path/to/project
+harness task-list --json --search "keyword" /path/to/project
+```
+
+The archive directory preserves old lifecycle table snapshots. After the Dashboard, `task-list` / `task-index`, and generated Ledger all reflect current tasks, the project owner may decide whether to delete the old archive. Migration agents should not delete historical table evidence directly. Delivery, Regression, Cadence, Closeout, and Module Registry governance tables are not deleted by this step unless a later version provides equivalent scanner and generator support.
+
 In full semantic rewrite mode, every task needs a standalone `brief.md`, but the brief must not be an empty template. A historical task brief is a readable index card: task goal, first human read, evidence sources, status judgment, and residuals. `visual_map.md` is a diagram collection, not a roadmap template; include phase flow, sequence, architecture, data-flow, state, topology, or decision maps only when they improve understanding. Do not generate empty diagrams to satisfy a checker.
 
 If the legacy project is a microservice, multi-repo, split frontend/backend, or externally integrated project, the migration plan must also ask the user whether external source material exists. Do not migrate dozens of external-team documents directly into `03/04/06`. First use `external-source-intake-standard.md` to create `docs/04-DEVELOPMENT/external-source-packs/<source-key>/`, complete the source index and digests, then project stable facts into service profiles, external contexts, and integration contracts.
@@ -282,7 +281,7 @@ Full migration should not let one agent edit everything from start to finish. Us
 | --- | --- | --- |
 | Task Contract Worker | `docs/09-PLANNING/TASKS/**/brief.md`, `execution_strategy.md`, `visual_map.md`, same-task `progress.md` append | Clear task contract gaps; in a confirmed rewrite mode, rewrite weak old surfaces. |
 | Review/Capability Worker | `.harness-capabilities.json`, current strict review files | Declare real capabilities and repair release-blocking review schema. |
-| Legacy Governance Worker | `AGENTS.md`, PR template, `docs/11-REFERENCE/**`, Ledger, Closeout SSoT, Lessons SSoT, walkthrough template | Clear legacy checker aggregate failures. |
+| Legacy Governance Worker | `AGENTS.md`, PR template, `docs/11-REFERENCE/**`, Ledger, Closeout SSoT, lesson candidates/detail docs, walkthrough template | Clear legacy checker aggregate failures. |
 | Brief Coverage Workers | date or module slices, missing or explicitly weak `brief.md` files | Bring dashboard brief coverage to 100 percent and remove empty templates. |
 | Quality Repair Worker | only files named by reviewers | Remove parser residue, empty templates, language mismatch, and weak evidence. |