ai-delivery-workflow 0.5.0 → 0.5.1

package/README.md

@@ -17,8 +17,7 @@
 - [Microcks Mock System 使用指南](docs/MOCK-SYSTEM.zh-CN.md)
 - [双仓工作区使用与维护说明](docs/DUAL-REPOSITORY-WORKSPACE.zh-CN.md)
 - [逐文件参考](docs/FILE-REFERENCE.zh-CN.md)
-- [工作流管理器使用指南](docs/VIEWER-USER-GUIDE.zh-CN.md)
-- [工作流管理器维护指南](docs/VIEWER-MAINTENANCE.zh-CN.md)
+- [Workflow Manager Agent Interface](docs/agents/workflow-manager-agent-interface.md)
 - [正式状态 CLI 使用指南](docs/STATE-CLI-USER-GUIDE.zh-CN.md)
 - [正式状态 CLI 维护指南](docs/STATE-CLI-MAINTENANCE.zh-CN.md)
 - [npm 版本与发布管理规范](docs/NPM-RELEASE-MANAGEMENT.zh-CN.md)
@@ -81,7 +80,7 @@ node .workflow/tools/state/state.mjs verify
 
 禁止直接编辑正式状态 YAML、审计 JSONL 或 runtime 任务状态。命令失败时应处理 revision 冲突或输入问题，不得手工绕过。
 
-累计研发版本、当前生产版本和当前生产 release ID 的权威来源是 `.workflow/delivery/workflow-state.yaml` 中经审计事件写入的 `latest_line_version_id`、`production_version_id` 和 `production_release_id`。版本收尾使用 `version-closed`，发布归档使用 `release-archived`；`project.yaml` 中的同名旧字段只作兼容回退。
+累计研发版本、当前生产版本和当前生产 release ID 的权威来源是 `.workflow/delivery/workflow-state.yaml` 中经审计事件写入的 `latest_line_version_id`、`production_version_id` 和 `production_release_id`。版本收尾使用 `version-closed`，发布归档使用 `release-archived`；`project.yaml` 仅保存描述性配置。
 
 正式工作流管理入口是工作流管理器。它通过同一个应用服务向 CLI、HTTP 和 React 界面投影正式状态，节点状态只来自 `state inspect.derived_node_states`：
 
@@ -93,7 +92,7 @@ npx ai-delivery-workflow@latest manager list . --resource contracts
 
 macOS/Linux 使用 `sh ./.workflow/tools/manager/start.sh`。也可运行 `npx ai-delivery-workflow@latest manager serve . --no-open`；服务只绑定 loopback。P01-P19 共 19 个固定 Page 均连接真实项目投影，P13 作为上下文详情页从原型审批或路由页面进入。未登记事实明确显示“尚未登记”，不会填充演示数据。AI 先从 `contracts` 资源和 `manager action <action-name> --help` 发现当前 Schema；安装后完整流程位于 `.workflow/tools/manager/AGENT-INTERFACE.md`。原型评论/截图/审核、项目系统脚本/生命周期、Mock 同步、Gate 决定、关系确认和设置修改只通过白名单动作执行，并校验 actor、revision/checksum、幂等键及所需的 plan checksum。
 
-旧 `.workflow/tools/viewer/` 和独立 Prototype Review Server 已退役。新安装不再包含它们；旧项目升级时，Viewer 由带备份和 checksum 的 `remove` 操作登记，受保护回滚可以恢复升级前字节。
+Workflow Manager 是唯一项目级控制面；新安装只包含当前 Manager、状态和 Bootstrap 运行时。
 
 研发完成不会自动上线。用户需要发布时明确选择截止版本：
 
@@ -122,9 +121,9 @@ npx ai-delivery-workflow@latest upgrade . --dry-run
 npx ai-delivery-workflow@latest upgrade .
 ```
 
-`init` 只允许首次安装；已有 `.workflow/config/install-manifest.json` 时必须使用 `upgrade`。升级 dry-run 输出 additions、replacements、preserved、preserved_summary、conflicts、backups 和 compatibility，且严格零写。`preserved` 中受管安装资产之外的明细最多报告 200 条，完整的总数、已报告数、省略数和排除的瞬态根见 `preserved_summary`；省略仅限制报告体积，不会删除文件。正式升级只替换安装清单声明的受管副本，保留业务物料、用户配置部分和嵌套代码仓库，并把收据和备份写入 `.workflow/delivery/runtime/upgrades/<upgrade-id>/`。在升级后尚未新增正式事务时，可执行 `upgrade . --rollback <upgrade-id>`；否则必须前向修复。初始化或升级完成后请新建 Codex 任务，使项目级 skills 和 Hook 信任状态重新加载。
+`init` 只允许首次安装；已有 `.workflow/config/install-manifest.json` 时必须使用 `upgrade`。升级 dry-run 输出 additions、replacements、preserved、preserved_summary、conflicts 和 backups，且严格零写。`preserved` 中受管安装资产之外的明细最多报告 200 条，完整的总数、已报告数、省略数和排除的瞬态根见 `preserved_summary`；省略仅限制报告体积，不会删除文件。正式升级只替换安装清单声明的受管副本，保留业务物料、用户配置部分和嵌套代码仓库，并把收据和备份写入 `.workflow/delivery/runtime/upgrades/<upgrade-id>/`。在升级后尚未新增正式事务时，可执行 `upgrade . --rollback <upgrade-id>`；否则必须前向修复。初始化或升级完成后请新建 Codex 任务，使项目级 skills 和 Hook 信任状态重新加载。
 
-旧项目如仍使用根目录 `delivery/` 和 `standards/`，需先迁移为 `.workflow/delivery/` 和 `.workflow/standards/`，同步更新产物引用与 checksum 后再执行 `init`。安装器不会在新旧两套状态之间自动选择权威来源。
+安装器只接受 `.workflow/` 布局；检测到根目录 `delivery/`、`standards/` 或 `.ai-delivery/` 时会确定性拒绝并报告冲突，不会在两套状态之间选择权威来源。
 
 ## 仓库内容边界
 

package/bin/ai-delivery.mjs

@@ -10,7 +10,7 @@ import { executeDeliveryStateCommand } from "../lib/delivery-state.mjs";
 import { dispatchEvolutionHookEvent, executeEvolutionCommand } from "../lib/evolution.mjs";
 import { doctorProject, initProject, upgradeProject } from "../lib/project-installer.mjs";
 import { bootstrapProject, inspectProjectState } from "../lib/project-bootstrap.mjs";
-import { migrateProject, repairProject } from "../lib/project-migration.mjs";
+import { repairProject } from "../lib/project-repair.mjs";
 import { validateVisualStandard } from "../lib/visual-standard.mjs";
 import { validatePrototypeRevision } from "../lib/prototype-revision.mjs";
 import { runFrontendGuardCommand } from "../lib/frontend-guard.mjs";
@@ -27,10 +27,7 @@ Usage:
   ai-delivery init [workspace-directory] [--workspace-id id] [--code-path code] [--code-id app] [--code-remote <url>] [--workflow-remote <url>] [--shared-remote <url>] [--dry-run] [--force]
   ai-delivery upgrade [workspace-directory] [--dry-run] [--force]
   ai-delivery upgrade [workspace-directory] --rollback <upgrade-id>
-  ai-delivery migrate [workspace-directory] [--decisions <file>] [--dry-run]
-  ai-delivery migrate [workspace-directory] --rollback <migration-id>
   ai-delivery repair [workspace-directory] --invalidate-archive <iteration-id> --reason <text> --actor human:<identity> --evidence <ref> --evidence <ref> [--dry-run]
-  ai-delivery compact [workspace-directory] [--dry-run]
   ai-delivery inspect [workspace-directory]
   ai-delivery bootstrap [workspace-directory] [--dry-run] [--force]
   ai-delivery doctor [workspace-directory]
@@ -53,9 +50,7 @@ Usage:
 Commands:
   init     Create a workflow repository and bind or create one nested code repository
   upgrade  Preview, apply, or roll back project-scoped managed installation assets
-  migrate  Preview or apply structural compatibility migration without business-state repair
   repair   Append an explicit forward correction without rewriting historical evidence
-  compact  Archive anchored legacy history and remove loose snapshots only after verified replay
   inspect  Detect workspace, code repository, workflow, and runtime state without writes
   bootstrap  Initialize missing workflow context or route recovery safely
   doctor   Validate the current project-scoped installation
@@ -72,7 +67,7 @@ Commands:
 Options:
   --dry-run  Show planned changes without writing files
   --force    Back up and replace conflicting managed files
-  --rollback  Restore one upgrade or migration before any later formal transaction
+  --rollback  Restore one upgrade before any later formal transaction
   --decisions  Apply checksum-bound human task-grouping decisions from a YAML or JSON file
   --code-path  Nested code repository directory (default: code)
   --code-id    Stable code repository identifier (default: app)
@@ -189,13 +184,6 @@ try {
       } else if (command === "inspect") {
         const report = inspectProjectState(target);
         process.stdout.write(`${JSON.stringify(report, null, 2)}\n`);
-      } else if (command === "migrate") {
-        const report = migrateProject(target, {
-          dryRun: flags.has("--dry-run"),
-          rollback: options.get("--rollback") || null,
-          decisions: options.get("--decisions") || null,
-        });
-        process.stdout.write(`${JSON.stringify(report, null, 2)}\n`);
       } else if (command === "repair") {
         const report = repairProject(target, {
           dryRun: flags.has("--dry-run"),
@@ -205,16 +193,6 @@ try {
           evidence: options.get("--evidence") || [],
         });
         process.stdout.write(`${JSON.stringify(report, null, 2)}\n`);
-      } else if (command === "compact") {
-        const stateArgs = ["artifact", "compact", "--project", target];
-        if (!flags.has("--dry-run")) stateArgs.push("--apply");
-        const report = executeDeliveryStateCommand(stateArgs, {
-          yaml: {
-            parse: parseYaml,
-            stringify: (value) => stringifyYaml(value, { lineWidth: 0 }),
-          },
-        });
-        process.stdout.write(`${JSON.stringify(report, null, 2)}\n`);
       } else if (command === "bootstrap") {
         const report = bootstrapProject(packageRoot, target, {
           dryRun: flags.has("--dry-run"),

package/docs/CLI-PARAMETER-REFERENCE.zh-CN.md

@@ -10,11 +10,8 @@ ai-delivery init [workspace-directory] [--workspace-id id] [--code-path code] [-
                  [--dry-run] [--force]
 ai-delivery upgrade [workspace-directory] [--dry-run] [--force]
 ai-delivery upgrade [workspace-directory] --rollback <upgrade-id>
-ai-delivery migrate [workspace-directory] [--decisions <file>] [--dry-run]
-ai-delivery migrate [workspace-directory] --rollback <migration-id>
 ai-delivery repair [workspace-directory] --invalidate-archive <iteration-id> --reason <text>
                    --actor human:<identity> --evidence <rca-ref> --evidence <recovery-ref> [--dry-run]
-ai-delivery compact [workspace-directory] [--dry-run]
 ai-delivery inspect [workspace-directory]
 ai-delivery bootstrap [workspace-directory] [--dry-run] [--force]
 ai-delivery doctor [workspace-directory]
@@ -58,9 +55,7 @@ npx ai-delivery-workflow@0.4.0 doctor .
 | --- | --- | --- |
 | `init` | 仅首次安装 25 个项目级 Skill、Hook、自包含 CLI、Workflow Manager 和工作流目录，并初始化或绑定两套独立 Git。已有安装清单时拒绝执行。 | 是 |
 | `upgrade` | 预览、应用或回滚安装清单声明的受管副本；不初始化 Git，不写业务物料、用户配置部分或嵌套代码仓库。 | 视参数而定 |
-| `migrate` | 预览、登记或回滚兼容结构及旧 Prototype member/set 迁移；报告 schema、任务分组、Prototype 合并、冲突、锚点和文件变化，不推断业务状态。 | 视参数而定 |
 | `repair` | 追加独立的前向归档失效事务；原归档证据保持逐字节不变。 | 视参数而定 |
-| `compact` | 把可信 anchor 覆盖的 legacy registry 全量快照打包为 checksummed gzip archive；精确 replay 验证通过后才移除 loose shards。 | 视参数而定 |
 | `inspect` | 只读识别工作区、两套 Git、安装完整性、正式状态和任务恢复建议。 | 否 |
 | `bootstrap` | 根据只读检查决定初始化缺失工作流、恢复 Agent 责任任务或停在用户/外部输入边界。 | 视路由而定 |
 | `doctor` | 校验受管文件 checksum、Skill、Hook、CLI、Workflow Manager、必需目录和持久项目配置；排除本地 runtime。 | 否 |
@@ -94,7 +89,7 @@ npx ai-delivery-workflow@0.4.0 doctor .
 
 ### 3.1 `workspace-directory`
 
-- 适用命令：`init`、`upgrade`、`migrate`、`repair`、`compact`、`inspect`、`bootstrap`、`doctor`、`codegraph setup`、`codegraph sync`、`mock setup`、`mock start`、`mock stop`、`mock status`、`mock sync`、`mock freeze`、`visual-standard validate`、`prototype-revision validate`、`frontend-guard check-file`、`frontend-guard verify-diff`、`ui-acceptance plan`、`ui-acceptance verify`、`manager inspect/list/show/export/action/serve`。
+- 适用命令：`init`、`upgrade`、`repair`、`inspect`、`bootstrap`、`doctor`、`codegraph setup`、`codegraph sync`、`mock setup`、`mock start`、`mock stop`、`mock status`、`mock sync`、`mock freeze`、`visual-standard validate`、`prototype-revision validate`、`frontend-guard check-file`、`frontend-guard verify-diff`、`ui-acceptance plan`、`ui-acceptance verify`、`manager inspect/list/show/export/action/serve`。
 - 含义：目标业务项目根目录，也是外层工作流 Git 根目录。
 - 默认值：当前工作目录。
 - 可以使用相对路径或绝对路径；CLI 会转换为绝对路径。
@@ -167,23 +162,14 @@ npx ai-delivery-workflow@0.4.0 doctor .
 - `--shared-remote` 不能与 `--code-remote` 或 `--workflow-remote` 同时使用；
 - 共用远程不等于共用 Git 根，外层和内层仍必须各自拥有独立 `.git`。
 
-### 4.5 `--decisions`
-
-- 仅适用于 `migrate`；
-- 指向 YAML 或 JSON 人工任务分组与 Prototype 合并决定文件；
-- 文件必须包含 `schema_version: 1`、dry-run 返回的 `anchors.proposed.source_checksum`、`human:<identity>` actor，以及 `decisions` 和 `prototype_decisions` 两个列表；没有对应歧义时保留空列表；
-- 每项决定使用 `keep-separate`，或使用带 `canonical_source_task_id` 的 `group`；两者都必须逐项绑定 dry-run 返回的 `source_task_ids` 并提供 rationale；
-- 每项 Prototype 决定使用 `choose-member`，逐项绑定 `conflict_id`、该冲突列出的 `member_id` 并提供 rationale；
-- 源 checksum、候选任务或决定格式变化时 fail-closed，必须重新 dry-run 和审阅。
-
 ## 5. 布尔选项
 
 ### 5.1 `--dry-run`
 
-- 适用命令：`init`、`upgrade`、`migrate`、`repair`、`compact`、`bootstrap`、`codegraph setup`、`codegraph sync`；
+- 适用命令：`init`、`upgrade`、`repair`、`bootstrap`、`codegraph setup`、`codegraph sync`；
 - 只返回计划动作，不写文件、不创建 Git 仓库、不修改远程；
-- `upgrade --dry-run` 返回结构化 JSON，包括 additions、replacements、preserved、preserved_summary、conflicts、backups、compatibility、`contract_retirement` 中受 pending `UX-LF` 影响的开放迭代，以及只报告、不应用的 `prototype_migration` follow-up；`preserved` 中受管安装资产之外的明细最多为 200 条，完整计数和排除的 `.workflow/delivery/runtime` 瞬态根见 `preserved_summary`，省略明细不改变保留行为；
-- `migrate --dry-run` 返回 schemas、task_grouping、`prototype_migration`、conflicts、anchors、file_changes 和 `can_apply`；Prototype 报告精确区分零、单、多旧成员，并按 terminal、Page、route、file 给出合并结果；`repair --dry-run` 返回目标归档 checksum 与计划事务路径；`compact --dry-run` 返回 anchor、legacy revision 覆盖范围、原历史根摘要、loose/archive 字节数和预计净释放空间；
+- `upgrade --dry-run` 返回结构化 JSON，包括 additions、replacements、preserved、preserved_summary、conflicts 和 backups；`preserved` 中受管安装资产之外的明细最多为 200 条，完整计数和排除的 `.workflow/delivery/runtime` 瞬态根见 `preserved_summary`，省略明细不改变保留行为；
+- `repair --dry-run` 返回目标归档 checksum 与计划事务路径；
 - 用于安装、升级、迁移和冲突处理前审阅；
 - `inspect` 和 `doctor` 本身只读，不需要该参数。
 
@@ -203,61 +189,14 @@ npx ai-delivery-workflow@0.4.0 doctor .
 - 公开 `init` 只用于首次安装；已有安装清单时返回非零退出码并指向 `upgrade`。
 - `upgrade --dry-run` 严格零写，不创建收据目录，也不初始化或修改任一 Git 仓库。
 - `upgrade --dry-run` 不遍历 `.workflow/delivery/runtime` 瞬态根；受管安装资产之外的文件只在 `preserved` 中报告前 200 条，并由 `preserved_summary` 汇总完整数量。
-- `upgrade` 只安装迁移能力、处理旧 Gate 契约退休并报告 Prototype follow-up；不会写入 `.workflow/experience/<iteration-id>/` 的迁移目标。
-- 普通升级只替换清单拥有的 Skill、Hook、状态/Bootstrap/Evolution/Manager 运行时和受管配置贡献；保留产品、架构、体验、迭代、发布、规范、正式状态、用户配置部分和代码仓库。旧安装的 Viewer 作为带备份和 checksum 的 `remove` 操作进入升级 Receipt，受保护回滚可恢复原字节。
-- `upgrade` 会以 `ensure-directory` 新增项恢复旧安装缺失的 `.workflow/control/migrations/` 和 `.workflow/control/repairs/`；目录已存在但缺 `.gitkeep` 时，以 `ensure-directory-marker` 新增项只恢复 marker。已存在目录及其中用户物料不归安装器所有。
+- `upgrade` 只替换当前安装契约声明的 Skill、Hook、状态/Bootstrap/Evolution/Manager 运行时和受管配置贡献；保留产品、架构、体验、迭代、发布、规范、正式状态、用户配置部分和代码仓库。
 - 受管副本相对安装清单发生本地漂移时列为 conflict；只有明确批准后才使用 `--force`。
 - 应用成功后返回 `upgrade_id`，备份和 `receipt.json` 位于 `.workflow/delivery/runtime/upgrades/<upgrade-id>/`。
 - `upgrade --rollback <upgrade-id>` 会恢复升级前受管副本和安装清单。升级后只要新增了 schema 2 正式事务或受管副本再次漂移，回滚就 fail-closed，并要求前向修复。
 
 ## 7. 常用组合
 
-### 7.1 兼容迁移与前向修复
-
-先完成受管资产升级，再预览结构迁移：
-
-```powershell
-npx ai-delivery-workflow@latest migrate . --dry-run
-npx ai-delivery-workflow@latest migrate .
-```
-
-`migrate` 只在 `can_apply: true` 时应用。旧根布局的 `delivery/`、`control/`、`standards/` 被复制到 `.workflow/`，源文件保持逐字节不变；平铺任务在目标布局或原位任务 shard 中增加显式 `attempts`，替换前字节备份到 `.workflow/control/migrations/<migration-id>/backups/`。任务后缀只作为候选族提示；goal、scope、依赖、输出、验收或代码身份不一致时保留为人工歧义。
-
-存在歧义时，根据 dry-run 的 `task_grouping.decision_template` 创建决定文件并重新预览：
-
-```yaml
-schema_version: 1
-source_checksum: <dry-run anchors.proposed.source_checksum>
-actor: human:delivery-owner
-decisions:
-  - family: TASK-WP02
-    action: keep-separate
-    source_task_ids: [TASK-WP02-F1, TASK-WP02-F2, TASK-WP02-R1]
-    rationale: review 使用不同验收证据，不属于同一重试契约
-prototype_decisions:
-  - conflict_id: PROTO-CONFLICT-0123456789ABCDEF
-    action: choose-member
-    member_id: PROTO-WEB
-    rationale: 该成员是此稳定身份的已确认权威来源
-```
-
-```powershell
-npx ai-delivery-workflow@latest migrate . --decisions .\migration-decisions.yaml --dry-run
-npx ai-delivery-workflow@latest migrate . --decisions .\migration-decisions.yaml
-```
-
-Prototype 迁移中，合法零成员返回 `not-required`；单成员只在身份和所有 checksum 无歧义时自动迁移；多成员按 terminal、Page、route、file 合并，相同稳定身份的不同定义会阻塞并要求 `prototype_decisions`。旧 member/set、关闭或归档证据、Gate 和旧事件保持原字节；新内容只写入 `.workflow/experience/<iteration-id>/`，且开放迭代必须冻结新 revision 并重新通过 `UX-UI`。迁移生成的 `current_revision_ref: null` 不能直接交给 `prototype-review` 审批。完整说明见 [Prototype 迁移指南](PROTOTYPE-MIGRATION.zh-CN.md)。
-
-迁移不激活或关闭任务、不推断节点/版本完成、不修改 scope，也不重写旧事件。迁移后没有新增 schema 2 事务且迁移生成/替换的字节未漂移时，可用 `migrate . --rollback <migration-id>` 删除复制目标并恢复任务备份；出现新事务或字节漂移后只能前向修复。
-
-结构迁移和业务修复完成后，legacy 全量快照历史仍保持原位。只有维护者明确要求时才先预览压缩：
-
-```powershell
-npx ai-delivery-workflow@latest compact . --dry-run
-npx ai-delivery-workflow@latest compact .
-```
-
-apply 会把 anchor 覆盖的 legacy `artifact-registry` shards 原字节编码进 `.workflow/control/archives/history/artifact-registry/<anchor-id>.json.gz`，并写同名 checksum manifest。命令从 archive 重新解压并完整 replay，只有最终 registry checksum 与可信 anchor 完全一致后才移除 loose shards；任一 schema、entry、bundle、anchor 或 replay 校验失败都保持 loose history 不变。之后 `verify --history` 返回 `compacted-history` 并验证压缩包与锚点，新事务从锚点记录链头继续。
+### 7.1 前向归档修复
 
 错误归档使用独立命令：
 

package/docs/DUAL-REPOSITORY-WORKSPACE.zh-CN.md

@@ -44,7 +44,7 @@ node bin/ai-delivery.mjs init C:\work\tasklite --workspace-id tasklite --code-pa
 
 工作流仓库使用 `workflow/tasklite`，代码仓库使用 `main` 及各研发、发布分支；两者虽然 origin 相同，但 Git 根和提交历史职责独立。
 
-升级仍含 `.ai-delivery/` 的旧项目时，安装器会先把旧目录完整备份到 `.workflow/delivery/runtime/backups/<timestamp>/legacy-ai-delivery/`，再迁移配置、状态 CLI、Hook 和 Workflow Manager；旧 Viewer 随迁移备份后移除。只有新核心文件验证完成后才删除旧目录；失败时保留旧目录和备份。迁移成功后 `.workflow/config/workspace.yaml` 是唯一权威配置，不再双写或回退读取旧路径。
+安装器只接受当前 `.workflow/` 双仓布局。发现 `.ai-delivery/` 或其他旧布局时，`doctor`/`upgrade --dry-run` 只读报告冲突并停止；修复后再按当前契约安装。`.workflow/config/workspace.yaml` 是代码仓库位置和 `repo_id` 的唯一来源。
 
 如果 `code/` 已是独立 Git 仓库，初始化器会绑定它。以下情况会拒绝：非空但不是 Git 的代码目录、绝对路径或多层路径、越界路径、符号链接、与工作流仓库相同的 Git 根。
 

package/docs/FILE-REFERENCE.zh-CN.md

@@ -3,13 +3,11 @@
 > 当前双仓目录、初始化规则、状态分层和 Git 边界见 [DUAL-REPOSITORY-WORKSPACE.zh-CN.md](DUAL-REPOSITORY-WORKSPACE.zh-CN.md)。
 
 > 适用目录：工作流发行仓库  
-> 适用包版本：`ai-delivery-workflow@0.4.0`
+> 适用包版本：`ai-delivery-workflow@0.5.1`
 > 使用方法和完整流程：[PROJECT-MANUAL.zh-CN.md](PROJECT-MANUAL.zh-CN.md)  
 > CLI 安装参数：[CLI-PARAMETER-REFERENCE.zh-CN.md](CLI-PARAMETER-REFERENCE.zh-CN.md)
 > CodeGraph 可选集成：[CODEGRAPH-INTEGRATION.zh-CN.md](CODEGRAPH-INTEGRATION.zh-CN.md)
-> Workflow Manager 使用：[VIEWER-USER-GUIDE.zh-CN.md](VIEWER-USER-GUIDE.zh-CN.md)
->
-> Workflow Manager 维护：[VIEWER-MAINTENANCE.zh-CN.md](VIEWER-MAINTENANCE.zh-CN.md)
+> Workflow Manager Agent Interface：[agents/workflow-manager-agent-interface.md](agents/workflow-manager-agent-interface.md)
 > 正式状态使用：[STATE-CLI-USER-GUIDE.zh-CN.md](STATE-CLI-USER-GUIDE.zh-CN.md)  
 > 正式状态维护：[STATE-CLI-MAINTENANCE.zh-CN.md](STATE-CLI-MAINTENANCE.zh-CN.md)  
 > npm 版本与发布：[NPM-RELEASE-MANAGEMENT.zh-CN.md](NPM-RELEASE-MANAGEMENT.zh-CN.md)
@@ -75,13 +73,12 @@
 
 | 文件 | 作用 |
 | --- | --- |
-| `lib/project-installer.mjs` | 实现项目级安装和诊断。复制 25 个 Skills、Workflow Manager 及自包含 Bootstrap/状态/Evolution/Mock CLI，创建研发、发布和自进化目录；升级旧安装时以 Receipt-backed `remove` 备份并移除 Viewer。 |
+| `lib/project-installer.mjs` | 实现项目级安装和诊断。复制 25 个 Skills、Workflow Manager 及自包含 Bootstrap/状态/Evolution/Mock CLI，创建研发、发布和自进化目录。 |
 | `lib/artifact-files.mjs` | Prototype revision、Manager 审核与 frontend guard 共用的 YAML mapping、SHA-256 和目录包含边界；统一拒绝绝对路径、`..` 和符号链接越界。 |
 | `lib/codegraph.mjs` | CodeGraph 可选适配器；从权威工作区配置解析代码仓，提供只读 doctor 检查和显式 setup/sync，不安装全局 CLI 或 MCP。 |
 | `lib/mock-system.mjs` | Microcks 项目适配器；固定镜像版本与 digest，管理并在健康失败时清理 loopback 易失容器，隔离 `external-dependencies.yaml` 与 `product-backends.yaml`，校验 OpenAPI/AsyncAPI operation、channel、具名 scenario 与 dispatcher 输入，并通过 multipart 本地 API 同步合同。 |
 | `lib/mock-scenario-pack.mjs` | Mock Scenario Pack 冻结器；绑定 Prototype revision、全部 Review Scene 唯一映射、受管 UI 实际导出物及其协议/场景 inventory、合同和脱敏证据 checksum，执行人工 candidate checksum 确认并拒绝覆盖不可变 Pack。 |
-| `lib/project-migration.mjs` | 兼容迁移编排器；统一规划旧布局、任务 attempt 与 Prototype member/set 迁移，校验 checksum 绑定人工决定，写 schema 3 清单并提供受保护回滚。 |
-| `lib/prototype-migration.mjs` | 旧 Prototype 迁移器；精确区分零/单/多 member，按 terminal、Page、route、file 合并，保留旧字节，并在无冲突时生成唯一 `PROTOTYPE` 的待 `UX-UI` 目标。 |
+| `lib/project-repair.mjs` | 归档完整性前向修复器；校验人工 actor、原因和证据，追加 checksum 链式失效事务并保留原归档字节。 |
 | `lib/project-bootstrap.mjs` | 只读扫描仓库并分类五种项目状态；识别代码、技术、Git、正式工作流和 runtime；为新接入项目生成草稿基线、文件清单、上下文索引、接入评估和引导计划；中断项目直接路由 checkpoint。 |
 | `lib/yaml-runtime.mjs` | 为发行包和安装后的项目内 Bootstrap 运行时解析 YAML；优先使用包依赖，项目内回退到状态 CLI 的 vendored YAML。 |
 | `lib/delivery-state.mjs` | 正式状态公共命令实现；管理物料、节点、Gate、候选、发布和可信历史锚点，提供 revision、锁、原子写、checksum、例行/增量/全历史校验。 |
@@ -105,12 +102,9 @@
 | --- | --- |
 | `docs/PROJECT-MANUAL.zh-CN.md` | 完整中文项目手册：定位、安装、状态识别、全流程、Gate、原型、TDD、Git、发布、checkpoint、规范、审计、维护和故障排查。 |
 | `docs/CLI-PARAMETER-REFERENCE.zh-CN.md` | CLI 安装参数参考：命令、位置参数、默认值、校验、远程组合、重复初始化和强制替换边界。 |
-| `docs/PROTOTYPE-MIGRATION.zh-CN.md` | 旧 member/set 到唯一 Prototype 的升级/迁移顺序、报告字段、零/单/多成员规则、决定文件、字节保留和在 Manager 重新完成 `UX-UI` 的边界。 |
 | `docs/CODEGRAPH-INTEGRATION.zh-CN.md` | CodeGraph 可选集成指南：适配器边界、doctor、setup/sync、telemetry、降级链、缓存和跨环境风险。 |
 | `docs/MOCK-SYSTEM.zh-CN.md` | Microcks Mock System 指南：镜像身份、生命周期、External/Product Backend 边界、catalog、runtime、安全与验证。 |
 | `docs/FILE-REFERENCE.zh-CN.md` | 本文件，说明发行仓库全部有效文件及同构路径。 |
-| `docs/VIEWER-USER-GUIDE.zh-CN.md` | Workflow Manager 用户手册；保留旧文件名以维持已有链接。 |
-| `docs/VIEWER-MAINTENANCE.zh-CN.md` | Workflow Manager 维护手册；说明权威源码、应用服务、安全边界和完整验收。 |
 | `docs/agents/workflow-manager-agent-interface.md` | Workflow Manager Agent Interface；规定契约发现、受控写入、并发、幂等、plan/apply、Receipt/Event、Outbox 和恢复流程。 |
 | `docs/STATE-CLI-USER-GUIDE.zh-CN.md` | 正式状态 CLI 用户手册：命令、revision、Gate、失败恢复和生产使用规则。 |
 | `docs/STATE-CLI-MAINTENANCE.zh-CN.md` | 正式状态 CLI 维护手册：实现边界、自包含安装、验证契约、测试和完成定义。 |
@@ -123,8 +117,8 @@
 
 | 文件 | 覆盖内容 |
 | --- | --- |
-| `verification/project-installer.test.mjs` | 项目级安装、Bootstrap 自包含入口、包版本升级、保留既有物料、Viewer Receipt-backed 移除/回滚、dry-run、冲突备份、Hook、路径边界和 CLI init/doctor。 |
-| `verification/workflow-manager.test.mjs` | Manager CLI/HTTP/UI/安装入口一致性、19 Page 浏览器验收、桌面布局和 Viewer/Review Server 发行收敛。 |
+| `verification/project-installer.test.mjs` | 项目级安装、Bootstrap 自包含入口、包版本升级、保留既有物料、dry-run、冲突备份、Hook、路径边界和 CLI init/doctor。 |
+| `verification/workflow-manager.test.mjs` | Manager CLI/HTTP/UI/安装入口一致性、19 Page 浏览器验收和桌面布局。 |
 | `verification/workflow-manager-facts.test.mjs` | 需求、任意相关工作项、任务、测试、交付成果和事件事实投影。 |
 | `verification/workflow-manager-governance.test.mjs` | Gate 评论、AI 关系建议/人工决定和设置安全白名单。 |
 | `verification/workflow-manager-prototypes.test.mjs` | Page/Scene 投影、评论、截图、多轮编辑、审核、执行锁和废弃规则。 |
@@ -290,17 +284,10 @@
 | `assets/experience-template/prototype-trigger-conditions.csv` | Review Scene 触发条件的唯一规范化目录。 |
 | `assets/experience-template/prototype-routes.csv` | 原型路由与真实生产 Page 路由的唯一目录。 |
 | `assets/experience-template/ui-mapping.csv` | Page/Review Scene、原型路由、生产路由、前端源码和验收 ID 的双向映射。 |
-| `assets/experience-template/prototype-set.yaml` | 旧多成员原型集的历史只读兼容输入；当前流程不生成。 |
-| `assets/experience-template/prototype-manifest.yaml` | 旧原型成员 manifest 的历史只读兼容输入；当前流程不生成。 |
 | `assets/experience-template/prototype-tool-candidates.csv` | 可用原型工具候选及适配分析。 |
 | `assets/experience-template/prototype-tool-selection.yaml` | 项目唯一 Prototype 的人工工具选择凭据。 |
-| `assets/experience-template/page-catalog.csv` | 旧成员 Page 目录的历史只读兼容输入；当前流程使用 `prototype-pages.csv`。 |
 | `assets/experience-template/screen-states.csv` | 页面状态、触发、行为、恢复和无障碍要求。 |
 | `assets/experience-template/feature-screen-coverage.csv` | 功能、终端、流程、页面和状态覆盖。 |
-| `assets/experience-template/canvas-catalog.csv` | 旧成员画布目录的历史只读兼容输入。 |
-| `assets/experience-template/canvas-pages.csv` | 旧画布与 Page 关系的历史只读兼容输入。 |
-| `assets/experience-template/prototype-files.csv` | 旧成员源文件目录的历史只读兼容输入。 |
-| `assets/experience-template/prototype-file-terminals.csv` | 旧成员文件/终端关系的历史只读兼容输入。 |
 | `assets/experience-template/prototype-traceability.csv` | 产品、终端、页面、状态、元素与源修订追踪。 |
 | `assets/experience-template/prototype-review-decision.yaml` | 视觉或交互原型必须执行分阶段人工评审的决定记录。 |
 | `assets/experience-template/prototype-review-sessions.csv` | 人工评审轮次和批准状态。 |
@@ -539,18 +526,9 @@
 | `.workflow/delivery/runtime/heartbeats/*.json` | 最近 Hook 活动心跳。 |
 | `.workflow/delivery/runtime/resumes/*.md` | 任务恢复摘要。 |
 | `.workflow/control/archives/versions/<version-id>/` | Git 可携带的权威版本任务归档；归档后活动 task/checkpoint 分片从普通恢复范围移除。 |
-| `.workflow/control/migrations/<migration-id>/migration-manifest.json` | schema 3 兼容迁移清单；记录人工/自动任务分组、Prototype 迁移报告、冲突、已验证锚点、源/目标 checksum、真实复制/替换动作和零业务状态推断声明。 |
-| `.workflow/control/migrations/<migration-id>/backups/` | 当前布局平铺任务显式化 attempts 前的逐字节备份；只供受保护迁移回滚使用。 |
-| `.workflow/experience/<iteration-id>/prototype.yaml` | Prototype 迁移生成的唯一当前描述；初始状态 `migration-pending-ux-ui`，在完整新 revision 冻结前 `current_revision_ref` 为 `null`。 |
-| `.workflow/experience/<iteration-id>/prototype-migration.yaml` | 旧 set/member、terminal/Page/route/file 合并、人工决定、保留历史和新 `UX-UI` 政策的不可变迁移记录。 |
-| `.workflow/experience/<iteration-id>/prototype/source/<member-id>/` | 从每个校验通过的旧 member source 逐字节复制的隔离迁移输入；旧 source 本身不修改。 |
-| `.workflow/experience/<iteration-id>/prototype/review-shell/index.html` | 迁移时生成的旧成员导航占位 Shell；不是完整冻结 revision，不能据此批准 `UX-UI`。 |
 | `.workflow/control/repairs/transactions/<sequence>-<repair-id>.json` | 独立前向修复事务链；归档失效记录引用原归档 checksum、人工 actor、原因、RCA 与恢复 evidence，原归档字节不变。 |
 | `.workflow/control/snapshots/formal-state/<anchor-id>/` | 正式状态可信锚点；保存两个当前视图的原字节副本、stream revision、视图与记录链 checksum、JSONL 边界和自校验锚点。 |
-| `.workflow/control/archives/history/artifact-registry/<anchor-id>.json.gz` | `ai-delivery compact` 生成的 legacy full-snapshot 压缩包；内含原 shard 字节、逐项 SHA-256、原历史根摘要、revision 覆盖范围和锚定 registry checksum。 |
-| `.workflow/control/archives/history/artifact-registry/<anchor-id>.yaml` | 压缩包 manifest；绑定 archive checksum、可信 anchor、覆盖范围、原/压缩字节数和自校验 checksum。 |
 | `.workflow/control/retention/artifact-registry/<anchor-id>.yaml` | 显式 `artifact prune --apply` 的不可变保留 receipt；绑定可信 anchor、裁剪 revision、删除数量和聚合 checksum。 |
-| `.workflow/delivery/runtime/archive/` | 可丢弃的本地详细归档副本和索引，不作为跨 clone 的权威来源。 |
 | `.workflow/product/` | 可跨迭代复用的产品基线。 |
 | `.workflow/architecture/` | 可跨迭代复用的架构基线。 |
 | `.workflow/experience/` | 可跨迭代复用的体验基线和原型管理基线。 |

package/docs/MAINTENANCE-VERIFICATION.zh-CN.md

@@ -5,8 +5,8 @@
 ## 1. npm 发布预检
 
 ```powershell
-npm run release:check -- prepare --version 0.4.0
-npm run release:check -- verify --version 0.4.0 --commit <40位提交ID>
+npm run release:check -- prepare --version 0.5.1
+npm run release:check -- verify --version 0.5.1 --commit <40位提交ID>
 ```
 
 `prepare` 默认执行 `full` 检查：清单与锁文件版本、`main`、干净工作树、Tag 可用性、全量测试、25 个 Skill、审计验证、`npm pack --dry-run`、`npm publish --dry-run`、官方 registry、版本未占用、npm 身份和 `auth-and-writes` 2FA。两个 dry-run 还必须返回一致的包名、版本、文件清单、文件数量和制品摘要；本包必须包含 `bin/`、`docs/`、`lib/`、`skills/` 及有效的 `bin.ai-delivery`。任一项失败都会输出 `decision: fail` 并返回非零退出码。

package/docs/PROJECT-MANUAL.zh-CN.md

@@ -1,10 +1,10 @@
 # AI Delivery Workflow 完整项目手册
 
-当前研发生产模型是 `development-seven-node`：`00-bootstrap -> 01-product-shaping -> 02-solution-design -> 03-delivery-readiness -> 04-implementation -> 05-candidate-assurance -> 06-version-closeout`。旧 13 节点仅用于历史 inspect、verify 和显式迁移；新项目和现行生产 Skill 不再生成旧节点 ID。
+当前研发生产模型是 `development-seven-node`：`00-bootstrap -> 01-product-shaping -> 02-solution-design -> 03-delivery-readiness -> 04-implementation -> 05-candidate-assurance -> 06-version-closeout`。新项目和现行生产 Skill 只生成这些节点 ID。
 
 > 仓库身份：当前源码仓库是工作流维护与发行项目，不是下文所述的业务工作区。不要对当前源码仓库套用双仓初始化、业务项目 bootstrap 或 `.workflow/` 状态恢复；下文双仓契约描述的是安装目标。
 >
-> 当前工作区契约：本手册现行运行形态只支持“工作流控制仓库 + 一个直接子目录代码仓库”，也不使用 Git submodule。`migrate` 只转换旧工作流物料布局，不负责把单仓代码历史拆成双仓；双仓建立或绑定规则见 [DUAL-REPOSITORY-WORKSPACE.zh-CN.md](DUAL-REPOSITORY-WORKSPACE.zh-CN.md)。
+> 当前工作区契约：本手册现行运行形态只支持“工作流控制仓库 + 一个直接子目录代码仓库”，也不使用 Git submodule。双仓建立或绑定规则见 [DUAL-REPOSITORY-WORKSPACE.zh-CN.md](DUAL-REPOSITORY-WORKSPACE.zh-CN.md)。
 
 ```text
 workspace/.git                 工作流 Git
@@ -18,7 +18,7 @@ workspace/code/.git            代码 Git
 初始化器还会合并根 `.gitattributes`，对 `.workflow/**`、项目级 `ai-delivery-*` Skills、`.codex/config.toml`、`AGENTS.md`、`.gitignore` 和 `.gitattributes` 强制 `eol=lf`。这是 checksum 可移植性约束；不会修改嵌套代码仓的换行策略。已冻结的旧迭代证据必须在根 `.gitattributes` 中使用精确路径，或“固定迭代目录 + 文件名 glob”的窄 `-text` 规则登记后，才能保留 raw checksum；嵌套或全局 attributes 不能自行获得该例外。产品、控制、工具等其他路径和 `text eol=crlf` 覆盖也不享受该例外。缺失或无效规则会使 `doctor` 失败，避免 Windows checkout 后正式状态和物料被误判为篡改。
 
 > 文档版本：1.0  
-> 适用包版本：`ai-delivery-workflow@0.4.0`
+> 适用包版本：`ai-delivery-workflow@0.5.1`
 > 默认文档语言：简体中文  
 > 文件级索引：[FILE-REFERENCE.zh-CN.md](FILE-REFERENCE.zh-CN.md)  
 > CodeGraph 可选集成：[CODEGRAPH-INTEGRATION.zh-CN.md](CODEGRAPH-INTEGRATION.zh-CN.md)
@@ -130,7 +130,7 @@ AI Delivery Workflow 是一套安装在单个代码仓库内的 AI 研发流程
       manager/                     # 正式工作流管理器 runtime 与静态界面
     mock-system/                   # 隔离的 external/product-backend catalog 与合同定义
     delivery/
-      project.yaml                # 项目描述与旧字段兼容回退
+      project.yaml                # 项目描述与当前配置
       workflow-state.yaml         # 正式流程、Gate、累计研发和生产身份
       artifact-registry.yaml      # 正式物料注册表
       state-events.jsonl          # 正式状态审计事件
@@ -152,7 +152,7 @@ AI Delivery Workflow 是一套安装在单个代码仓库内的 AI 研发流程
   .gitattributes                  # 固定工作流受控文本为 LF
 ```
 
-安装器为上述可能为空但必须跨 clone 保留的内容目录，以及 `.workflow/control/` 下的任务、Checkpoint、物料、Gate、版本、发布、事件、迁移和修复分片目录创建 `.gitkeep`。这些占位文件属于结构契约；重新克隆后无需再次执行 `init` 即可通过 `doctor`。`upgrade` 会把旧安装缺失的 `migrations/` 和 `repairs/` 作为 `ensure-directory` 新增项恢复；目录已存在但缺少 `.gitkeep` 时，只以独立 `ensure-directory-marker` 新增项恢复 marker。已存在目录及其中用户物料不属于安装器所有，也不会被替换。
+安装器为上述可能为空但必须跨 clone 保留的内容目录，以及 `.workflow/control/` 下的任务、Checkpoint、物料、Gate、版本、发布、事件和修复分片目录创建 `.gitkeep`。这些占位文件属于结构契约；重新克隆后无需再次执行 `init` 即可通过 `doctor`。已存在目录及其中用户物料不属于安装器所有，也不会被替换。
 
 ## 5. 安装、升级与诊断
 
@@ -183,7 +183,7 @@ npx ai-delivery-workflow@latest doctor .
 npx ai-delivery-workflow@latest manager inspect .
 ```
 
-Windows 使用 `.\.workflow\tools\manager\start.cmd` 或 `start.ps1` 启动；macOS/Linux 使用 `sh ./.workflow/tools/manager/start.sh`。等价的发行包入口是 `ai-delivery manager serve .`。服务只绑定 `127.0.0.1`；可用 `--port` 固定端口，`--no-open` 禁止自动打开浏览器。19 个 Page 使用正式项目事实，未登记能力明确显示“尚未登记”。旧 `.workflow/tools/viewer/` 和独立 Prototype Review Server 不再安装；旧项目升级时 Viewer 通过带备份的 Receipt 操作移除。
+Windows 使用 `.\.workflow\tools\manager\start.cmd` 或 `start.ps1` 启动；macOS/Linux 使用 `sh ./.workflow/tools/manager/start.sh`。等价的发行包入口是 `ai-delivery manager serve .`。服务只绑定 `127.0.0.1`；可用 `--port` 固定端口，`--no-open` 禁止自动打开浏览器。19 个 Page 使用正式项目事实，未登记能力明确显示“尚未登记”。
 
 ### 5.3 从本地源码安装到另一个项目
 
@@ -216,7 +216,7 @@ npx ai-delivery-workflow@latest init . --dry-run
 npx ai-delivery-workflow@latest upgrade . --dry-run
 ```
 
-审阅结构化报告中的 additions、replacements、preserved、preserved_summary、conflicts、backups 和 compatibility 后执行：
+审阅结构化报告中的 additions、replacements、preserved、preserved_summary、conflicts 和 backups 后执行：
 
 ```bash
 npx ai-delivery-workflow@latest upgrade .
@@ -228,7 +228,7 @@ npx ai-delivery-workflow@latest upgrade .
 
 安装器不会把降级当作升级。目标包版本早于已安装版本时默认拒绝；只有用户明确批准降级并审阅备份影响后，才可使用 `--force`。
 
-旧项目兼容迁移属于独立 `migrate` 流程。`upgrade` 只安装迁移能力并在 `prototype_migration.required_follow_up` 报告后续命令，不写 Prototype 迁移目标；真正迁移只在审阅 `migrate --dry-run` 后执行。结构迁移不推断业务完成度，不激活或关闭任务，不改变 scope，也不重写旧事件。错误归档由独立 `repair` 前向事务失效，原归档字节不变。旧 `.workflow/tools/viewer/` 不再是可选安装能力；升级会将其备份并移除，受保护回滚可恢复升级前字节。
+升级只处理当前 `.workflow` 安装契约。发现旧布局、旧 schema 或受管文件漂移时，`upgrade --dry-run` 报告冲突并保持只读；明确的归档完整性问题使用 `repair --invalidate-archive` 前向修复，原证据字节保持不变。
 
 ### 5.5 升级
 
@@ -240,19 +240,11 @@ npx ai-delivery-workflow@latest upgrade .
 4. 处理规范冲突。
 5. 执行新版 `upgrade`；仅在受管副本漂移且明确采用发行基线时使用 `--force`。
 6. 执行 `doctor`。
-7. 对旧 schema、旧任务模型或旧 Prototype member/set 执行 `migrate --dry-run`，审阅 schema、任务分组、零/单/多成员计划、terminal/Page/route/file 合并报告、歧义、冲突、anchor 和文件变化。
-8. 只有报告 `can_apply: true` 时执行 `migrate`；任务与 Prototype 冲突使用同一 checksum 绑定决定文件，业务状态冲突先形成独立 repair 决定。
-9. 新建 Codex 任务，对 AI 说“继续”；AI 自主调用 Bootstrap 和后续 Skill。
+7. 新建 Codex 任务，对 AI 说“继续”；AI 自主调用 Bootstrap 和后续 Skill。
 
 升级完成但尚未产生新的 schema 2 正式事务时，可以执行 `upgrade . --rollback <upgrade-id>` 恢复升级前受管副本和安装清单。新增正式事务或升级后再次修改受管副本会关闭回滚窗口，此时必须前向修复。
 
-#### 兼容结构迁移与业务修复
-
-`migrate --dry-run` 是旧 schema、旧全量快照事件、旧任务模型和旧 Prototype member/set 的审阅入口。报告包含源/目标 schema、按语义契约精确匹配的逻辑任务组、需要人工确认的候选族、正式状态/归档冲突、经 pointer、anchor、snapshot 和 revision 校验的可信历史 anchor、`prototype_migration` 零/单/多成员计划，以及精确文件变化。`F/R/T/P/vN` 后缀只提示候选关系；goal、scope、依赖、输出、acceptance 或代码身份不同就不能据此自动合并。显式 `derived_from`/`supersedes` 作为关系边记录，不作为必须相等的普通字段。
-
-旧根布局迁移会把 `delivery/`、`control/`、`standards/` 复制到 `.workflow/`，根目录源证据保持原字节；当前布局中的平铺任务会原位增加显式 `attempts`，原字节备份到 `.workflow/control/migrations/<migration-id>/backups/`。manifest 记录每个源、目标和备份的 SHA-256。新增 attempts 只投影既有 lifecycle 事实，不激活或关闭任务，不改变顶层 status、scope、正式 view 或旧事件。
-
-任务族或 Prototype 合并仍有歧义时，使用一份决定文件：`decisions` 来自 `task_grouping.decision_template`，`prototype_decisions` 来自 `prototype_migration.decision_template`。填写 `human:<identity>` actor、逐项 rationale 和 dry-run 返回的稳定身份，再用 `migrate . --decisions <file> --dry-run` 复核。决定文件绑定 `anchors.proposed.source_checksum`；源文件或候选集合变化后必须重新决定。单 Prototype 迁移只在 member 身份、manifest/source/catalog checksum 和目标路径都无歧义时自动应用；多成员按 terminal、Page、route、file 生成合并报告。旧 member/set、关闭或归档 Prototype、Gate 与旧事件保持原字节，新文件只写入 `.workflow/experience/<iteration-id>/`，状态为 `migration-pending-ux-ui`，开放迭代必须冻结新 revision 并重新通过 `UX-UI`。完整字段和操作见 [Prototype 迁移指南](PROTOTYPE-MIGRATION.zh-CN.md)。迁移后尚无新 schema 2 事务且迁移目标字节未漂移时，可以执行 `migrate . --rollback <migration-id>` 删除复制目标并恢复任务备份；一旦产生新事务或目标漂移，回滚 fail-closed，只允许前向修复。
+#### 归档完整性修复
 
 错误版本归档不得直接编辑或删除。使用 `repair --invalidate-archive`，提供 `human:<identity>` actor、原因、RCA evidence 和恢复 evidence。dry-run 返回原归档 tree checksum 与计划事务路径；应用后在 `.workflow/control/repairs/transactions/` 追加带前序 checksum 的事务，并把当前资格投影为 `invalidated`，原 `.workflow/control/archives/versions/<iteration-id>/` 保持逐字节不变。
 
@@ -266,12 +258,7 @@ npx ai-delivery-workflow@latest upgrade .
 | `ai-delivery upgrade [project] --dry-run` | 否 | 结构化预览受管资产升级，严格零写。 |
 | `ai-delivery upgrade [project] [--force]` | 是 | 备份并升级安装清单拥有的受管资产。 |
 | `ai-delivery upgrade [project] --rollback <upgrade-id>` | 是 | 在没有后续正式事务或受管漂移时恢复升级前版本。 |
-| `ai-delivery migrate [project] --dry-run` | 否 | 报告 schema、任务分组/歧义、冲突、anchor 和精确文件变化。 |
-| `ai-delivery migrate [project] [--decisions <file>]` | 是 | 在无未决冲突/歧义时复制旧布局、显式化 task attempts 并写迁移清单；不改变业务状态。 |
-| `ai-delivery migrate [project] --rollback <migration-id>` | 是 | 在没有迁移后 schema 2 事务或目标漂移时删除复制目标并恢复任务备份。 |
 | `ai-delivery repair [project] --invalidate-archive <iteration-id> ... [--dry-run]` | 视参数而定 | 预览或追加错误归档的独立前向失效事务；保留原证据字节。 |
-| `ai-delivery compact [project] --dry-run` | 否 | 零写入验证 legacy history、可信 anchor、压缩包计划与预计净释放空间。 |
-| `ai-delivery compact [project]` | 是 | 写入 checksummed gzip archive；从包内完整 replay 到锚定 registry checksum 后才移除 loose shards。 |
 | `ai-delivery inspect [project]` | 否 | 输出机器可读的项目、代码、流程和运行时状态。 |
 | `ai-delivery bootstrap [project]` | 视状态而定 | 初始化空项目或存量项目上下文，或把中断项目路由到恢复。 |
 | `ai-delivery bootstrap [project] --dry-run` | 否 | 预览引导动作。 |
@@ -305,7 +292,7 @@ Mock System 使用固定版本与 digest 的 Microcks Uber 镜像，External Dep
 
 Workflow Manager 是唯一项目内控制面。P01-P19 汇总七节点状态、需求、任务、测试、交付成果、人工决策、业务项目原型、项目系统、Mock、事件和设置；P13 是从原型审批或路由页面进入的上下文详情页。UI、HTTP 和 `manager list/show/export/action` CLI 使用同一应用服务。
 
-界面不是任意文件编辑器或命令执行器。原型评论/截图/审核、系统初始化脚本/生命周期、Mock 同步、Gate 决定、需求关系和设置修改只能调用发行白名单动作，按能力验证 actor、expected revision/checksum、幂等键和 plan checksum，并生成 Receipt/Event。完整用法见[工作流管理器使用指南](VIEWER-USER-GUIDE.zh-CN.md)；修改前阅读[工作流管理器维护指南](VIEWER-MAINTENANCE.zh-CN.md)，AI 操作遵循 [Workflow Manager Agent Interface](agents/workflow-manager-agent-interface.md)。
+界面不是任意文件编辑器或命令执行器。原型评论/截图/审核、系统初始化脚本/生命周期、Mock 同步、Gate 决定、需求关系和设置修改只能调用发行白名单动作，按能力验证 actor、expected revision/checksum、幂等键和 plan checksum，并生成 Receipt/Event。AI 操作遵循 [Workflow Manager Agent Interface](agents/workflow-manager-agent-interface.md)。
 
 ### 5.8 项目原型审核
 
@@ -444,9 +431,8 @@ flowchart LR
 
 正式前端始终执行“Prototype 修改 -> 用户 Page 审核 -> 冻结 revision/scope -> 正式代码修改”。每个 UI 文件首次写入前运行 `ai-delivery frontend-guard check-file`；合并和正式验证从固定 base/head 运行 `ai-delivery frontend-guard verify-diff`，由独立 Git diff 复核，不能用 Hook 成功代替。
 
-AI 必须根据当前项目、终端、交互复杂度、协作需求和可用工具推荐。旧 `prototype-set.yaml` / member manifest 仅允许作为历史只读输入，不得由新流程创建或修改。
+AI 必须根据当前项目、终端、交互复杂度、协作需求和可用工具推荐。新流程统一使用 `prototype-revision-catalog.v2`，由 Workflow Manager 读取和审核。
 
-旧 member/set 迁移不会直接产生可审核 revision。迁移生成的 `prototype.yaml` 使用 `migration-pending-ux-ui` 且 `current_revision_ref: null`；先整理完整 Prototype、冻结并校验新的 revision，再在 Workflow Manager 的 P12/P13 完成新 `UX-UI`。管理器不会根据迁移记录推断批准。
 
 ### 9.2 页面编号
 
@@ -466,15 +452,14 @@ P01-02-页面名称2
 - 页面显示名称可以调整，但稳定 ID 不复用；
 - 功能、终端、页面、状态、画布、文件和具体元素使用显式关系表追踪。
 
-### 9.3 画布和文件
+### 9.3 页面、路由和映射
 
-- 同一主页面及其派生子页面可以放在同一画布族；
-- 无关主页面应拆为独立画布或原型文件；
-- `canvas-catalog.csv` 管理画布；
-- `canvas-pages.csv` 管理画布与页面关系；
-- `prototype-files.csv` 管理原型源文件；
-- `prototype-file-terminals.csv` 管理文件与终端关系；
-- 不允许用“全部页面放在一个无限画布”替代管理。
+- `prototype-pages.csv` 管理稳定 Page 身份；
+- `prototype-review-scenes.csv` 管理可审核状态；
+- `prototype-trigger-conditions.csv` 管理场景触发条件；
+- `prototype-routes.csv` 管理原型与生产路由；
+- `ui-mapping.csv` 绑定页面、路由、前端源码和验收 ID；
+- 不允许用未登记的画布、文件或路由替代规范化关系。
 
 ### 9.4 生产兼容原型与确认
 
@@ -630,17 +615,17 @@ node .workflow/tools/state/state.mjs inspect
 node .workflow/tools/state/state.mjs verify
 ```
 
-每次 artifact mutation 必须使用 `inspect` 返回的 `artifact_registry.revision` 作为 `--expected-revision`；节点、迭代、候选、发布和 Gate mutation 使用 owning `development_state.revision` 或 `release_state.revision` 作为 `--expected-scope-revision`。`draft/review-draft` 是 registry 外的可变 working file；提交、拒绝、批准、冻结、失败等语义决定才通过 `artifact register` 创建不可变 revision，后续决定使用新 ID 和 `--supersedes`。`artifact status` 只兼容迁移升级前已登记的 draft。节点、迭代、候选和发布通过 `transition` 管理，Gate 通过 `gate request/decide` 管理。Gate 决定必须包含明确 `actor`、`rationale` 和已登记 evidence。
+每次 artifact mutation 必须使用 `inspect` 返回的 `artifact_registry.revision` 作为 `--expected-revision`；节点、迭代、候选、发布和 Gate mutation 使用 owning `development_state.revision` 或 `release_state.revision` 作为 `--expected-scope-revision`。`draft/review-draft` 是 registry 外的可变 working file；提交、拒绝、批准、冻结、失败等语义决定才通过 `artifact register` 创建不可变 revision，后续决定使用新 ID 和 `--supersedes`。节点、迭代、候选和发布通过 `transition` 管理，Gate 通过 `gate request/decide` 管理。Gate 决定必须包含明确 `actor`、`rationale` 和已登记 evidence。
 
 `workflow-state.yaml` schema 2 包含独立的 `development_state` 与 `release_state`。研发由 `iteration-started` 建立，发布仅在用户明确请求后由 `release-started` 建立；两个状态域分别维护 scope ID、局部 revision、节点、Gate、节点尝试和选定物料，因此发布期间仍可继续下一累计版本研发。独立 scope 可在等待同一提交区后分别成功，同一 scope 的过期 writer 必须冲突停止。顶层 revision 只负责审计流串行化，任何一个状态域都不得重置另一个。
 
 状态 CLI 根据流程图元数据校验前置依赖，不采用简单的相邻编号规则。`03-delivery-readiness` 内的平台准备可与计划和测试设计并行；Product Shaping 和 Solution Design 可因原型校正带原因重开；后续迭代可用已登记且 identity/checksum 精确匹配的成功冻结基线满足未受影响的前置条件。节点完成证据必须处于允许的成功状态，并完成当前节点尝试的强制 Gate。生产审批 Gate ID 固定为 `PRODUCTION-APPROVAL`，不能标记为 `not-required`。
 
-Delivery Readiness 通过 `scope freeze` 将 Slice、需求、验收、任务和物料冻结为带 revision/checksum 的 manifest，并启用 `scope_contract_version: 1`。冻结后，只有明确人工批准的 `scope amend` 可以通过 `--supersedes` 创建下一 revision；`scope warn` 只写入 `warn-only` 和 `reslice_performed: false`，预算超限不会自动重新切片、重排计划或改变验收。旧 scope 没有 `scope_contract_version` 时保持旧契约兼容，不自动迁移。
+Delivery Readiness 通过 `scope freeze` 将 Slice、需求、验收、任务和物料冻结为带 revision/checksum 的 manifest，并启用 `scope_contract_version: 1`。冻结后，只有明确人工批准的 `scope amend` 可以通过 `--supersedes` 创建下一 revision；`scope warn` 只写入 `warn-only` 和 `reslice_performed: false`，预算超限不会自动重新切片、重排计划或改变验收。
 
 `inspect.derived_node_states` 根据 task、最新 blocking finding、Gate、artifact、immutable candidate、当前 manifest 与 completion receipt 联合投影正式节点状态，而不是由单个子任务状态直接决定。可能状态为 `pending`、`active`、`waiting`、`blocked`、`ready-to-complete` 和 `completed`。新契约节点只有达到 `ready-to-complete` 才能完成；CLI 随后生成绑定 manifest、任务/物料事实、Gate、candidate、blocking defect、evidence 和 checksum 的不可变 completion receipt。完整 `scope freeze`、`scope amend`、`scope warn` 命令见正式状态指南。
 
-节点交接、生产审批、部署、版本归档和中断恢复后都必须运行 `verify`。最新可信 anchor 建立后，`ai-delivery compact <project> --dry-run` 零写入报告 legacy 全量快照覆盖范围、历史根摘要和预计净释放空间；apply 先写 checksummed gzip archive 和 manifest，从包内完整 replay 到锚定 registry checksum 后才移除 loose shards，之后 `verify --history` 返回 `compacted-history`。`artifact prune` 是另一项保留操作：默认以零写入 dry-run 列出可裁剪 artifact shard，只有显式 `--apply` 才删除前缀并写 retention receipt；其历史模式是 `retained-history`，不能声称重新审计已删除字节。完整命令、revision 冲突恢复和生产规则见[正式状态 CLI 使用指南](STATE-CLI-USER-GUIDE.zh-CN.md)。
+节点交接、生产审批、部署、版本归档和中断恢复后都必须运行 `verify`。`artifact prune` 默认以零写入 dry-run 列出可裁剪 artifact shard，只有显式 `--apply` 才删除前缀并写 retention receipt；其历史模式是 `retained-history`，不能声称重新审计已删除字节。完整命令、revision 冲突恢复和生产规则见[正式状态 CLI 使用指南](STATE-CLI-USER-GUIDE.zh-CN.md)。
 
 ### 13.3 任务登记
 
@@ -876,7 +861,7 @@ R00 发布请求
 
 R00 同时固定当时 `main` 的 commit。R04 通过 `release-git.mjs create-candidate` 携带 `--expected-main`、精确 `--source-tag/--source-commit`、`--receipt` 和 `--apply` 从该 commit 创建 `release/<release-id>-<slug>`。增量发布只以 `--no-ff` 合入目标 `version-ready/<version-id>/rN` Tag，得到唯一候选合并提交；同版本重发要求该 Tag 已在快照历史中，候选就是快照且不新增合并。R09 成功时先生成机器可读 `production-verification.json`（固定 `operation: production-verification-decision`、release ID、R00 基线、已验证和已部署候选），再通过 `release-git.mjs promote` 携带 `--production-verification` 把 `main` 从该原始快照快进到同一个已部署提交。若 `main` 已变化、候选提交不一致，或目标 Tag 不满足相应的增量/同版本 ancestry，停止并新建发布请求，不能拿当前分支头继续。发布修复在成功验证后、R10 归档前准备 schema 2 产品线级 `candidate-inventory.json`：根部固定 `scope: product-line`、`product_id`、`line_branch` 和 active candidate，每个候选固定自己的 `release_id`、ID、commit/status，根部不得定义 release ID。用 `release-git.mjs sync-release-fix` 携带 `--production-verification`、前代 `--candidate-inventory`、不同路径的 `--successor-candidate-inventory` 和 `--expected-line` 同步进 `line/<product-id>`；输入库存不改写，脚本把跨产品线派生的 stale 更新写入 successor，并在回执中绑定两份库存。stale 候选由脚本派生并写入带 release ID 的 `candidate_status_updates`，不接受调用方传入 stale 列表。已经存在于 line 时仍写入显式 `idempotent` receipt，且只能复用字节完全一致的 successor；任何遗漏修复的可选候选不能继续发布。
 
-版本收尾和发布归档都必须通过正式状态 CLI 固化事实。`version-closed` 在 `06-version-closeout` 完成并登记 `release-ready` 物料后更新 `latest_line_version_id`；它不会触发发布。`release-archived` 在 R10 完成并登记 `released` 物料后更新 `production_version_id` 和 `production_release_id`。R09 只能提供已验证身份，不能直接写入生产事实。以上三个字段以 `.workflow/delivery/workflow-state.yaml` 为权威来源，`project.yaml` 仅保留项目描述和旧项目兼容字段。
+版本收尾和发布归档都必须通过正式状态 CLI 固化事实。`version-closed` 在 `06-version-closeout` 完成并登记 `release-ready` 物料后更新 `latest_line_version_id`；它不会触发发布。`release-archived` 在 R10 完成并登记 `released` 物料后更新 `production_version_id` 和 `production_release_id`。R09 只能提供已验证身份，不能直接写入生产事实。以上三个字段以 `.workflow/delivery/workflow-state.yaml` 为权威来源，`project.yaml` 仅保留项目描述和当前配置。
 
 版本任务归档写入 `.workflow/control/archives/versions/<version-id>/`，保存版本 Manifest、任务快照和共享 checkpoint。只有可携带归档完整写入后，脚本才移除 `.workflow/control/tasks/` 与 `.workflow/control/checkpoints/` 中该版本的活动分片。普通恢复以及 `--include-closed` 都只扫描活动集合；历史详情必须通过显式审计读取归档。`.workflow/delivery/runtime/archive/` 仅是可丢弃的本地详细副本。