release-skill 0.3.0 → 0.4.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "release-skill",
-  "version": "0.3.0",
+  "version": "0.4.0",
   "description": "Safe preparation and frozen GitHub/npm production publishing with full happy end verification",
   "author": {
     "name": "广州市风荷科技有限公司"

package/references/01-state-machine.md

@@ -48,7 +48,7 @@
 | PUBLISHING | PUBLISHED | 所有检查点成功 |
 | PUBLISHING | PARTIAL | 至少一个检查点成功但后续失败 |
 | PUBLISHING | BLOCKED | 外部服务阻断且无法继续 |
-| PUBLISHED | VERIFIED | `verify` 全部通过 |
+| PUBLISHED | VERIFIED | `verify` 的远端、npm、Claude/Codex 等自动化检查全部通过；新计划中的 Kimi/CodeBuddy 人工安装任务不由系统核验且不阻塞该状态 |
 | PUBLISHED | POST_PUBLISH_VERIFY_FAILED | 发布后验证失败（保留 PUBLISHED 事实但标记验证失败） |
 | NEEDS_INPUT | DISCOVERED | 用户提供输入后重新开始评估 |
 | NEEDS_INPUT | ASSESSED | 用户提供输入后恢复评估 |

package/references/06-adapter-contract.md

@@ -108,13 +108,14 @@
 | 查询插件状态 | observe | 检查插件是否可被发现 |
 | 验证安装性 | verify | 在全新环境中安装并验证插件可调用 |
 
-支持目标：Claude Code plugin marketplace、Codex plugin manifest/marketplace、Kimi Code（人工 attestation 闭环）、CodeBuddy/WorkBuddy（人工 attestation 闭环）。
+支持目标：Claude Code plugin marketplace、Codex plugin manifest/marketplace、Kimi Code（发布后人工安装任务）、CodeBuddy/WorkBuddy（发布后人工安装任务）。
 
-**CodeBuddy/WorkBuddy 接入形态（人工 attestation 闭环）**：目录名 `workbuddy` 与平台名 `codebuddy` 指同一目标——build adapter 目录保持 `adapters/workbuddy/`（由 build-adapters 生成的自包含分发适配器，清单 `.codebuddy-plugin/plugin.json`，组件位于插件根，技能以 `${CODEBUDDY_PLUGIN_ROOT}` 渲染），而 platform id / distributionType / actionType 分别为 `codebuddy` / `codebuddy-plugin` / `codebuddy-marketplace-install`。codebuddy CLI 的 `plugin marketplace add` 与 `plugin install` 均无 ref 选项、安装跟踪市场默认分支，**无法钉死冻结 ref**，自动化安装检查点无法保证冻结产物同一性，因此**不采用自动化安装检查点**，改与 Kimi Code 同级的人工 attestation 闭环：
+**Kimi/CodeBuddy/WorkBuddy 接入形态（非阻塞人工跟进）**：目录名 `workbuddy` 与平台名 `codebuddy` 指同一目标——build adapter 目录保持 `adapters/workbuddy/`（由 build-adapters 生成的自包含分发适配器，清单 `.codebuddy-plugin/plugin.json`，组件位于插件根，技能以 `${CODEBUDDY_PLUGIN_ROOT}` 渲染），而 platform id / distributionType / actionType 分别为 `codebuddy` / `codebuddy-plugin` / `codebuddy-marketplace-install`。Kimi 没有可脚本化安装接口；codebuddy CLI 的 `plugin marketplace add` 与 `plugin install` 均无 ref 选项、安装跟踪市场默认分支，无法可靠核验冻结产物同一性。因此新计划设置 `humanConsumersStrategy: manualFollowUps`：
 
-- `execute` 不 exec 任何 codebuddy 命令，写出绑定冻结计划摘要与身份的手动安装 requirement（声明桌面端/CLI 双安装通道与统一市场 `ifoohoo/artifact-skill-set`），检查点失败关闭、run 置 `PARTIAL`（其余自动化外写先完成）。
-- 操作者经 **WorkBuddy 桌面端统一市场**（`ifoohoo/artifact-skill-set`，落点 `~/.workbuddy/plugins/marketplaces/artifact-skill-set/plugins/<plugin>/`）或 **codebuddy CLI**（隔离 `HOME` 下 `plugin marketplace add https://github.com/ifoohoo/artifact-skill-set` 再 `plugin install <plugin>@artifact-skill-set`）安装；因无法钉死 ref，出具 attestation 前必须核实已安装清单版本等于冻结版本。
-- `observe`/`verify` 仅消费结构化人工 attestation 并只读核验安装点 manifest：校验 `planDigest`/`payloadDigest` 绑定、`consumer==='codebuddy'`、`installChannel`（`desktop`/`cli`）与 `marketplace`、按通道校验 `installPath` 布局，以及时间窗（`attestedAt` 不在未来、`expiresAt` 在 `attestedAt` 后 24 小时内且未过期），任一不符即 fail-closed；缺失或失配证明时 CodeBuddy 单元绝不进入 `VERIFIED`，与 Kimi 同阶（发布后验证不可豁免）。
+- `publish` 不执行 Kimi/CodeBuddy 安装，也不因其尚未安装进入 `PARTIAL`；自动化发布完成后进入 `PUBLISHED`，并返回含平台、插件、版本和安装说明的 `manualFollowUps`。
+- `verify` 跳过这两个平台的安装核验，为每个任务返回 `verifiedBySystem: false`；任务完成与否不改变自动化发布的 `VERIFIED` 状态，系统不得声称已验证其安装。
+- 操作者可在发布完成后经 Kimi 交互安装、WorkBuddy 桌面市场或 codebuddy CLI 安装；这是团队待办，不是 release-skill 门禁。
+- 缺少 `humanConsumersStrategy` 的旧冻结计划继续按历史 attestation 契约读取证明，避免升级后破坏进行中的旧发布；`attest` 只用于该兼容路径。
 
 **外部独立市场形态（claude/codex）**：distribution 声明可选字段 `marketplaceRepo`（`owner/name`）即启用外部形态，marketplace 索引与插件仓库解耦：
 

package/schemas/release-plan.schema.json

@@ -988,6 +988,13 @@
       "type": "string",
       "description": "Overall snapshot digest across all units"
     },
+    "humanConsumersStrategy": {
+      "type": "string",
+      "enum": [
+        "manualFollowUps"
+      ],
+      "description": "Human consumer strategy marker. 'manualFollowUps': Kimi/CodeBuddy installations are non-blocking post-release manual tasks; verify returns VERIFIED with manualFollowUps list and does not block on attestation. Absent: legacy attestation closed loop (backward compatibility)."
+    },
     "digest": {
       "type": "string",
       "minLength": 1

package/schemas/release-run.schema.json

@@ -432,6 +432,49 @@
         }
       }
     },
+    "manualFollowUps": {
+      "type": "array",
+      "description": "Non-blocking manual follow-up tasks for human consumer platforms (Kimi/CodeBuddy) when plan declares humanConsumersStrategy: 'manualFollowUps'",
+      "items": {
+        "type": "object",
+        "required": [
+          "actionId",
+          "platform",
+          "plugin",
+          "verifiedBySystem"
+        ],
+        "additionalProperties": false,
+        "properties": {
+          "actionId": {
+            "type": "string",
+            "minLength": 1
+          },
+          "platform": {
+            "type": "string",
+            "enum": [
+              "kimi",
+              "codebuddy"
+            ]
+          },
+          "plugin": {
+            "type": "string"
+          },
+          "version": {
+            "type": "string"
+          },
+          "unitId": {
+            "type": "string"
+          },
+          "verifiedBySystem": {
+            "const": false,
+            "description": "Always false — these tasks are not verified by the system"
+          },
+          "reason": {
+            "type": "string"
+          }
+        }
+      }
+    },
     "skillResourceClosureReceipts": {
       "type": "array",
       "description": "Per-surface skill resource closure verification receipts from verify phase",

package/skills/release-help/SKILL.md

@@ -35,12 +35,12 @@ description: "Discoverable entry point for release-skill: dependency and environ
 node "${CLAUDE_PLUGIN_ROOT}/bin/release-skill.mjs" help --json
 node "${CLAUDE_PLUGIN_ROOT}/bin/release-skill.mjs" setup --root <path> --json
 node "${CLAUDE_PLUGIN_ROOT}/bin/release-skill.mjs" assess --root <path> --offline --json
-# 日常发布快速路径：最多两个授权摘要，状态文件可恢复
+# 日常发布快速路径：仅在发布前确认一次可读计划摘要，状态文件可恢复
 node "${CLAUDE_PLUGIN_ROOT}/bin/release-skill.mjs" ship --root <path> --target-version <version> --json
 # 开发阶段执行声明 hooks 并生成 prepare 可复用的内容绑定收据
-node "${CLAUDE_PLUGIN_ROOT}/bin/release-skill.mjs" hooks validate --root <path> \
-  --acknowledge-hook-side-effects --json
-# Kimi/CodeBuddy 安装完成后记录人工事实，不手改 JSON
+# 命令调用本身即授权执行配置中的 hooks
+node "${CLAUDE_PLUGIN_ROOT}/bin/release-skill.mjs" hooks validate --root <path> --json
+# 仅旧冻结计划兼容：记录历史 Kimi/CodeBuddy 人工证明
 node "${CLAUDE_PLUGIN_ROOT}/bin/release-skill.mjs" attest --root <path> \
   --platform <kimi|codebuddy> --plugin <id> --result <passed|failed> --actor <person> --json
 # 发布文档刷新：默认只读演练
@@ -59,7 +59,7 @@ node "${CLAUDE_PLUGIN_ROOT}/bin/release-skill.mjs" docs refresh --unit <id> \
 - **只读演练**：`docs refresh --unit <id> --json` 输出逐文件相对路径、locale、新旧摘要、`version`、`locales`、`inputDigest`、`refreshDigest` 和 `nextCommand.argv`；候选无变化时 `status: "clean"`。
 - **确认写入**：必须同时提供 `--write`、精确 `--confirm-refresh <refreshDigest>` 和 `--ack-local-document-write`，全部目标作为一个事务提交；成功后立即复演必须为 `clean`。
 
-**授权边界**：本地发布文档写入授权只覆盖声明的本地文档目标，不是 hook、Git 提交、push、publish 或安装的授权。写入后必须审阅、提交，再重新 prepare。
+**授权边界**：本地发布文档写入授权只覆盖声明的本地文档目标，不是 Git 提交、push、publish 或安装的授权。hook/gate 由对应命令调用直接授权。写入后必须审阅、提交，再重新 prepare。
 
 ## 故障路由
 

package/skills/release-prepare/SKILL.md

@@ -13,9 +13,7 @@ description: Freeze an immutable release plan with local configuration, document
 
 运行项目构建/测试 hook，生成公开快照并扫描泄漏，冻结不可变发布计划。prepare 自身不调用发布 adapter，但会执行用户配置的 hook。hook 是任意本地进程，不受文件系统/网络隔离，可能产生项目目录外的副作用或远端写入。
 
-**Hook 授权门**: 当项目配置含任何 hook 时，prepare 默认失败关闭并展示将执行的 executable/args/cwd。只有显式传入 `--acknowledge-hook-side-effects`（CLI）或 `hooksAuthorized: true`（API）才能执行。授权表示用户接受 hook 风险，不表示 hook 安全。
-
-**Gate 授权门**: 当项目含 `snapshot-verify` gate 时，prepare 同样默认失败关闭。逐项审阅后才可传入 `--acknowledge-gate-side-effects`（CLI）或 `verificationGatesAuthorized: true`（API）；gate 也没有操作系统或网络沙箱。
+**Hook 与 Gate 执行**: 命令调用本身即授权执行已配置的 hook 和 gate，不再设置额外人工授权环节。
 
 **阶段通过规则**: 本阶段的通过只能由 CLI exit code 0 和结构化状态码 `PREPARED` 确认。Agent 无权自行宣布计划冻结成功。
 
@@ -30,9 +28,8 @@ description: Freeze an immutable release plan with local configuration, document
 1. 使用插件根相对路径运行 CLI：`CLI="node ${CLAUDE_PLUGIN_ROOT}/bin/release-skill.mjs"`
 2. 配置含 `releaseDocuments` 时，先运行只读演练 `${CLI} docs refresh --unit <id> --json`；`status: "changes"` 时展示逐文件路径/语种/版本/`refreshDigest`，取得"本地发布文档写入"明确授权后才执行 `nextCommand.argv` 写入，审阅并提交刷新结果后再继续；`status: "clean"` 时直接进入 prepare
 3. 运行 `${CLI} prepare --root <path> --offline --json`
-4. 若遇到 hook/gate 授权门失败，分别展示命令和风险，获取授权后只增加实际需要的 `--acknowledge-hook-side-effects` / `--acknowledge-gate-side-effects`
-5. 检查 exit code 0，读取 JSON 返回的 immutable `planPath=plans/<planDigest>.json`，再从该文件读取 `status`、`units`、`externalActions`
-6. 向用户展示 targetVersion、externalActions、planDigest 和 planPath；后续 approve/publish 只能使用该 immutable planPath，等待确认后再 approve
+4. 检查 exit code 0，读取 JSON 返回的 immutable `planPath=plans/<planDigest>.json`，再从该文件读取 `status`、`units`、`externalActions`
+5. 向用户展示可读的 `approvalSummary`（版本、仓库/包、branch/tag、外部动作和例外）；`planDigest` 仅作为内部绑定字段，不要求用户复制或确认。后续 approve/publish 只能使用该 immutable planPath，等待确认后再 approve
 
 若用户明确要求 GitHub+npm 生产发布，加入 `--production`。该模式还会封存独立
 Git commit/tree 和 npm tarball，并把路径、SHA/integrity、branch/tag 写入计划。
@@ -63,24 +60,18 @@ node "${CLAUDE_PLUGIN_ROOT}/bin/release-skill.mjs" docs refresh --unit <id> \
 node "${CLAUDE_PLUGIN_ROOT}/bin/release-skill.mjs" prepare --root <path> --offline --json
 # 生产 happy end：bound 基线必须 online；远端目标唯一性仍由 publish 全局预检
 node "${CLAUDE_PLUGIN_ROOT}/bin/release-skill.mjs" prepare --root <path> --online --production --json
-# 项目含 hook 时需显式授权:
-node "${CLAUDE_PLUGIN_ROOT}/bin/release-skill.mjs" prepare --root <path> --offline --acknowledge-hook-side-effects --json
-# 项目含 snapshot gate 时另行显式授权:
-node "${CLAUDE_PLUGIN_ROOT}/bin/release-skill.mjs" prepare --root <path> --offline --acknowledge-gate-side-effects --json
 ```
 
 ## 执行顺序
 
 1. 校验配置 schema → 2. 版本解析与发布文档新鲜度门（只读，RELEASE_DOCS_STALE）→
-3. Hook 授权门 → 4. 运行 hooks 并复检文档新鲜度 → 5. 捕获 Git baseline →
-6. 逐 unit 观察前序公开基线 → 7. 生成快照/扫描/README → 8. 原子写入 plan
+3. 运行 hooks 并复检文档新鲜度 → 4. 捕获 Git baseline →
+5. 逐 unit 观察前序公开基线 → 6. 生成快照/扫描/README → 7. 原子写入 plan
 
 ## 故障路由
 
 | 错误码 | 处理 |
 |---|---|
-| GATE_FAILED (hook 授权) | 向用户展示 hook 命令和风险，获得授权后加 `--acknowledge-hook-side-effects` 重试 |
-| GATE_FAILED (gate 授权) | 向用户展示 snapshot gate 命令和风险，获得授权后加 `--acknowledge-gate-side-effects` 重试 |
 | GATE_FAILED (bound + offline) | 改用 `--online --production`，不得把 unobserved-offline plan 交给 publish |
 | GATE_FAILED (前序基线漂移) | 先取得并比较实际远端内容；人工选择 merge/adopt/reject。merge/adopt 都必须把接受内容落回 human-owned 权威源，并把 `previousPublicBaseline` 更新为接受状态的精确 repo/ref/commit 后重新 online production prepare；reject 停止调查，禁止改 `mode: none` 绕过 |
 | GATE_FAILED (`npm-entry-closure`) | 修复打包内容或入口声明后重新 prepare；不得用 `requiredPublicFiles`/`smokeBin` 缺省绕过 |
@@ -94,4 +85,4 @@ node "${CLAUDE_PLUGIN_ROOT}/bin/release-skill.mjs" prepare --root <path> --offli
 
 ## 后续引导
 
-计划冻结后，读取命令返回的 immutable `planPath` 展示给用户，等待确认后再 approve。`release-plan.json` 等 latest alias 只用于浏览，不得作为生产 authority 传递。
+计划冻结后，读取命令返回的 immutable `planPath` 和 `approvalSummary` 展示给用户，等待确认后再 approve。`planDigest` 由系统自动计算和绑定，不作为人工交互口令。`release-plan.json` 等 latest alias 只用于浏览，不得作为生产 authority 传递。

package/skills/release-publish/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: release-publish
-description: 从已批准且摘要确认的生产计划发布冻结 Git branch/tag、npm tarball 与 GitHub Release，并执行已配置的 Claude/Codex marketplace 隔离消费者安装检查以达到 PUBLISHED；随后必须路由 release-verify 才可能达到 VERIFIED；遇到冲突或不确定远端状态时失败关闭并要求人工介入
+description: 从已批准的生产计划发布冻结 Git branch/tag、npm tarball 与 GitHub Release，并执行已配置的 Claude/Codex marketplace 隔离消费者安装检查以达到 PUBLISHED；随后必须路由 release-verify 才可能达到 VERIFIED；遇到冲突或不确定远端状态时失败关闭并要求人工介入
 ---
 
 # release-publish
@@ -25,16 +25,15 @@ description: 从已批准且摘要确认的生产计划发布冻结 Git branch/t
 
 ## 授权门
 
-1. 展示 `planDigest`、版本、仓库/包名、branch/tag 和全部 actions。
-2. 必须存在未过期且绑定同一 digest 的 approval record。
-3. 用户必须明确提供 `--confirm-production <planDigest>`；Agent 不得代替用户猜测确认值。
-4. 只有 CLI exit code 0 且结构化状态为 `PUBLISHED` 才算外写阶段通过；随后必须运行 verify，只有 `VERIFIED` 才是完整终态。
+1. 展示可读的 `approvalSummary`：版本、仓库/包名、branch/tag、全部 actions 和例外。
+2. 必须存在未过期且由系统绑定同一内部 digest 的 approval record；批准后不再要求用户复制摘要做二次确认。
+3. 只有 CLI exit code 0 且结构化状态为 `PUBLISHED` 才算外写阶段通过；随后必须运行 verify，只有 `VERIFIED` 才是完整终态。
 
 ## 确定性执行
 
 ```bash
 node "${CLAUDE_PLUGIN_ROOT}/bin/release-skill.mjs" publish --root <path> --plan <plan-path> \
-  --approval <approval-path> --confirm-production <planDigest> --json
+  --approval <approval-path> --json
 ```
 
 执行顺序：全局只读预检 → 配置的公开分支（按三种 `branchStrategy` 执行）→ 必要时

package/skills/release-reconcile/SKILL.md

@@ -32,7 +32,7 @@ marketplace 隔离消费者 checkpoint，但只恢复到 `PUBLISHED`；最终 np
 1. 使用插件根相对路径运行 CLI，确认有 `--run` 路径（必需），且源 run 状态为 `PARTIAL`
 2. 运行 `node "${CLAUDE_PLUGIN_ROOT}/bin/release-skill.mjs" reconcile --root <path> --plan <plan-path> --run <run-path> --json`
 3. 检查 exit code 和结构化状态：`PUBLISHED`（恢复完成，待 verify）/ `PARTIAL`（需重试）/ `BLOCKED`（需人工决策）
-4. 若 PARTIAL 且需重试，加 `--approval`；生产计划还必须加 `--confirm-production <planDigest>`
+4. 若 PARTIAL 且需重试，加 `--approval`；批准记录由系统核验与冻结计划的内部摘要绑定，不再要求二次摘要确认
 
 ## 确定性脚本调用
 
@@ -42,7 +42,7 @@ node "${CLAUDE_PLUGIN_ROOT}/bin/release-skill.mjs" reconcile --root <path> --pla
 # verify
 node "${CLAUDE_PLUGIN_ROOT}/bin/release-skill.mjs" verify --root <path> --plan <plan-path> --run <reconcile-run-path> --json
 # 重试（需 --approval）
-node "${CLAUDE_PLUGIN_ROOT}/bin/release-skill.mjs" reconcile --root <path> --plan <plan-path> --run <run-path> --approval <approval-path> --confirm-production <planDigest> --json
+node "${CLAUDE_PLUGIN_ROOT}/bin/release-skill.mjs" reconcile --root <path> --plan <plan-path> --run <run-path> --approval <approval-path> --json
 ```
 
 ## 幂等跳过逻辑

package/skills/release-verify/SKILL.md

@@ -17,7 +17,7 @@ verify 只接受 `PUBLISHED` 状态的源 run；`VERIFIED` 是终态，不会再
 
 ## 职责与边界
 
-验证远端所有 action 的实际状态与冻结计划一致。执行精确 `<package>@<version>` npm 安装到隔离目录，验证包名、版本、静态入口闭包，并在配置时验证 bin 路径安全和 CLI 烟雾输出。对每个声明的 marketplace distribution 执行全新隔离消费者安装验证。
+验证远端所有自动化 action 的实际状态与冻结计划一致。执行精确 `<package>@<version>` npm 安装到隔离目录，验证包名、版本、静态入口闭包，并在配置时验证 bin 路径安全和 CLI 烟雾输出。对 Claude/Codex marketplace distribution 执行全新隔离消费者安装验证。新计划中的 Kimi/CodeBuddy 安装只返回 `manualFollowUps`，明确标记 `verifiedBySystem: false`，不阻塞 `VERIFIED`；缺少该策略字段的旧冻结计划继续走历史 attestation 兼容路径。
 
 **阶段通过规则**: 只有 CLI exit code 0 和结构化状态码 `VERIFIED` 才是完整终态。
 
@@ -28,7 +28,7 @@ verify 只接受 `PUBLISHED` 状态的源 run；`VERIFIED` 是终态，不会再
 ## 正向执行路径
 
 1. 确认有 `--run` 路径（必需），且源 run 状态为 PUBLISHED
-2. 使用插件根相对路径运行 CLI；若存在 consumer gate 或 npm `smokeBin`，先逐项审阅并增加 `--acknowledge-gate-side-effects`
+2. 使用插件根相对路径运行 CLI；命令调用本身即授权执行已配置的 verification gate 和 smoke process
 3. 检查 exit code 和结构化状态：`VERIFIED`（全部通过）/ 失败（具体错误）
 4. 只有 `VERIFIED` 才是 happy end
 
@@ -37,8 +37,6 @@ verify 只接受 `PUBLISHED` 状态的源 run；`VERIFIED` 是终态，不会再
 ```bash
 # 从插件根运行
 node "${CLAUDE_PLUGIN_ROOT}/bin/release-skill.mjs" verify --root <path> --plan <plan-path> --run <run-path> --json
-# 计划含 consumer gate 或 smokeBin 时：
-node "${CLAUDE_PLUGIN_ROOT}/bin/release-skill.mjs" verify --root <path> --plan <plan-path> --run <run-path> --acknowledge-gate-side-effects --json
 ```
 
 ## 验证步骤
@@ -47,7 +45,7 @@ node "${CLAUDE_PLUGIN_ROOT}/bin/release-skill.mjs" verify --root <path> --plan <
 2. 加载源 run，验证 planDigest 匹配和 checkpoint 完整性
 3. 对每个 plan action 执行 adapter.verify()（远端状态重检）
 4. 对每个 npm distribution 执行隔离安装烟雾测试
-5. 对每个 marketplace distribution 执行全新隔离消费者安装验证
+5. 对 Claude/Codex marketplace distribution 执行全新隔离消费者安装验证；收集 Kimi/CodeBuddy 的非阻塞 `manualFollowUps`
 6. 全部通过 → `VERIFIED`
 
 ## 烟雾测试
@@ -69,4 +67,4 @@ node "${CLAUDE_PLUGIN_ROOT}/bin/release-skill.mjs" verify --root <path> --plan <
 | 远端状态不匹配 | POST_PUBLISH_VERIFY_FAILED | 停止 |
 | npm 安装失败 | POST_PUBLISH_VERIFY_FAILED | 停止 |
 | CLI 烟雾输出不匹配 | POST_PUBLISH_VERIFY_FAILED | 停止 |
-| consumer gate / smokeBin 未授权 | GATE_FAILED | 展示命令和副作用，人工确认后加 `--acknowledge-gate-side-effects` |
+| consumer gate / smokeBin 执行失败 | GATE_FAILED | 检查失败原因，修复后重试 |

package/skills-src/release-help/SKILL.md

@@ -35,12 +35,12 @@ description: "Discoverable entry point for release-skill: dependency and environ
 node "${CLAUDE_PLUGIN_ROOT}/bin/release-skill.mjs" help --json
 node "${CLAUDE_PLUGIN_ROOT}/bin/release-skill.mjs" setup --root <path> --json
 node "${CLAUDE_PLUGIN_ROOT}/bin/release-skill.mjs" assess --root <path> --offline --json
-# 日常发布快速路径：最多两个授权摘要，状态文件可恢复
+# 日常发布快速路径：仅在发布前确认一次可读计划摘要，状态文件可恢复
 node "${CLAUDE_PLUGIN_ROOT}/bin/release-skill.mjs" ship --root <path> --target-version <version> --json
 # 开发阶段执行声明 hooks 并生成 prepare 可复用的内容绑定收据
-node "${CLAUDE_PLUGIN_ROOT}/bin/release-skill.mjs" hooks validate --root <path> \
-  --acknowledge-hook-side-effects --json
-# Kimi/CodeBuddy 安装完成后记录人工事实，不手改 JSON
+# 命令调用本身即授权执行配置中的 hooks
+node "${CLAUDE_PLUGIN_ROOT}/bin/release-skill.mjs" hooks validate --root <path> --json
+# 仅旧冻结计划兼容：记录历史 Kimi/CodeBuddy 人工证明
 node "${CLAUDE_PLUGIN_ROOT}/bin/release-skill.mjs" attest --root <path> \
   --platform <kimi|codebuddy> --plugin <id> --result <passed|failed> --actor <person> --json
 # 发布文档刷新：默认只读演练
@@ -59,7 +59,7 @@ node "${CLAUDE_PLUGIN_ROOT}/bin/release-skill.mjs" docs refresh --unit <id> \
 - **只读演练**：`docs refresh --unit <id> --json` 输出逐文件相对路径、locale、新旧摘要、`version`、`locales`、`inputDigest`、`refreshDigest` 和 `nextCommand.argv`；候选无变化时 `status: "clean"`。
 - **确认写入**：必须同时提供 `--write`、精确 `--confirm-refresh <refreshDigest>` 和 `--ack-local-document-write`，全部目标作为一个事务提交；成功后立即复演必须为 `clean`。
 
-**授权边界**：本地发布文档写入授权只覆盖声明的本地文档目标，不是 hook、Git 提交、push、publish 或安装的授权。写入后必须审阅、提交，再重新 prepare。
+**授权边界**：本地发布文档写入授权只覆盖声明的本地文档目标，不是 Git 提交、push、publish 或安装的授权。hook/gate 由对应命令调用直接授权。写入后必须审阅、提交，再重新 prepare。
 
 ## 故障路由
 

package/skills-src/release-prepare/SKILL.md

@@ -13,9 +13,7 @@ description: Freeze an immutable release plan with local configuration, document
 
 运行项目构建/测试 hook，生成公开快照并扫描泄漏，冻结不可变发布计划。prepare 自身不调用发布 adapter，但会执行用户配置的 hook。hook 是任意本地进程，不受文件系统/网络隔离，可能产生项目目录外的副作用或远端写入。
 
-**Hook 授权门**: 当项目配置含任何 hook 时，prepare 默认失败关闭并展示将执行的 executable/args/cwd。只有显式传入 `--acknowledge-hook-side-effects`（CLI）或 `hooksAuthorized: true`（API）才能执行。授权表示用户接受 hook 风险，不表示 hook 安全。
-
-**Gate 授权门**: 当项目含 `snapshot-verify` gate 时，prepare 同样默认失败关闭。逐项审阅后才可传入 `--acknowledge-gate-side-effects`（CLI）或 `verificationGatesAuthorized: true`（API）；gate 也没有操作系统或网络沙箱。
+**Hook 与 Gate 执行**: 命令调用本身即授权执行已配置的 hook 和 gate，不再设置额外人工授权环节。
 
 **阶段通过规则**: 本阶段的通过只能由 CLI exit code 0 和结构化状态码 `PREPARED` 确认。Agent 无权自行宣布计划冻结成功。
 
@@ -30,9 +28,8 @@ description: Freeze an immutable release plan with local configuration, document
 1. 使用插件根相对路径运行 CLI：`CLI="node ${CLAUDE_PLUGIN_ROOT}/bin/release-skill.mjs"`
 2. 配置含 `releaseDocuments` 时，先运行只读演练 `${CLI} docs refresh --unit <id> --json`；`status: "changes"` 时展示逐文件路径/语种/版本/`refreshDigest`，取得"本地发布文档写入"明确授权后才执行 `nextCommand.argv` 写入，审阅并提交刷新结果后再继续；`status: "clean"` 时直接进入 prepare
 3. 运行 `${CLI} prepare --root <path> --offline --json`
-4. 若遇到 hook/gate 授权门失败，分别展示命令和风险，获取授权后只增加实际需要的 `--acknowledge-hook-side-effects` / `--acknowledge-gate-side-effects`
-5. 检查 exit code 0，读取 JSON 返回的 immutable `planPath=plans/<planDigest>.json`，再从该文件读取 `status`、`units`、`externalActions`
-6. 向用户展示 targetVersion、externalActions、planDigest 和 planPath；后续 approve/publish 只能使用该 immutable planPath，等待确认后再 approve
+4. 检查 exit code 0，读取 JSON 返回的 immutable `planPath=plans/<planDigest>.json`，再从该文件读取 `status`、`units`、`externalActions`
+5. 向用户展示可读的 `approvalSummary`（版本、仓库/包、branch/tag、外部动作和例外）；`planDigest` 仅作为内部绑定字段，不要求用户复制或确认。后续 approve/publish 只能使用该 immutable planPath，等待确认后再 approve
 
 若用户明确要求 GitHub+npm 生产发布，加入 `--production`。该模式还会封存独立
 Git commit/tree 和 npm tarball，并把路径、SHA/integrity、branch/tag 写入计划。
@@ -63,24 +60,18 @@ node "${CLAUDE_PLUGIN_ROOT}/bin/release-skill.mjs" docs refresh --unit <id> \
 node "${CLAUDE_PLUGIN_ROOT}/bin/release-skill.mjs" prepare --root <path> --offline --json
 # 生产 happy end：bound 基线必须 online；远端目标唯一性仍由 publish 全局预检
 node "${CLAUDE_PLUGIN_ROOT}/bin/release-skill.mjs" prepare --root <path> --online --production --json
-# 项目含 hook 时需显式授权:
-node "${CLAUDE_PLUGIN_ROOT}/bin/release-skill.mjs" prepare --root <path> --offline --acknowledge-hook-side-effects --json
-# 项目含 snapshot gate 时另行显式授权:
-node "${CLAUDE_PLUGIN_ROOT}/bin/release-skill.mjs" prepare --root <path> --offline --acknowledge-gate-side-effects --json
 ```
 
 ## 执行顺序
 
 1. 校验配置 schema → 2. 版本解析与发布文档新鲜度门（只读，RELEASE_DOCS_STALE）→
-3. Hook 授权门 → 4. 运行 hooks 并复检文档新鲜度 → 5. 捕获 Git baseline →
-6. 逐 unit 观察前序公开基线 → 7. 生成快照/扫描/README → 8. 原子写入 plan
+3. 运行 hooks 并复检文档新鲜度 → 4. 捕获 Git baseline →
+5. 逐 unit 观察前序公开基线 → 6. 生成快照/扫描/README → 7. 原子写入 plan
 
 ## 故障路由
 
 | 错误码 | 处理 |
 |---|---|
-| GATE_FAILED (hook 授权) | 向用户展示 hook 命令和风险，获得授权后加 `--acknowledge-hook-side-effects` 重试 |
-| GATE_FAILED (gate 授权) | 向用户展示 snapshot gate 命令和风险，获得授权后加 `--acknowledge-gate-side-effects` 重试 |
 | GATE_FAILED (bound + offline) | 改用 `--online --production`，不得把 unobserved-offline plan 交给 publish |
 | GATE_FAILED (前序基线漂移) | 先取得并比较实际远端内容；人工选择 merge/adopt/reject。merge/adopt 都必须把接受内容落回 human-owned 权威源，并把 `previousPublicBaseline` 更新为接受状态的精确 repo/ref/commit 后重新 online production prepare；reject 停止调查，禁止改 `mode: none` 绕过 |
 | GATE_FAILED (`npm-entry-closure`) | 修复打包内容或入口声明后重新 prepare；不得用 `requiredPublicFiles`/`smokeBin` 缺省绕过 |
@@ -94,4 +85,4 @@ node "${CLAUDE_PLUGIN_ROOT}/bin/release-skill.mjs" prepare --root <path> --offli
 
 ## 后续引导
 
-计划冻结后，读取命令返回的 immutable `planPath` 展示给用户，等待确认后再 approve。`release-plan.json` 等 latest alias 只用于浏览，不得作为生产 authority 传递。
+计划冻结后，读取命令返回的 immutable `planPath` 和 `approvalSummary` 展示给用户，等待确认后再 approve。`planDigest` 由系统自动计算和绑定，不作为人工交互口令。`release-plan.json` 等 latest alias 只用于浏览，不得作为生产 authority 传递。

package/skills-src/release-publish/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: release-publish
-description: 从已批准且摘要确认的生产计划发布冻结 Git branch/tag、npm tarball 与 GitHub Release，并执行已配置的 Claude/Codex marketplace 隔离消费者安装检查以达到 PUBLISHED；随后必须路由 release-verify 才可能达到 VERIFIED；遇到冲突或不确定远端状态时失败关闭并要求人工介入
+description: 从已批准的生产计划发布冻结 Git branch/tag、npm tarball 与 GitHub Release，并执行已配置的 Claude/Codex marketplace 隔离消费者安装检查以达到 PUBLISHED；随后必须路由 release-verify 才可能达到 VERIFIED；遇到冲突或不确定远端状态时失败关闭并要求人工介入
 ---
 
 # release-publish
@@ -25,16 +25,15 @@ description: 从已批准且摘要确认的生产计划发布冻结 Git branch/t
 
 ## 授权门
 
-1. 展示 `planDigest`、版本、仓库/包名、branch/tag 和全部 actions。
-2. 必须存在未过期且绑定同一 digest 的 approval record。
-3. 用户必须明确提供 `--confirm-production <planDigest>`；Agent 不得代替用户猜测确认值。
-4. 只有 CLI exit code 0 且结构化状态为 `PUBLISHED` 才算外写阶段通过；随后必须运行 verify，只有 `VERIFIED` 才是完整终态。
+1. 展示可读的 `approvalSummary`：版本、仓库/包名、branch/tag、全部 actions 和例外。
+2. 必须存在未过期且由系统绑定同一内部 digest 的 approval record；批准后不再要求用户复制摘要做二次确认。
+3. 只有 CLI exit code 0 且结构化状态为 `PUBLISHED` 才算外写阶段通过；随后必须运行 verify，只有 `VERIFIED` 才是完整终态。
 
 ## 确定性执行
 
 ```bash
 node "${CLAUDE_PLUGIN_ROOT}/bin/release-skill.mjs" publish --root <path> --plan <plan-path> \
-  --approval <approval-path> --confirm-production <planDigest> --json
+  --approval <approval-path> --json
 ```
 
 执行顺序：全局只读预检 → 配置的公开分支（按三种 `branchStrategy` 执行）→ 必要时

package/skills-src/release-reconcile/SKILL.md

@@ -32,7 +32,7 @@ marketplace 隔离消费者 checkpoint，但只恢复到 `PUBLISHED`；最终 np
 1. 使用插件根相对路径运行 CLI，确认有 `--run` 路径（必需），且源 run 状态为 `PARTIAL`
 2. 运行 `node "${CLAUDE_PLUGIN_ROOT}/bin/release-skill.mjs" reconcile --root <path> --plan <plan-path> --run <run-path> --json`
 3. 检查 exit code 和结构化状态：`PUBLISHED`（恢复完成，待 verify）/ `PARTIAL`（需重试）/ `BLOCKED`（需人工决策）
-4. 若 PARTIAL 且需重试，加 `--approval`；生产计划还必须加 `--confirm-production <planDigest>`
+4. 若 PARTIAL 且需重试，加 `--approval`；批准记录由系统核验与冻结计划的内部摘要绑定，不再要求二次摘要确认
 
 ## 确定性脚本调用
 
@@ -42,7 +42,7 @@ node "${CLAUDE_PLUGIN_ROOT}/bin/release-skill.mjs" reconcile --root <path> --pla
 # verify
 node "${CLAUDE_PLUGIN_ROOT}/bin/release-skill.mjs" verify --root <path> --plan <plan-path> --run <reconcile-run-path> --json
 # 重试（需 --approval）
-node "${CLAUDE_PLUGIN_ROOT}/bin/release-skill.mjs" reconcile --root <path> --plan <plan-path> --run <run-path> --approval <approval-path> --confirm-production <planDigest> --json
+node "${CLAUDE_PLUGIN_ROOT}/bin/release-skill.mjs" reconcile --root <path> --plan <plan-path> --run <run-path> --approval <approval-path> --json
 ```
 
 ## 幂等跳过逻辑

package/skills-src/release-verify/SKILL.md

@@ -17,7 +17,7 @@ verify 只接受 `PUBLISHED` 状态的源 run；`VERIFIED` 是终态，不会再
 
 ## 职责与边界
 
-验证远端所有 action 的实际状态与冻结计划一致。执行精确 `<package>@<version>` npm 安装到隔离目录，验证包名、版本、静态入口闭包，并在配置时验证 bin 路径安全和 CLI 烟雾输出。对每个声明的 marketplace distribution 执行全新隔离消费者安装验证。
+验证远端所有自动化 action 的实际状态与冻结计划一致。执行精确 `<package>@<version>` npm 安装到隔离目录，验证包名、版本、静态入口闭包，并在配置时验证 bin 路径安全和 CLI 烟雾输出。对 Claude/Codex marketplace distribution 执行全新隔离消费者安装验证。新计划中的 Kimi/CodeBuddy 安装只返回 `manualFollowUps`，明确标记 `verifiedBySystem: false`，不阻塞 `VERIFIED`；缺少该策略字段的旧冻结计划继续走历史 attestation 兼容路径。
 
 **阶段通过规则**: 只有 CLI exit code 0 和结构化状态码 `VERIFIED` 才是完整终态。
 
@@ -28,7 +28,7 @@ verify 只接受 `PUBLISHED` 状态的源 run；`VERIFIED` 是终态，不会再
 ## 正向执行路径
 
 1. 确认有 `--run` 路径（必需），且源 run 状态为 PUBLISHED
-2. 使用插件根相对路径运行 CLI；若存在 consumer gate 或 npm `smokeBin`，先逐项审阅并增加 `--acknowledge-gate-side-effects`
+2. 使用插件根相对路径运行 CLI；命令调用本身即授权执行已配置的 verification gate 和 smoke process
 3. 检查 exit code 和结构化状态：`VERIFIED`（全部通过）/ 失败（具体错误）
 4. 只有 `VERIFIED` 才是 happy end
 
@@ -37,8 +37,6 @@ verify 只接受 `PUBLISHED` 状态的源 run；`VERIFIED` 是终态，不会再
 ```bash
 # 从插件根运行
 node "${CLAUDE_PLUGIN_ROOT}/bin/release-skill.mjs" verify --root <path> --plan <plan-path> --run <run-path> --json
-# 计划含 consumer gate 或 smokeBin 时：
-node "${CLAUDE_PLUGIN_ROOT}/bin/release-skill.mjs" verify --root <path> --plan <plan-path> --run <run-path> --acknowledge-gate-side-effects --json
 ```
 
 ## 验证步骤
@@ -47,7 +45,7 @@ node "${CLAUDE_PLUGIN_ROOT}/bin/release-skill.mjs" verify --root <path> --plan <
 2. 加载源 run，验证 planDigest 匹配和 checkpoint 完整性
 3. 对每个 plan action 执行 adapter.verify()（远端状态重检）
 4. 对每个 npm distribution 执行隔离安装烟雾测试
-5. 对每个 marketplace distribution 执行全新隔离消费者安装验证
+5. 对 Claude/Codex marketplace distribution 执行全新隔离消费者安装验证；收集 Kimi/CodeBuddy 的非阻塞 `manualFollowUps`
 6. 全部通过 → `VERIFIED`
 
 ## 烟雾测试
@@ -69,4 +67,4 @@ node "${CLAUDE_PLUGIN_ROOT}/bin/release-skill.mjs" verify --root <path> --plan <
 | 远端状态不匹配 | POST_PUBLISH_VERIFY_FAILED | 停止 |
 | npm 安装失败 | POST_PUBLISH_VERIFY_FAILED | 停止 |
 | CLI 烟雾输出不匹配 | POST_PUBLISH_VERIFY_FAILED | 停止 |
-| consumer gate / smokeBin 未授权 | GATE_FAILED | 展示命令和副作用，人工确认后加 `--acknowledge-gate-side-effects` |
+| consumer gate / smokeBin 执行失败 | GATE_FAILED | 检查失败原因，修复后重试 |

package/src/commands/approve.mjs

@@ -54,7 +54,8 @@ function defaultClock() {
  *
  * @param {Object} options
  * @param {string} options.planPath - Absolute path to the frozen release plan.
- * @param {string} options.expectedDigest - Expected SHA-256 digest of the plan.
+ * @param {string} [options.expectedDigest] - Expected SHA-256 digest of the plan.
+ *   When omitted, the digest is computed from the immutable plan file.
  * @param {string} options.actor - Identity of the approver.
  * @param {number} [options.expiresInMs=86400000] - Approval validity in ms (default 24h).
  * @param {() => string} [options.clock] - Clock function returning ISO-8601 strings.
@@ -70,7 +71,7 @@ function defaultClock() {
 export async function approvePlan(options) {
   const {
     planPath,
-    expectedDigest,
+    expectedDigest: expectedDigestInput,
     actor,
     expiresInMs = 24 * 60 * 60 * 1000, // 24 hours
     clock,
@@ -83,9 +84,6 @@ export async function approvePlan(options) {
   if (!planPath || typeof planPath !== 'string') {
     throw new ReleaseError(PLAN_DIGEST_MISMATCH, 'planPath must be a non-empty string');
   }
-  if (!expectedDigest || typeof expectedDigest !== 'string') {
-    throw new ReleaseError(PLAN_DIGEST_MISMATCH, 'expectedDigest must be a non-empty string');
-  }
   if (!actor || typeof actor !== 'string') {
     throw new ReleaseError(GATE_FAILED, 'actor must be a non-empty string');
   }
@@ -119,7 +117,11 @@ export async function approvePlan(options) {
   const actualDigest = computePlanDigest(plan);
   assertImmutablePlanAuthority(planPath, plan);
 
-  // --- Step 3: Compare digests ---
+  // --- Step 3: Resolve expectedDigest ---
+  // When expectedDigest is omitted, auto-compute from the immutable plan file.
+  const expectedDigest = expectedDigestInput ?? actualDigest;
+
+  // --- Step 4: Compare digests ---
   if (actualDigest !== expectedDigest) {
     throw new ReleaseError(
       PLAN_DIGEST_MISMATCH,

package/src/commands/hooks.mjs

@@ -4,7 +4,7 @@ import { resolve } from 'node:path';
 import { loadProjectConfig } from '../core/config.mjs';
 import { createEvidenceWriter } from '../core/evidence.mjs';
 import { runDeclaredHooks } from './prepare.mjs';
-import { ReleaseError, GATE_FAILED } from '../core/errors.mjs';
+// ReleaseError and GATE_FAILED removed: no authorization gate remains.
 
 /**
  * Run the declared development gates and populate the exact same content-bound
@@ -14,16 +14,12 @@ import { ReleaseError, GATE_FAILED } from '../core/errors.mjs';
 export async function validateDeclaredHooks(options = {}) {
   const {
     root = process.cwd(),
-    hooksAuthorized,
+    hooksAuthorized: _hooksAuthorized,
     hookCache = true,
     runDir = resolve(root, '.release-skill', 'runs', `hooks-${Date.now()}`),
   } = options;
-  if (hooksAuthorized !== true) {
-    throw new ReleaseError(
-      GATE_FAILED,
-      'hooks validate executes declared project commands; pass --acknowledge-hook-side-effects',
-    );
-  }
+  // The command invocation itself authorizes execution of configured hooks.
+  // Old --acknowledge-hook-side-effects is accepted as a no-effect compatibility input.
   const { config, configDigest } = await loadProjectConfig({ root });
   await mkdir(runDir, { recursive: true });
   const evidence = createEvidenceWriter({