release-skill 0.9.0 → 0.9.3

package/.claude-plugin/marketplace.json

@@ -9,7 +9,7 @@
     {
       "name": "release-skill",
       "source": "./",
-      "version": "0.9.0",
+      "version": "0.9.3",
       "description": "Safe preparation and frozen GitHub/npm production publishing with full happy end verification",
       "author": {
         "name": "广州市风荷科技有限公司"

package/.claude-plugin/plugin.json

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

package/.codebuddy-plugin/plugin.json

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

package/.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "release-skill",
-  "version": "0.9.0",
+  "version": "0.9.3",
   "description": "Safe preparation and frozen GitHub/npm production publishing with full happy end verification",
   "author": {
     "name": "广州市风荷科技有限公司"
@@ -19,7 +19,7 @@
     ],
     "defaultPrompt": [
       "Assess this project for release readiness.",
-      "Prepare a release plan for version 0.9.0.",
+      "Prepare a release plan for version 0.9.3.",
       "Help me understand the release workflow."
     ]
   }

package/.kimi-plugin/plugin.json

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

package/CHANGELOG.md

@@ -1,5 +1,86 @@
 # Changelog
 
+<!-- release-skill:changelog:start version=0.9.3 locale=en baseline=sha256:96e5f9167abb13203ba308ebacbb081452f8c23e26ff0b377514556338ebdfff -->
+## [0.9.3] - 2026-08-31
+
+0.9.3 is a local source candidate for the four workflow safeguards and the narrow Hook cache v2 and isolated-install-tree integrations. It consumes the three Foundation packages at the exact 0.15.0 release. This note is not evidence of publication, real-host acceptance, consumer installation verification, or independent acceptance.
+
+### Security
+
+- Unknown, corrupt, non-stable, or unsupported observations remain fail-closed. A cache hit never replaces a Hook execution when the authority or identity evidence is unavailable, and no TTL or ambient PATH inference is used.
+- Any host plan remains a qualified frozen-plan path and requires a VERIFIED-run before host acceptance; this source candidate does not provide that acceptance.
+
+### Added
+
+- Add the opt-in pre-hook public-surface check, ship help and target-version conflict guard, verify lineage guidance, and evidence-based adoption suggestions without adding a new command, state, or approval authority.
+- Add the narrow Hook cache v2 consumer path: absolute-path and validated cwd-relative executable identity, closed input and environment binding, no TTL, and fail-closed cache reuse for bare PATH, PATHEXT, Windows, and unavailable observations while Hooks still execute cold.
+- Add the narrow isolated install-tree record path after a completed host command, recording host-added links without following them and rejecting declared-payload symlinks while preserving legacy full-tree semantics.
+
+### Changed
+
+- Consume skill-family-contracts, skill-family-harness-node, and skill-family-engineering-kit at the exact 0.15.0 release through their public package-root APIs.
+- Keep the 0.9.2 production plan PREPARED and immutable as an unpublished historical record now replaced by the 0.9.3 candidate; with an explicit target, only unfinished records that pass complete run, plan, digest/binding, and lineage validation and whose plan target matches participate in current recovery, while all other history remains diagnostics. Without a target, route still shows full-history diagnostics, but workflow selection remains based on the current diff and baseline.
+- The CodeBuddy plugin explicitly declares marketplace: release-skill, and both release-finish local-finish examples pass --root <project-root>.
+
+### Upgrade Notes
+
+Real-host acceptance can begin only after 0.9.3 is officially published and VERIFIED; the official 0.9.3 entry must be installed or reloaded first. A source candidate, an older installed entry, or the mere existence of plan and run files cannot complete real-host acceptance. Each selected host must complete a first successful update. On the second run, Claude, Kimi, CodeBuddy, and WorkBuddy must report `ALREADY_CURRENT`; Codex may report `UPDATED` only when it reinstalls the same exact 0.9.3 frozen reference, payload validation passes, and `restartRequired=true` is declared. The 0.9.2 plan was never published and remains an immutable historical record. With an explicit target, only unfinished records that pass complete run, plan, digest/binding, and lineage validation and whose plan target matches participate in current recovery; all other history remains diagnostics. Without a target, route still shows full-history diagnostics, but workflow selection remains based on the current diff and baseline.
+<!-- release-skill:changelog:end version=0.9.3 locale=en -->
+
+
+<!-- release-skill:changelog:start version=0.9.2 locale=en baseline=sha256:748e2f51de3ee9b773ddc2f0f2ffccb3756065c814ec218dffc738364ad25630 -->
+## [0.9.2] - 2026-08-30
+
+0.9.2 is a local source candidate for two release-finish maintenance updates and a route recovery maintenance update. Foundation remains pinned to 0.14.0, whose public temporary-workspace and raw-output APIs pass the default Node.js 22 macOS consumer composition. This note is not evidence of publication, real-host acceptance, consumer installation verification, or independent acceptance.
+
+### Security
+
+- The release-finish maintenance keeps the qualified frozen-plan boundary and the VERIFIED-run requirement; the consumer test combines the public withTemporaryWorkspace and superviseProcess.rawSink APIs under the default Node.js 22 macOS temporary directory.
+
+### Changed
+
+- Self-bootstrap now declares marketplace: release-skill explicitly for the CodeBuddy plugin.
+- Both release-finish local-finish examples now pass --root <project-root> explicitly.
+- Route recovery now skips only failed publish attempts that the current evidence-v2 writer contract proves never acquired release authority; unknown or corrupt history remains blocking DIAGNOSE with an exact path and formal next action.
+
+### Upgrade Notes
+
+Real-host acceptance can begin only after 0.9.2 is officially published and VERIFIED; the official 0.9.2 entry must be installed or reloaded first. A source candidate, an older installed entry, or the mere existence of plan and run files cannot complete real-host acceptance. Each selected host must complete a first successful update. On the second run, Claude, Kimi, CodeBuddy, and WorkBuddy must report `ALREADY_CURRENT`; Codex may report `UPDATED` only when it reinstalls the same exact 0.9.2 frozen reference, payload validation passes, and `restartRequired=true` is declared. In the current workspace, route still reports 63 DIAGNOSE records and 2 VERIFY records; the first UNKNOWN legacy record has no automatic safe recovery entry and requires the formal diagnostic action.
+<!-- release-skill:changelog:end version=0.9.2 locale=en -->
+
+
+<!-- release-skill:changelog:start version=0.9.1 locale=en baseline=sha256:71720f2bbde891ebccda25baf35ef03593d1f6aee1077aeccb3b4af4d2eddfc0 -->
+## [0.9.1] - 2026-08-28
+
+0.9.1 is a local source candidate for safer post-release host finishing. It now pins Foundation 0.14.0, whose public temporary-workspace and raw-output APIs pass the default Node.js 22 macOS consumer composition. This note is not evidence of publication, real-host acceptance, consumer installation verification, or independent acceptance.
+
+### Security
+
+- Real-host acceptance requires a qualified frozen release plan and a VERIFIED run from the same release lineage. The workflow confirms the exact plan digest and selected hosts before any host write. release-skill's optional local finishing never changes the terminal release state.
+
+### Changed
+
+- Pin skill-family-contracts, skill-family-harness-node, and skill-family-engineering-kit together at 0.14.0. A consumer test now combines the public withTemporaryWorkspace and superviseProcess.rawSink APIs under the default Node.js 22 macOS temporary directory.
+- Derive platform-manifest.json version ownership from package.json.version and check manifest freshness before prepare runs hooks, including docs-only and config-only workflows.
+- Expand ship's plan-approval summary from the frozen plan so reviewers can see public repositories, branch strategies, tags, npm targets, GitHub Releases, external action targets, waivers, and separately gated postPublish hooks.
+- Claude now re-observes the installed plugin after marketplace rebinding before deciding whether a plugin update is still required. Codex keeps the formal frozen-marketplace reinstall path.
+- Kimi accepts a managed installation without a .git directory when the package name, version, release tag, installed revision, managed root, and real payload all match. Legacy local-path entries are removed and reinstalled from the pinned release tag in one controlled TUI session.
+- CodeBuddy/WorkBuddy can update an existing bundled-family entry only when one remote query proves that the frozen tag and mutable marketplace branch both resolve to the frozen commit. The final installed list must contain exactly one entry with the expected marketplace, version, and revision.
+
+### Fixed
+
+- Prevent prepare from freezing a stale platform manifest into the public snapshot or npm tarball.
+- Remove the misleading claim that plan approval includes a requiresApproval postPublish checkpoint. Plan approval remains the single normal release-level approval; each gated postPublish hook needs its own approval record, bound to the plan digest and hook id for at most 24 hours.
+- Avoid a redundant Claude plugin update after marketplace rebinding has already removed or replaced the old installed entry.
+- Classify legacy Kimi local-path installations before managed-root checks so they can follow the explicit migration path.
+- Keep CodeBuddy/WorkBuddy host state unchanged when the target is absent, standalone, inaccessible, ambiguous, or inconsistent with the frozen release identity.
+
+### Upgrade Notes
+
+Real-host acceptance can begin only after 0.9.1 is officially published and VERIFIED; the official 0.9.1 entry must be installed or reloaded first. A source candidate, an older installed entry, or the mere existence of plan and run files cannot complete real-host acceptance. Each selected host must complete a first successful update and a second run that reports `ALREADY_CURRENT`.
+<!-- release-skill:changelog:end version=0.9.1 locale=en -->
+
+
 <!-- release-skill:changelog:start version=0.9.0 locale=en baseline=sha256:80f51046ce63386f75ed1a2b869cf3245732e9a1b040e11eb8942dba5f7c8fed -->
 ## [0.9.0] - 2026-08-28
 

package/INSTALL.md

@@ -2,7 +2,7 @@
 
 [简体中文](INSTALL.zh-CN.md)
 
-<!-- release-skill:release-version: 0.9.0 -->
+<!-- release-skill:release-version: 0.9.3 -->
 ## Prerequisites
 
 - Node.js 22.0.0 or later
@@ -114,15 +114,23 @@ tag pinned to the exact version (never the bare repository URL, which installs
 the latest release or default branch), confirm the trust prompt, then reload:
 
    ```
-   /plugins install https://github.com/ifoohoo/release-skill/releases/tag/release-skill-v0.9.0
+   /plugins install https://github.com/ifoohoo/release-skill/releases/tag/release-skill-v0.9.3
    /plugins reload
    ```
 
 After the release has reached `VERIFIED`, the optional `release-finish` workflow
 can perform the same TUI interaction only after explicit user confirmation. It
-then re-reads Kimi's managed installation root and requires the version, tag,
-revision, and Git commit to match the frozen plan. This local check is not part
-of `verify` and does not alter the `VERIFIED` release state.
+requires the package name, version, release tag, installed revision, and managed
+root to match the frozen plan. An exact current installation is checked before
+returning `ALREADY_CURRENT`. When an installation or migration occurs, the
+resulting managed installation is checked only after the operation. A `.git`
+directory is optional diagnostic evidence, not a success requirement. After an
+installation or migration, release-finish re-reads Kimi's managed installation root
+rather than reusing the pre-operation observation, then verifies the final identity
+and actual payload. If the existing entry is a legacy local-path
+install, release-finish removes it and installs the pinned release tag in the
+same TUI session before accepting the trust prompt and reloading. This local
+check is not part of `verify` and does not alter the `VERIFIED` release state.
 
 No receipt or attestation is required. The `attest` command remains available
 only for frozen plans created by older versions that lack the
@@ -152,10 +160,15 @@ reports `verifiedBySystem: false`. Install from the bundled-family marketplace
 for new plans; `attest` exists only for old frozen-plan compatibility.
 
 The optional `release-finish` workflow can inspect the CodeBuddy/WorkBuddy list
-after explicit confirmation. It reports `ALREADY_CURRENT` only when the listed
-marketplace, version, and frozen commit all match. Because the CLI cannot pin a
-ref, a mismatch remains `MANUAL_REQUIRED`; release-finish does not update to an
-unbound latest version.
+after explicit confirmation. It reports `ALREADY_CURRENT` only when one listed
+entry already matches the marketplace, version, and frozen commit. A matching
+bundled-family entry can be updated through the official marketplace and plugin
+update commands only after one remote query proves that both the frozen tag and
+the plan's mutable marketplace branch resolve to that same frozen commit. The
+final list must contain exactly one matching entry with the expected marketplace,
+version, and revision. Missing installations, standalone sources, inaccessible
+or conflicting refs, and any identity mismatch return `MANUAL_REQUIRED` without
+modifying the host.
 
 For a single session from a source checkout you can also point CodeBuddy at the
 generated plugin directory with `--plugin-dir <path>/adapters/workbuddy`; the

package/INSTALL.zh-CN.md

@@ -2,7 +2,7 @@
 
 [English](INSTALL.md)
 
-<!-- release-skill:release-version: 0.9.0 -->
+<!-- release-skill:release-version: 0.9.3 -->
 ## 前置条件
 
 - Node.js 22.0.0 或更高版本
@@ -104,14 +104,18 @@ Kimi Code 有交互式插件市场，但**没有可脚本化的非交互安装
 （切勿使用裸仓库地址，它会安装最新 release 或默认分支），确认信任提示后重新加载：
 
    ```
-   /plugins install https://github.com/ifoohoo/release-skill/releases/tag/release-skill-v0.9.0
+   /plugins install https://github.com/ifoohoo/release-skill/releases/tag/release-skill-v0.9.3
    /plugins reload
    ```
 
 发布达到 `VERIFIED` 后，可选的 `release-finish` 工作流可以在用户明确同意后执行
-同一套 TUI 操作。随后它会重新读取 Kimi 的受管安装根，并要求版本、标签、修订号和
-Git 提交与冻结计划一致。这个本机检查不属于 `verify`，也不会改变已经完成的
-`VERIFIED` 发布状态。
+同一套 TUI 操作。包名、版本、发布标签、已安装修订号和受管安装根都必须与冻结计划
+一致。精确当前安装会在返回 `ALREADY_CURRENT` 前核对；发生安装或迁移时，只在操作
+完成后核对结果。`.git` 目录只提供附加诊断，不是通过条件。发生安装或迁移后，
+release-finish 会重新读取 Kimi 的受管安装根，不复用操作前的观察；随后核对最终身份与
+真实载荷。若现有条目来自旧的本地路径安装，release-finish 会在同一个 TUI 会话中先
+移除，再按发布标签安装、确认信任并重新加载。这个本机检查不属于 `verify`，也不会改变
+已经完成的 `VERIFIED` 发布状态。
 
 新计划无需收据或人工证明。`attest` 命令仅兼容缺少
 `humanConsumersStrategy: manualFollowUps` 标记的旧冻结计划。
@@ -135,9 +139,12 @@ codebuddy CLI 可以添加市场并安装插件，但 **`plugin marketplace add`
 `ifoohoo/release-skill` 安装即可。新计划无需收据或人工证明；`attest` 只兼容旧冻结计划。
 
 可选的 `release-finish` 工作流会在用户明确同意后读取 CodeBuddy/WorkBuddy 的安装
-列表。只有市场、版本和冻结提交全部一致时才报告 `ALREADY_CURRENT`。由于 CLI 无法
-钉死 ref，不匹配时仍返回 `MANUAL_REQUIRED`；release-finish 不会改装到一个未绑定的
-latest 版本。
+列表。只有唯一条目的市场、版本和冻结提交全部一致时，才报告 `ALREADY_CURRENT`。
+对于同一 bundled-family 插件和市场，release-finish 只在一次远端查询证明冻结标签与
+计划声明的可变市场分支都解析到同一冻结提交后，调用正式的市场更新和插件更新命令。
+更新完成后，它会重新读取列表，并精确核对唯一条目的市场、版本和修订号。目标未安装、
+使用 standalone 来源、远端引用不可访问或冲突、身份不一致时，均返回
+`MANUAL_REQUIRED`，不修改宿主。
 
 源码检出后也可以用 `--plugin-dir <path>/adapters/workbuddy` 把 CodeBuddy 指向
 生成的插件目录做单会话使用；适配器不引用自身目录之外的任何文件。

package/README.md

@@ -2,7 +2,7 @@
 
 [简体中文](README.zh-CN.md) · Installation: [English](INSTALL.md) / [简体中文](INSTALL.zh-CN.md)
 
-<!-- release-skill:release-version: 0.9.0 -->
+<!-- release-skill:release-version: 0.9.3 -->
 Release preparation for Claude Code, CodeBuddy, WorkBuddy, Codex, and Kimi Code, with human-edited files kept intact.
 
 release-skill helps a maintainer answer three questions: what will be released,
@@ -14,37 +14,34 @@ Setup surfaces only the deterministic `compactSummary` review view; the full
 report stays in a temporary session directory.
 
 <!-- release-skill:managed:start id=latest-release -->
-**0.9.0** (2026-08-28)
+**0.9.3** (2026-08-31)
 
-0.9.0 is a local source candidate for multi-unit postPublish plans and optional post-release local finishing. This note records the intended scope and verification boundaries; it is not evidence of publication, consumer-installation verification, or independent acceptance. Release availability must be established from the corresponding release records and post-publish verification results.
+0.9.3 is a local source candidate for the four workflow safeguards and the narrow Hook cache v2 and isolated-install-tree integrations. It consumes the three Foundation packages at the exact 0.15.0 release. This note is not evidence of publication, real-host acceptance, consumer installation verification, or independent acceptance.
 
 **Security**
 
-- release-finish requires a plan-digest confirmation and a VERIFIED run from the same release lineage before any host command. Host updates use a restricted environment; Claude/Codex exact results are bound to the real installed payload, and every host fails closed when the identity evidence its protocol can provide is insufficient.
+- Unknown, corrupt, non-stable, or unsupported observations remain fail-closed. A cache hit never replaces a Hook execution when the authority or identity evidence is unavailable, and no TTL or ambient PATH inference is used.
+- Any host plan remains a qualified frozen-plan path and requires a VERIFIED-run before host acceptance; this source candidate does not provide that acceptance.
 
 **Added**
 
-- Plan version 3 freezes postPublish declarations per release unit as an ordered array. Each declaration carries its own targets, hooks, approval binding, execution bundle, checkpoints, and postVerify continuation while explicit plan versions 1 and 2 retain their established single-declaration behavior.
-- A new release-finish workflow derives a read-only local checklist from the frozen plan and VERIFIED run. After explicit user confirmation it can update Claude and Codex, drive the Kimi TUI and verify the resulting installation, or confirm that CodeBuddy/WorkBuddy already matches the frozen identity; CodeBuddy/WorkBuddy updates that cannot pin the frozen ref remain manual. None of these local actions changes the published release terminal state.
+- Add the opt-in pre-hook public-surface check, ship help and target-version conflict guard, verify lineage guidance, and evidence-based adoption suggestions without adding a new command, state, or approval authority.
+- Add the narrow Hook cache v2 consumer path: absolute-path and validated cwd-relative executable identity, closed input and environment binding, no TTL, and fail-closed cache reuse for bare PATH, PATHEXT, Windows, and unavailable observations while Hooks still execute cold.
+- Add the narrow isolated install-tree record path after a completed host command, recording host-added links without following them and rejecting declared-payload symlinks while preserving legacy full-tree semantics.
 
 **Changed**
 
-- The distribute and postVerify phases preflight every declaration before the first external write, then re-observe mutable remote proposal state during execution. Checkpoint identifiers are namespaced by release unit, and an earlier hook failure skips all later-unit work.
-- PostPublish hook identifiers are unique across the complete plan. Prepare, setup, approval, distribute, and postVerify consume the same validation rule before side effects.
-
-**Fixed**
-
-- Prevent a later unit's missing bundle or deterministic proposal conflict from being discovered only after an earlier unit has already written remotely.
-- Preserve PARTIAL when a checkpoint has succeeded before a later failure, and preserve BLOCKED when no external checkpoint succeeded.
-- Prevent duplicate target names and duplicate hook identifiers from collapsing evidence or approval identity across release units.
+- Consume skill-family-contracts, skill-family-harness-node, and skill-family-engineering-kit at the exact 0.15.0 release through their public package-root APIs.
+- Keep the 0.9.2 production plan PREPARED and immutable as an unpublished historical record now replaced by the 0.9.3 candidate; with an explicit target, only unfinished records that pass complete run, plan, digest/binding, and lineage validation and whose plan target matches participate in current recovery, while all other history remains diagnostics. Without a target, route still shows full-history diagnostics, but workflow selection remains based on the current diff and baseline.
+- The CodeBuddy plugin explicitly declares marketplace: release-skill, and both release-finish local-finish examples pass --root <project-root>.
 
 **Upgrade Notes**
 
-Prepare a new 0.9.0 plan to use plan version 3; do not edit or upgrade frozen older plans. Plan versions 1 and 2 remain readable only through their explicit compatibility path. release-finish is optional local follow-up, not publication evidence: branch merges, Kimi trust prompts, and local host changes still require explicit user consent, and unsupported exact-ref updates remain manual. Hook cache v2, safe full-tree inventory, the Audit offline release-record verifier, and mandatory public-marketplace host invocation gates remain outside this version.
+Real-host acceptance can begin only after 0.9.3 is officially published and VERIFIED; the official 0.9.3 entry must be installed or reloaded first. A source candidate, an older installed entry, or the mere existence of plan and run files cannot complete real-host acceptance. Each selected host must complete a first successful update. On the second run, Claude, Kimi, CodeBuddy, and WorkBuddy must report `ALREADY_CURRENT`; Codex may report `UPDATED` only when it reinstalls the same exact 0.9.3 frozen reference, payload validation passes, and `restartRequired=true` is declared. The 0.9.2 plan was never published and remains an immutable historical record. With an explicit target, only unfinished records that pass complete run, plan, digest/binding, and lineage validation and whose plan target matches participate in current recovery; all other history remains diagnostics. Without a target, route still shows full-history diagnostics, but workflow selection remains based on the current diff and baseline.
 <!-- release-skill:managed:end id=latest-release -->
 
 <!-- release-skill:capability:external-write-boundary -->
-> **Current boundary:** v0.9.0 is the current source candidate. This README
+> **Current boundary:** v0.9.3 is the current source candidate. This README
 > records intended scope and verification boundaries; it is not evidence of
 > publication, consumer-installation verification, or independent acceptance.
 > Release availability must be established from the corresponding release records
@@ -68,7 +65,7 @@ Prepare a new 0.9.0 plan to use plan version 3; do not edit or upgrade frozen ol
 > publish global preflight.
 
 <!-- release-skill:capability:safe-first-command -->
-> **Production path verified since the v0.1.1 milestone; v0.9.0 is the current
+> **Production path verified since the v0.1.1 milestone; v0.9.3 is the current
 > source candidate. Its README does not establish publication,
 > consumer-installation verification, or independent acceptance.**
 > The npm-installed CLI is the supported user entry. Source checkout
@@ -97,11 +94,12 @@ checkpoints remain intact and use matching-version recovery. Evidence v1 stays
 read-only; v2 uses a closed top level with phase extensions in `details`.
 Summaries and recovery suggestions are diagnostic, never publication authority.
 
-This version excludes R-02 safe full-tree inventory, R-05 Hook cache v2,
-R-10 historical-release verification implementation, real Kimi/WorkBuddy
-public-marketplace installation and invocation gates, and an Audit public
-offline release-record verifier.
-Foundation dependencies are pinned to the three released 0.13.0 packages.
+The current 0.9.3 candidate includes the narrow R-05 Hook cache v2 consumer
+path and the stable isolated install-tree record path (A2/A3). It still
+excludes R-02 safe full-tree inventory, R-10 historical-release verification
+implementation, real Kimi/WorkBuddy public-marketplace installation and
+invocation gates, and an Audit public offline release-record verifier.
+Foundation dependencies are pinned to the three released 0.15.0 packages.
 For new bundled-family Kimi/CodeBuddy plans, verify calls the released
 `runPluginVerification` entry with the complete frozen payload and records a
 minimal `install-only` observation receipt. Kimi maps to `kimi-code`; CodeBuddy
@@ -172,7 +170,10 @@ This scope summary is not a remote publication record or a consumer upgrade inst
 > Treat `prepare` as local-only only when those processes are absent or separately
 > audited and explicitly acknowledged. Production publishing uses
 > `ship --target-version <ver> → ship --approve --actor <name>`.
-> The `ship` command runs hooks and gates automatically; the only human gate is plan approval.
+> Frozen-plan approval is the only normal release-level human gate.
+> Here, “only human gate” means the only normal release-level approval. A postPublish hook whose effective
+> `requiresApproval` is true still needs a separate checkpoint approval bound
+> to the plan digest and hook id; that approval expires after at most 24 hours.
 > For bundled-family Kimi/CodeBuddy releases, Foundation first observes the
 > complete frozen payload in a fresh local installation. Real marketplace
 > installation and host invocation remain non-blocking manual follow-up tasks.
@@ -230,9 +231,10 @@ See [INSTALL.md](INSTALL.md) for CodeBuddy, Codex, and Kimi Code commands.
 ### Main workflow
 
 For routine releases, use the durable fast path. It persists authoritative
-paths and resumes safely, so a normal run needs at most one human gate: the
-frozen plan approval. `ship` runs configured hooks and verification gates
-automatically. For bundled-family Kimi/CodeBuddy releases, Foundation first
+paths and resumes safely. Frozen plan approval is the only normal
+release-level approval. `ship` runs configured hooks and verification gates
+automatically. A gated postPublish hook still needs its independent checkpoint
+approval; plan approval does not include it. For bundled-family Kimi/CodeBuddy releases, Foundation first
 observes the complete frozen payload in a fresh local installation. Real
 marketplace installation and host invocation remain non-blocking post-release
 manual tasks; the system does not verify their completion.
@@ -365,6 +367,7 @@ ACTOR=your-name
      --plan "$PLAN_PATH" --approval "$APPROVAL_PATH" --json)
    PUBLISH_RUN_PATH=$(printf '%s\n' "$PUBLISH_JSON" | jq -r '.runPath')
    ```
+   A valid approved production plan may enter `publish` directly; `route` is only a workflow suggestion. `publish` still requires the plan, approval, frozen digest and artifact identity, remote preflight, and fail-closed `PARTIAL` checkpoint rules.
    `PUBLISHED` is **not** the terminal state.
 9. **verify** — consumer install check:
    ```bash
@@ -686,7 +689,8 @@ postPublish:
 
 A hook with `requiresApproval: true` parks at `AWAITING_APPROVAL` until a
 checkpoint approval is minted and consumed. The approval record is bound to
-the plan digest and the hook id, and expires after 24 hours:
+the plan digest and the hook id, and expires after 24 hours. Frozen plan
+approval never includes this checkpoint approval:
 
 ```bash
 release-skill approve --plan "$PLAN_PATH" --hook hub-entry-proposal --actor "$ACTOR" --json
@@ -729,11 +733,12 @@ verification is automated. Kimi Code and CodeBuddy/WorkBuddy are returned as
 condition for the automated release to reach `VERIFIED`.
 
 After `VERIFIED`, the optional `release-finish` workflow can update Claude and
-Codex from the frozen marketplace identity, drive Kimi's TUI and re-check its
-managed installation, or confirm an already exact CodeBuddy/WorkBuddy entry.
-It requires explicit user confirmation, does not change release status, and
-leaves CodeBuddy/WorkBuddy mismatches for manual handling because that CLI
-cannot pin the frozen ref.
+Codex from the frozen marketplace identity, migrate or update Kimi through one
+controlled TUI session and verify its real managed payload, or update an existing
+bundled-family CodeBuddy/WorkBuddy entry when the frozen tag and mutable branch
+both resolve to the frozen commit. It requires explicit user confirmation and
+does not change release status. Missing, standalone, inaccessible, or ambiguous
+CodeBuddy/WorkBuddy targets remain manual and receive no host mutation.
 
 A `codebuddy-plugin` distribution may optionally declare `marketplace` (and
 `marketplaceSource`, the URL consumers use to add the marketplace) to override
@@ -751,7 +756,7 @@ the first minimal semantic boundary, so the static gate fails closed until the
 declaration is narrowed to concrete targets.
 
 <!-- release-skill:capability:unsupported-scope -->
-- **not in the current version:** Hook cache v2 (executor-identity receipts, R-05) — the current version keeps the v1 content-bound hook cache and never imports old run evidence; full consumer install-tree scanning (R-02) — only declared files are verified byte-for-byte; and a real-host (Kimi/WorkBuddy) verification gate — host verification stays a design and can never produce `PASS`/`VERIFIED` in this version;
+- **not in the current version:** full consumer install-tree scanning (R-02) — the current implementation handles only the declared public surface and the stable isolated install-tree record; and a real-host (Kimi/WorkBuddy) verification gate — host verification stays a non-blocking manual follow-up and does not produce `PASS`/`VERIFIED` evidence;
 - no automatic README generation or source-file overwrite;
 - no automatic conflict merge or rollback workflow;
 - no claim that a real production canary has run for marketplace verification;
@@ -762,8 +767,8 @@ declaration is narrowed to concrete targets.
   the ref is absent, while existing branches use an ordinary non-force push;
 - no Kimi or CodeBuddy/WorkBuddy marketplace install checkpoint in the release
   state machine — optional release-finish can drive and re-check Kimi locally,
-  or confirm an already exact CodeBuddy/WorkBuddy entry, but those results do
-  not become publication evidence;
+  or update an existing CodeBuddy/WorkBuddy entry under strict frozen-identity
+  checks, but those results do not become publication evidence;
 - no promise of Windows or broad multi-platform native write support;
 - no hidden commit, push, tag, release, or package publication.
 

package/README.zh-CN.md

@@ -2,43 +2,40 @@
 
 [English](README.md) · 安装指南：[中文](INSTALL.zh-CN.md) / [English](INSTALL.md)
 
-<!-- release-skill:release-version: 0.9.0 -->
+<!-- release-skill:release-version: 0.9.3 -->
 面向 Claude Code、CodeBuddy、WorkBuddy、Codex 和 Kimi Code 的发布准备工具，完整保留人工维护的文件内容。
 
 release-skill 帮助维护者回答三个问题：准备发布什么、还有哪些检查未通过、最终发布的内容是什么。它不重新生成、也不回写项目源文件。`prepare` 把每个配置的公开文件复制到隔离快照并验证字节——先冻结并供人工审阅，再从同一份冻结产物发布。`setup` 只显示确定性的 `compactSummary` 审阅视图，完整报告保留在临时会话目录中。
 
 <!-- release-skill:managed:start id=latest-release -->
-**0.9.0** (2026-08-28)
+**0.9.3** (2026-08-31)
 
-0.9.0 是多发布单元 postPublish 计划和可选发布后本机收尾能力的本地源码候选。本说明记录预期范围与验证边界，不代表已经发布、完成消费者安装验证或通过独立验收。版本是否可用，须以对应的生产发布记录和发布后验证结果为准。
+0.9.3 是四项工作流安全修补、Hook cache v2 窄接线和稳定隔离安装树记录接线的本地源码候选。三项 Foundation 依赖均精确消费已发布的 0.15.0。本说明不代表已经发布、完成真实宿主验收、完成消费者安装验证或通过独立验收。
 
 **安全**
 
-- release-finish 在执行宿主命令前，要求确认计划摘要，并核对同一发布血缘的 VERIFIED run。宿主更新只传入受限环境；Claude/Codex 的精确结果绑定真实安装载荷，各宿主在自身协议能够提供的身份依据不足时都会失败关闭。
+- 未知、损坏、非稳定或不支持的观察结果继续失败关闭。权威或身份证据不足时，缓存命中不能替代 Hook 执行；不使用 TTL，也不从环境 PATH 推断可执行文件身份。
+- 任何宿主计划都必须是合格冻结计划，且宿主验收要求 VERIFIED run；本源码候选不提供该验收。
 
 **新增**
 
-- 计划版本 3 按发布单元冻结有序的 postPublish 声明数组。每项声明分别绑定目标、Hook、批准、执行包、检查点和 postVerify 后续动作；显式的计划版本 1、2 继续保持既有单声明语义。
-- 新增 release-finish 工作流。它从冻结计划和同一血缘的 VERIFIED run 派生只读本机收尾清单；用户明确同意后，可更新 Claude 和 Codex、驱动 Kimi TUI 并复验安装结果，或确认 CodeBuddy/WorkBuddy 已经精确匹配冻结身份。CodeBuddy/WorkBuddy 无法钉死冻结 ref 时仍转人工处理；这些本机动作都不改变已经完成的发布终态。
+- 新增可选的 Hook 前公开表面检查、ship 帮助与目标版本冲突保护、verify 血缘提示和基于证据的接入建议，不增加新命令、状态或批准权威。
+- 新增窄范围 Hook cache v2 消费路径：支持绝对路径和经真实 cwd 校验的 cwd-relative executable identity，绑定封闭输入与环境，无 TTL；裸 PATH、PATHEXT、Windows 或观察不可用时仅禁止缓存复用，Hook 仍正常冷执行。
+- 新增宿主命令完成后的稳定隔离安装树记录路径：记录宿主附加链接但不跟随；声明载荷中的 symlink 仍失败关闭，同时保留 legacy 全树语义。
 
 **变更**
 
-- distribute 和 postVerify 在首次外部写入前预检全部声明，执行时重新观察可能变化的远端 proposal 状态。检查点 ID 按发布单元区分；前一项 Hook 失败后，后续单元全部跳过。
-- 整份计划中的 postPublish Hook ID 必须唯一。prepare、setup、批准、distribute 和 postVerify 在副作用发生前复用同一条校验规则。
-
-**修复**
-
-- 修复后续单元缺执行包或存在确定性 proposal 冲突时，前序单元已经写入远端的问题。
-- 任一检查点成功后发生后续失败时保留 PARTIAL；没有外部检查点成功时保持 BLOCKED。
-- 避免不同发布单元使用同名 target 或重复 Hook ID 时，证据与批准身份发生碰撞。
+- 通过公开包根 API 精确消费 skill-family-contracts、skill-family-harness-node 和 skill-family-engineering-kit 0.15.0。
+- 保留从未发布的 0.9.2 production plan 作为不可变历史记录；它已由 0.9.3 候选取代。显式传入目标时，只有完整通过 run、plan、digest/binding 和 lineage 校验且计划目标匹配的未完成记录，才参与当前恢复；其他历史仅保留为 diagnostics。未传目标时仍展示全历史 diagnostics，但 workflow 始终按当前 diff 和 baseline 选择，历史不能覆盖工作流。
+- CodeBuddy plugin 显式声明 marketplace: release-skill，两个 release-finish local-finish 示例都显式传入 --root <project-root>。
 
 **升级说明**
 
-使用计划版本 3 时须重新生成 0.9.0 计划，禁止修改或升级已经冻结的旧计划。计划版本 1、2 只通过显式兼容路径读取。release-finish 是可选的本机后续动作，不构成发布证据：分支合并、Kimi 信任提示和本机宿主修改仍须用户明确同意；宿主不支持精确 ref 更新时继续转人工处理。本版不包含 Hook cache v2、安全整树盘点、Audit 离线发布记录验证器或强制的公开市场宿主调用门禁。
+只有 0.9.3 正式发布并达到 VERIFIED，且先安装或重载正式的 0.9.3 入口，才能开始真实宿主验收。源码候选、旧的已安装入口或仅存在计划和运行文件都不能完成真实宿主验收。每个选定宿主都须首次成功更新。第二次运行时，Claude、Kimi、CodeBuddy 和 WorkBuddy 必须返回 `ALREADY_CURRENT`；Codex 可以返回 `UPDATED`，但仅当再次安装同一精确 0.9.3 冻结引用、载荷验证通过且声明 `restartRequired=true`。0.9.2 计划从未发布，作为不可变历史记录保留并已由 0.9.3 候选取代。显式传入目标时，只有完整通过 run、plan、digest/binding 和 lineage 校验且计划目标匹配的未完成记录，才参与当前恢复；其他历史仅保留为 diagnostics。未传目标时仍展示全历史 diagnostics，但 workflow 始终按当前 diff 和 baseline 选择，历史不能覆盖工作流。
 <!-- release-skill:managed:end id=latest-release -->
 
 <!-- release-skill:capability:external-write-boundary -->
-> **当前边界：** v0.9.0 只是当前源码候选。本 README 记录预期范围与验证边界，
+> **当前边界：** v0.9.3 只是当前源码候选。本 README 记录预期范围与验证边界，
 > 不代表已经发布、完成消费者安装验证或通过独立验收。
 > 版本可用性以对应发布记录及发布后验证结果为准。
 > v0.4.1 是更早的已发布里程碑（v0.2.2 曾处于已发布状态，后因平台验证收敛修复而更新）。
@@ -54,7 +51,7 @@ release-skill 帮助维护者回答三个问题：准备发布什么、还有哪
 > 远端唯一性检查在 `publish` 全局预检执行。
 
 <!-- release-skill:capability:safe-first-command -->
-> **生产路径自 v0.1.1 里程碑起已完成真实生产验证；v0.9.0 是当前源码候选，本 README 不证明该候选已经发布、完成消费者安装验证或通过独立验收。**
+> **生产路径自 v0.1.1 里程碑起已完成真实生产验证；v0.9.3 是当前源码候选，本 README 不证明该候选已经发布、完成消费者安装验证或通过独立验收。**
 > npm 安装的 CLI 是受支持的用户入口；源码 checkout 保留为开发/贡献者路径。
 >
 > **第一条命令：**
@@ -72,9 +69,9 @@ marketplace 委托目标工作区发布的边界不变。
 
 旧 production 计划缺少 `sourceAuthority` 时，在外部写入前拒绝。未发生外部写入的计划必须重新 prepare 并批准新摘要，不能补写旧计划或迁移批准。已有 `PARTIAL` 保留检查点，走匹配版本的恢复路径。evidence v1 只读；v2 顶层封闭，阶段扩展放在 `details`。摘要和恢复建议只作诊断，不构成发布权威。
 
-本版不包含 R-02 安全整树盘点、R-05 Hook cache v2、R-10 历史发布验证的产品实现、真实 Kimi/WorkBuddy 公开市场安装与调用门禁或 Audit 公开离线发布记录验证器。本范围说明不构成远端发布记录或消费者升级指引。
+当前 0.9.3 候选包含窄范围的 R-05 Hook cache v2 消费路径和稳定隔离安装树记录路径（A2/A3）。当前仍不包含 R-02 安全整树盘点、R-10 历史发布验证的产品实现、真实 Kimi/WorkBuddy 公开市场安装与调用门禁或 Audit 公开离线发布记录验证器。本范围说明不构成远端发布记录或消费者升级指引。
 
-Foundation 三包精确依赖已发布的 0.13.0。新生成的 Kimi/CodeBuddy 同仓计划在 verify 阶段调用正式 `runPluginVerification`，把完整冻结载荷交给 Foundation，并记录最小的 `install-only` 观察收据。Kimi 映射为 `kimi-code`，CodeBuddy 映射为兼容的 `workbuddy`。`observed` 与 `payloadMatches` 只表示机制观察结果，不代表远端已发布或 release-skill 已完成领域验证。独立市场来源、真实市场安装和宿主调用仍是人工后续任务。
+Foundation 三包精确依赖已发布的 0.15.0。新生成的 Kimi/CodeBuddy 同仓计划在 verify 阶段调用正式 `runPluginVerification`，把完整冻结载荷交给 Foundation，并记录最小的 `install-only` 观察收据。Kimi 映射为 `kimi-code`，CodeBuddy 映射为兼容的 `workbuddy`。`observed` 与 `payloadMatches` 只表示机制观察结果，不代表远端已发布或 release-skill 已完成领域验证。独立市场来源、真实市场安装和宿主调用仍是人工后续任务。
 
 <!-- release-skill:maturity:distribute-v1 -->
 <!-- release-skill:capability:distribute -->
@@ -128,7 +125,10 @@ Foundation 三包精确依赖已发布的 0.13.0。新生成的 Kimi/CodeBuddy
 > 可以写出项目目录、访问凭据、发起网络请求或执行远端发布。只有未配置这些进程，或已单独审计并
 > 显式确认其副作用时，才可以把 `prepare` 视为”仅本地”。生产发布使用
 > `ship --target-version <ver> → ship --approve --actor <name>`。
-> `ship` 自动执行 hooks 和门禁，唯一的人工门禁是计划批准。
+> 正常发布级流程只有一次人工批准：批准冻结计划。
+> 这里的“唯一”仅指正常发布级流程。
+> 有效 `requiresApproval: true` 的 postPublish hook 仍须等待独立 checkpoint 批准；
+> 该批准绑定计划摘要与 hook id，有效期最长 24 小时。
 > Kimi/CodeBuddy 的同仓发布先由 Foundation 在新鲜本地目录观察完整冻结载荷。
 > 真实市场安装和宿主调用仍是非阻塞的人工后续任务。
 
@@ -184,9 +184,9 @@ CodeBuddy、Codex 和 Kimi Code 的完整命令见 [INSTALL.zh-CN.md](INSTALL.zh
 
 ### 主流程
 
-日常发布优先使用可恢复的快速路径。它会持久化所有权威文件路径，正常流程只需
-一次可读的冻结计划批准。`ship` 自动执行配置中的 hooks 和验证门禁，不进入
-hook 授权等待态。Kimi/CodeBuddy 的同仓发布先由 Foundation 在新鲜本地目录
+日常发布优先使用可恢复的快速路径。它会持久化所有权威文件路径。
+冻结计划批准是正常发布级流程的唯一批准门。`ship` 自动执行配置中的 hooks 和验证门禁，不进入
+hook 授权等待态。受限的 postPublish hook 仍须独立批准，计划批准不包含该 checkpoint。Kimi/CodeBuddy 的同仓发布先由 Foundation 在新鲜本地目录
 观察完整冻结载荷。真实市场安装和宿主调用仍是发布完成后的非阻塞人工后续任务，
 系统不核验其完成结果。
 
@@ -306,6 +306,7 @@ ACTOR=your-name
      --plan "$PLAN_PATH" --approval "$APPROVAL_PATH" --json)
    PUBLISH_RUN_PATH=$(printf '%s\n' "$PUBLISH_JSON" | jq -r '.runPath')
    ```
+   持有合法批准的 production plan 时可以直接进入 `publish`；`route` 只是工作流建议。`publish` 仍要求计划、批准、冻结摘要与制品身份、远端预检，并在检查点失败时保持 fail-closed 的 `PARTIAL` 规则。
    `PUBLISHED` **不是**终态。
 9. **verify** — 消费者安装检查：
    ```bash
@@ -587,7 +588,7 @@ postPublish:
       envAllowlist: [CI]
 ```
 
-`requiresApproval: true` 的 hook 停留在 `AWAITING_APPROVAL`，直到 checkpoint 批准被铸造并消费。批准记录绑定 plan digest 与 hook id，24 小时后过期：
+`requiresApproval: true` 的 hook 停留在 `AWAITING_APPROVAL`，直到 checkpoint 批准被铸造并消费。批准记录绑定 plan digest 与 hook id，24 小时后过期。冻结计划批准不包含该 checkpoint 批准：
 
 ```bash
 release-skill approve --plan "$PLAN_PATH" --hook hub-entry-proposal --actor "$ACTOR" --json
@@ -621,9 +622,10 @@ release-skill ship --root "$PROJECT" --hook-approval "$HOOK_APPROVAL_PATH" --jso
 每个适配器闭包都自带 CLI、skills 和 schemas 副本，安装后无需外部依赖即可运行。Claude/Codex 验证是自动化的；Kimi Code 和 CodeBuddy/WorkBuddy 以 `manualFollowUps` 返回并标记 `verifiedBySystem: false`，其完成情况不阻塞自动发布进入 `VERIFIED`。
 
 发布达到 `VERIFIED` 后，可选的 `release-finish` 工作流可以按冻结市场身份更新 Claude
-和 Codex、驱动 Kimi TUI 并复查受管安装，或确认 CodeBuddy/WorkBuddy 已经精确匹配。
-它要求用户明确同意，不改变发布状态；由于 CodeBuddy/WorkBuddy CLI 无法钉死冻结
-ref，不匹配时仍转人工处理。
+和 Codex，也可以在同一个受控 TUI 会话中迁移或更新 Kimi，并核对真实受管载荷。
+对于已有的 bundled-family CodeBuddy/WorkBuddy 条目，只有冻结标签与可变分支都解析到
+冻结提交时才允许更新。该流程要求用户明确同意，且不改变发布状态。目标缺失、使用
+standalone 来源、远端不可访问或身份含糊时仍转人工处理，不修改宿主。
 
 `codebuddy-plugin` 分发可以可选地声明 `marketplace`（以及 `marketplaceSource`，即消费者添加市场所用的 URL）来覆盖默认统一市场 `artifact-skill-set`；未声明的分发保持默认值，冻结计划字节不变。
 
@@ -635,13 +637,13 @@ ref，不匹配时仍转人工处理。
 静态门禁会阻断，直到入口声明收窄为具体目标。
 
 <!-- release-skill:capability:unsupported-scope -->
-- **当前版本不含：** Hook cache v2（执行器身份收据，R-05）——当前版本保持 v1 内容绑定缓存，且从不导入旧运行证据；消费者安装整树盘点（R-02）——只对声明文件做逐字节核对；真实宿主（Kimi/WorkBuddy）验证门禁——宿主验证仍是设计，本版本中不能产生 `PASS` 或 `VERIFIED`；
+- **当前版本不含：** 消费者安装整树盘点（R-02）——当前版本只处理声明的公开表面和稳定隔离安装树记录；真实宿主（Kimi/WorkBuddy）验证门禁——宿主验证仍是非阻断的人工后续任务，不产生 `PASS` 或 `VERIFIED` 证据；
 - 不自动生成 README，不覆盖项目源文件；
 - 不自动合并冲突，也不要求回滚工作流；
 - 不声称已经替项目完成真实生产 canary，不声称已完成真实插件市场验证；
 - `prepare --online` 只观察 bound 前序基线；目标唯一性由 publish 全局预检完成；
 - 不覆盖已有 branch/tag/Release，不 unpublish npm；
-- 发布状态机不提供 Kimi 或 CodeBuddy/WorkBuddy marketplace 安装检查点——可选的 release-finish 可以在本机驱动并复查 Kimi，或确认 CodeBuddy/WorkBuddy 已经精确匹配，但这些结果不构成发布证据；
+- 发布状态机不提供 Kimi 或 CodeBuddy/WorkBuddy marketplace 安装检查点——可选的 release-finish 可以在本机驱动并复查 Kimi，也可以在严格核对冻结身份后更新已有 CodeBuddy/WorkBuddy 条目，但这些结果不构成发布证据；
 - 不承诺 Windows 或广泛的跨平台原生写入；
 - 不会隐藏地 commit、push、打 tag、创建 Release 或发布包。
 

package/adapters/claude/.claude-plugin/marketplace.json

@@ -9,7 +9,7 @@
     {
       "name": "release-skill",
       "source": "./",
-      "version": "0.9.0",
+      "version": "0.9.3",
       "description": "Safe preparation and frozen GitHub/npm production publishing with full happy end verification",
       "author": {
         "name": "广州市风荷科技有限公司"