/release-verification

name: release-verification
description: 发布验证规范 — 覆盖版本、changelog、测试、pack、install smoke、commit/tag/push/publish 前确认与发布后 registry/tag 验收

Release Verification Skill

职责

当用户明确要求 release / tag / publish / 版本发布时，执行发布前后验证链。它只做验证和确认边界，不自动执行真实发布动作。

触发条件

| 场景 | 是否触发 | |------|:--------:| | 用户明确要求 `release` / `publish` / `tag` | 🔴 必须 | | 修改 package/plugin/version/changelog 口径 | 🟡 条件 | | 普通未发布实现批次 | N/A，默认写 `changelogs/unreleased.md` |

R0~R7 验证链

| 阶段 | 检查 | |------|------| | R0 | 确认目标版本、SemVer、tag 和 registry 唯一性；执行 `ReleaseAuthorityBeforeCompatibilityGate`，冻结 publishedState、consumerEvidence、authoritySources 与兼容决策 | | R1 | 将 `changelogs/unreleased.md` 归档到 `changelogs/releases/vX.Y.Z.md`，并更新根 `CHANGELOG.md` | | R2 | 同步 `package.json`、`package-lock.json`、`plugin.json`、Profile/README/website 版本口径；发布型 Profile 必须补齐 CI workflow/job 矩阵、tag/publish 触发链、失败恢复路径、外部消费者验证矩阵、dist 产物边界、registry/tag 验收与常见故障诊断；用户可交互发布面追加 `InteractiveSemanticProbe` | | R2a | 执行 `CandidateFreezeGate`：冻结 candidate identity/generation、授权 scope、允许进入当前 release 的 mutation class 与 evidence dependency graph；冻结后新发现的非 P0/P1、非发布阻断治理项进入下一版本 | | R3 | 执行 `npm test`（默认全链）| | R3a | 执行 `CandidateDiffCompletenessGate`：先清点 tracked/untracked/ignored 边界，再使用临时 `GIT_INDEX_FILE` 物化本次授权范围，禁止改写用户真实 index；对隔离 snapshot 执行 `git diff --cached --check`、`git diff --cached --name-status`、项目策略要求的 secret-shape scan 和 intended scope 对账；最后验证用户 index digest 与 staged set 前后不变。普通 `git diff --check` 不能替代本门禁 | | R3b | 执行 `npm run test:audit`，并完成 package completeness gate（`description`、`keywords`、`repository`、`homepage`、`bugs`、`license`、`files/exports/bin`、`publishConfig`、`engines`、`plugin.json` 元数据）；包边界检查必须在构建/benchmark/codegen 完成后单独串行执行；公开打包脚本必须执行 `PackagedScriptDependencyClosureGate`，递归核对本地 `require()`、`path.join(ROOT,'scripts',...)` 或等价运行时脚本依赖都进入 tarball | | R3c | 执行 `RemoteCIParityPushGate`：push / tag / release / publish 前先执行与远端 CI 同构的本地门禁；若项目存在远端 CI（如 GitHub Actions），确认目标 commit 对应 CI run 已完成且 conclusion 为 `success`；若存在独立消费者仓，再执行 `ConsumerValidationEngineeringGate`，证明 source event→consumer run、目标 SHA、身份新鲜度和全部适用分母 accepted；无远端 CI/消费者或无权限查询时必须写 `N/A + skipReason`，不得把普通测试通过替代 coverage、audit、examples、website、pack 或矩阵脚本 | | R3e | Skill portfolio / V92：`generate-skill-portfolio --check` 必须在**与 CI 同语义**下通过——consumer 扫描仅用 **git-tracked** 文件；禁止在含 untracked 杂项的脏树按「全盘 walk」生成并提交 `skills/portfolio.json`；push 前建议 `git worktree add --detach` 于目标 SHA 复跑 `--check` | | R3d | 执行 `ReleaseCriticalPathBudgetGate`、`ValidationEvidenceReuseGate` 与条件 `ReleaseReworkIncidentGate`；预算或复用不得削弱 immutable candidate、version、pack、registry 与 R7 证据 | | R4 | 执行 `npm pack --dry-run` 与 `npm publish --dry-run`（遵循当前 `publishConfig`），并执行 `NativeCommandExitCodeGate` | | R5 | 条件执行 pack install smoke，并执行 `IsolatedConsumerCwdGate`：显式 consumer manifest、真实 consumer cwd、source candidate identity 前后对账与真实命令退出码缺一不可 | | R6 | commit/tag/push/publish 前输出确认，真实发布动作必须等待用户**当前消息**明确确认（`SharedStateMutationGate` / PI-119）；一次历史发版授权不覆盖后续补丁 push；本会话自引入 CI 回归须先 `OwnIntroducedRegressionSelfFixGate` 本地修绿再进入 R6。负向：无用户确认却宣称「已 push」→ 违规；CI 自引入失败却「暂停不修」→ 违规（`classifyPushAuthorizationSample` / `classifyOwnIntroducedRegressionSample`） | | R7 | 发布后验证 git tag、registry 版本、安装包边界和 `node scripts/validate.js` |

PublisherCredentialTopologyGate

首次 publish、repository/owner/package name/registry/publisher/auth mode 变化、迁移发布 workflow，或用户要求“参考成功项目发布”时，必须在 R0~R3c 之间冻结发布凭据拓扑；普通 patch 且拓扑明确未变时可记录 `unchanged + evidence`，不得静默跳过。

| 字段 | 要求 | |------|------| | `publisherIdentity` | 实际发布主体/组织；不得包含 token 或 secret value | | `repositoryIdentity` | owner/repository、workflow 所在仓库与可访问边界 | | `packageIdentity` | package name、registry、package owner/access 与现存版本 | | `authMode` | `trusted-publishing / workflow-secret / local-token / other` | | `secretTopology` | 只记录 org/repo/environment/local scope、access policy 和传递/继承方式；禁止读取或复制 value | | `workflowPermissions` | OIDC/trusted publishing 所需最小权限；无 workflow 时 `N/A + skipReason` | | `referenceEvidence` | 参考成功仓库或最近成功 publish run 的身份、拓扑和结论；复制 YAML 不等于凭据等价 | | `topologyParity` | `aligned / mismatch / unverifiable`、阻断原因与恢复动作 |

GitHub Actions secrets 的 org/repo/environment scope、access policy 与 precedence 必须作为拓扑事实；reusable workflow 的显式 secret 传递或 `secrets: inherit` 只在平台允许的边界内成立。npm registry 采用 trusted publishing 时，按官方条件验证 OIDC、runner、Node/npm 与 `id-token: write`；其他 registry 不得机械套用 npm trusted publisher 结论。

ScopedRegistryResolutionGate

同一 scoped package 发布到多个 registry，或仓库/用户 `.npmrc` 已声明 `@scope:registry` 时，`--registry=<target>` 不能单独作为目标 registry 证据。每个 view/whoami/dry-run/publish/post-check 必须冻结 package scope、全局 registry、scope registry、userconfig 来源与命令级优先级，并以隔离 userconfig 或显式 `--@scope:registry=<target>` 绑定目标；双 registry 查询若返回完全相同版本集，先判定为可能被 scope 路由污染，禁止直接认定两个 registry 均已验证。

验证至少包含：默认配置下的污染复现、显式 scope override 后的目标 registry 结果、命令参数单测、真实退出码，以及不读取 token value 的 `whoami / package existence / ownership` 证据。npmjs primary 未通过身份与 scope 解析时，不得先发布 mirror 或创建 tag，避免半发布状态。

ReleaseAuthorityBeforeCompatibilityGate

| 字段 | 要求 | |------|------| | `publishedState` | `released / unreleased / unknown`；用 tag、registry、release note、public docs 和目标 commit 交叉证明 | | `consumerEvidence` | 稳定外部消费者、已公开示例/类型/配置、安装或升级路径；本地 fixture 不等于稳定消费者 | | `authoritySources` | 每条发布或未发布结论的权威来源、时间/版本与冲突处理 | | `decision` | released → 兼容/迁移评估；unreleased 且无稳定消费者 → 直接收敛 canonical contract；unreleased 但有产品取舍 → 用户决策；unknown → 阻断兼容结论 |

不得因为字段或行为曾在未发布分支、草稿文档、内部 fixture 或本地历史包中出现，就自动引入 alias、fallback 或迁移层。需要保留未发布兼容行为时，必须记录真实消费者证据或用户明确产品决策。

ReleaseEfficiencyControlGate

CandidateFreezeGate

在首次完整 qualification 前形成 `CandidateFreezeRecord`：

| 字段 | 要求 | |------|------| | `candidateIdentity` | commit/tree 或临时 staged snapshot digest、package version、pack-relevant inputs | | `candidateGeneration` | 每次冻结后 mutation 单调递增；旧 generation 证据不得冒充当前候选 | | `authorizedScope` | intended files、public surfaces、registry、target version 与明确排除项 | | `allowedMutationClasses` | `release-blocker / P0-P1 / approved-scope / deferred`；冻结后 deferred 不进入当前版本 | | `evidenceDep