release-skill 0.1.6 → 0.1.8

package/README.zh-CN.md

@@ -2,65 +2,31 @@
 
 [English](README.md) · 安装指南：[中文](INSTALL.zh-CN.md) / [English](INSTALL.md)
 
-<!-- release-skill:release-version: 0.1.6 -->
-面向 Claude Code 和 Codex 的发布准备工具，完整保留人工维护的文件内容。
+<!-- release-skill:release-version: 0.1.8 -->
+面向 Claude Code、Codex 和 Kimi Code 的发布准备工具，完整保留人工维护的文件内容。
 
-release-skill 帮助维护者回答三个问题：准备发布什么、还有哪些检查未通过、最终
-发布的字节究竟是什么。它先冻结并供人工审阅，再从同一份冻结制品发布，不会在
-最后一步重新生成 README、重新打包活动工作区或覆盖人工内容。
+release-skill 帮助维护者回答三个问题：准备发布什么、还有哪些检查未通过、最终发布的内容是什么。它先冻结并供人工审阅，再从同一份冻结产物发布，不会在最后一步重新生成 README、重新打包当前工作区或覆盖人工内容。
 
 <!-- release-skill:managed:start id=latest-release -->
-**0.1.6** (2026-07-22)
-
-v0.1.6 是一个发布准备版本，收口了 release-docs 自动化闭环。单一结构化发布说明源通过两阶段、摘要绑定的写入协议与 prepare 文档新鲜度门禁，确定性地驱动多语 CHANGELOG 与 README 刷新；同时终态事务收据被有界化，CLI 生命周期、路径安全与错误输出脱敏均得到加固。
-
-**新增**
-
-- **结构化发布说明驱动的文档刷新（`docs refresh`）**：单一结构化发布说明源
-  （`release-notes/0.1.6.yaml`）现在确定性地驱动受管 CHANGELOG 与 README 区域的
-  多语刷新。刷新以两阶段协议运行：只读计划阶段渲染每个候选并冻结一个
-  `inputDigest`（绑定规范化说明与说明源字节）以及一个 `refreshDigest`（绑定协议
-  版本、unit、version、配置投影与逐文件新旧摘要），写入阶段则仅在三项授权齐备
-  （`--write`、精确匹配的 `--confirm-refresh <refreshDigest>` 与
-  `--ack-local-document-write`）时才提交变更目标。写入阶段在独占锁下重新计划；
-  摘要分歧时收敛为 `RELEASE_DOCS_REFRESH_STALE` 且零写入，干净计划则是零写入的
-  空操作。prepare 文档新鲜度门禁使包版本与公开文档之间的版本漂移在发布计划冻结
-  之前失败关闭。
-- **有界化的终态事务收据与恢复安全**：终态（已提交 / 已回滚）事务现在持久化
-  仅含摘要的收据而非完整载荷，单个收据上限 256 KB（`TERMINAL_RECEIPT_SIZE_CAP`），
-  并受 50 条终态记录的保留上限约束（`DEFAULT_TRANSACTION_RETENTION_MAX`）。保留
-  裁剪只移除终态记录，永不裁剪 `RECOVERY_CONFLICT` 记录或任何非终态（与恢复相关）
-  的记录，因此即便达到数量上限也保留恢复证据；保留失败永不中止进行中的提交。
-- **严格的 `docs refresh` 参数验证（失败关闭）**：`docs` 命令在调用刷新服务
-  之前验证每个参数，因此即便没有项目配置或 safe-fs 后端，也能给出精确的稳定参数
-  错误。`--flag=value` 等号形式与空格分隔形式走完全相同的验证；重复参数在任何
-  服务调用、配置读取、加锁或事务之前即以 `DUPLICATE_PARAMETER` 失败关闭；裸位置
-  参数与单短横参数（如 `-w`）被识别为未识别而拒绝。未带 `--write` 的写入授权参数，
-  或授权不全的 `--write`，都以精确原因失败关闭，而非静默继续。
-
-**修复**
-
-- **bundle 入口生命周期以真实退出码收敛**：自包含 bundle 现在拥有命令生命
-  周期。其入口等待命令完成，并针对成功、业务错误、已处理的异步拒绝与未知命令以
-  真实业务退出码退出，使启动器不再遗留未结算的顶层 await（Node 退出码 13）。当
-  bundle 缺失或无法求值时，启动器仅以静态文本失败关闭，绝不插值机器相关路径、
-  用户名或主机布局，因为模块加载失败信息携带绝对路径。
-- **失败关闭的路径规范化与稳定诊断**：artifact 路径规范化要求 POSIX 分隔符，
-  并拒绝 POSIX（`/`）、Windows 盘符与 UNC 拼写的绝对路径，连同穿越、Windows 保留
-  设备名与冒号，以 `PATH_UNSAFE` 失败关闭，而不是把不安全拼写规范化为另一个公开
-  路径。错误输出脱敏现在区分真实文件系统路径与严格的 RFC 6901 JSON Pointer 诊断
-  坐标（如 `/units/0/version`）：绝对 POSIX/Windows/UNC 路径收敛为稳定的
-  `<redacted-path>` 占位符，而诊断指针按原样保留，使失败可诊断且不泄露主机路径。
-- **self 公开边界脱敏**：集中式脱敏权威（`core/redact.mjs`）现在闭合 self
-  公开边界，使运行时错误输出与 detail 结构绝不携带 release-skill 工作区自身的绝对
-  路径，也不携带 macOS `Users`、Linux home、macOS `private`/`var` 别名、temp 或 CI
-  检出等域。脱敏经由 `ReleaseError` 收口点失败关闭：任何两段及以上、以 `/` 开头且
-  非严格诊断 JSON Pointer 的 token 都被替换为 `<redacted-path>`，因此自我发布绝不
-  向公开输出泄露私有文件系统布局。
+**0.1.8** (2026-07-23)
+
+v0.1.8 在不改写已经公开的 v0.1.7 制品的前提下，新增对 Kimi Code 一等插件宿主的支持。由于 Kimi Code 没有可脚本化的非交互插件安装接口，Kimi 分发采用生成的自包含适配器，以及失败关闭、绑定冻结计划的人工安装证明。npm 包名（`release-skill`）、发布身份（`publisher: mzdbxqh`）、公开仓库（`ifoohoo/release-skill`）与公司维护主体均保持不变。
+
+**变更**
+
+- **Kimi Code 插件分发与验证**：v0.1.8 新增根
+  `.kimi-plugin/plugin.json`、生成的自包含 `adapters/kimi/` 适配器和公开安装说明。
+  由于 Kimi Code 没有可脚本化的非交互插件安装接口，生产发布会生成版本钉死的人工
+  安装要求并进入 `PARTIAL`；操作者必须在隔离的 `KIMI_CODE_HOME` 中完成安装，并
+  提供分别绑定冻结计划摘要和载荷摘要的可信证明，之后 `reconcile` 才能进入
+  `PUBLISHED`，`verify` 才能进入 `VERIFIED`。
+- **保留不可变的 v0.1.7 历史**：既有 v0.1.7 Git 标签、GitHub Release、npm
+  版本与公开提交均不改写。v0.1.8 生产计划以已公开的 v0.1.7 提交
+  `fe5897456d4166a2ec60e99405836b122562b80d` 作为前序公开基线。
 <!-- release-skill:managed:end id=latest-release -->
 
 <!-- release-skill:capability:external-write-boundary -->
-> **当前边界：** v0.1.6 是当前发布版本（v0.1.5 完成真实生产验证后曾处于这一状态）。
+> **当前边界：** v0.1.8 是当前发布版本（v0.1.7 曾处于已发布、待独立验证状态）。
 > v0.1.1 已完成 GitHub 与 npm 的
 > 真实生产发布，是首次生产验证的历史里程碑，并从冻结 Git ref 完成精确 npm
 > 安装及 Claude/Codex 消费者安装验证；“当前发布版本”与“首次生产验证里程碑”
@@ -73,7 +39,7 @@ v0.1.6 是一个发布准备版本，收口了 release-docs 自动化闭环。
 > 远端唯一性检查在 `publish` 全局预检执行。
 
 <!-- release-skill:capability:safe-first-command -->
-> **生产路径自 v0.1.1 里程碑起已完成真实生产验证；v0.1.6 是当前发布版本。**
+> **生产路径自 v0.1.1 里程碑起已完成真实生产验证；v0.1.8 是当前发布版本。**
 > npm 安装的 CLI 是受支持的用户入口；源码 checkout 保留为开发/贡献者路径。
 >
 > **第一条命令：**
@@ -89,33 +55,21 @@ v0.1.6 是一个发布准备版本，收口了 release-docs 自动化闭环。
 
 ## 为什么人工修改的 README 不会丢失
 
-release-skill 不重新生成、也不回写项目源文件。`prepare` 从当前工作区把每个公开文件复制
-到隔离的本地快照，并验证复制前后的字节。README 的 slogan、示例、正文、格式，
-以及后续任何人工修改都会作为完整文件被保留。
+release-skill 不重新生成、也不回写项目源文件。`prepare` 从当前工作区把每个公开文件复制到隔离的本地快照，并验证复制前后的字节。README 的 slogan、示例、正文、格式，以及后续任何人工修改都会作为完整文件被保留。
 
 - 后续 prepare 重新读取当前文件，不会从模板重建。
 - 快照必须与源文件逐字节一致。
 - 计划变化会产生新的 digest，旧批准不能授权新内容。
-- prepare 后再改源文件，publish 会因 baseline 变化在远端写入前停止。保留修改的
-  正确方式是重新 prepare、重新审阅并重新 approve。
+- prepare 后再改源文件，publish 会因 baseline 变化在远端写入前停止。保留修改的正确方式是重新 prepare、重新审阅并重新 approve。
 - 冻结制品被篡改时，publish 会因 snapshot/tarball/Git object 摘要不符停止。
 - 远端 branch、tag、Release 或 npm 版本冲突时交给人工；系统不 force、不覆盖。
-- 只有 `publicFiles` 明确列出的文件会被复制；需要发布的翻译 README、图片、
-  演示文件和链接文档都要显式加入配置。
-- 发布只冻结当前真相：`prepare` 不会刷新或重写人工文档。维护者必须先更新
-  README、INSTALL 与 CHANGELOG（包括必须与 `package.json` 版本一致的机器可读
-  `release-skill:release-version` 标记，以及当前包版本的正式 CHANGELOG 标题），
-  再 prepare、审阅和批准。任一文档版本标记或 CHANGELOG 当前版本条目漂移时，
-  发布前门禁失败关闭。
+- 只有 `publicFiles` 明确列出的文件会被复制；需要发布的翻译 README、图片、演示文件和链接文档都要显式加入配置。
+- 发布只冻结当前真相：`prepare` 不会刷新或重写人工文档。维护者必须先更新 README、INSTALL 与 CHANGELOG（包括必须与 `package.json` 版本一致的机器可读 `release-skill:release-version` 标记，以及当前包版本的正式 CHANGELOG 标题），再 prepare、审阅和批准。任一文档版本标记或 CHANGELOG 当前版本条目漂移时，发布前门禁失败关闭。
 
 保护规则只有一句话：**复制当前事实，冻结已审阅事实，不重写人工事实。**
 
 ## 快速开始
 
-下文每个只读步骤都把可能很大的报告保存在临时文件中，只展示确定性的
-`compactSummary`（紧凑摘要）审阅视图；紧凑摘要只是审阅辅助，不能替代绑定摘要
-授权。
-
 ### 安装 / 前置条件
 
 - Node.js 22+
@@ -142,8 +96,6 @@ release-skill help
 
 **开发安装（贡献者回退，从源码 checkout）：**
 
-设置源码路径并安装依赖：
-
 ```bash
 export RELEASE_SKILL_HOME=/absolute/path/to/release-skill
 cd "$RELEASE_SKILL_HOME"
@@ -159,11 +111,9 @@ npm exec --yes pnpm@10.17.1 -- install --frozen-lockfile
 !.release-skill/project.yaml
 ```
 
-### 首次接入：不加载完整报告的确定性流程
+### 首次接入
 
-setup 默认只读。可能很大的完整报告只写入临时文件；用户和 Agent 只查看确定性的
-`compactSummary`（紧凑摘要）审阅视图。紧凑摘要不能替代授权：`setupDigest` 仍绑定
-完整事实、候选和 answers。
+`setup` 默认只读。把完整报告写入临时文件，只查看确定性的 `compactSummary`（紧凑摘要）：
 
 ```bash
 PROJECT=/absolute/path/to/my-project
@@ -177,11 +127,9 @@ release-skill setup --root "$PROJECT" --json > "$REPORT" || test "$?" -eq 2
 node -e 'const fs=require("node:fs");const r=JSON.parse(fs.readFileSync(process.argv[1],"utf8"));if(!r.compactSummary){console.error("compactSummary missing");process.exit(2)}process.stdout.write(JSON.stringify(r.compactSummary,null,2)+"\n")' "$REPORT"
 ```
 
-`NEEDS_INPUT` 和 `LOCAL_ONLY_DETECTED` 按设计返回退出码 2。若
-`proposalConflicts` 非空，包括 `PUBLIC_REPO_AUTHORITY_CONFLICT` 或公开文件映射冲突，
-必须停止自动路径，由人工修正冲突的仓库或映射权威事实后重新运行 setup，不得猜测选边。
+`NEEDS_INPUT` 和 `LOCAL_ONLY_DETECTED` 按设计返回退出码 2。若 `proposalConflicts` 非空，必须停止自动路径，由人工修正冲突的仓库或映射权威事实后重新运行 setup，不得猜测选边。
 
-没有冲突时，只能机械提取机器提案；Agent 不得重写或逐项抄写：
+没有冲突时，机械提取机器提案：
 
 ```bash
 SETUP_SESSION='/上一步打印的会话目录绝对路径'
@@ -217,17 +165,11 @@ node -e 'const fs=require("node:fs");const [c,p,a]=process.argv.slice(1).map(x=>
 node -e 'require("node:fs").rmSync(process.argv[1],{recursive:true,force:false})' "$SETUP_SESSION"
 ```
 
-写入必须返回 `CONFIG_CREATED`，下一次 setup 必须返回 `ALREADY_CONFIGURED`。已有配置
-永不重新生成，后续只做经审阅的增量编辑。解释器/包管理器间接脚本会以
-`SIDE_EFFECTS_UNPROVEN` 排除，不会自动选择；项目特有 hook/gate 只有人工审阅后才
-增量加入：hook 编辑 `projectConfig.hooks`；gate 编辑 `verificationGates` 并将同一 id
-加入 `selectedGateIds`，随后重新运行绑定 dry-run。人工文件保持 `mode: preserve`；只有显式跨单元共享源才使用
-`sourceScope: workspace`。
+写入必须返回 `CONFIG_CREATED`，下一次 setup 必须返回 `ALREADY_CONFIGURED`。已有配置永不重新生成，后续只做经审阅的增量编辑。发现的解释器/包管理器脚本标记为 `SIDE_EFFECTS_UNPROVEN`，不会被自动选中。只有在人工审阅之后才添加项目专属的 hook 或 gate：编辑 `projectConfig.hooks`，或编辑 `verificationGates` 并把同一个 id 加入 `selectedGateIds`，然后重新运行绑定 dry-run。人工维护的文件保持 `mode: preserve`；只有明确的跨单元共享来源才使用 `sourceScope: workspace`。
 
-#### 进阶 schema 参考——不是首次接入主路径
+#### 进阶：schema 参考——并非首次接入路径
 
-下面只说明 schema 形状。正常 setup 不应手写，而应按上文机械提取
-`recommendedAnswers`。
+下面的 wrapper 仅用于说明 schema。正常 setup 路径中不要手工编写它；按上文机械提取 `recommendedAnswers`。
 
 ```json
 {
@@ -265,11 +207,9 @@ node -e 'require("node:fs").rmSync(process.argv[1],{recursive:true,force:false})
 }
 ```
 
-这是 schema 参考，不是接入模板。正常 setup 必须使用机器提案；只有确认不存在任何
-历史公开版本时才可使用 `mode: none`。
+这只是 schema 参考，不是接入模板。正常 setup 必须使用机器提案。`mode: none` 仅在不存在任何公开版本时有效。
 
-下面的参考只说明人工审阅过的 gate 与 `selectedGateIds` 的精确对应关系。需要时仅对
-已提取的机器提案做这一处增量编辑：
+下面的参考展示经人工审阅的 gate 与 `selectedGateIds` 之间的精确关系。该关系只能作为对提取出的机器提案的增量编辑来应用：
 
 ```json
 {
@@ -315,10 +255,7 @@ node -e 'require("node:fs").rmSync(process.argv[1],{recursive:true,force:false})
 }
 ```
 
-id 必须复制自当前 `gateCandidates`，不得自创。示例命令只依赖公开快照中的
-`package.json`。如果改用项目脚本，该脚本及其全部依赖必须包含在 `publicFiles` 中；
-snapshot gate 看不到父工作空间的测试、开发依赖或 `node_modules`，除非它们本来就是
-显式公开内容。
+id 必须从当前 `gateCandidates` 复制，不得臆造。示例命令在公开快照内自包含。项目脚本只有在脚本本身及其全部依赖都包含在 `publicFiles` 中时才有效；snapshot gate 看不到父工作区的测试、开发依赖或 `node_modules`，除非它们被显式公开。
 
 ```bash
 release-skill setup --root /absolute/path/to/my-project \
@@ -328,15 +265,9 @@ release-skill setup --root /absolute/path/to/my-project \
   --write --confirm-setup <setupDigest> --json
 ```
 
-setup 只会原子创建不存在的 `.release-skill/project.yaml`。v0.1.3 的 create-once
-写入使用随包提供、带摘要登记的 `darwin-arm64` 原生预构建；
-不支持的平台会以 `SAFE_WRITE_UNAVAILABLE` 失败关闭，不会退回存在路径竞态的写法。
-已有配置返回 `ALREADY_CONFIGURED`/`CONFIG_EXISTS`，后续由人工增量编辑；README、slogan、
-CHANGELOG 和业务脚本不会被生成或覆盖。没有远端渠道时会返回
-`LOCAL_ONLY_DETECTED`，表示生产渠道仍需人工建立或明确放弃。
+Setup 只原子创建缺失的 `.release-skill/project.yaml`。这一 create-once 步骤使用 v0.1.3 起随包发布、经 digest 登记的 `darwin-arm64` 原生预编译产物；不支持的平台以 `SAFE_WRITE_UNAVAILABLE` 失败关闭，不会回退到基于路径的写入。`ALREADY_CONFIGURED`/`CONFIG_EXISTS` 表示现有文件仍由人工所有，只能增量编辑。README、slogan、CHANGELOG 和业务脚本永不被生成或覆盖。没有远端渠道的项目会报告 `LOCAL_ONLY_DETECTED`，而不是虚构生产支持。
 
-下面是人工配置的最小示例；npm 可见性、公开文件边界和远端目标必须显式选择，
-不能依赖工具猜测：
+以下是一个最小的人工编写配置。npm 可见性、公开文件边界和远端目标都必须显式声明：
 
 ```yaml
 apiVersion: release-skill/v1
@@ -365,18 +296,18 @@ releaseUnits:
         mode: preserve
     requiredPublicFiles: [README.md, LICENSE, package.json]
     previousPublicBaseline:
-      mode: none              # 首次发布：确认不存在前序公开版本
+      mode: none              # 首次发布：不存在更早的公开版本
     distributions:
       - type: npm
         package: my-project
-        access: public       # 或 restricted；必须按真实包策略选择
-        provenance: false    # 只有 CI/OIDC 已配置时才启用 true
+        access: public       # 或 restricted；选择真实的包策略
+        provenance: false    # 只有在 CI/OIDC 配置完成后才使用 true
         tag: latest
         registry: https://registry.npmjs.org
         publisher: my-npm-username
-        # 可选：CLI 冒烟验证。配置 smokeBin 后，verify 会在隔离目录安装包
-        # 并运行指定的二进制文件。未配置 smokeBin 时，verify 只确认安装
-        # 和 name/version 一致。
+        # 可选：CLI smoke 验证。配置 smokeBin 后，verify 会在隔离目录
+        # 安装该包并运行指定二进制。不配置 smokeBin 时，verify 只确认
+        # 安装与 name/version。
         # smokeBin: my-project
         # smokeArgs: [help, --json]
         # smokeExpectedJson:
@@ -389,8 +320,7 @@ releaseUnits:
       releaseNotes: "人工维护的发布说明"
 ```
 
-每个发布单元都必须声明前序公开基线。只有确认不存在任何前序公开版本时才使用
-`mode: none`。已有公开仓库必须绑定不可变的 ref 和 commit：
+每个发布单元都必须声明其前序公开基线。只有当你确认不存在更早的公开版本时才使用 `mode: none`。对于已有公开仓库，绑定精确的不可变 ref 与 commit：
 
 ```yaml
     previousPublicBaseline:
@@ -400,79 +330,13 @@ releaseUnits:
       commit: 0123456789abcdef0123456789abcdef01234567
 ```
 
-`none` 不是跳过冲突检查的开关：publish 仍会在任何写入前检查目标 branch、tag、
-GitHub Release 和 npm version 的唯一性。bound 的生产 prepare 必须在线运行，以便
-观察 ref 到 commit 的映射。
-默认 observer 不下载远端文件内容，因此只能报告 mapping diff，并明确标记 content
-diff unavailable。发生漂移时先停止发布，由人工取得并审阅真实远端 commit；工具
-不会下载或合并远端文件。`merge` 表示在 human-owned 权威源中同时保留本地与远端
-修改；`adopt` 表示把审阅后的远端字节复制回该权威源；`reject` 表示停止本次发布并
-调查或修复远端/ref，禁止改成 `mode: none` 绕过。选择 `merge` 或 `adopt` 后，还必须
-把 `previousPublicBaseline` 重新绑定到人工接受的不可变 `repo`/`ref`/`commit`，再运行
-新的 `prepare --online --production`、审阅和 approve。
-
-分支策略也必须符合真实仓库语义：
-
-- `create-release-branch`：创建不存在的独立发布分支；同名分支存在即停止。
-- `advance-existing-branch`：在 `previousPublicBaseline` 精确提交上创建单父提交，
-  只允许普通 fast-forward push；远端并发漂移时交由人工。
-- `initialize-default-branch`：受控创建不存在的标准分支；只有显式配置
-  `setAsDefaultBranch` 和 `expectedCurrentDefaultBranch` 时，默认分支切换才成为
-  计划中可批准、可观察、可 reconcile 的独立动作。
-
-三种策略的最小配置如下：
-
-```yaml
-# 新建不可变 release 分支；目标必须不存在。
-previousPublicBaseline: { mode: none } # 仅限真正的首次公开发布
-production:
-  branchTemplate: release/{tag}
-  branchStrategy: create-release-branch
-```
-
-```yaml
-# 推进 main；绑定的 ref 必须与目标分支精确一致。
-previousPublicBaseline:
-  mode: bound
-  repo: owner/my-project
-  ref: refs/heads/main
-  commit: 0123456789abcdef0123456789abcdef01234567
-production:
-  branchTemplate: main
-  branchStrategy: advance-existing-branch
-```
-
-```yaml
-# 一次性创建尚不存在的 main，并显式切换默认分支。
-previousPublicBaseline:
-  mode: bound
-  repo: owner/my-project
-  ref: refs/heads/old-public-branch
-  commit: 0123456789abcdef0123456789abcdef01234567
-production:
-  branchTemplate: main
-  branchStrategy: initialize-default-branch
-  setAsDefaultBranch: true
-  expectedCurrentDefaultBranch: old-public-branch
-```
-
-后两种策略必须运行 `prepare --online --production`。如果观察到的分支、commit、
-目标不存在性或当前默认分支与预期不符，先停止并审阅真实远端状态，再人工更新权威
-源文件/配置；禁止 force push 或弱化基线。
+`none` 不是绕过冲突检查的手段：publish 仍会在任何写入前检查目标 branch、tag、GitHub Release 与 npm 版本的唯一性。bound 模式的生产 prepare 必须在线运行，以便观察 ref 到 commit 的映射。默认观察器不下载远端文件内容，因此它报告映射差异并标记内容差异不可用。发生漂移时停止，由人工选择 `merge`、`adopt` 或 `reject`。先获取并审阅真实远端 commit；工具不会下载或合并其文件。`merge` 在人工所有的来源中保留本地与远端双方修改；`adopt` 把审阅过的远端字节复制进该来源；`reject` 在调查或修正远端/ref 期间停止本次发布；永远不要为了绕过漂移而改回 `mode: none`。`merge` 或 `adopt` 之后，把 `previousPublicBaseline` 重新绑定到已接受的不可变 `repo`/`ref`/`commit`，再运行新的 `prepare --online --production`、审阅并批准。
 
-这只是解释机制的本地示例，不是完整的 npm 发布清单。真实发布前必须枚举全部
-公开运行时代码、可执行文件、类型声明、图片和链接文档。monorepo 应把 `source`
-设为 `packages/my-plugin` 之类的子目录；每个 `from` 仍相对工作空间根，例如
-`packages/my-plugin/README.md`。
-
-首次 prepare 前，建议提交 `.gitignore`、`.release-skill/project.yaml`、README、版本文件和
-全部待发布内容，使 Git baseline 易于复现。prepare 前已有且之后未变化的未提交修改也会
-进入 snapshot/baseline；只有 prepare 后再次变化才会使后续 baseline 校验停止。
+分支策略应与真实仓库匹配（`create-release-branch`、`advance-existing-branch`、`initialize-default-branch`）；三种策略的最小配置示例见[英文 README](README.md)。
 
 ### 主流程
 
-按以下顺序执行。步骤 1–4 是安全默认（只读或仅本地）；步骤 5–9 是需要显式
-人工门禁的生产发布。
+按以下顺序执行。步骤 1–4 是安全默认（只读或仅本地）；步骤 5–9 是需要显式人工门禁的生产发布。
 
 ```bash
 # npm 安装的 CLI（推荐）：
@@ -483,9 +347,6 @@ ACTOR=your-name
 # CLI=(node "$RELEASE_SKILL_HOME/packages/release-skill/bin/release-skill.mjs")
 ```
 
-v0.1.1 生产发布验证完成后，npm 安装的 CLI 是受支持的用户入口；
-源码 checkout 保留为开发/贡献者路径。
-
 1. **环境检查：**
    ```bash
    "${CLI[@]}" help
@@ -494,8 +355,7 @@ v0.1.1 生产发布验证完成后，npm 安装的 CLI 是受支持的用户入
    ```bash
    "${CLI[@]}" setup --root "$PROJECT" --json
    ```
-   按上文机械提取 `compactSummary` 与 `recommendedAnswers`，只确认一次绑定后的
-   `setupDigest`；配置已存在时跳过。
+   按上文机械提取 `compactSummary` 与 `recommendedAnswers`，只确认一次绑定后的 `setupDigest`；配置已存在时跳过。
 3. **就绪评估（只读）：**
    ```bash
    "${CLI[@]}" assess --root "$PROJECT" --offline --json
@@ -506,14 +366,8 @@ v0.1.1 生产发布验证完成后，npm 安装的 CLI 是受支持的用户入
      --acknowledge-hook-side-effects \
      --acknowledge-gate-side-effects --json
    ```
-   只有项目配置没有对应 hook 或 snapshot gate 时，才省略相应授权参数。授权前
-   必须审阅可执行文件、参数、工作目录和副作用，不能把授权参数当固定样板。
-5. **人工审阅：** 检查返回的 `planPath`、`externalActions`、
-   `units[].targetVersion` 和 `planDigest`。每个发布单元的快照位于
-   `<evidenceDir>/snapshots/<unit-id>/`。release-skill 自身只把数据写入
-   `.release-skill/`；获得授权的项目 hook/gate 是没有操作系统沙箱的任意项目
-   进程，可能写入其他位置、访问网络，并读取当前账号可访问的凭据、令牌、密钥和
-   环境变量。
+   只有项目配置没有对应 hook 或 snapshot gate 时，才省略相应授权参数。授权前必须审阅可执行文件、参数、工作目录和副作用，不能把授权参数当固定样板。
+5. **人工审阅：** 检查返回的 `planPath`、`externalActions`、`units[].targetVersion` 和 `planDigest`。每个发布单元的快照位于 `<evidenceDir>/snapshots/<unit-id>/`。
 6. **生产计划冻结：**
    ```bash
    PRODUCTION_JSON=$("${CLI[@]}" prepare --root "$PROJECT" --online --production \
@@ -523,12 +377,7 @@ v0.1.1 生产发布验证完成后，npm 安装的 CLI 是受支持的用户入
    PLAN_PATH=$(printf '%s\n' "$PRODUCTION_JSON" | jq -r '.planPath')
    PLAN_DIGEST=$(printf '%s\n' "$PRODUCTION_JSON" | jq -r '.planDigest')
    ```
-   同样，只省略配置不需要的授权，并在授权前逐项审阅项目进程。
-   审阅新 plan 的 externalActions、npm access/provenance/tag、branch/tag 和冻结摘要。
-   `prepare --json` 返回的生产权威 `planPath` 指向
-   `<项目>/.release-skill/plans/<planDigest>.json`，后续必须始终沿用这个返回值。
-   `.release-skill/release-plan.json` 只是可变便利副本，不得传给生产
-   approve/publish/reconcile。
+   同样，只省略配置不需要的授权，并在授权前逐项审阅项目进程。`prepare --json` 返回的生产权威 `planPath` 指向 `<项目>/.release-skill/plans/<planDigest>.json`，后续必须始终沿用这个返回值。`.release-skill/release-plan.json` 只是可变便利副本，不得传给生产 approve/publish/reconcile。
 7. **批准：**
    ```bash
    APPROVAL_JSON=$("${CLI[@]}" approve --plan "$PLAN_PATH" \
@@ -536,14 +385,7 @@ v0.1.1 生产发布验证完成后，npm 安装的 CLI 是受支持的用户入
    printf '%s\n' "$APPROVAL_JSON" | jq .
    APPROVAL_PATH=$(printf '%s\n' "$APPROVAL_JSON" | jq -r '.approvalPath')
    ```
-   返回的生产权威 `approvalPath` 指向
-   `<项目>/.release-skill/approvals/<planDigest>/<approvalDigest>.json`。
-   `latestApprovalPath` 指向 `.release-skill/approval-record.json`，它只是可变便利
-   副本，不得传给生产 publish/reconcile。批准 24 小时失效；PARTIAL 恢复可为同一
-   plan 重新批准，同时逐字节保留全部旧批准。后续必须使用返回的 immutable
-   `approvalPath` 和 `expiresAt`。`--actor` 只是未经认证的本地审计标签：
-   release-skill 不执行身份认证、不提供数字签名，因此无法证明真人已经批准——
-   它只记录操作者自报的身份。
+   批准 24 小时失效；`--actor` 只是未经认证的本地审计标签。后续必须使用返回的 immutable `approvalPath` 和 `expiresAt`。
 8. **发布（从此开始写远端）：**
    ```bash
    PUBLISH_JSON=$("${CLI[@]}" publish --root "$PROJECT" \
@@ -559,27 +401,13 @@ v0.1.1 生产发布验证完成后，npm 安装的 CLI 是受支持的用户入
      --plan "$PLAN_PATH" --run "$PUBLISH_RUN_PATH" \
      --acknowledge-gate-side-effects --json
    ```
-   只有计划既没有 consumer gate，也没有 npm `smokeBin` 时才省略授权。两者都会
-   执行已安装的项目代码，而且没有操作系统或网络沙箱。
-
-以上返回值交接示例依赖 `jq`。没有 `jq` 时必须从 JSON 原样复制这四个字段；不要把
-文档其他位置的尖括号标签直接当作 shell 语法。
+   只有计划既没有 consumer gate，也没有 npm `smokeBin` 时才省略授权。
 
-生产 prepare 会把每个公开快照封存为独立 Git commit/tree，并为 npm 单元生成固定
-tarball。`publish` 先对所有动作做只读预检，再按“公开快照 branch → tag → npm →
-GitHub Release → Claude/Codex 插件市场（marketplace）安装”执行并逐项观察。`verify` 在隔离目录
-安装每一个精确 npm `package@version`；配置 `smokeBin` 后还会运行 CLI 并校验输出。
-只有全部证据与冻结计划一致才进入 `VERIFIED`。真实发布前运行 `gh auth login`、
-`gh auth setup-git` 和 `npm login`，同时确认 Git HTTPS credential 能访问目标仓库。
-默认分支名为 `release/<tag>`，可由每个 unit 的 `production.branchTemplate` 配置；
-同名远端对象存在时停止，交由人工判断。
+生产 prepare 会把每个公开快照封存为独立 Git commit/tree，并为 npm 单元生成固定 tarball。`publish` 先对所有动作做只读预检，再按“公开快照 branch → tag → npm → GitHub Release → Claude/Codex 插件市场安装”执行并逐项观察。Kimi Code 没有可脚本化的安装接口，其检查点**失败关闭**：`publish` 在完成自动化写入后落入 `PARTIAL`，并产出版本钉死的手动安装要求。操作者随后用 requirement 给出的隔离 `KIMI_CODE_HOME` 启动 Kimi Code，运行钉死的 `/plugins install <release-tag URL>`，把可信证明（同时绑定冻结**计划**摘要与快照**载荷**摘要）写入按计划摘要命名的目录 `.release-skill/kimi-attestations/<planDigest>/<plugin>/`，再运行 `reconcile`（→ `PUBLISHED`）与 `verify`（→ `VERIFIED`）；两者都从同一稳定位置读取证明。安装到日常 `~/.kimi-code` 不被接受。完整流程与证明 JSON 字段见 `INSTALL.zh-CN.md`。`verify` 在隔离目录安装每一个精确 npm `package@version`；配置 `smokeBin` 后还会运行 CLI 并校验输出。只有全部证据与冻结计划一致才进入 `VERIFIED`。默认分支名由每个 unit 的 `production.branchTemplate` 配置；同名远端对象存在时停止，交由人工判断。
 
 ### 发布文档刷新（可选）
 
-发布单元可以声明 `releaseDocuments`，用一份结构化双语说明源确定性刷新 README
-受管区域和 CHANGELOG 当前版本条目。核心 CLI 完全离线运行：不联网、不调用大模型、
-不自动翻译；只改写声明过的受管区域、唯一版本标记的机器值和 CHANGELOG 当前版本
-受管条目，区域外字节逐字保留。`prepare` 只检查新鲜度，不写工作树。
+发布单元可以声明 `releaseDocuments`，用一份结构化双语说明源确定性刷新 README 受管区域和 CHANGELOG 当前版本条目。核心 CLI 完全离线运行：不联网、不调用大模型、不自动翻译；只改写声明过的受管区域、唯一版本标记的机器值和 CHANGELOG 当前版本受管条目，区域外字节逐字保留。`prepare` 只检查新鲜度，不写工作树。
 
 ```yaml
 # .release-skill/project.yaml（发布单元片段）
@@ -604,76 +432,24 @@ releaseUnits:
           regions: [latest-release]
 ```
 
-`notesSource` 和所有目标路径均相对发布单元根。`versionMarkers[].pattern` 必须与
-README 现有唯一版本标记精确匹配，`{version}` 代表机器版本值；刷新只替换该值
-（零次或多次匹配失败关闭）。
-
-```yaml
-# release-notes/0.1.6.yaml（结构化说明源）
-version: 0.1.6
-date: 2026-07-21
-locales:
-  en:
-    summary: Deterministic multilingual release-document refresh.
-    changes:
-      added:
-        - Refresh managed README regions and changelogs from one source.
-    upgradeNotes: Review and commit refreshed documents before prepare.
-  zh-CN:
-    summary: 从同一说明源确定性刷新多语种发布文档。
-    changes:
-      added:
-        - 自动刷新 README 受管区域和 CHANGELOG。
-    upgradeNotes: prepare 前审阅并提交刷新结果。
-```
-
-`version` 必须与解析出的单元版本精确一致；每个配置语种恰好出现一次，`summary`
-与变更项非空，且 `security`、`breaking`、`added`、`changed`、`deprecated`、
-`removed`、`fixed` 中至少一个类别含条目。YAML alias、重复键、未知字段和语种回退
-均失败关闭。
-
 1. **只读演练：**
    ```bash
    "${CLI[@]}" docs refresh --root "$PROJECT" --unit my-project --json
    ```
-   输出 `status`（`changes` 或 `clean`）、逐文件相对 `path`、`locale`、`kind`、
-   新旧摘要、单元 `version`、`locales`、`inputDigest` 和 `refreshDigest`。
-   `refreshDigest` 绑定协议版本、发布单元、规范说明对象、配置投影和按路径排序的
-   逐文件新旧摘要，不绑定时间、绝对路径或展示文本；`nextCommand.argv` 给出精确
-   写入命令。
 2. **摘要确认的本地写入（仅在用户明确授权“本地发布文档写入”后执行）：**
    ```bash
    "${CLI[@]}" docs refresh --root "$PROJECT" --unit my-project \
      --write --confirm-refresh <refreshDigest> \
      --ack-local-document-write --json
    ```
-   三项绑定缺一不可；摘要不匹配以 `RELEASE_DOCS_REFRESH_STALE` 失败关闭且零写入。
-   候选无变化时演练返回 `clean`，写入同样零写入。全部目标作为一个事务提交；
-   写入成功后立即复演，必须返回 `clean`。
-
-该授权只覆盖声明的本地发布文档目标，不是 hook、Git 提交、push、publish 或安装的
-授权：维护者必须审阅刷新结果并提交，然后重新 `prepare`——新字节会改变快照、
-workspace digest 和 plan digest，旧批准不能授权刷新后的计划。
 
-配置了 `releaseDocuments` 的文档发生漂移时，`prepare` 在 hook、基线、快照、
-远端检查和计划冻结前以 `RELEASE_DOCS_STALE` 失败关闭。恢复路径：运行演练，审阅
-展示的文件/语种/版本/摘要，授权并执行本地写入，审阅提交后重新 `prepare`。
-`RELEASE_DOCS_INVALID`（配置或说明数据非法）、`RELEASE_DOCS_TRANSLATION_MISSING`
-（配置语种缺失）和 `RELEASE_DOCS_CONFLICT`（非受管同版本内容或标记损坏）都需要
-先修复源或目标，不得扩大写入范围解决。
+该授权只覆盖声明的本地发布文档目标，不是 hook、Git 提交、push、publish 或安装的授权：维护者必须审阅刷新结果并提交，然后重新 `prepare`。
 
 ### 父工作空间 + npm 子单元 + 插件子单元
 
-当 monorepo 从不同目录同时产出 npm 包和 Claude/Codex 插件时，应定义独立的
-发布单元。只有当某个单元确实以 manifest、marketplace 和 entry Skill 的形式
-发布插件时，才为其添加插件分发：
+当 monorepo 从不同目录同时产出 npm 包和 Claude/Codex/Kimi Code 插件时，应定义独立的发布单元。只有当某个单元确实以 manifest、marketplace 和 entry Skill 的形式发布插件时，才为其添加插件分发：
 
-本例中的 `project` 是父工作空间的编排容器，本身不是公开发布单元；如果工作空间
-根目录也要发布独立仓库或 package，应再增加一个 `source: .` 的 release unit。
-`version.source` 相对于该发布单元的 `source` 目录解析
-（`version.source` is resolved relative to that release unit's `source` directory）：
-`source: packages/app` 的单元应直接写 `package.json`，而不是
-`packages/app/package.json`。
+这里的 `project` 是父工作空间的编排容器，不是公开发布单元。如果工作区根目录也发布自己的仓库或包，再添加一个 `source: .` 的发布单元。`version.source` 相对于该发布单元的 `source` 目录解析（`version.source` is resolved relative to that release unit's `source` directory）：因此 `source: packages/app` 的单元写裸 `package.json`，而不是 `packages/app/package.json`。
 
 ```yaml
 apiVersion: release-skill/v1
@@ -727,17 +503,21 @@ releaseUnits:
       tagTemplate: my-plugin-v{version}
     distributions:
       # 只有当单元确实发布插件时才声明插件消费者。
-      # CLI 冒烟独立；只有插件包同时暴露 CLI 二进制时才声明 smokeBin。
+      # CLI smoke 是独立的；只有当插件包同时暴露 CLI 二进制时才声明 smokeBin。
       - type: claude-plugin
         plugin: my-plugin
         marketplace: my-plugin
         entrySkill: my-plugin-help
-        timeoutMs: 300000     # 可选；范围 30000–900000；默认 300000
+        timeoutMs: 300000     # 可选；范围 30000-900000；默认 300000
       - type: codex-plugin
         plugin: my-plugin
         marketplace: my-plugin
         entrySkill: my-plugin-help
-        timeoutMs: 300000     # 可选；范围 30000–900000；默认 300000
+        timeoutMs: 300000     # 可选；范围 30000-900000；默认 300000
+      - type: kimi-plugin
+        plugin: my-plugin
+        entrySkill: my-plugin-help
+        timeoutMs: 300000     # 可选；范围 30000-900000；默认 300000（Kimi 无安装命令；仅约束只读验证）
     publicFiles:
       - from: packages/plugin/.claude-plugin/plugin.json
         to: .claude-plugin/plugin.json
@@ -748,6 +528,9 @@ releaseUnits:
       - from: packages/plugin/.codex-plugin/plugin.json
         to: .codex-plugin/plugin.json
         mode: preserve
+      - from: packages/plugin/.kimi-plugin/plugin.json
+        to: .kimi-plugin/plugin.json
+        mode: preserve
       - from: packages/plugin/.agents/plugins/marketplace.json
         to: .agents/plugins/marketplace.json
         mode: preserve
@@ -767,6 +550,7 @@ releaseUnits:
       - .claude-plugin/plugin.json
       - .claude-plugin/marketplace.json
       - .codex-plugin/plugin.json
+      - .kimi-plugin/plugin.json
       - .agents/plugins/marketplace.json
       - skills/my-plugin-help/SKILL.md
       - README.md
@@ -779,21 +563,13 @@ releaseUnits:
       releaseTitleTemplate: "{unit} {version}"
 ```
 
-每个插件单元**必须**列出 Claude/Codex `plugin.json`、`marketplace.json`、
-入口 Skill 和全部 required public files。CLI 冒烟（`smokeBin`）对插件单元
-是可选项，仅当发布包同时暴露 CLI 二进制时才适用。
+每个插件单元**必须**列出其 Claude/Codex/Kimi Code `plugin.json`、Claude/Codex 的 `marketplace.json`（Kimi Code 没有 marketplace 清单）、entry Skill 以及全部必需公开文件。CLI smoke（`smokeBin`）对插件单元是可选的，只适用于发布的 npm 包暴露 CLI 二进制的情况。
 
-插件分发可声明 `timeoutMs`（范围 30,000–900,000 毫秒；默认 300,000 毫秒），
-用于设置 marketplace add、plugin install 和 plugin list 三条命令的子进程超时。
-真实网络下这些命令可能需要 40–105 秒；默认 300 秒超时避免误报 `PARTIAL`。
-解析后的值冻结到计划中，与其他动作参数一起接受批准。无 `timeoutMs` 的旧计划
-在执行时默认回退到 300,000 毫秒以保证向后兼容。
+插件分发可以声明 `timeoutMs`（范围 30,000–900,000 ms；默认 300,000 ms），用于 marketplace add、插件安装与插件列表命令的子进程超时。真实网络下这些命令可能需要 40–105 秒；默认 300 秒超时可以避免误报 `PARTIAL`。解析后的值会冻结进计划，并随其他动作参数一起批准。没有 `timeoutMs` 的旧计划在执行时按 300,000 ms 兼容处理。
 
 ### PARTIAL 恢复与 reconcile
 
-当 `publish` 在部分检查点成功但在其他检查点失败时，运行进入 `PARTIAL`
-状态。**不要从头重跑，也不要删除远端状态**（例如不要删除已推送的 tag 或
-unpublish 已发布的包）。
+当 `publish` 在部分检查点成功但在其他检查点失败时，运行进入 `PARTIAL` 状态。**不要从头重跑，也不要删除远端状态。**
 
 使用 `reconcile` 检查实际远端状态，跳过已一致的步骤，安全重试未完成的动作：
 
@@ -805,21 +581,12 @@ RECONCILE_JSON=$("${CLI[@]}" reconcile --root "$PROJECT" \
   --confirm-production "$PLAN_DIGEST" --json)
 printf '%s\n' "$RECONCILE_JSON" | jq .
 RECONCILE_RUN_PATH=$(printf '%s\n' "$RECONCILE_JSON" | jq -r '.runPath')
-# 保存 reconcile 返回的新 runPath，再执行全新的安装验证。
 "${CLI[@]}" verify --root "$PROJECT" \
   --plan "$PLAN_PATH" --run "$RECONCILE_RUN_PATH" \
   --acknowledge-gate-side-effects --json
 ```
 
-只有冻结计划既没有 consumer gate，也没有 npm `smokeBin` 时才省略 verify 授权。
-以上变量沿用主流程从 JSON 提取的精确值；如果恢复期间批准已过期，应为同一个不可变
-计划重新批准，并在 reconcile 前替换 `APPROVAL_PATH`。
-
-`reconcile` 查询实际远端状态（Git refs、npm 版本、GitHub Release、
-marketplace 安装），跳过证据已匹配冻结计划的步骤，只重试安全且未完成的
-步骤。远端冲突（例如意外的 tag 或 npm 版本）需要人工判断，无法自动解决。
-reconcile 成功只返回 `PUBLISHED`，不会返回 `VERIFIED`；只有全新运行的 verify
-可以产生终态 `VERIFIED`。
+reconcile 成功只返回 `PUBLISHED`，不会返回 `VERIFIED`；只有全新运行的 verify 可以产生终态 `VERIFIED`。
 
 ## 已验收能力
 
@@ -832,20 +599,15 @@ reconcile 成功只返回 `PUBLISHED`，不会返回 `VERIFIED`；只有全新
 - 记录 Git/工作区身份，冻结绑定 digest 的发布计划；
 - 用计划摘要、有效期和显式 action allowlist 绑定人工批准；
 - 从冻结 Git object 和 npm tarball 发布，并核对远端 commit/tree/tag/integrity；
-- 从冻结 Git ref 安装配置的 Claude/Codex 插件，证明入口 Skill 和安装载荷摘要；
+- 从冻结 Git ref 安装配置的 Claude/Codex 插件，证明入口 Skill 和安装载荷摘要；对 Kimi Code（无可脚本化安装接口）产出版本钉死的手动安装要求，仅依据绑定到冻结计划摘要的可信证明来确认入口 Skill 和载荷摘要；
 - 明确区分 `PUBLISHED`（外写完成）与 `VERIFIED`（远端和消费者安装证据完成）；
 - 中途失败停止后续动作，记录独立 run；不修改冻结 plan，不自动撤销已成功动作。
 
 ## 个性化验证：hook 与 gate
 
-`hooks.docs/build/test/typecheck/lint` 在冻结前运行，适合确实需要生成源文件或依赖
-父工作区的步骤。它们可能修改项目或访问网络，prepare 必须显式传入
-`--acknowledge-hook-side-effects`。
+`hooks.docs/build/test/typecheck/lint` 在冻结前运行，适合确实需要生成源文件或依赖父工作区的步骤。它们可能修改项目或访问网络，prepare 必须显式传入 `--acknowledge-hook-side-effects`。
 
-每个 hook 都是一个对象，绝不是裸命令列表。
-`command` 是可执行文件/参数数组，不是 shell 字符串
-（`command` is an executable/argument array, not a shell string）。每个 hook 还声明
-`cwd`、`timeoutMs` 和 `envAllowlist`：
+每个 hook 都是一个对象，`command` 是可执行文件/参数数组，不是 shell 字符串（`command` is an executable/argument array, not a shell string）。每个 hook 还声明 `cwd`、`timeoutMs` 和 `envAllowlist`：
 
 ```yaml
 hooks:
@@ -861,9 +623,6 @@ hooks:
     envAllowlist: []
 ```
 
-hook 同样必须先逐项审阅配置的可执行文件、参数、工作目录和副作用，
-并经 `prepare --acknowledge-hook-side-effects` 明确授权才会运行。
-
 `verificationGates` 是更适合发布校准的受控扩展点：
 
 ```yaml
@@ -878,26 +637,11 @@ verificationGates:
     cwd: .
     timeoutMs: 120000
     envAllowlist: [CI]
-  - id: installed-help
-    phase: consumer-verify
-    scope: { unit: my-project, distribution: npm }
-    command: [node, scripts/check-installed-help.mjs]
-    cwd: .
-    timeoutMs: 30000
-    envAllowlist: []
-    expectedJson: { status: READY }
 ```
 
-snapshot 示例刻意设计为自包含，只读取已映射的公开文件。若替换成项目脚本，该脚本
-及其全部依赖必须存在于冻结公开快照；consumer 脚本也必须存在于精确安装的发行物。
-gate 不能借用父工作空间中的测试、开发依赖或 `node_modules`。
+`snapshot-verify` 在冻结公开快照的一次性可写副本中执行；`consumer-verify` 在精确 npm/Claude/Codex/Kimi Code 隔离安装根执行。两者都使用命令数组而非 shell 字符串，定义和结果会进入摘要证据，并要求 prepare/verify 显式传入 `--acknowledge-gate-side-effects`。
 
-`snapshot-verify` 在冻结公开快照的一次性可写副本中执行；`consumer-verify` 在精确
-npm/Claude/Codex 隔离安装根执行。两者都使用命令数组而非 shell 字符串，定义和
-结果会进入摘要证据，并要求 prepare/verify 显式传入
-`--acknowledge-gate-side-effects`。gate 仍是无网络沙箱的项目进程，release-skill
-无法保证它不会写文件或访问网络。push、tag、默认分支切换、GitHub Release 和
-npm publish 不能放进 hook/gate，只能由冻结计划的受控动作执行。
+push、tag、默认分支修改、GitHub Release 和 npm publish 不能放进 hook/gate，只能由冻结计划的受控动作执行。
 
 ## 当前不会做什么
 
@@ -905,23 +649,16 @@ npm publish 不能放进 hook/gate，只能由冻结计划的受控动作执行
 - 不自动生成 README，不覆盖项目源文件；
 - 不自动合并冲突，也不要求回滚工作流；
 - 不声称已经替项目完成真实生产 canary；
-- `prepare --online` 只观察 bound 前序基线的 ref→commit 映射；目标唯一性由
-  publish 全局预检完成；
-- 不覆盖已有 branch/tag/Release，不 unpublish npm；新建 ref 仅使用
-  `--force-with-lease=<ref>:` 作为“目标必须不存在”的原子比较并设置断言，推进已有
-  分支使用普通非 force push；
+- `prepare --online` 只观察 bound 前序基线；目标唯一性由 publish 全局预检完成；
+- 不覆盖已有 branch/tag/Release，不 unpublish npm；
 - 不承诺 Windows 或广泛的跨平台原生写入；
 - 不会隐藏地 commit、push、打 tag、创建 Release 或发布包。
 
 ### 写入安全
 
-`setup` 默认只读，写入只允许精确摘要确认后首次创建配置。`assess` 默认只读，
-只有显式指定报告输出时才写报告。`prepare` 会在
-`.release-skill/` 下写本地文件，但不会写项目源文件或远端服务。如果配置了
-hook，它就是任意本地进程，必须使用 `--acknowledge-hook-side-effects` 明确授权；
-gate 同样是项目进程，必须使用 `--acknowledge-gate-side-effects` 明确授权。它们
-可能自行产生文件系统或网络副作用。`publish` 是唯一生产外写入口，必须同时
-提供 approval 和当前 plan digest。最小安全演练应省略 hook，并在本地沙箱目标运行。
+`setup` 默认只读，写入只允许精确摘要确认后首次创建配置。`assess` 默认只读。`prepare` 会在 `.release-skill/` 下写本地文件，但不会写项目源文件或远端服务。如果配置了 hook，它就是任意本地进程，必须使用 `--acknowledge-hook-side-effects` 明确授权；gate 同样需要 `--acknowledge-gate-side-effects`。
+
+`publish` 是唯一生产外写入口，必须同时提供 approval 和当前 plan digest。
 
 ### 失败时怎么办
 
@@ -931,15 +668,15 @@ gate 同样是项目进程，必须使用 `--acknowledge-gate-side-effects` 明
 | `LOCAL_ONLY_DETECTED` | 决定建立远端渠道或仅保留本地配置设计；不得冒充生产就绪。 |
 | `SETUP_DIGEST_MISMATCH` | 项目事实或 answers 已变化；重新 dry-run、审阅并确认新摘要。 |
 | `CONFIG_EXISTS` | setup 不覆盖已有配置；运行 assess 后人工增量修改。 |
-| `SAFE_WRITE_UNAVAILABLE` | 当前平台不支持自动 create-once；保留只读报告，由人工首次创建经审阅的配置，且不得覆盖已有文件。 |
+| `SAFE_WRITE_UNAVAILABLE` | 当前平台不支持自动 create-once；保留只读报告，由人工首次创建经审阅的配置。 |
 | `CONFIG_INVALID` | 修正 `.release-skill/project.yaml`，重新运行 `assess`。 |
 | `PUBLIC_FILE_MISSING` | 添加或修正配置中的公开文件。 |
 | `FORBIDDEN_CONTENT_DETECTED` | 移除泄漏或私有内容，再次 prepare。 |
 | `SNAPSHOT_FIDELITY_FAILED` | 检查源文件和快照路径，重新运行 `prepare`。 |
 | `BASELINE_CHANGED` | 保留人工修改，重新 prepare、审阅和 approve。 |
-| `prepare` 阶段 `GATE_FAILED` | 修复 snapshot gate 或冻结公开制品，再生成一份新 plan；失败 plan 不得批准。 |
-| `verify` 阶段 `GATE_FAILED` | 若是消费者环境失败，修复环境后从同一 `PUBLISHED` run 重跑 verify；若是已发布制品缺陷，发布新的补丁版本，不覆盖旧制品。 |
-| `PARTIAL` | 不重跑整套发布、不删除远端；审阅返回的 `runPath` 并运行 `reconcile`（见上文）。 |
+| `prepare` 阶段 `GATE_FAILED` | 修复 snapshot gate 或冻结公开制品，再生成一份新 plan。 |
+| `verify` 阶段 `GATE_FAILED` | 若是消费者环境失败，修复环境后从同一 `PUBLISHED` run 重跑 verify；若是已发布制品缺陷，发布新的补丁版本。 |
+| `PARTIAL` | 不重跑整套发布、不删除远端；审阅返回的 `runPath` 并运行 `reconcile`。 |
 | `PUBLISHED` | 运行 `verify --plan <planPath> --run <publishRunPath>`；此时还不是终态。 |
 | `VERIFIED` | 远端状态、精确 npm 安装和插件消费者安装都与冻结计划一致。 |
 
@@ -953,9 +690,6 @@ gate 同样是项目进程，必须使用 `--acknowledge-gate-side-effects` 明
 - `release-reconcile`：基于证据恢复 PARTIAL；冲突时人工介入。
 - `release-verify`：发布后验证；只有 `VERIFIED` 才是 happy end。
 
-冲突默认仍由人工介入。v0.1.1 生产发布后，受支持的用户入口是 npm 安装的
-`release-skill` CLI；源码 checkout 保留为开发/贡献者路径。
-
 ## 许可证
 
 MIT，见 [LICENSE](LICENSE)。