ai-delivery-workflow 0.4.0 → 0.5.1

package/README.md

@@ -1,6 +1,6 @@
 # AI Delivery Workflow
 
-本仓库是 `ai-delivery-workflow` 的维护与发行源码仓库，不是安装后的业务工作区，也不按双仓项目进行初始化。`bin/`、`lib/`、`skills/`、`docs/`、`verification/` 和 `audit/` 都是工作流实现或直接物料；`.tmp/` 统一保存可丢弃的本地运行物料。
+本仓库是 `ai-delivery-workflow` 的维护与发行源码仓库，不是安装后的业务工作区，也不按双仓项目进行初始化。`bin/`、`lib/`、`skills/`、`docs/`、`verification/`、`audit/` 和 `prototypes/` 都是工作流实现或直接物料；`.tmp/` 统一保存可丢弃的本地运行物料。
 
 本仓库发布的工作流在安装到业务项目后，固定采用“工作流控制仓库 + 嵌套代码仓库”的双仓工作区：工作流仓库跟踪 `.workflow/` 和共享 checkpoint，独立的 `code/` Git 仓库跟踪应用源码、测试、分支和 Tag。详见 [双仓工作区说明](docs/DUAL-REPOSITORY-WORKSPACE.zh-CN.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,15 +121,15 @@ 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/` 时会确定性拒绝并报告冲突，不会在两套状态之间选择权威来源。
 
 ## 仓库内容边界
 
 本工作流维护仓库把长期资产分为源码、永久验证源码和审计物料。安装器、状态 CLI、Hook、Skill、Workflow Manager 等通用自动化验证统一位于 `verification/` 并纳入 Git；可重建的全流程交付证据与历史快照位于 `audit/` 并纳入 Git，但不会被 `init` 安装到业务项目。
 
-所有测试工作区、缓存、日志、报告、临时 Git 仓库、npm cache、打包产物、认证辅助文件和绑定单次演练的脚本统一放入 `.tmp/`。根 `.gitignore` 整体忽略 `/.tmp/`，其中任何内容都不得作为权威源码或审计证据。`audit/` 候选包、部署副本和历史快照内嵌的应用测试属于审计物料，可保留原路径；执行这些校验的维护入口位于 `verification/`。
+已确认、需要重复启动或作为审核参考的设计原型及其伴随业务夹具统一放在 `prototypes/` 并纳入 Git；它们是设计资产，不等于正式产品前端，也不随安装器部署到业务项目。所有测试工作区、缓存、日志、报告、临时 Git 仓库、npm cache、打包产物、认证辅助文件和绑定单次演练的脚本统一放入 `.tmp/`。根 `.gitignore` 整体忽略 `/.tmp/`，其中任何内容都不得作为权威源码或审计证据。`audit/` 候选包、部署副本和历史快照内嵌的应用测试属于审计物料，可保留原路径；执行这些校验的维护入口位于 `verification/`。
 
 ```bash
 npm test

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/bin/release-check.mjs

@@ -4,6 +4,7 @@ import fs from "node:fs";
 import os from "node:os";
 import path from "node:path";
 import { spawnSync } from "node:child_process";
+import { withNpmAccessToken } from "../lib/npm-auth.mjs";
 import { normalizeNpmPackageResult } from "../lib/npm-package-result.mjs";
 
 function parseArguments(argv) {
@@ -45,6 +46,7 @@ function windowsNpmCli(name) {
 }
 
 function command(root, program, args, options = {}) {
+  const usesNpmConfig = new Set(["npm", "npx"]).has(program);
   if (process.platform === "win32" && new Set(["npm", "npx"]).has(program)) {
     const cli = windowsNpmCli(program);
     if (!cli) return { ok: false, status: null, stdout: "", stderr: `cannot locate ${program} CLI` };
@@ -56,7 +58,7 @@ function command(root, program, args, options = {}) {
     encoding: "utf8",
     windowsHide: true,
     timeout: options.timeout || 10 * 60 * 1000,
-    env: options.env || process.env,
+    env: usesNpmConfig ? withNpmAccessToken(options.env || process.env) : options.env || process.env,
   });
   return {
     ok: result.status === 0 && !result.error,
@@ -71,7 +73,11 @@ function readJson(file) {
 }
 
 function safeDetail(value) {
-  return String(value || "").slice(-2000);
+  const detail = String(value || "");
+  const token = typeof process.env.NPM_ACCESS_TOKEN === "string"
+    ? process.env.NPM_ACCESS_TOKEN.trim()
+    : "";
+  return (token ? detail.replaceAll(token, "[redacted]") : detail).slice(-2000);
 }
 
 function createRecorder(checks) {

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 根。
 
@@ -88,6 +88,8 @@ node .agents/skills/ai-delivery-checkpoint-task/scripts/task-state.mjs publish -
 
 每个代码引用至少记录：`repo_id`、`code_commit`、可选 `code_tag`、`source_path` 和 SHA-256。
 
+`product_id` 是产品累计研发线的稳定身份，在项目首次 bootstrap 的身份基线中确定；它不是代码仓 `repo_id`、版本号或 release ID。该产品首次开始计划版本时，从当时的代码 `main` 创建一次 `line/<product-id>`。随后每个版本从最新 line 开始，版本收尾才将 line 快进到 immutable `version-ready` Tag；不得在每次迭代或发布时再从 `main` 新拉 line。
+
 ## 5. 版本收尾与发布身份
 
 版本收尾顺序不可调整：
@@ -100,6 +102,17 @@ node .agents/skills/ai-delivery-checkpoint-task/scripts/task-state.mjs publish -
 
 `release-ready` 身份由代码 Tag、工作流 Tag 和 Manifest SHA-256 三者组成。发布闭包同时检查代码 ancestry、两个 Tag、Manifest checksum、连续版本关系和 `repo_id`。任一项缺失或漂移都阻止发布。
 
+发布采用 main-first 集成，不从 target Tag 直接签出 release 分支：
+
+1. 用户提出 R00 请求时，记录代码 `main` 的精确 commit 为 `expected_main`；
+2. R01/R02 确认该 commit 仍是 `main` 并完成连续闭包校验；增量发布要求它是选中目标 `version-ready` Tag 的祖先，同版本重发要求 Tag 已是该 commit 的祖先或相等；
+3. R04 从 `expected_main` 创建 `release/<release-id>-<slug>`；增量发布只用 `--no-ff` 合入一个目标 immutable `version-ready` Tag，合并提交是唯一候选身份；同版本重发不新增合并，候选就是 `expected_main`；
+4. R05 至 R08 只验证、审批和部署该精确候选，冻结的 release Tag 也绑定该提交；
+5. R09 成功后才将代码 `main` 从 `expected_main` 快进到这个已部署候选。若 main 发生漂移，旧候选为 `stale`，必须以新请求和新快照重建；
+6. 活动候选上的 `release-fix/<release-id>/<defect-id>` 在生产验证成功后、R10 归档前通过 `release-git.mjs sync-release-fix` 携带 R09 `--production-verification`、全量 schema 2 产品线级 `--candidate-inventory`、新的 `--successor-candidate-inventory` 和 `--expected-line` 受控同步到 `line/<product-id>`。库存根部固定 `scope: product-line`、`product_id`、`line_branch` 与 active candidate；每个候选固定自己的 `release_id`、commit 和 status，根部没有 release ID。输入库存不可改写，脚本只在不同的 successor 路径写入派生后的不可变库存。同步回执必须记录 operation、R09/前代与 successor 库存的证据路径和 SHA-256、source ref/commit、verified release commit、line 的旧/新 head、合并策略、带 release ID 的派生 stale candidate IDs/status updates 和 `applied` 或幂等 `idempotent` 状态。
+
+中间版本 Tag 仅用于闭包和物料追溯，不能重复合入 release 分支。历史 version-ready Tag、版本 Manifest、workflow-ready Tag 和 release Tag 都保持不可变；失败、回滚或阻塞发布不会推进 `main` 或 `line`。
+
 `workflow-state.yaml` 是累计研发和生产身份的权威审计视图。schema 2 分别使用 `development_state` 和 `release_state` 保存两条可并行轨道，发布不得重置累计研发状态。版本收尾在完成节点和登记 `release-ready` 物料后执行 `version-closed`；发布归档在完成 R10 和登记 `released` 物料后执行 `release-archived`。不得直接修改这些字段，也不得从代码分支当前位置反推生产事实。
 
 多版本发布必须逐一校验相邻版本的代码提交和工作流提交 ancestry，不能只证明当前生产提交可到达最终目标。版本任务的跨 clone 归档位于 `.workflow/control/archives/versions/<version-id>/`；归档后活动 task/checkpoint 分片被移除，普通恢复不会重新加载历史版本。

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)
@@ -26,6 +24,7 @@
 | 发行源码 | npm 包实际发布并用于安装目标项目的 `bin/`、`lib/`、`skills/` 和 `docs/`。 |
 | 永久验证 | 根配置和 `verification/` 中的通用测试与审计校验器，用于维护本发行仓库。 |
 | 审计物料 | `audit/` 中 TaskLite 历史 V1 证据与当前契约 ITER-V2 物料，纳入 Git，但不会安装到目标项目。 |
+| 可版本化设计原型 | `prototypes/` 中已确认的 Workflow Manager 原型及其业务页面夹具，纳入 Git，但不进入 npm 包或安装目标。 |
 | 临时物料 | `.tmp/` 中的测试工作区、缓存、日志、报告、临时仓库、打包文件和单次场景脚本，整体忽略且可丢弃。 |
 
 ## 2. 根目录
@@ -44,6 +43,7 @@
 | `docs/` | 完整项目手册、Workflow Manager 使用/维护指南和本文。 | 是 |
 | `verification/` | 工作流仓库的通用自动化测试、专项验证器和长期测试辅助程序，纳入 Git，不进入 npm 包。 | 否 |
 | `audit/` | TaskLite 全流程审计物料；其中内嵌测试属于候选包、部署副本或历史快照，不随 `init` 安装。 | 否 |
+| `prototypes/` | 已确认、可重复启动的设计原型及其伴随业务夹具；纳入 Git，不等于正式产品前端。 | 否 |
 | `.tmp/` | 全部临时运行物料，整体忽略，可随时删除。 | 否 |
 
 ## 3. CLI 与实现库
@@ -73,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、例行/增量/全历史校验。 |
@@ -103,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 维护手册：实现边界、自包含安装、验证契约、测试和完成定义。 |
@@ -121,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 投影、评论、截图、多轮编辑、审核、执行锁和废弃规则。 |
@@ -288,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` | 人工评审轮次和批准状态。 |
@@ -422,15 +411,15 @@
 | 路径 | 作用 |
 | --- | --- |
 | `skills/ai-delivery-close-version/` | 关闭已验证计划版本，生成版本 Manifest、血缘、version-ready Tag 与累计研发线推进记录，并在 release-ready 时归档任务。 |
-| `skills/ai-delivery-orchestrate-release/` | 只在用户明确发布时编排 R00 至 R10，管理发布请求和截止版本选择。 |
-| `skills/ai-delivery-assemble-release/` | 使用 `scripts/plan-release.mjs` 计算连续闭包并校验 Git/Tag，输出版本纳入表、物料索引、Git 计划和发布候选模板。 |
+| `skills/ai-delivery-orchestrate-release/` | 只在用户明确发布时编排 R00 至 R10，固定请求时 main 快照、目标版本选择、精确候选晋级和 release-fix 回写；R10 使用产品线级候选库存及不可变 successor。 |
+| `skills/ai-delivery-assemble-release/` | 使用 `scripts/plan-release.mjs` 计算连续闭包并校验 Git/Tag，输出版本纳入表、main-first Git 计划和发布候选模板。 |
 
 ### 12.1 `ai-delivery-prepare-release`
 
 | 文件 | 作用 |
 | --- | --- |
-| `skills/ai-delivery-prepare-release/SKILL.md` | 在 R06 冻结一个已验证发布候选，核对完整变更、实际交付物和回滚能力；生产审批独立位于 R07。 |
-| `references/release-contract.md` | release ID、候选 digest、Tag、交付清单、配置、迁移、验证、回滚和审批契约。 |
+| `skills/ai-delivery-prepare-release/SKILL.md` | 在 R06 冻结一个已验证的 main-first 发布候选，核对完整变更、实际交付物、精确晋级前提和回滚能力；生产审批独立位于 R07。 |
+| `references/release-contract.md` | release ID、main 基线、source Tag/commit、候选 digest/Tag、交付清单、配置、迁移、验证、回滚、line 回写和审批契约。 |
 | `assets/release-template/release-manifest.yaml` | 不可变发布清单模板。 |
 | `assets/release-template/delivery-items.csv` | 镜像、应用、配置、数据、基础设施、文档和运维项的实际交付清单模板。 |
 
@@ -447,7 +436,7 @@
 | --- | --- |
 | `skills/ai-delivery-verify-production/SKILL.md` | 每次部署或回滚后独立验证技术与业务信号，决定 released、失败或回滚。 |
 | `references/production-verification-contract.md` | 生产制品身份、烟雾/业务信号、决策、预授权回滚和归档准入契约。 |
-| `assets/production-verification-template/production-verification.md` | 生产验证报告模板。 |
+| `assets/production-verification-template/production-verification.md`、`production-verification.json` | 人读生产验证报告与强制机器可读 R09 决策模板。 |
 
 ## 13. 治理 skills
 
@@ -462,8 +451,9 @@
 
 | 文件 | 作用 |
 | --- | --- |
-| `skills/ai-delivery-manage-git/SKILL.md` | 管理 protected main、迭代分支、工作包分支/worktree、hotfix、release Tag 和串行生产转换。 |
-| `references/git-policy.md` | 分支命名、合并、Tag、候选保留、清理和“镜像回滚而非回滚分支”规范。 |
+| `skills/ai-delivery-manage-git/SKILL.md` | 管理 protected main、累计研发线、工作包分支/worktree、hotfix、main-first release、release-fix 回写和串行生产转换。 |
+| `scripts/release-git.mjs` | 受控创建 main-first 候选、精确晋级 main、将成功 release-fix 同步到 line，并输出绑定 schema-2 产品线候选库存前代/不可变 successor 的 JSON receipt。 |
+| `references/git-policy.md` | 分支命名、合并、Tag、候选保留、main 快照、schema-2 产品线候选库存、release-fix 回写、清理和“镜像回滚而非回滚分支”规范。 |
 
 ### 13.3 `ai-delivery-manage-standards`
 
@@ -536,23 +526,14 @@
 | `.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/` | 可跨迭代复用的体验基线和原型管理基线。 |
 | `.workflow/iterations/<iteration-id>/<node-id>/` | 迭代内每个流程节点的默认文档输出目录。 |
-| `.workflow/releases/<release-id>/<release-node>/` | 独立发布 R00 至 R10 的默认文档输出目录。 |
+| `.workflow/releases/<release-id>/<release-node>/` | 独立发布 R00 至 R10 的默认文档输出目录；R10 的 release-fix 物料引用 schema-2 产品线候选库存及其不可变 successor。 |
 | `.workflow/delivery/runtime/active-task.json` | 当前工作流工作区的唯一活动任务指针，任务关闭后删除；外部代码 worktree 通过 `--state-root` 或环境变量关联。 |
 
 ## 16. 本地和生成目录

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/NPM-RELEASE-MANAGEMENT.zh-CN.md

@@ -40,7 +40,7 @@ git diff --check
 - 包名、版本、文件数量和制品摘要符合预期；
 - `bin.ai-delivery` 为 `bin/ai-delivery.mjs`，文件以 Node shebang 开头；
 - `bin/`、`lib/`、`skills/` 和 `docs/` 均进入制品；
-- `.tmp/`、`verification/`、`audit/`、凭据和本地日志不进入 npm 包。
+- `prototypes/`、`.tmp/`、`verification/`、`audit/`、凭据和本地日志不进入 npm 包。
 
 版本号使用以下命令同步到两个清单文件：
 
@@ -65,6 +65,7 @@ Git Tag 和 npm 版本必须指向同一发行内容。不得删除远程 Tag
 
 - 发布前执行 `npm whoami --registry=https://registry.npmjs.org/`，确认账号正确。
 - 交互发布必须启用 `auth-and-writes` 2FA，并使用 npm 的一次性网页认证或 OTP。
+- 本地或自动化预检可通过 `NPM_ACCESS_TOKEN` 提供令牌；维护脚本只把它映射到官方 registry 的 npm 子进程环境，不写入 `.npmrc`、仓库或审计物料。令牌无效或过期时仍必须重新登录或更换令牌。
 - 密码、OTP、恢复码和 npm token 不得写入仓库、`.tmp/` 审计物料、命令日志或对话文档。
 - CI 只能使用最小权限、限定包、可过期的 granular access token；只有发布任务需要时才允许 bypass 2FA，并存入 CI secret store。
 - `publishConfig.registry` 必须固定为 `https://registry.npmjs.org/`，避免把正式包发布到本地镜像。