ai-delivery-workflow 0.2.2 → 0.4.0

package/docs/PROTOTYPE-MIGRATION.zh-CN.md

@@ -0,0 +1,164 @@
+# Prototype 迁移指南
+
+本文说明如何把旧 `prototype-set.yaml` / member manifest 模型迁移为项目唯一逻辑 Prototype。迁移只处理开放迭代；关闭迭代和归档证据保持历史原貌。
+
+## 1. 固定执行顺序
+
+使用准备发布的同一个安装包依次执行：
+
+```powershell
+npx --yes --package .\ai-delivery-workflow-<version>.tgz ai-delivery upgrade . --dry-run
+npx --yes --package .\ai-delivery-workflow-<version>.tgz ai-delivery upgrade .
+npx --yes --package .\ai-delivery-workflow-<version>.tgz ai-delivery doctor .
+npx --yes --package .\ai-delivery-workflow-<version>.tgz ai-delivery migrate . --dry-run
+```
+
+`upgrade` 只安装迁移能力、退休旧 `UX-LF` 契约并报告 `prototype_migration` follow-up；它不会应用 Prototype 迁移。只有审阅 `migrate --dry-run` 且报告 `can_apply: true` 后，才执行：
+
+```powershell
+npx --yes --package .\ai-delivery-workflow-<version>.tgz ai-delivery migrate .
+npx --yes --package .\ai-delivery-workflow-<version>.tgz ai-delivery doctor .
+```
+
+每次 dry-run 都严格零写入。源文件、决定文件或目标文件变化后必须重新 dry-run。
+
+## 2. 读取迁移报告
+
+`upgrade --dry-run` 和 `migrate --dry-run` 都返回 `prototype_migration`：
+
+| 字段 | 含义 |
+| --- | --- |
+| `status` | `not-required`、`ready`、`blocked` 或 `already-current`。 |
+| `iteration_id` | 当前开放迭代；只有该迭代会产生新的唯一 Prototype。 |
+| `source_checksum` | 旧 Prototype set/member 输入的聚合 SHA-256。 |
+| `member_count` | 旧 set 声明的成员总数。 |
+| `valid_member_count` | 通过身份、manifest 和 source 校验的成员数量。 |
+| `invalid_member_count` | 声明但未通过完整性校验的成员数量。 |
+| `legacy_sets` / `members` | 旧 set、member manifest、source、terminal 和 checksum 清单。 |
+| `target` | 固定 `prototype_id: PROTOTYPE` 及 `.workflow/experience/<iteration-id>/` 目标。 |
+| `merge_report` | 按 terminal、Page、route 和 file 稳定身份合并的记录与冲突。 |
+| `unresolved_conflicts` | 尚未由 checksum 绑定人工决定解决的冲突。 |
+| `preserved_history` | 关闭迭代和归档 set 的逐字节保留清单。 |
+| `preserved_sources` | 应用前再次校验且不会原地改写的旧源文件。 |
+| `approval` | 固定不复用旧批准；有旧成员时要求新的 `UX-UI`。 |
+| `file_changes` | 新增描述/记录/Review Shell 和逐字节 source copy 的精确计划。 |
+| `can_apply` | 所有结构、任务和 Prototype 歧义都关闭后才为 `true`。 |
+
+`member_count`、`valid_member_count` 和 `invalid_member_count` 分别报告声明、有效和无效成员。损坏的 manifest、非法身份或 checksum 漂移会保留在声明总数与无效数中，并令 `status: blocked`，不能把它误判为没有旧成员。
+
+### 2.1 零成员
+
+有效旧 set 中没有成员，或当前开放迭代没有旧 set 时：
+
+- `member_count: 0`、`valid_member_count: 0`、`invalid_member_count: 0`；
+- `status: not-required`；
+- `file_changes.additions` 和 `file_changes.copies` 为空；
+- 不创建 Prototype 迁移文件，也不要求迁移专属 `UX-UI`。
+
+### 2.2 单成员
+
+单成员只有在以下条件全部无歧义时自动迁移：
+
+- set 中身份与 member manifest 身份一致；
+- manifest、source 与必须目录都声明 `sha256` 且实际字节匹配；
+- source 和目录引用都是受控相对路径；
+- terminal、Page、route、file 身份没有冲突；
+- 目标路径不存在不同字节。
+
+满足时报告 `status: ready`、`can_apply: true`。任一条件失败均为 `blocked`，不会用猜测或显示名称补齐身份。
+
+### 2.3 多成员
+
+多成员不会重新切片。迁移器按稳定身份汇总：
+
+- `merge_report.terminals`；
+- `merge_report.pages`；
+- `merge_report.routes`；
+- `merge_report.files`；
+- `merge_report.conflicts`。
+
+相同身份且记录 checksum 相同的定义自动合并；相同身份但定义不同的记录生成稳定 `conflict_id`，等待人工选择 canonical member。每个成员的 source 仍逐字节复制到 `prototype/source/<member-id>/`，不会把不同源码树混写成一个目录。
+
+## 3. 冲突决定文件
+
+决定文件同时承载任务分组和 Prototype 冲突，所以有且只有一份文件，并同时保留 `decisions` 与 `prototype_decisions`：
+
+```yaml
+schema_version: 1
+source_checksum: <migrate-dry-run anchors.proposed.source_checksum>
+actor: human:delivery-owner
+decisions: []
+prototype_decisions:
+  - conflict_id: PROTO-CONFLICT-0123456789ABCDEF
+    action: choose-member
+    member_id: PROTO-WEB
+    rationale: 该成员是此稳定身份的已确认权威来源
+```
+
+任务分组有歧义时，从 `task_grouping.decision_template.decisions` 填写 `decisions`；Prototype 有冲突时，从 `prototype_migration.decision_template.prototype_decisions` 填写 `prototype_decisions`。每项 Prototype 决定必须：
+
+- 使用 dry-run 返回的原 `conflict_id`；
+- 使用 `action: choose-member`；
+- 从该冲突的 `member_ids` 中选择一个 `member_id`；
+- 提供非空 `rationale`；
+- 由 `human:<identity>` actor 作出；
+- 绑定当前迁移 `source_checksum`。
+
+复核和应用必须使用同一文件：
+
+```powershell
+ai-delivery migrate . --decisions .\migration-decisions.yaml --dry-run
+ai-delivery migrate . --decisions .\migration-decisions.yaml
+```
+
+未知、重复、缺失或过期的决定一律失败关闭。
+
+## 4. 应用结果与不可变边界
+
+应用只在 `.workflow/experience/<iteration-id>/` 新增：
+
+```text
+prototype.yaml
+prototype-migration.yaml
+prototype/source/<legacy-member-id>/...
+prototype/review-shell/index.html
+```
+
+`prototype.yaml` 的状态是 `migration-pending-ux-ui`，`current_revision_ref` 为 `null`；`prototype-migration.yaml` 记录旧 set/member、合并结果、人工决定、历史保留清单和批准政策。
+
+以下内容保持原字节：
+
+- 旧 `prototype-set.yaml`、member manifest、成员 source 和目录；
+- 关闭迭代与归档 Prototype；
+- 已有 Gate 文件和 Gate 决定；
+- 旧事件、正式状态视图和归档证据。
+
+迁移清单使用 schema 3 记录 Prototype 新增与复制文件的 checksum，供受保护回滚使用。迁移后出现新正式事务或目标字节漂移时，回滚失败关闭，只能前向修复。
+
+## 5. 重新通过 UX-UI
+
+开放迭代不会继承旧 member/set 的批准。升级退休 pending `UX-LF` 后会续接 pending `UX-UI`；迁移完成后必须在同一个逻辑 Prototype 中完成：
+
+1. 按新目录和当前视觉规范整理完整 source、Review Shell 及规范化目录；
+2. 冻结新的不可变 `prototype-revision.yaml`；
+3. 运行 `prototype-revision validate`；
+4. 启动 Workflow Manager，并在 P12/P13 打开该精确 revision；
+5. 由用户逐 Page/Review Scene 审核并完成新的 `UX-UI`；
+6. 之后才允许修改正式前端。
+
+迁移生成的占位 Review Shell 只帮助定位旧成员，不是完整冻结 revision。Workflow Manager 不能对 `current_revision_ref: null` 或未冻结、未完整校验的迁移状态签发批准。
+
+## 6. Workflow Manager
+
+Workflow Manager 可以查看 `.workflow/experience/<iteration-id>/prototype-migration.yaml`、迁移清单及其 checksum，用于审计“从什么迁到什么”，但不会把迁移完成推断为设计批准。P11 只接受精确 Visual Reference，P12/P13 只接受完整、冻结、校验通过的 Prototype Revision；Page 决定、审核凭据和最终 `UX-UI` 只能通过 Manager 白名单动作产生。
+
+## 7. 完成检查
+
+迁移完成后至少确认：
+
+- `migrate` 返回 `applied: true` 且 `prototype_migration.applied: true`；
+- `doctor` 的 required checks 全部通过，包括 `package-surface`；
+- 旧 set/member、关闭/归档证据和旧事件 checksum 未变化；
+- 新 `prototype.yaml` 指向唯一 `PROTOTYPE`，状态为 `migration-pending-ux-ui`；
+- 开放迭代存在待完成的新 `UX-UI`，旧批准未复用；
+- 后续所有正式前端修改仍遵守“先改 Prototype -> 用户确认 -> 再改正式前端”。

package/docs/STATE-CLI-MAINTENANCE.zh-CN.md

@@ -1,6 +1,8 @@
 # 正式状态 CLI 维护指南
 
-当前写入顺序为“权威事件分片 -> 全局兼容视图 -> JSONL 事件索引”。`verify` 同时检查事件分片自身 checksum 和最新分片与全局视图是否一致；`rebuild` 从每个 stream 的最新分片恢复 YAML，并按确定顺序重建 JSONL 索引。
+当前生产图是 `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`、`rebuild` 和显式迁移继续消费历史记录；所有新任务、物料登记、transition、candidate、版本收尾和 Gate mutation 在写入及 Hook dispatch 前拒绝。`R00-release-request` 至 `R10-release-archive` 继续允许写入。
+
+正式状态写入会先完整暂存权威事件分片、全局兼容视图和 JSONL 事件索引，持久化 prepared journal，再提交各目标并写入 committed marker；同步异常时恢复原文件，进程中断后由下一次受锁 mutation 或 `rebuild` 幂等恢复。`inspect`、`verify`、Bootstrap 诊断与 Workflow Manager 正式状态读取期间获取与 mutation 共用的 formal-state lock；活动 writer、其他 reader 或未恢复 journal 均使读取 fail-closed，避免检查通过后又读到混合 revision。只读调用方不得接管死锁或执行事务恢复。日常 `verify` 不遍历历史分片，只校验当前视图、JSONL 索引、物料和状态不变量；显式 `verify --history` 还检查全部事件分片的连续性、元数据、记录 checksum、schema 2 checksum 链以及最新 replay 结果与全局视图的一致性。`rebuild` 按 revision replay 每个 stream，并按确定顺序重建 JSONL 索引。
 
 ## 1. 权威源码与安装结果
 
@@ -35,15 +37,20 @@
 - `workflow-state`；
 - `artifact-registry`。
 
+artifact registry 与 workflow state 的新 mutation 都使用 schema 2 增量事务。schema 2 记录包含 `transaction_id`、`idempotency_key`、`before_revision`、`after_revision`、`operations`、`previous_checksum`、`after_checksum` 和 `record_checksum`。artifact operations 只携带 registry 元数据、本次新增物料或本次新增 handoff 关系；workflow operations 只携带顶层元数据和本次受影响的 scope，首个 delta 同时固化两个 scope 作为 replay 基线。带已登记 evidence 的 transition 或 Gate 会向 registry 顶层 `handoffs` 追加独立关系，不改写 evidence artifact revision，并把 workflow delta 与 artifact delta 放入同一个 `transaction_id` 和恢复 journal；任一 stream 写入失败时整个语义动作回滚。
+
 每次 mutation：
 
-1. 获取两个 stream 共用的 formal-state lock，避免并发追加审计事件时相互覆盖；
-2. 读取并比较 `--expected-revision`；
+1. 获取 mutation 与只读正式状态快照共用的 formal-state lock，避免并发追加或读取时观察到部分提交；
+2. artifact 读取并比较 `--expected-revision`；workflow 读取并比较 owning scope 的 `--expected-scope-revision`，旧顶层参数只作兼容；
 3. 校验命令输入和跨文件引用；
-4. revision 加一；
-5. 原子替换 YAML；
-6. 向 `state-events.jsonl` 追加包含 stream、revision、事件类型和 `after_checksum` 的审计事件；
-7. 释放锁。
+4. 每个受影响 aggregate 的 revision 分别加一；
+5. 生成同一语义动作涉及的全部事件分片、当前 YAML、兼容视图和下一版 JSONL 的完整暂存内容，并对每个原文件和新文件记录 checksum；
+6. 持久化一个 prepared journal，再替换全部目标；捕获到异常时按 checksum 恢复整个写集合；
+7. 所有目标替换完成后持久化 committed marker，再清理备份、暂存文件和 journal；
+8. 进程中断后，下一次受锁 mutation 或 `rebuild` 回滚 prepared journal，或验证并清理 committed journal；锁持有进程仍存活时拒绝接管；
+9. schema 2 事务把前一分片 `record_checksum` 写入 `previous_checksum`，旧分片没有记录 checksum 时使用其规范化记录 checksum 作为链锚；scope start 的 `project.yaml` 兼容字段与 workflow shard、当前视图、JSONL 同事务提交；物料交接的 workflow/artifact 分片共享事务 ID；
+10. 释放锁。
 
 不要在新调用方中解析并重写正式 YAML。调用 `executeDeliveryStateCommand()`，或在已安装项目中执行 `.workflow/tools/state/state.mjs`。bootstrap 已按此边界登记诊断报告。
 
@@ -53,34 +60,37 @@
 
 - `inspect`
 - `verify`
+- `snapshot create`
 - `artifact register`
 - `artifact status`
+- `artifact compact`（顶层 `ai-delivery compact --dry-run` 为零写入；apply 先验证压缩归档再移除 loose history）
+- `artifact prune`（默认零写入 dry-run，显式 `--apply` 才执行保留裁剪）
 - `transition`
 - `gate request`
 - `gate decide`
 
 `transition` 还承载两个受约束的里程碑事件：
 
-- `version-closed`：校验已完成的 `12-version-closeout` 和 `release-ready` 物料，只更新 `latest_line_version_id`；
+- `version-closed`：校验已完成的 `06-version-closeout` 和 `release-ready` 物料，只更新 `latest_line_version_id`；
 - `release-archived`：校验已完成的 `R10-release-archive`、`released` 物料和目标生产版本，只更新 `production_version_id`、`production_release_id`。
 
-这些字段属于 `workflow-state` 审计流。不得把 `project.yaml` 变成第二写入口，也不得由查看器、Hook 或 R09 直接回写。
+这些字段属于 `workflow-state` 审计流。不得把 `project.yaml` 变成第二写入口，也不得由 Workflow Manager UI、Hook 或 R09 直接回写。
 
 新增行为时遵循一个失败测试、最小实现、单文件测试的 TDD 循环。测试只通过 `executeDeliveryStateCommand()` 或真实 CLI 观察行为，不测试内部函数。
 
 任何新增 mutation 都必须：
 
-- 要求 `--expected-revision`；
+- artifact 要求 `--expected-revision`，workflow 要求 `--expected-scope-revision`；
 - 使用正确 stream lock；
 - 原子写；
 - 产生审计事件；
-- 返回新 revision；
+- 返回新的 stream revision，并为 workflow 返回 `scope_revision`；
 - 保持 `verify` 可检测绕过写入；
 - 在用户手册、正式状态契约和相关节点 Skill 中同步说明。
 
 ## 5. `verify` 契约
 
-当前校验：
+日常 `verify` 校验：
 
 - `workflow-state.schema_version` 为 2（兼容读取 1），`artifact-registry.schema_version` 为 1；
 - revision 为非负整数；
@@ -91,13 +101,19 @@
 - 物料文件存在于 `.workflow/` 内，真实路径不逃逸；
 - 登记 checksum 与当前文件 SHA-256 一致。
 
+可信快照写入 `.workflow/control/snapshots/formal-state/<anchor-id>/`。`snapshot create --id <anchor-id> --reason version-boundary` 创建版本边界锚点；`snapshot create --reason configured-interval` 读取 `project.yaml.formal_state_snapshot_interval`，未达到正整数阈值时无写入返回。相同最新锚点 ID、reason、stream revision 和视图 checksum 均未变化时，重跑返回 `deduplicated: true`；其他已存在 ID 拒绝覆盖。锚点事务同时写入两个正式视图的原字节副本、带自校验 checksum 的 `anchor.yaml` 和带自校验 checksum 的 `latest.yaml`。锚点记录 stream revision、视图 checksum、记录链头、JSONL 字节偏移和事件数。首次创建前运行完整历史校验；后续创建以前一可信锚点为 replay 基线，只校验后缀。
+
+`snapshot references --iteration-id <id> [--candidate-id <id>]` 是版本归档唯一可信引用投影。它复用正式状态模块的 anchor 校验，在同一读锁内验证 pointer、anchor、快照、scope manifest 与 candidate，并为 Gate decision 生成 canonical checksum。checkpoint 任务脚本只能消费该 JSON 输出，不得复制 anchor 校验逻辑。
+
+已有锚点时，日常 `verify` 验证锚点与快照 checksum、当前正式视图和 JSONL 后缀，不读取事件分片或解压历史归档。`verify --history --since-anchor` 额外要求锚点后每个 stream 的分片数量与 revision 差一致，后缀 revision 各出现一次，分片元数据与 JSONL 后缀一致，记录 checksum 和 checksum 链连续，并从锚点快照 replay 到当前正式视图。没有 compaction/retention 时，`verify --history` 保持完整历史审计：要求每个 stream 的分片数量与当前 revision 一致，revision 1 到当前 revision 各出现一次，并 replay 全部旧快照与 delta。`artifact compact` 只选择最新可信 anchor 覆盖的 legacy `after_value` shards；dry-run 零写入计算 root digest、coverage 和净释放空间，apply 先写 gzip bundle/manifest、重新校验所有 entry checksum 并 replay 到锚定 registry checksum，验证失败不得移动 loose 文件。成功后 `verify --history` 返回 `compacted-history` 并审计归档包与保留后缀。`artifact prune` 则删除 anchor 前缀并写 `.workflow/control/retention/artifact-registry/<anchor-id>.yaml` receipt；其 `verify --history` 返回 `retained-history`，不能伪称重新审计已删除字节。`rebuild` 以 anchor 原字节快照为基线，不得从 revision 0 replay 或重写仍承担 anchor 边界的 JSONL 索引。
+
 JSONL 审计不是外部签名账本。拥有仓库写权限的人可以同时篡改状态和审计文件；高保证环境应把 Git 签名、CI 证明或外部不可变审计存储作为补充，不能宣称本地 checksum 可抵御恶意共同篡改。
 
-## 6. 查看器集成
+## 6. Workflow Manager 集成
 
-查看器从 `artifact-registry.yaml` 结构化读取已登记物料。对于路径匹配的物料，注册表中的 ID、status、version 和 node 优先于正文字段；Git 未提交变更仍作为独立的“已变更”状态优先显示。查看器只读，不能调用状态 mutation。
+Workflow Manager 通过正式状态模块读取 `derived_node_states`、Gate 和已登记物料，不重新实现状态推导。Manager 的资源投影只读；需要 Gate 决定时，白名单动作调用同一正式状态服务，并保留 actor、evidence、revision 与 Receipt。UI 不能直接写 YAML 或绕过 mutation。
 
-查看器在安装项目中读取同一 vendored YAML；在发行仓库测试环境中回退到包依赖。修改目录关系时同时验证源码模板和安装后运行时。
+Manager 在安装项目中复用同一 vendored YAML；发行仓库测试回退到包依赖。修改目录关系时同时验证维护源码、安装后 runtime 和 CLI/HTTP/UI 一致性。
 
 ## 7. Evolution Hook 接线
 
@@ -109,7 +125,7 @@ JSONL 审计不是外部签名账本。拥有仓库写权限的人可以同时
 node --test verification/delivery-state.test.mjs
 node --test verification/project-installer.test.mjs
 node --test verification/project-bootstrap.test.mjs
-node --test verification/workflow-viewer.test.mjs
+node --test verification/workflow-manager*.test.mjs
 npm test
 node --test verification/checkpoint-task-state.test.mjs
 npm run audit:verify
@@ -121,6 +137,8 @@ npm run audit:verify
 
 `workflow-state.yaml` 当前 schema 为 2。修改状态实现时必须保持 schema 1 只读兼容，并分别验证 `development_state` 与 `release_state` 的 scope、局部 revision、节点集合、Gate 集合和节点尝试。流程图不能退化为简单“上一编号节点”判断：平台准备允许并行，体验与产品允许带原因重开，后续迭代允许用成功的冻结基线物料满足未受影响的前置条件。
 
+独立 aggregate 的 writer 仍通过共享提交区串行更新 JSONL 和全局视图，但使用各自的 aggregate revision：最多等待可识别的活动事务 30 秒，获取锁后重新读取并可分别成功。同一 aggregate 的 writer 在等待后必须因 revision conflict fail-closed。未知格式锁和只读入口不等待、不恢复，遇到 live lock 或 journal 立即失败。
+
 安装诊断不得从项目内可编辑 manifest 推导可信 Skill 集合。固定 Skill 清单、Skill 目录摘要、Hook 摘要和状态运行时摘要以发行包为准；manifest 必须与发行包一致。`doctor` 还必须运行安装后状态 CLI 的 `inspect` 与 `verify`，并校验 JSON 输出语义。
 
 正式状态相关变更只有在以下条件全部满足后才完成：
@@ -129,7 +147,7 @@ npm run audit:verify
 - 安装后的自包含 CLI 实际可运行；
 - bootstrap 等调用方没有直接写正式状态；
 - `doctor` 检查运行时完整；
-- 查看器仍为只读并正确显示注册表状态；
+- Manager 的状态投影仍为只读，白名单 Gate 动作仍经正式状态服务并正确显示结果；
 - 25 个 Skill 通过校验；
 - 审计物料校验和全量测试通过；
 - 用户手册、维护手册、文件索引和相关 Skill 已同步。

package/docs/STATE-CLI-USER-GUIDE.zh-CN.md

@@ -1,15 +1,19 @@
 # 正式状态 CLI 使用指南
 
+当前研发生产模型是 `development-seven-node`：`00-bootstrap -> 01-product-shaping -> 02-solution-design -> 03-delivery-readiness -> 04-implementation -> 05-candidate-assurance -> 06-version-closeout`。生产 Skill 为新任务、物料和 transition 使用这些节点 ID。旧 13 个研发节点仅保留只读兼容：`inspect`、`verify`、`rebuild` 和显式迁移可读取历史记录；新任务、物料登记、transition、candidate、版本收尾和 Gate 写入全部拒绝。`R00-release-request` 至 `R10-release-archive` 继续允许写入。
+
 ## 可重建视图
 
-每次正式状态 mutation 会先写入 `.workflow/control/events/<stream>/<revision>-<event-id>.yaml` 权威事件分片，再刷新兼容的 `workflow-state.yaml`、`artifact-registry.yaml` 和 `state-events.jsonl` 视图。视图丢失或损坏时执行：
+正式状态 mutation 会生成 `.workflow/control/events/<stream>/<revision>-<event-id>.yaml` 权威事件分片，并与 `workflow-state.yaml` 或 `artifact-registry.yaml` 当前视图及 `state-events.jsonl` 索引作为一组提交。workflow 与 artifact mutation 都使用 schema 2 增量事务：事件只保存顶层元数据和受影响的 scope 或物料，不再嵌入完整视图；scope start 还把 `project.yaml` 兼容身份纳入同一事务。带已登记 evidence 的 transition/Gate 会在同一事务中同时生成 workflow delta 和 artifact handoff delta，并向 registry 顶层 `handoffs` 追加独立关系；已登记 artifact revision 的字段保持不变。提交前会在 `.workflow/delivery/runtime/formal-state-locks/` 写入恢复 journal；`inspect`、`verify`、Bootstrap 诊断及 Workflow Manager 正式状态读取期间持有同一把 formal-state lock，遇到并发 mutation 或未恢复 journal 时 fail-closed，不会返回混合 revision。mutation writer 最多等待可识别的活动提交 30 秒，获取锁后重新读取并校验自己的 aggregate revision。下一次 mutation 或 `rebuild` 根据 commit marker 回滚 prepared 事务或清理 committed 事务。旧的完整快照分片保持只读兼容且不会在首次追加新事务时被改写。视图丢失或损坏时执行：
 
 ```powershell
 node .workflow/tools/state/state.mjs rebuild
 node .workflow/tools/state/state.mjs verify
+node .workflow/tools/state/state.mjs verify --history
+node .workflow/tools/state/state.mjs verify --history --since-anchor
 ```
 
-`rebuild` 不从聊天记录推断状态，只读取不可变事件分片。没有事件分片的历史项目保持原视图不变。
+`rebuild` 不从聊天记录推断状态，只读取不可变事件分片，并可连续 replay 旧快照和新增量事务。没有事件分片的历史项目保持原视图不变。未创建锚点时，日常 `verify` 校验完整 JSONL 索引但不遍历历史分片；已有可信锚点时，它验证锚点和当前状态后只读取 JSONL 后缀。`verify --history --since-anchor` 进一步校验并 replay 锚点后的分片。`verify --history` 仍显式校验全部历史分片的连续性、元数据、记录 checksum、增量事务 checksum 链及其与 JSONL 和当前视图的一致性。
 
 > 适用入口：`.workflow/tools/state/state.mjs`  
 > 适用范围：正式流程、物料、Gate、候选和发布状态
@@ -19,7 +23,7 @@ node .workflow/tools/state/state.mjs verify
 `.workflow/delivery/workflow-state.yaml` 和 `.workflow/delivery/artifact-registry.yaml` 是研发流程的控制面，不是普通说明文档。通过脚本修改可以统一完成：
 
 - revision 乐观并发控制；
-- 文件锁和原子替换；
+- 文件锁和分片、当前视图、JSONL 索引的事务提交；
 - 物料 SHA-256 登记；
 - Gate 证据和决策人校验；
 - 节点状态不变量校验；
@@ -39,112 +43,182 @@ Hook 只记录脱敏生命周期事件和心跳，不得修改两类状态，也
 
 ## 3. 标准操作顺序
 
-1. 先通过只读 Bootstrap inspect 读取 `next_action_owner`；仅当它为 `agent` 时才用 `task-state.mjs recover` 恢复并激活 `recommended_task_id`。`user/external` 等待态禁止写入；收到所需输入后，用带新 `--next-action` 的 `activate --next-action-owner agent` 原子恢复本机 runtime 并接管任务。
+1. 先通过只读 Bootstrap inspect 读取 `next_action_owner`；仅当它为 `agent` 时才用 `task-state.mjs recover` 恢复并激活 `recommended_task_id`。推荐状态为 `failed` 时使用 `activate --new-attempt --phase repair`；Bootstrap 不会自动创建 attempt。`user/external` 等待态禁止写入；收到所需输入后，用带新 `--next-action` 的 `activate --next-action-owner agent` 原子恢复本机 runtime 并接管任务。
 2. 在 `.workflow/` 写入并验证本节点交付物。
-3. 运行 `inspect`，取得 `workflow_state.revision` 和 `artifact_registry.revision`。
+3. 运行 `inspect`，取得 owning `development_state.revision` 或 `release_state.revision`，以及 `artifact_registry.revision`；顶层 `workflow_state.revision` 仅用于审计串行化和旧调用兼容。
 4. 登记物料或更新物料状态。
 5. 需要 Gate 时提交请求并记录明确决定。
 6. 使用已登记物料作为 evidence 完成节点流转。
 7. 运行 `verify`。
 8. 将物料 ID、revision 和验证结果写入任务 checkpoint 或完成记录。
 
+任务层使用稳定逻辑身份。初始化时用 `--scope`、`--acceptance` 和 `--responsibility` 固定 iteration、node、skill、goal、范围、验收、责任边界和依赖；同一 ID、同一契约重复 `init` 是零写入，相同契约换用新 ID 会失败。契约实质变化时必须创建新任务，并使用 `--derived-from` 或 `--supersedes` 建立显式关系。规划、实现、评审、分诊、修复、测试和验证使用同一任务下的结构化 attempt/phase，不再创建 F/R/T/P/vN 后缀任务。
+
+```bash
+node .agents/skills/ai-delivery-checkpoint-task/scripts/task-state.mjs inspect --task-id TASK-01 --include-closed
+node .agents/skills/ai-delivery-checkpoint-task/scripts/task-state.mjs activate --task-id TASK-01 --phase implementation
+node .agents/skills/ai-delivery-checkpoint-task/scripts/task-state.mjs finish --task-id TASK-01 --status failed --phase review --finding-json '{"finding_id":"FIND-01","severity":"blocking","status":"open","summary":"验收分支未覆盖"}' --change-set-json '{"change_set_id":"CHANGESET-01","approval_actor":"product-owner@example.invalid","rationale":"集中修复完整反馈集","finding_ids":["FIND-01"],"allowed_files":["src/acceptance.mjs"],"expected_evidence":["test-report@2"],"review_axes":["standards","spec"],"collection_decision":"fail"}' --time-category review --elapsed-minutes 12 --next-action "执行修复"
+node .agents/skills/ai-delivery-checkpoint-task/scripts/task-state.mjs activate --task-id TASK-01 --new-attempt --phase repair --next-action "执行已批准修复集"
+node .agents/skills/ai-delivery-checkpoint-task/scripts/task-state.mjs finish --task-id TASK-01 --status completed --phase review --finding-json '{"finding_id":"FIND-01","severity":"blocking","status":"resolved","summary":"验收分支已覆盖","evidence":["test-report@2"],"changed_files":["src/acceptance.mjs"],"change_set_id":"CHANGESET-01"}' --next-action "恢复迭代"
+node .agents/skills/ai-delivery-checkpoint-task/scripts/task-state.mjs init --task-id TASK-02 --iteration-id ITER-01 --node implementation --skill ai-delivery-develop-iteration --status queued --goal "扩展后的任务" --scope SLICE-02 --acceptance AC-02 --derived-from TASK-01 --next-action "等待范围批准"
+```
+
+`init` 只创建 queued 任务，默认状态也是 queued；其它状态会被拒绝。queued 没有 attempt，只有首次 activate 会检查依赖并创建 `A1`，queued 不能直接 checkpoint/finish；phase 状态由 task transition 推导，`--phase-status` 不受支持。blocked/interrupted 后恢复仍属于当前 attempt。failed 既不满足依赖，也不能隐式重启，但默认 recover 会把它列入 `retryable_task_ids` 并优先于 queued 任务推荐；只有 `--new-attempt` 会在原 task 下创建下一 attempt。进入 review phase 时 CLI 固定 `review_subject_baseline`，批准前若 Git 状态变化则拒绝。`--finding-json` 使用结构化 JSON 且记录只追加；同一 finding ID 的最后一条记录是 task 级最新结论。review phase 用 `--change-set-json` 提供批准人、理由、全部 open finding IDs、允许文件、预期证据、`review_axes` 和 `collection_decision`；CLI 把固定对象固化为 `repair_baseline`、持久化规范 `feedback_collection` 并计算 `collection_checksum`。resolved 必须引用该批准集内已有 open finding，只能在集中复审的 review phase 携带预期 evidence 写入，且 `changed_files` 必须与批准后真实 Git 变化完全一致并位于批准范围内；最新 blocking finding 仍为 `open` 时不能 completed。`completed/failed/abandoned` 只能使用 `finish`。`--time-category` 必须与 `--elapsed-minutes` 成对出现。`task-state.mjs inspect` 严格只读，不创建 runtime、resume、checkpoint、lock 或 Git 变更。
+
 ## 4. 只读命令
 
 ```bash
 node .workflow/tools/state/state.mjs inspect
 node .workflow/tools/state/state.mjs verify
+node .workflow/tools/state/state.mjs verify --history
+node .workflow/tools/state/state.mjs verify --history --since-anchor
+```
+
+`inspect` 返回规范化后的项目、流程和注册表状态，不写文件。日常 `verify` 校验 Schema、revision、节点互斥、物料 ID/路径唯一性、路径边界、物料 checksum、JSONL 审计 revision 连续性和正式状态文件最后 checksum。`verify --history --since-anchor` 只读取可信锚点后的 JSONL 与事件分片并从快照 replay；`verify --history` 读取全部事件分片，检查 revision 不缺失不重复、分片元数据与 JSONL 一致、记录 checksum 有效，并确认最新分片与当前视图一致。
+
+可信快照位于 `.workflow/control/snapshots/formal-state/<anchor-id>/`，包含原字节 `workflow-state.yaml`、`artifact-registry.yaml` 和带自校验 checksum 的 `anchor.yaml`；`latest.yaml` 指向最新锚点。版本边界显式创建锚点：
+
+```bash
+node .workflow/tools/state/state.mjs snapshot create --id <anchor-id> --reason version-boundary
+```
+
+普通安全点可尝试按配置间隔创建：
+
+```bash
+node .workflow/tools/state/state.mjs snapshot create --reason configured-interval
 ```
 
-`inspect` 返回规范化后的项目、流程和注册表状态，不写文件。`verify` 校验 Schema、revision、节点互斥、物料 ID/路径唯一性、路径边界、物料 checksum、审计 revision 连续性和正式状态文件最后 checksum。
+新项目的 `project.yaml.formal_state_snapshot_interval` 默认为 100。间隔未达到时命令返回 `created: false` 且不写文件。相同最新锚点 ID 在正式视图未变化时可安全重跑，并返回 `deduplicated: true`；状态已推进或 ID 与最新锚点不一致时拒绝复用。第一个锚点创建前执行完整历史校验；已有锚点时只验证上一个锚点后的链。锚点固定两个 stream 的 revision、视图 checksum、事件记录链头，以及 JSONL 字节偏移和事件数。增量校验信任通过 checksum 验证的锚点，因此不会读取或发现锚点前分片的后续篡改；需要取证或兼容性审计时仍运行完整 `verify --history`。
 
 也可由发行包维护者运行：
 
 ```bash
 ai-delivery state inspect --project <project-root>
 ai-delivery state verify --project <project-root>
+ai-delivery state verify --history --project <project-root>
 ```
 
 项目执行和恢复时优先使用项目内 `.workflow/tools/state/state.mjs`，确保命令版本与项目安装版本一致。
 
+### 4.1 冻结范围与推导节点状态
+
+Delivery Readiness 批准后，使用 `scope freeze` 一次性冻结 Slice、需求、验收、必需任务和必需物料，并启用 `scope_contract_version: 1`：
+
+```bash
+node .workflow/tools/state/state.mjs scope freeze --expected-scope-revision <revision> --iteration-id ITER-01 --manifest-id SCOPE-ITER-01-R1 --slice SLICE-01 --requirement REQ-01 --acceptance AC-01 --required-task 04-implementation:TASK-01 --required-artifact 04-implementation:ART-01 --approved-by human:product-owner --reason "Delivery Readiness 已批准"
+```
+
+冻结后不得直接调整清单。唯一范围变更入口是显式人工批准的 `scope amend`，新 revision 必须通过 `--supersedes` 指向当前 manifest：
+
+```bash
+node .workflow/tools/state/state.mjs scope amend --expected-scope-revision <revision> --iteration-id ITER-01 --manifest-id SCOPE-ITER-01-R2 --supersedes SCOPE-ITER-01-R1 --slice SLICE-01 --slice SLICE-02 --requirement REQ-01 --acceptance AC-01 --required-task 04-implementation:TASK-01 --required-artifact 04-implementation:ART-01 --approved-by human:product-owner --reason "批准扩大范围"
+```
+
+Slice 超过逻辑任务数、活跃工时、墙钟时长或阻塞修复轮次预算时，只登记告警：
+
+```bash
+node .workflow/tools/state/state.mjs scope warn --expected-scope-revision <revision> --iteration-id ITER-01 --metric logical-tasks --observed 9 --reason "超过默认预算"
+```
+
+`scope warn` 固定写入 `action: warn-only` 和 `reslice_performed: false`，不会自动重新切片、重排计划或改变验收。只有人明确要求并批准后，才另行执行 `scope amend`。未包含 `scope_contract_version` 的历史 scope 继续按旧收口规则读取，不会因升级被隐式迁移。
+
+`inspect.derived_node_states` 把每个节点投影为 `pending`、`active`、`waiting`、`blocked`、`ready-to-complete` 或 `completed`。投影同时读取冻结 manifest、稳定 task 状态、最新 append-only blocking finding、强制 Gate、已登记 artifact 及 checksum、选定 immutable candidate 和 completion receipt；不能仅由一个子任务或聊天结论决定正式节点状态。受新契约治理的节点只有在 `ready-to-complete` 时才能执行 `node-completed`。成功命令会生成不可变 completion receipt，绑定当前 manifest、任务/物料事实、Gate、candidate、blocking defect 集、evidence 与 receipt checksum；`verify` 会拒绝篡改或与当前 scope 不一致的收据。
+
 ## 5. 物料命令
 
-首次登记：
+working draft 保持为普通可变文件，不调用正式状态 CLI。提交评审时才首次登记不可变语义版本：
 
 ```bash
 node .workflow/tools/state/state.mjs artifact register \
   --expected-revision 0 \
   --id ART-PRODUCT-001 \
   --artifact-type product-baseline \
-  --path .workflow/iterations/ITER-01/02-product-definition/product-baseline.yaml \
-  --node 02-product-definition \
-  --status draft \
+  --path .workflow/iterations/ITER-01/01-product-shaping/product-baseline.yaml \
+  --node 01-product-shaping \
+  --status submitted \
   --version 1.0.0 \
   --producer-skill ai-delivery-define-product
 ```
 
-更新生命周期：
+批准、拒绝、冻结、失败或内容变化时，创建新文件和新 ID，并引用被替代 revision：
 
 ```bash
-node .workflow/tools/state/state.mjs artifact status \
+node .workflow/tools/state/state.mjs artifact register \
   --expected-revision 1 \
-  --id ART-PRODUCT-001 \
+  --id ART-PRODUCT-002 \
+  --path .workflow/iterations/ITER-01/01-product-shaping/product-baseline-v2.yaml \
+  --node 01-product-shaping \
   --status approved \
-  --evidence GATE-B-DECISION-001
+  --version 2.0.0 \
+  --supersedes ART-PRODUCT-001
 ```
 
-已登记内容发生变化时，创建新文件和新 ID：
+`draft` 和 `review-draft` 不得登记。新登记的 submitted、rejected、approved、frozen、failed 和 superseded revision 都不可原地修改；`artifact status` 只用于把升级前已登记的遗留 draft 携带 evidence 一次性迁移为正式状态。`--path` 必须是项目相对路径，以 `.workflow/` 开头，且真实文件不能通过符号链接逃逸。重复 ID、重复受控版本和正式 revision 重写会被拒绝。成功命令会原子提交 delta 分片、当前 registry 和 JSONL 索引；任一目标无法暂存或替换时立即回滚。若进程在提交窗口中断，`inspect` 和 `verify` 会拒绝读取半提交状态；重试 mutation 或运行 `rebuild` 会先恢复 journal，再继续命令。
+
+可信 history anchor 建立后，可先零写入预览可裁剪的 artifact shard：
 
 ```bash
-node .workflow/tools/state/state.mjs artifact register \
-  --expected-revision 2 \
-  --id ART-PRODUCT-002 \
-  --path .workflow/iterations/ITER-01/02-product-definition/product-baseline-v2.yaml \
-  --node 02-product-definition \
-  --status draft \
-  --version 2.0.0 \
-  --supersedes ART-PRODUCT-001
+node .workflow/tools/state/state.mjs artifact prune
+node .workflow/tools/state/state.mjs artifact prune --apply
 ```
 
-`--path` 必须是项目相对路径，以 `.workflow/` 开头，且真实文件不能通过符号链接逃逸。重复 ID、重复受控版本、无 evidence 的状态变更和 terminal 状态重写会被拒绝。
+默认命令只返回计划，不创建目录、receipt 或时间戳。只有显式 `--apply` 才删除 anchor 已覆盖的 `.workflow/control/events/artifact-registry/` 分片，并在 `.workflow/control/retention/artifact-registry/<anchor-id>.yaml` 写入一条带 checksum 的保留决策；anchor 后的分片和 JSONL 边界继续保留。裁剪后 `verify --history` 返回 `retained-history`，从最新可信 anchor 验证剩余链，不再声称重新审计了已删除的前缀；`rebuild` 同样从 anchor 快照开始 replay。
+
+legacy full-snapshot history 需要保留可重放原字节时，不使用 prune，而由发行包执行独立 compact：
+
+```bash
+ai-delivery compact <project-root> --dry-run
+ai-delivery compact <project-root>
+```
+
+dry-run 严格零写入，返回 anchor、revision 覆盖范围、原历史根摘要、loose/archive 字节数和预计净释放空间。apply 把 anchor 覆盖的 legacy `after_value` shards 写入 `.workflow/control/archives/history/artifact-registry/<anchor-id>.json.gz`，manifest 绑定 bundle checksum、每个原文件、coverage 和锚定 registry checksum。CLI 从落盘 bundle 解压并完整 replay，只有 replay checksum 与 anchor 完全一致才移除 loose shards；失败时不移除任何 loose history。压缩后 `verify --history` 返回 `compacted-history` 并重新校验 archive、entry、anchor 与 replay；第一条后续 delta 从 anchor 的记录链头继续。
+
+版本归档前由 `task-state.mjs archive-version` 内部调用以下只读投影；通常不需要人工单独执行：
+
+```bash
+node .workflow/tools/state/state.mjs snapshot references --iteration-id ITER-01 --candidate-id CAND-01
+```
+
+该命令在正式读锁内统一验证最新 pointer、anchor 和快照，只返回 scope manifest、candidate、Gate decision 与 history anchor 的相对 JSON Pointer 和 checksum。任何缺失都会使归档在写文件和移除活动任务前失败；任务脚本不得自行解析 anchor 或写入 `null` 正式引用。
 
 ## 6. 流程和 Gate 命令
 
 启动与完成节点：
 
 ```bash
-node .workflow/tools/state/state.mjs transition --expected-revision 0 --event node-started --iteration-id ITER-01 --node 02-product-definition
-node .workflow/tools/state/state.mjs transition --expected-revision 1 --event node-completed --iteration-id ITER-01 --node 02-product-definition --evidence ART-PRODUCT-002
+node .workflow/tools/state/state.mjs transition --expected-scope-revision 0 --event node-started --iteration-id ITER-01 --node 01-product-shaping
+node .workflow/tools/state/state.mjs transition --expected-scope-revision 1 --event node-completed --iteration-id ITER-01 --node 01-product-shaping --evidence ART-PRODUCT-002
 ```
 
-阻塞与解除阻塞必须提供原因。新迭代使用 `iteration-started` 和规划 evidence。候选与发布分别使用 `candidate-selected`、`release-selected` 和已登记的不可变制品 ID。
+阻塞与解除阻塞必须提供原因。新迭代使用 `iteration-started` 和规划 evidence。候选与发布分别使用 `candidate-selected`、`release-selected` 和已登记的不可变制品 ID。凡 transition 或 Gate 消费已登记 evidence，workflow 与 artifact 两个 aggregate 会共享同一事务 ID 提交；交接后 artifact registry revision 已前进，下一条物料命令必须重新 `inspect`。
 
 版本完成和发布归档还需要两个里程碑事件。它们不启动发布，只把已由节点和物料证明的事实写入审计状态：
 
 ```bash
 node .workflow/tools/state/state.mjs transition \
-  --expected-revision <revision> \
+  --expected-scope-revision <development-scope-revision> \
   --event version-closed \
   --iteration-id <version-id> \
   --artifact-id <closeout-artifact-id>
 
 node .workflow/tools/state/state.mjs transition \
-  --expected-revision <revision> \
+  --expected-scope-revision <release-scope-revision> \
   --event release-archived \
   --iteration-id <release-id> \
   --artifact-id <release-archive-artifact-id> \
   --production-version-id <version-id>
 ```
 
-`version-closed` 要求 `12-version-closeout` 已完成，且物料来自该节点并处于 `release-ready`；它更新 `latest_line_version_id`。`release-archived` 要求 `R10-release-archive` 已完成，且物料来自该节点并处于 `released`；它更新 `production_version_id` 和 `production_release_id`。三个字段的权威来源都是 `workflow-state.yaml`，不得直接编辑；`project.yaml` 中的旧字段只用于兼容读取。
+`version-closed` 要求 `06-version-closeout` 已完成，且物料来自该节点并处于 `release-ready`；它更新 `latest_line_version_id`。`release-archived` 要求 `R10-release-archive` 已完成，且物料来自该节点并处于 `released`；它更新 `production_version_id` 和 `production_release_id`。三个字段的权威来源都是 `workflow-state.yaml`，不得直接编辑；`project.yaml` 中的旧字段只用于兼容读取。
 
 Gate 请求：
 
 ```bash
 node .workflow/tools/state/state.mjs gate request \
-  --expected-revision 1 \
+  --expected-scope-revision 1 \
   --gate-id GATE-B \
   --iteration-id ITER-01 \
-  --node 02-product-definition \
+  --node 01-product-shaping \
   --evidence ART-PRODUCT-002
 ```
 
@@ -152,7 +226,7 @@ Gate 决定：
 
 ```bash
 node .workflow/tools/state/state.mjs gate decide \
-  --expected-revision 2 \
+  --expected-scope-revision 2 \
   --gate-id GATE-B \
   --decision approved \
   --actor human:product-manager \
@@ -160,11 +234,13 @@ node .workflow/tools/state/state.mjs gate decide \
   --evidence ART-PRODUCT-002
 ```
 
-决定必须保留请求时的全部 evidence，并明确记录 `actor` 和 `rationale`。AI 文本、Hook、查看器操作或命令成功不能替代批准。非视觉体验范围把 UX Gate 设为 `not-required` 时，还必须附加来自 `02-product-definition`、状态成功且 `artifact_type` 包含 `terminal` 的已登记证据；推荐统一使用 `product-terminal-scope`。
+决定必须保留请求时的全部 evidence，并明确记录 `actor` 和 `rationale`。AI 文本、Hook、Manager 页面成功提示或命令成功不能替代正式批准凭证。非视觉体验范围把 UX Gate 设为 `not-required` 时，还必须附加来自 `01-product-shaping`、状态成功且 `artifact_type` 包含 `terminal` 的已登记证据；推荐统一使用 `product-terminal-scope`。
+
+`UX-LF` 已从当前契约退役。新的 request 和 decide 会在写入前拒绝；历史记录仍可 inspect、verify 和 rebuild。升级 dry-run 会在 `contract_retirement.affected_iterations` 中列出开放 scope 的 pending `UX-LF`，正式升级由 `system:package-upgrade` 追加 `gate-contract-retired` 事件和 checksum 回执，不创建人工 Gate 决定，也不改写关闭迭代或归档。
 
 ## 7. revision 冲突与失败恢复
 
-每个 mutation 都必须传 `--expected-revision`。收到 revision conflict 时：
+物料 mutation 必须传 `--expected-revision`；transition 和 Gate mutation 必须传 owning scope 的 `--expected-scope-revision`。旧 workflow 调用可继续使用顶层 `--expected-revision`，但不得与新参数同时使用。独立 development/release writer 最多等待可识别的当前提交 30 秒后分别成功；同一 scope 的过期 writer 必须 fail-closed。transition/Gate 的 evidence 交接也会增加 artifact registry revision，不得在其后复用旧的 artifact revision。收到 revision conflict 时：
 
 1. 停止当前写入，不自动递增数字重试。
 2. 重新运行 `inspect`。
@@ -173,14 +249,14 @@ node .workflow/tools/state/state.mjs gate decide \
 5. 使用新的当前 revision 执行经过重新确认的命令。
 6. 运行 `verify`。
 
-`verify` 失败时，根据错误修复物料或控制面。物料 checksum 不一致通常表示登记后被修改，应恢复原文件或创建新版本；audit checksum 不一致表示正式状态文件可能绕过脚本被修改，应从可信审计、版本控制和交付证据恢复，不能继续流转。
+`verify` 失败时，根据错误修复物料或控制面。物料 checksum 不一致通常表示登记后被修改，应恢复原文件或创建新版本；audit checksum 不一致表示正式状态文件可能绕过脚本被修改，应从可信审计、版本控制和交付证据恢复，不能继续流转。只有显式历史审计才运行 `verify --history`；缺少历史分片、分片 revision 不连续或分片元数据不一致都必须停止并审阅，不得用日常校验结果替代。
 
 ## 8. 生产阶段
 
-研发与发布使用两个独立状态域：`development_state.scope_id` 由 `iteration-started` 建立，`release_state.scope_id` 由用户明确发布后执行 `release-started` 建立。两者分别保存局部 revision、活动/阻塞/完成节点、Gate、节点尝试次数和选定物料；顶层 `workflow_state.revision` 仍用于 `--expected-revision` 和审计串行化。
+研发与发布使用两个独立状态域：`development_state.scope_id` 由 `iteration-started` 建立，`release_state.scope_id` 由用户明确发布后执行 `release-started` 建立。两者分别保存局部 revision、活动/阻塞/完成节点、Gate、节点尝试次数和选定物料；局部 revision 用于 workflow 乐观并发，顶层 `workflow_state.revision` 只负责审计串行化并保留旧参数兼容。
 
 `node-started` 会验证流程图前置条件。当前迭代未执行的前置节点，可以用来自该节点且处于成功状态的已登记基线物料作为 evidence；这用于后续迭代只重访受影响基线。重新打开已完成节点必须提供 `--reason`，并产生新的节点尝试，旧 Gate 决定不能批准新一轮输出。
 
-`node-completed` 只接受成功状态物料，并检查当前尝试的必需 Gate：`GATE-A`、`GATE-B`、`UX-LF`、`UX-VS`、`UX-UI` 和 `PRODUCTION-APPROVAL`。只有确实无视觉交互的体验范围可以依据产品终端证据把 UX Gate 决定为 `not-required`；Gate A、Gate B 和生产审批必须为 `approved`。历史 `12-release-preparation` 至 `16-version-archive` 只允许登记和读取审计物料，新的 transition 和 Gate 命令会拒绝这些节点。
+`node-completed` 只接受成功状态物料，并检查当前尝试的必需 Gate：`GATE-A`、`GATE-B`、`UX-VS`、`UX-UI` 和 `PRODUCTION-APPROVAL`。只有确实无视觉交互的体验范围可以依据产品终端证据把活动 UX Gate 决定为 `not-required`；Gate A、Gate B 和生产审批必须为 `approved`。历史 `12-release-preparation` 至 `16-version-archive` 只允许登记和读取审计物料，新的 transition 和 Gate 命令会拒绝这些节点。
 
-版本收尾、每个发布节点交接、生产审批、部署和发布归档前必须运行 `verify`。新研发流程使用 `12-version-closeout` 和 `release-ready`；完成该节点后通过 `version-closed` 记录累计研发版本，但不得创建任何 R 节点。独立发布使用 `R00-release-request` 至 `R10-release-archive`；启动 R00 时必须提供节点为 R00、状态成功且 `artifact_type: release-request` 的显式用户请求物料。R09 只产生生产验证结论，R10 完成并登记 `released` 归档物料后，才通过 `release-archived` 正式回写生产版本和 release ID。发布选择只能引用精确不可变 `version-ready` Tag 和已登记版本物料，生产审批只发生在 R07，并绑定精确 release ID、包 checksum、镜像 digest、配置、迁移、环境和回滚镜像；任一项变化均创建新发布候选并重新审批。
+每个节点交接、生产审批和部署前运行日常 `verify`；版本收尾和发布归档还必须运行 `verify --history`。新研发流程使用 `06-version-closeout` 和 `release-ready`；完成该节点后通过 `version-closed` 记录累计研发版本，但不得创建任何 R 节点。独立发布使用 `R00-release-request` 至 `R10-release-archive`；启动 R00 时必须提供节点为 R00、状态成功且 `artifact_type: release-request` 的显式用户请求物料。R09 只产生生产验证结论，R10 完成并登记 `released` 归档物料后，才通过 `release-archived` 正式回写生产版本和 release ID。发布选择只能引用精确不可变 `version-ready` Tag 和已登记版本物料，生产审批只发生在 R07，并绑定精确 release ID、包 checksum、镜像 digest、配置、迁移、环境和回滚镜像；任一项变化均创建新发布候选并重新审批。