openxiangda-skill-kit 2.0.0-alpha.29 → 2.0.0-alpha.30

package/docs/architecture/admin-shell-v2.md

@@ -996,7 +996,7 @@ flowchart LR
 
 - 单次提交/PR：`pnpm verify:affected`，Admin 阶段另跑 `pnpm --filter openxiangda-admin check test build`；浏览器交互实际变化时运行模板聚焦 Playwright。
 - 本地完整里程碑：`pnpm verify:local`，用真实 tarball 创建并销毁全新应用，执行 generate/check/test/Chromium/build，并验证持久 reference app、Skills 和文档；它是主动全量验收，不是每次保存文件的必跑项。
-- 正式候选：Changesets 经 `pnpm release:version` 物化并形成已推送的版本提交后，`pnpm release:publish` 冻结真实候选 tarball，再由机器生成并执行一次增量矩阵。每个候选始终在 monorepo 外的新应用完成 install/generate/check/test/build；只有 Admin/浏览器契约变化升级 Chromium，核心 SDK 变化增加临时 Verdaccio reference app，未知变化 fail closed 到全量。`pnpm verify:release` 仅用于无发布演练。
+- 正式候选：Changesets 经 `pnpm release:version` 物化并形成已推送的版本提交后，`pnpm verify:release` 冻结真实候选 tarball，再由机器生成并执行一次增量矩阵并留下验证凭据；`pnpm release:publish` 只消费相同凭据和字节。每个候选始终在 monorepo 外的新应用完成 install/generate/check/test/build；只有 Admin/浏览器契约变化升级 Chromium，核心 SDK 变化增加临时 Verdaccio reference app，未知变化 fail closed 到全量。
 - 周期审计或重大 alpha：`pnpm verify:release:full`。发包不回放 1.x 测试，也不为多个候选包重复运行同一浏览器路径。
 
 ## 14. 明确拒绝的方案

package/docs/architecture/implementation-roadmap.md

@@ -28,12 +28,12 @@
 | Workflow Kernel v2 | Kernel 状态机与平台持久实例；业务字段仍在 Data/App API | 已交付基线 | 同意/拒绝、转交、回退、撤回、加签、代理、两种退回语义、重新提交、长任务委托、Provider 恢复与并发 CAS/lease 真实链路通过 | 可视化编辑器和更多业务协议按独立需求设计；不把业务字段迁入流程库 |
 | 独立 NestJS 后端与应用交付 | 应用 Git/AppPackage；Platform Server DeploymentRun/Environment Head | 已交付功能基线，E4 激活边界待实现 | 不可变包摘要、后端 OCI digest、版本化 Kubernetes workload、readiness、重试/取消/回滚/晋级和资源限制已有证据 | 候选当前可能先取得可用 runtime credential，同进程 Worker/Scheduler 缺活动 Head lease，共享 NodePort 缺强路径证明。E4 以 pending credential、短租约、gateway assertion、failed candidate GC 收敛；仍保持每应用独立容器，不拆成多应用 Node 进程或强制三个 Deployment |
 | 2.0 CLI/MCP/Skills/模板 | 独立 `openxiangda-v2` 仓库与已发布 npm 工件 | 已交付基线 | 16 包 check/test/build、边界扫描、真实 tarball 新应用、持久 reference app、Chromium、Skills、文档全部通过；2026-08-15 再以 12 个候选 tarball 经临时本地 registry 安装到仓库外参考应用，生成、类型检查、单测、真实 NestJS OAuth2/Native 身份联调与生产构建全部通过；不调用 1.x | 新能力必须同时更新命令/MCP/Skill/模板消费证据，禁止只写 CLI 命令 |
-| 确定性工具链发布 | Changesets 版本提交、冻结工件清单、release receipt | 已交付 | 待消费 Changeset 在构建前 fail-fast；版本只由 Changesets 物化；正式发布只验证一次同一批 tarball；CLI alpha.20 与 skill-kit alpha.19 已按该状态机发布并打 Git tag | 周期性全量审计保留；不得恢复人工选包、手工版本或重复正式门禁 |
+| 确定性工具链发布 | Changesets 版本提交、冻结工件清单、release receipt | 已实现待发布 | `verify:release` 已成为唯一候选验证入口并产出绑定 HEAD/registry/模式/工件摘要的 `validated` receipt；`release:publish` 无凭据即拒绝写入，只复查不可变与并发条件并可按阶段恢复，不再调用正式门禁或写 reference 仓库；38 个状态/工件/渠道策略测试、工作区单写者门禁与文档/Skill 构建通过，详见[发布验证凭据](./release-verification-receipt-v2.md) | 物化并发布本轮 Skill Kit 候选，以真实“verify 一次→publish 复用 receipt”记录闭环；公开包成功后再显式同步 reference lock |
 | 环境配置内核 E0-E6 | AppVersion/component revision + native Runtime Environment + minimal Environment Head + 环境运行态 | E1-C0/C1/S0/S1/T0 已完成 | breaking config/contracts v3、平台纯编译器、六领域不可变投影、聚合投影、AppVersion binding、compile receipt、精确 artifact shadow prepare 与真实 PostgreSQL 并发/来源防伪/绑定后不可变已经通过；全新 `openxiangda-v2-native-reference-app` 由候选 tarball 创建并完成 check/test/build，连续构建逐字节一致，config/contract v3 闭包和 artifact/manifest 篡改拒绝已进入发布门禁 | 下一步进入 A0 Native 环境授权；随后实现 Data physical/logical、最小 Head CAS、pending credential、调用委托/网关断言、runtime lease、候选 GC 与 generation cutover。旧 alpha 只留审计历史，不做双读、双写或导入 |
 | 授权内核 A0-N/C/P | 不可变 authz revision + 环境 authz state + native role/scope 表 | 已确认实施；N0/N1/N2/C1/C2/P 完成 | N1/C1 建立不可变定义、两环境 state 与原子版本；N2 建立独立 Native 运行表与局部撤权；C2 建立 DB-authoritative evaluator、request cache、环境/版本 cache namespace、边界 TTL 与 RelationshipGrant 直读；P 升级 `native-2` 配置契约并建立 source definition、projection state/job/receipt/value/closure/effective grant、Data API 与 membership 原子失效、冷启动恢复与 strict gate；89 个 SQL migration 校验、35 个 2.0 migration 真实 PostgreSQL 幂等应用、39 个平台套件 / 263 项测试和工具链全 workspace 测试通过 | 当前推进 N3-N5。alpha membership/grant 不复制、不迁移，禁止给 legacy 表补 environmentKey 或建立长期双读/双写 |
 | Ant Design Pro v6 Admin 全量切换 | Ant Design Pro v6 承担通用 Admin；`openxiangda-admin` 承担平台集成 | 已交付基线 | Vite/旧自研 Shell 与仪器示例已从模板删除；React 19、Ant Design 6、Umi Max 4、ProComponents 3、utoopack、ProLayout、ProTable、ProForm、Field Kit 和企业采购参考应用已落地。桌面 Chromium 单链路通过工作台、菜单、会话标签、稳定角色切换、列表/详情、独立供应商表单、工作中心、单按钮流程提交和个人中心；正式包已发布，仓库外参考应用使用 registry lock 构建，并以同一 AppPackage 完成 preproduction→production 晋级 | 移动用户端 Field Kit 已有独立 renderer；完整移动页面模板与设备 Chromium 验收另列后续主题，不回填到 PC Admin |
 | 前端动态挂载路径 | Platform Server 注入 runtime base；`openxiangda-admin` 适配 Umi basename | 已交付 | `openxiangda-admin@2.0.0-alpha.26` 与 `create-openxiangda@2.0.0-alpha.27` 已发布；参考应用的同一前端 digest 先部署 preproduction 再晋级 production。正式根入口和业务深链均返回 200、`application-v2`、production 环境修订和正确 runtime base，全部 JS/CSS 资源 200；Chrome 保持 `/view/openxiangda-v2-reference-app/` 并显示应用标题 | 后续路由能力只按独立需求增加；不改 hash history，不增加环境专用构建或第二套路由状态 |
-| 稳定字段值合同与服务端 UI 依赖边界 | `openxiangda-contracts` 拥有值形状；Field Kit 拥有 codec/平台控制器/renderer | 已实现待发布 | 稳定值类型已移到无依赖 contracts，Field Kit 保留前端重导出，模板 domain 删除 Field Kit；服务端依赖门禁与选择性 Docker 安装已落地。生产目录实测由约 253MB/195 包降至约 54MB/85 包，未含 Field Kit/React/Ant Design，瘦身产物可启动 Nest；49 项 affected task 通过，详见[稳定字段值合同与 UI 依赖边界](./field-value-contract-boundary.md) | 完成 Changesets 正式门禁与发布；registry 参考应用构建新 Docker 镜像，并用同一 AppPackage 完成线上 preproduction→production 验收 |
+| 稳定字段值合同与服务端 UI 依赖边界 | `openxiangda-contracts` 拥有值形状；Field Kit 拥有 codec/平台控制器/renderer | 已交付 | 稳定值类型已移到无依赖 contracts，Field Kit 保留前端重导出，模板 domain 删除 Field Kit；13 个对应 npm 候选已发布并打 Git tag。参考应用 amd64 镜像约 63.8MB、生产依赖 85 包且不含 Field Kit/React/Ant Design；同一 AppPackage 已完成 prod-1 preproduction→production 晋级，正式根路由、深链和六个首屏资源均返回 200，详见[稳定字段值合同与 UI 依赖边界](./field-value-contract-boundary.md) | 后续只按新字段合同或后端制品边界独立演进，不把 UI 运行时重新引入 Nest 镜像 |
 | Admin A1 RoleSession 上下文 | Native RoleSession bootstrap 是唯一身份资料/role subject/scope 来源 | 已设计待确认 | SubjectProfile 字段白名单、tenant 联合查询、非 active scope=null、capability=`authz.role-session-context`、有界 role subject 分页与切换 CAS 已定义 | A0 native cutover 后实现；A1 自身不再增加身份存储，但不得建立在 alpha 全局 assignment 上；平台先发，工具链后要求 capability |
 | Admin B0-O 租户公共 Origin | Platform Server Origin module + 版本/head/hostname claim registry | 已设计待确认 | 全仓确认多套模糊解析和广泛 URL 调用者；prod-1 证实 HTTPS/HTTP 配置差异、未登记 vhost 别名，且生产 `default_configs` 没有源码宣称的复合唯一约束；稳定租户 UUID、不可变 staged→challenge→verified→active、head revision CAS、hostname claim、事务审计、全局兼容阶段+单租户事实源状态、无长期双写和[逐文件实施蓝图](./tenant-public-origin-implementation-blueprint.md)已定义 | 确认后先做 O0 只读 inventory/digest 与 plan validator；操作者显式决定 migrate/decommission，所有服务实例同版后进入 migrating，再逐租户冻结/验证/切换，单租户失败不阻塞全平台；B0-R 不得绕过该阶段 |
 | Admin B0-C Cookie 安全 | Platform Server `AuthCookieService` + 无状态 policy resolver | 已设计待确认 | 已确认当前 DOMAIN JSON 同时决定 Cookie Domain 且 `secure:false`；共享会话/协议 Cookie 所有权、HTTPS Secure/`__Host-`/host-only、版本化名称、legacy scope manifest、C0/C1/C2 状态机和旧 host retirement 已定义 | B0-O registry 稳定后独立实现；首期不支持跨子域共享；C1 后只能回滚到理解 v2 Cookie 的兼容镜像，不和 Origin 数据迁移、return target 或 OAuth state 混发 |

package/docs/architecture/release-verification-receipt-v2.md

@@ -0,0 +1,72 @@
+# OpenXiangda 2.0 发布验证凭据
+
+状态：2026-08-16 决策确认，进入实现。
+
+## 问题证据
+
+一次工具链发布先显式执行了 `pnpm verify:release`，随后
+`pnpm release:publish` 又重新运行完整候选依赖闭包、全新应用、reference app、
+Skills 和文档门禁。13 个包已经写入 npm 后，发布命令又尝试修改独立 reference
+仓库的 lockfile，并因该仓库存在正常源码改动而以失败退出。registry 已经发生不可逆
+写入，但命令表面状态仍是失败，既浪费时间，也扩大了跨仓库并发和恢复歧义。
+
+## 能力所有者
+
+- `release-publish.mjs` 是工具链候选工件、验证凭据和 npm/Git 发布状态的唯一所有者。
+- Git `master` 是源码与版本清单事实源；冻结 tarball 是待发布字节事实源；npm 和 Git
+  tag 只保存已经发布的不可变结果。
+- 独立 reference app 只拥有自身源码和 lockfile。工具链发布器可在隔离副本中消费它做
+  验收，但不得在 npm 发布事务中修改其工作树。
+- AI、CLI 会话和 reference 仓库均不拥有发布状态，也不能临场选择版本、测试范围或
+  跳过门禁。
+
+## 稳定不变量与命令合同
+
+1. `pnpm verify:release` 是正式候选的准备与验证入口。它只打包一次，运行机器规划的
+   正式门禁，并留下 phase 为 `validated` 的凭据。
+2. 凭据绑定精确 Git HEAD、registry、普通/全量模式、候选包版本、工件清单摘要以及
+   每个 tarball 的 SHA-256、npm integrity 和字节数。
+3. `pnpm release:publish` 只接受同一提交的 `validated` 凭据；没有凭据或凭据仍为
+   `planned` 时在第一次 registry 写入前失败，并提示先执行对应 verify 命令。
+4. publish 重新检查主线、候选尚未被并发发布、dist-tag 可恢复状态和全部工件摘要，
+   但不重复 check/test/build、Chromium、reference、Skills 或文档门禁。
+5. `verify:release:full` 生成 full 凭据，只能由 `release:publish:full` 消费；普通与全量
+   模式不能交叉复用。
+6. reference 验收继续使用一次性 loopback registry 中的同一批冻结 tarball；发布后
+   lockfile 收敛由显式 `pnpm release:sync-reference` 完成，不影响 npm/Git 发布成功。
+7. 1.x 仓库、应用、流程、自动化和发布脚本不读取该凭据，也不进入本门禁。
+
+## 失败、并发与资源边界
+
+- 验证失败保留 `planned` 凭据和冻结工件，修复源码形成新提交后可安全废弃；同一提交
+  重试 verify 复用工件并重新执行尚未成功的正式门禁。
+- publish 在每个不可逆阶段前后原子写凭据。进程中断后，已发布且 integrity 一致的包
+  被跳过；内容不同、外部 dist-tag 漂移或 Git tag 指向其他提交时 fail closed。
+- 一旦进入 `publishing-packages`，凭据不能跨 Git 提交重建或丢弃；必须在原提交上恢复
+  到 npm 内容、dist-tag 和 Git tag 全部收敛。
+- reference 工作树脏、不可访问或锁文件尚未同步不再发生在 registry 事务内，因而不会
+  把“包已发布”伪装成“发布失败”。显式同步仍要求 reference 的 `master` 干净且与远端
+  一致。
+- 凭据和 tarball 位于 Git 私有目录，不进入应用包或 npm；文件权限为 0600。状态机不
+  持有 npm token、应用 Secret 或用户数据。验证次数从两次降为一次，不增加浏览器、
+  PostgreSQL 或临时 registry 的并发实例。
+
+## 受影响合同与回滚边界
+
+这是 2.0 工具仓维护命令的 breaking workflow change：发布者必须先 verify，再
+publish。公开 npm 包内容、应用运行时协议、Data API、Workflow 和平台数据库均不变。
+回滚单元仅包含发布脚本、测试、文档和 Skill；尚未写 registry 时可以整体回滚。开始
+写 registry 后只能依照原凭据向前恢复，不能用代码回滚覆盖已发布版本。
+
+## 可证伪验证
+
+1. 无凭据直接 publish 在任何 npm 写调用前失败。
+2. verify 成功后 receipt 为 `validated`，第二次 verify 不重跑门禁，publish 复用同一
+   manifest/tarball 并不调用 `release-validate.mjs`。
+3. 修改 HEAD、registry、full 模式、manifest 或任一 tarball 后，publish 在写入前失败。
+4. 在 `planned`、`validated`、`publishing-packages`、`packages-published`、
+   `dist-tags-synchronized` 注入中断，重试只执行允许的后续阶段。
+5. reference 仓库脏时，正式 publish 状态机测试仍可完成；显式 sync 单独给出清晰错误。
+6. release 脚本单测、边界扫描、2.0 受影响验证和模拟 registry 故障测试通过，测试不得
+   连接真实写权限 registry。
+

package/docs/architecture/repository-and-release.md

@@ -23,7 +23,7 @@
 1. 提交与 PR 使用 `pnpm verify:affected`，只运行受影响包及其依赖任务。
 2. 已评审 Changesets 先由 `pnpm release:version` 在干净且已同步远端的 `master` 上物化；人工只审核生成的版本、内部依赖与模板 BOM，不手改版本。版本 diff 必须提交并推送后才成为候选源码事实。
 3. 发布候选运行 `pnpm release:plan`，由真实候选 tarball 差异和包依赖图确定门禁；待消费 Changesets 未物化时在任何构建前失败。
-4. `pnpm release:publish` 从干净的远端 `master` 生成一次带摘要的候选工件清单；候选安装、reference 验证和 npm publish 复用相同 tarball，禁止重新打包，并且只执行一次正式验证。公开 registry 确认收到相同 tarball 后，发布命令会从公开包自动同步 reference 仓库锁文件并执行 frozen install；锁文件不再从发布前的临时 registry 生成。`pnpm verify:release` 只用于需要提前获得无发布验收证据的演练，不是正式发布前必须重复执行的步骤。
+4. `pnpm verify:release` 从干净的远端 `master` 生成一次带摘要的候选工件清单；候选安装和 reference 验证消费相同 tarball，只执行一次正式验证，并留下绑定 HEAD、registry、模式和工件摘要的 `validated` receipt。`pnpm release:publish` 没有该凭据就拒绝写 registry，只重复不可变与并发前置检查后发布同一批字节，不重新打包或重跑门禁。公开 registry 发布完成后，通过独立的 `pnpm release:sync-reference` 收敛 reference 仓库锁文件；跨仓库同步不属于 npm 发布事务。
    从源码创建候选 tarball 前，制品入口按候选包及其 workspace 依赖统一执行一次 Turbo 增量构建；不能直接打包工作区里可能过期的 `dist`。如果输入已经是带摘要的 release artifact manifest，则跳过构建并只消费冻结制品。
 5. 每次候选都在全新独立项目安装真实 tarball 并完成 generate/check/test/build；浏览器相关变化再执行完整 Chromium E2E。
 6. 平台集成测试部署到测试环境；只有平台协议或部署能力变更才需要阻塞核心发布。
@@ -42,8 +42,9 @@ reviewed Changesets
   -> immutable tarball/version preflight
   -> deterministic affected validation plan
   -> candidate closure + independent tarball verification
+  -> validated receipt
   -> npm publish of the exact validated tarballs
-  -> published reference lock synchronization + frozen install
+  -> explicit published reference lock synchronization + frozen install
   -> independent-project acceptance
   -> immutable promotion
 ```
@@ -54,7 +55,7 @@ Changeset，但包版本只能由 Changesets 物化，最终范围由 Git diff
 `master` 可审计提交，Git 中的 package.json、候选 tarball、npm 版本和 Git tag
 共同指向同一份源码事实。
 
-增量门禁不是按文件名随意跳测试：计划器读取 npm 当前版本和上一发布版本，解包并比较真实发行物。候选包和依赖闭包永远 check/test/build，候选 tarball 永远安装进全新应用。Admin 或浏览器契约变化触发 Chromium；核心 SDK/后端/Workflow 变化触发 reference app；Skill Kit 变化触发 Skill 与文档；未知包、没有可比较前版或显式 `--full` 一律运行完整矩阵。正式写 registry 前再次确认候选版本仍未被并发发布。
+增量门禁不是按文件名随意跳测试：计划器读取 npm 当前版本和上一发布版本，解包并比较真实发行物。候选包和依赖闭包永远 check/test/build，候选 tarball 永远安装进全新应用。Admin 或浏览器契约变化触发 Chromium；核心 SDK/后端/Workflow 变化触发 reference app；Skill Kit 变化触发 Skill 与文档；未知包、没有可比较前版或显式 `--full` 一律运行完整矩阵。`verify:release` 成功后固定门禁证据，正式写 registry 前只再次确认候选版本仍未被并发发布以及 receipt 和工件未变化。
 
 ## OAuth2 外部应用身份
 

package/docs/delivery.md

@@ -44,15 +44,15 @@ Changesets 管理各个 `openxiangda-*` 包、CLI、MCP 与 skill-kit 的独立
 
 版本物化是发布状态机的独立步骤：`pnpm release:version` 只允许在干净、已同步 `origin/master` 的 `master` 上运行，把尚未消费的评审 Changesets 确定性写入包版本、内部依赖和模板 BOM；它不提交、不发包。生成 diff 经审核、提交并推送后，才允许 `release:plan`、`verify:release` 或 `release:publish` 识别候选。这样 Git 中的版本清单是 npm 工件和 Git tag 的唯一源码事实，不使用临时目录里的虚拟版本，也不允许手工跳过物化。
 
-`release:publish` 在真正写 registry 前执行不可变版本门禁：未发布版本进入候选集；已经发布的版本则分别解包 registry 工件和当前本地包并逐文件比较。相同内容视为未变包，不重复发布；任何内容差异都必须先用 Changesets 产生新版本；没有新版本时拒绝空发布。发布范围、版本和是否允许写入由机器判定，不由 AI 临场决定。
+`verify:release` 在真正写 registry 前执行不可变版本门禁：未发布版本进入候选集；已经发布的版本则分别解包 registry 工件和当前本地包并逐文件比较。相同内容视为未变包，不重复发布；任何内容差异都必须先用 Changesets 产生新版本；没有新版本时拒绝空发布。`release:publish` 只消费该门禁形成的验证凭据。发布范围、版本和是否允许写入由机器判定，不由 AI 临场决定。
 
-发布入口只打包一次，并在 Git 私有目录写入绑定源码 `HEAD`、registry、包版本、字节数、SHA-256 与 npm SHA-512 integrity 的工件清单。全新应用、独立 reference app 与正式 npm publish 必须消费同一批 `.tgz`；任何字节或清单变化都会在写 registry 前失败。部分发布中断后可以从 receipt 继续：已经发布且 integrity 一致的包被跳过，不一致则停止。npm 在逐包写入时可能先推进预发布 tag；receipt 只接受这一个可恢复中间态，并在所有包确认后统一收敛最终 dist-tag 和 Git tag。
+`verify:release` 只打包一次，并在 Git 私有目录写入绑定源码 `HEAD`、registry、验证模式、包版本、字节数、SHA-256 与 npm SHA-512 integrity 的工件清单和 `validated` receipt。全新应用、独立 reference app 与正式 npm publish 必须消费同一批 `.tgz`；`release:publish` 没有对应凭据就拒绝写入，任何字节或清单变化也都会在写 registry 前失败。部分发布中断后可以从 receipt 继续：已经发布且 integrity 一致的包被跳过，不一致则停止。npm 在逐包写入时可能先推进预发布 tag；receipt 只接受这一个可恢复中间态，并在所有包确认后统一收敛最终 dist-tag 和 Git tag。
 
-`pnpm verify:local` 是日常可重复执行的全量验收入口。涉及本地 PostgreSQL 生命周期时，候选 tarball 只在 monorepo 外的新应用中运行一次 Chromium：生命周期门禁先通过受所有权校验的 reset 建立确定性数据库，再让同一浏览器套件同时经过 React、本地平台、NestJS 与 PostgreSQL；不会先跑 UI-only 再重复浏览器工作，也不会清理开发者现有应用的数据。正式候选在版本提交推送后由 `pnpm release:plan` 比较 npm 与本地 tarball，并比较候选与上一发布版本；漏升版或待消费 Changeset 会在昂贵测试前直接失败。`pnpm release:publish` 冻结一次候选工件，执行机器生成的增量计划，并在成功后发布同一批 tarball；候选依赖闭包永远完成 check/test/build，每个候选 tarball 都在 monorepo 外安装进全新生成应用并完成 generate/check/test/build。浏览器相关变化提升到真实 Chromium E2E，核心应用 SDK 变化增加持久 reference app，Skill/文档变化增加相应门禁。`pnpm verify:release` 提供相同规则的无发布演练，不能与正式发布组合成必须重复执行的双门禁。未知变化 fail-closed 到完整矩阵；`pnpm verify:release:full` 保留周期性全量审计。
+`pnpm verify:local` 是日常可重复执行的全量验收入口。涉及本地 PostgreSQL 生命周期时，候选 tarball 只在 monorepo 外的新应用中运行一次 Chromium：生命周期门禁先通过受所有权校验的 reset 建立确定性数据库，再让同一浏览器套件同时经过 React、本地平台、NestJS 与 PostgreSQL；不会先跑 UI-only 再重复浏览器工作，也不会清理开发者现有应用的数据。正式候选在版本提交推送后由 `pnpm release:plan` 比较 npm 与本地 tarball，并比较候选与上一发布版本；漏升版或待消费 Changeset 会在昂贵测试前直接失败。`pnpm verify:release` 冻结一次候选工件并执行机器生成的增量计划；候选依赖闭包永远完成 check/test/build，每个候选 tarball 都在 monorepo 外安装进全新生成应用并完成 generate/check/test/build。浏览器相关变化提升到真实 Chromium E2E，核心应用 SDK 变化增加持久 reference app，Skill/文档变化增加相应门禁。成功凭据随后由 `release:publish` 复用，发布命令不再重跑这些门禁。未知变化 fail-closed 到完整矩阵；周期审计使用匹配的 `verify:release:full` 与 `release:publish:full`。
 
 Playwright 浏览器使用官方缓存目录；`playwright install chromium` 已安装对应版本时是无操作。发包门禁不会额外运行 1.x 测试，也不会为每个包重复浏览器验收，而是在最终独立新应用上只运行一次完整用户路径。
 
-当计划要求 reference app 时，工具仓只把本次候选包发布到一次性、仅绑定 `127.0.0.1` 的 registry。每个候选包按精确包名注册为本地权威源且禁止回源，防止同版本公网包抢先占位或旧包被静默安装；未变化的包和普通依赖才继续从 npm 代理取得。验收副本不复用 reference worktree 的 lockfile，而是在临时目录从本轮 registry 生成一次 scratch-only lock，避免尚未物化新版本时相同预发布版本的旧 integrity 触发无意义重试；源仓锁文件不会被隐式修改。持久独立 reference app 再执行安装、契约生成、类型检查、单测、真实 NestJS 身份/Data API 进程验收和生产构建。`pnpm reference:install:from-build` 可在未公开发包时通过同一 registry 协议刷新 reference worktree 的本地依赖，避免 `file:`/`link:` 破坏独立性。
+当计划要求 reference app 时，工具仓只把本次候选包发布到一次性、仅绑定 `127.0.0.1` 的 registry。每个候选包按精确包名注册为本地权威源且禁止回源，防止同版本公网包抢先占位或旧包被静默安装；未变化的包和普通依赖才继续从 npm 代理取得。验收副本不复用 reference worktree 的 lockfile，而是在临时目录从本轮 registry 生成一次 scratch-only lock，避免尚未物化新版本时相同预发布版本的旧 integrity 触发无意义重试；源仓锁文件不会被隐式修改。持久独立 reference app 再执行安装、契约生成、类型检查、单测、真实 NestJS 身份/Data API 进程验收和生产构建。`pnpm reference:install:from-build` 可在未公开发包时通过同一 registry 协议刷新 reference worktree 的本地依赖，避免 `file:`/`link:` 破坏独立性。公开 npm integrity 的采用由发布成功后的 `pnpm release:sync-reference` 显式执行；reference 工作树状态不会参与 registry 事务。
 
 增量门禁先用 Turbo 完成候选包及其依赖闭包的 check/test/build；全量模式完成整个 workspace。后续生成契约、tarball 黑盒、技能校验和文档构建复用已验证的 `dist`。`distribution:smoke`、`skills:check`、`docs:build` 仍保留可独立执行的自包含入口。
 

package/docs/getting-started.md

@@ -70,10 +70,11 @@ pnpm verify:local
 pnpm release:version
 # review, commit and push the generated version diff
 pnpm release:plan
+pnpm verify:release
 pnpm release:publish
 ```
 
-`release:version` 不提交、不发包，只把 Changesets 确定的候选版本写入 Git 工作树；未完成这一步时，后续所有发布命令会在构建前失败。`release:plan` 会完成 npm 不可变性检查并比较候选包与上一发布版本的真实 tarball。`release:publish` 冻结一批带摘要的候选 tarball，只针对这批工件执行一次正式增量门禁，成功后再发布同一批字节；不会在发包前后重复跑同一测试。真实 PostgreSQL 生命周期门禁也只在本地平台、开发生命周期或相关模板发生变化时运行。需要提前做一次不写 registry 的演练时单独运行 `pnpm verify:release`，它不是正式发布的必选重复步骤。无法分类的新包或变化自动升级为全量验证，周期审计使用 `pnpm verify:release:full`。
+`release:version` 不提交、不发包，只把 Changesets 确定的候选版本写入 Git 工作树；未完成这一步时，后续所有发布命令会在构建前失败。`release:plan` 会完成 npm 不可变性检查并比较候选包与上一发布版本的真实 tarball。`verify:release` 冻结一批带摘要的候选 tarball，只针对这批工件执行一次正式增量门禁，并留下不可变验证凭据；`release:publish` 必须消费该凭据，只复查并发与摘要后发布同一批字节，不会重复测试。真实 PostgreSQL 生命周期门禁也只在本地平台、开发生命周期或相关模板发生变化时运行。无法分类的新包或变化自动升级为全量验证，周期审计使用配对的 `pnpm verify:release:full` 和 `pnpm release:publish:full`。发布后需要更新独立 reference 仓库时，再显式执行 `pnpm release:sync-reference`。
 
 ## OAuth2 应用身份
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "openxiangda-skill-kit",
-  "version": "2.0.0-alpha.29",
+  "version": "2.0.0-alpha.30",
   "description": "Validation and deterministic packaging for OpenXiangda 2.0 AI skills.",
   "type": "module",
   "main": "./dist/index.js",

package/skills/openxiangda-v2-delivery/SKILL.md

@@ -51,11 +51,15 @@ the monorepo into a newly generated application. Admin/browser changes require
 Chromium, core application SDK changes require the independent reference app,
 and Skill Kit changes require Skills/docs. Unknown or first-release packages
 fail closed to the full matrix. Run `pnpm verify:release:full` for the periodic
-complete audit. `pnpm release:publish` freezes one candidate artifact manifest,
-runs the formal gate once, and publishes those exact bytes. `pnpm
-verify:release` is a publish-free rehearsal, not a second mandatory step before
-`release:publish`. The final publish command repeats version availability before
-writing npm, so concurrent publication cannot invalidate the reviewed plan.
+complete audit. `pnpm verify:release` freezes one candidate artifact manifest,
+runs the formal gate once, and leaves a validated receipt bound to the exact
+HEAD, registry, mode and tarball digests. `pnpm release:publish` requires that
+receipt, repeats only immutable/concurrency preconditions, and publishes those
+exact bytes without rerunning the formal gate. Use `verify:release:full` only
+with `release:publish:full`. The final publish command repeats version
+availability before writing npm, so concurrent publication cannot invalidate
+the reviewed plan. It never modifies the independent reference worktree;
+`pnpm release:sync-reference` is an explicit post-publication repository task.
 `pnpm distribution:smoke` runs only this packed-distribution verification.
 Keep `strictDepBuilds: true` in the official workspace and template. Permit only
 reviewed dependency lifecycle scripts (`esbuild` today); never suppress the