release-skill 0.1.7 → 0.1.9

package/README.zh-CN.md

@@ -2,38 +2,37 @@
 
 [English](README.md) · 安装指南：[中文](INSTALL.zh-CN.md) / [English](INSTALL.md)
 
-<!-- release-skill:release-version: 0.1.7 -->
-面向 Claude Code 和 Codex 的发布准备工具，完整保留人工维护的文件内容。
+<!-- release-skill:release-version: 0.1.9 -->
+面向 Claude Code、Codex 和 Kimi Code 的发布准备工具，完整保留人工维护的文件内容。
 
-release-skill 帮助维护者回答三个问题：准备发布什么、还有哪些检查未通过、最终
-发布的字节究竟是什么。它先冻结并供人工审阅，再从同一份冻结制品发布，不会在
-最后一步重新生成 README、重新打包活动工作区或覆盖人工内容。
+release-skill 帮助维护者回答三个问题：准备发布什么、还有哪些检查未通过、最终发布的内容是什么。它先冻结并供人工审阅，再从同一份冻结产物发布，不会在最后一步重新生成 README、重新打包当前工作区或覆盖人工内容。
 
 <!-- release-skill:managed:start id=latest-release -->
-**0.1.7** (2026-07-23)
-
-v0.1.7 是一个组织迁移版本。公开 GitHub 仓库从 `mzdbxqh/release-skill` 迁移至 `ifoohoo/release-skill`（仓库名不变，GitHub 对旧 URL 做重定向），项目新增明确的公司维护主体与版权持有人（广州市风荷科技有限公司），并将面向未来版本的仓库、维护主体、作者与版权元数据在 npm 包、插件市场清单、NOTICE、LICENSE 与发布配置中统一对齐到新组织。npm 包名（`release-skill`）与 npm 发布身份（`publisher: mzdbxqh`）保持不变，已发布的 v0.1.6 标签、GitHub Release 与 npm 版本不被改写。
-
-**变更**
-
-- **公开仓库迁移至 `ifoohoo` 组织**：公开 GitHub 仓库从
-  `mzdbxqh/release-skill` 转移到 `ifoohoo/release-skill`，仓库名不变。默认分支仍为
-  `main`，v0.1.6 标签、发行版与历史均被保留，旧 URL 以 HTTP 301 重定向到新位置。
-  发布配置（`publicRepo` 与绑定的 `previousPublicBaseline`）现在指向
-  `ifoohoo/release-skill`，并以公开 v0.1.6 提交
-  `48fb2a258a2786c2e32136ad67bd51f3a280b3b8` 作为上一公开基线。
-- **公司维护主体与版权**：MIT LICENSE（根目录与公开包）现在携带 release-skill
-  贡献者与广州市风荷科技有限公司的双行版权声明；NOTICE 明确项目由广州市风荷科技
-  有限公司维护，并说明 GitHub 仓库转移属于托管位置与维护身份的行政变更，本身不构成
-  著作权转让。
-- **面向未来版本的元数据与组织对齐**：npm `package.json` 的仓库、主页与问题
-  跟踪地址指向 `ifoohoo/release-skill`，并在保留 release-skill 贡献者的同时新增公司
-  作者。Claude Code 插件市场所有者现在标识 `ifoohoo` 组织。npm 包名
-  （`release-skill`）与 npm 发布身份（`publisher: mzdbxqh`）保持不变。
+**0.1.9** (2026-07-23)
+
+v0.1.9 修复一个结构性的 marketplace 安装校验失败：声明插件 `source` 子目录（如 `./adapters/claude`）的消费者安装现在能把安装载荷绑定到密封整 unit 快照中声明的子树，Claude 根目录 `.in_use` 标记作为消费者所有的传输元数据获得豁免。密封快照摘要、发布计划 schema 与 prepare 冻结均未改动，已冻结计划无需重新审批即可 reconcile。npm 包名（`release-skill`）、发布身份（`publisher: mzdbxqh`）、公开仓库（`ifoohoo/release-skill`）与公司维护主体保持不变。
+
+**修复**
+
+- **子目录 source 布局的 marketplace 载荷绑定**：消费者清单可以声明
+  `./adapters/claude` 这样的插件 `source` 子目录，此时消费者 CLI 只安装该子树，
+  而密封权威是整个 unit 快照。安装校验现在先重验密封整快照摘要，再从摘要已验证
+  的快照条目内部读取清单声明的 source，并把安装载荷绑定到剥离前缀后的子树；
+  根布局与 Kimi 保持整树比较。这解决了 flow-architect v0.4.1 与 v0.5.0 的
+  marketplace 安装 PARTIAL 失败；密封摘要、计划 schema 与 prepare 冻结均未改动，
+  已冻结计划可以不变地 reconcile 收口。
+- **Claude `.in_use` 传输标记豁免**：Claude CLI 会在插件安装根目录写入空的
+  `.in_use` 标记，现在与既有的 Codex/Kimi `.git` 豁免一样作为消费者所有的传输
+  元数据豁免，并统一为单一共享 helper（observe 诊断回退同样复用）。豁免仅限根
+  直接子项：嵌套标记、多余载荷、字节篡改与密封权威篡改仍然失败关闭。
+- **回归覆盖**：新增协议级 fake-CLI 测试覆盖带 `.in_use` 的子目录 claude
+  完整链路（含字节篡改、多余文件、缺失文件、`.git` 不豁免与嵌套标记负例）、
+  失败关闭的清单异常（重复插件条目、marketplace 名不符、空 source 投影）、
+  带 `.in_use` 的根布局 claude，以及 codex 子目录变体。
 <!-- release-skill:managed:end id=latest-release -->
 
 <!-- release-skill:capability:external-write-boundary -->
-> **当前边界：** v0.1.7 是当前发布版本（v0.1.6 完成真实生产验证后曾处于这一状态）。
+> **当前边界：** v0.1.9 是当前发布版本（v0.1.8 曾处于已发布、待独立验证状态）。
 > v0.1.1 已完成 GitHub 与 npm 的
 > 真实生产发布，是首次生产验证的历史里程碑，并从冻结 Git ref 完成精确 npm
 > 安装及 Claude/Codex 消费者安装验证；“当前发布版本”与“首次生产验证里程碑”
@@ -46,7 +45,7 @@ v0.1.7 是一个组织迁移版本。公开 GitHub 仓库从 `mzdbxqh/release-sk
 > 远端唯一性检查在 `publish` 全局预检执行。
 
 <!-- release-skill:capability:safe-first-command -->
-> **生产路径自 v0.1.1 里程碑起已完成真实生产验证；v0.1.7 是当前发布版本。**
+> **生产路径自 v0.1.1 里程碑起已完成真实生产验证；v0.1.9 是当前发布版本。**
 > npm 安装的 CLI 是受支持的用户入口；源码 checkout 保留为开发/贡献者路径。
 >
 > **第一条命令：**
@@ -62,33 +61,21 @@ v0.1.7 是一个组织迁移版本。公开 GitHub 仓库从 `mzdbxqh/release-sk
 
 ## 为什么人工修改的 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+
@@ -115,8 +102,6 @@ release-skill help
 
 **开发安装（贡献者回退，从源码 checkout）：**
 
-设置源码路径并安装依赖：
-
 ```bash
 export RELEASE_SKILL_HOME=/absolute/path/to/release-skill
 cd "$RELEASE_SKILL_HOME"
@@ -132,11 +117,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
@@ -150,11 +133,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='/上一步打印的会话目录绝对路径'
@@ -190,17 +171,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
 {
@@ -238,11 +213,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
 {
@@ -288,10 +261,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 \
@@ -301,15 +271,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
@@ -338,18 +302,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:
@@ -362,8 +326,7 @@ releaseUnits:
       releaseNotes: "人工维护的发布说明"
 ```
 
-每个发布单元都必须声明前序公开基线。只有确认不存在任何前序公开版本时才使用
-`mode: none`。已有公开仓库必须绑定不可变的 ref 和 commit：
+每个发布单元都必须声明其前序公开基线。只有当你确认不存在更早的公开版本时才使用 `mode: none`。对于已有公开仓库，绑定精确的不可变 ref 与 commit：
 
 ```yaml
     previousPublicBaseline:
@@ -373,79 +336,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。
-
-分支策略也必须符合真实仓库语义：
+`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`、审阅并批准。
 
-- `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 或弱化基线。
-
-这只是解释机制的本地示例，不是完整的 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（推荐）：
@@ -456,9 +353,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
@@ -467,8 +361,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
@@ -479,14 +372,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 \
@@ -496,12 +383,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" \
@@ -509,14 +391,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" \
@@ -532,27 +407,13 @@ v0.1.1 生产发布验证完成后，npm 安装的 CLI 是受支持的用户入
      --plan "$PLAN_PATH" --run "$PUBLISH_RUN_PATH" \
      --acknowledge-gate-side-effects --json
    ```
-   只有计划既没有 consumer gate，也没有 npm `smokeBin` 时才省略授权。两者都会
-   执行已安装的项目代码，而且没有操作系统或网络沙箱。
+   只有计划既没有 consumer gate，也没有 npm `smokeBin` 时才省略授权。
 
-以上返回值交接示例依赖 `jq`。没有 `jq` 时必须从 JSON 原样复制这四个字段；不要把
-文档其他位置的尖括号标签直接当作 shell 语法。
-
-生产 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（发布单元片段）
@@ -577,76 +438,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
@@ -700,17 +509,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
@@ -721,6 +534,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
@@ -740,6 +556,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
@@ -752,21 +569,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` 检查实际远端状态，跳过已一致的步骤，安全重试未完成的动作：
 
@@ -778,21 +587,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`。
 
 ## 已验收能力
 
@@ -805,20 +605,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:
@@ -834,9 +629,6 @@ hooks:
     envAllowlist: []
 ```
 
-hook 同样必须先逐项审阅配置的可执行文件、参数、工作目录和副作用，
-并经 `prepare --acknowledge-hook-side-effects` 明确授权才会运行。
-
 `verificationGates` 是更适合发布校准的受控扩展点：
 
 ```yaml
@@ -851,26 +643,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，只能由冻结计划的受控动作执行。
 
 ## 当前不会做什么
 
@@ -878,23 +655,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。
 
 ### 失败时怎么办
 
@@ -904,15 +674,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 安装和插件消费者安装都与冻结计划一致。 |
 
@@ -926,9 +696,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)。