fix: make Host updates simple and fast

Host repair could fail while adopting the published OpenCode Runtime, then
repeat package and payload verification and carry durable metadata snapshots
for recovery. Host preparation now verifies each acquired compound archive
once, adopts signed Agent and Runtime metadata without rereading payload trees,
and retries failed work by cleaning staging and preparing fresh.

The desktop and Agent versions are advanced to 0.11.9 with the approved
bilingual release notes. Remote Projects remain a disabled-by-default technical
preview, Agent packages remain separate Linux x64/arm64 releases, and this
release has no LoongArch preview.

Release note: 修复 Host 更新采用失败，移除重复远端包体校验，并将中断恢复简化为清理暂存后重新准备。

docs/architecture/remote-host-and-goodbuddy-agent-design.md

@@ -14,7 +14,7 @@ Main-only 模型桥、断线恢复、输出重放、同一 OpenCode Session 续
 Host 上完成 provider-free 验证。上一轮 Linux x64 验收使用 Agent `0.11.2-e2e.12` 与
 OpenCode Runtime `1.18.9` 完成了一次有界真实模型工具调用；加入每 helper 随机 loopback
 路径 capability 后，Agent `0.11.7` 已通过独立 workflow 发布 Linux x64/arm64 复合包和
-签名累计目录；当前源码准备 `0.11.8`，修复 Host 更新并消除重复 payload 验证。失败的
+签名累计目录；当前源码准备 `0.11.9`，修复 Host 更新并消除重复 payload 验证。失败的
 `agent-v0.11.3` 保持不可变且未发布。
 
 ## 产品语义
@@ -108,16 +108,16 @@ Detached GoodBuddy Agent
   bootstrap Node；约 294 MiB 完整包不会一次读入 Main `Buffer`，Host 仍再次校验完整包。
 - 两种 acquisition 交付到固定 operation staging 后，完全共用 control-plane
   `prepare → commit → Agent activate/health → Runtime activate → finalize → cleanup`。
-  commit 终态持久化；通道丢失时 `commit-status` 读取终态，或从已认证准备状态幂等完成
-  中断的目录/metadata 发布，不重新下载或准备包。prepare
-  完成后、commit 前快照 Agent/Runtime 五个 metadata 文件，任一组件 adoption 失败都恢复其原字节或原缺失
-  状态；已经发布的 side-by-side payload 可以保留但不能成为 current。确认 adoption 后
-  才显式 cleanup；cleanup 失败只保留维护重试，不回滚健康环境。Host 在 prepare 解包时
+  Main 只保存清理 operation staging 所需的 operation ID。中断或 adoption 失败后，下次
+  更新尽力清理旧暂存并重新 prepare，不保存或恢复 Agent/Runtime metadata 副本。确认
+  adoption 后才显式 cleanup；cleanup 失败不回滚健康环境，也不阻塞下一次 fresh prepare。
+  Host 在 prepare 解包时
   完成一次完整 payload 校验，commit 和后续注册检查不再遍历包体。首次 bootstrap 不依赖
   既有 Agent daemon，也不要求 format v1 归档携带 `agent/lib/package-installer.cjs`。
 - 即使版本号均为当前版本，Host 卡片仍提供同版本“重新安装”，用于修复 registry、签名
   或安装 identity 异常。GoodBuddy-owned 同 digest 目录损坏时先隔离后替换，并在发布或
-  激活失败时恢复；不要求删除 Host、凭据或引用项目。
+  原子 commit 失败时恢复；commit 成功后的激活失败保留新发布内容，下次点击重新安装时
+  清理旧暂存并重新 prepare/adopt。不要求删除 Host、凭据或引用项目。
 - Host 卡片的“版本匹配”badge 只表达版本事实，不代表 Agent 正在运行或环境健康。重新安装
   失败时明确显示本次操作未完成，并以随后重新检查的版本卡片表达当前事实；提交结果
   不确定时不声称旧版本未被替换。
@@ -246,7 +246,7 @@ Execute 不经过 Ask 的 bubblewrap profile：
 - 2026-08 的本地 fixture 完整验证 Linux x64 Agent `0.11.2-e2e.12`、Node `24.19.0`
   和 Agent protocol `2.0`；当时没有 arm64 fixture，因此该记录不能作为当前独立发布
   的双架构验收。Agent `0.11.7` 后续已由原生 workflow 发布并公开验证双架构工件；
-  当前源码 lock 是修复候选 `0.11.8`。
+  当前源码 lock 是修复候选 `0.11.9`。
 - 正常 Host 更新路径把 Linux x64 Host 的 Agent 更新为 `0.11.2-e2e.12`，并确认
   OpenCode Runtime 已安装版本与所需版本均为 `1.18.9`。
 - 一条新的 Ask 用户操作只提交一次。OpenCode 先在 build 模型轮次请求一个原生

docs/architecture/remote-host-environment-provisioning-design.md

@@ -152,19 +152,13 @@ daemon 参与。两种 acquisition 的差别只在于如何把同一个签名 co
    `prepare` channel 发送有界 one-shot installer 与结构化输入。
 2. Host 在解包写入准备目录的同一遍处理中校验归档大小、SHA-256、外层及内层签名、
    平台、架构、协议和每个 payload digest；不再先完整扫描 payload、再重复解包和哈希。
-3. `prepare` 完成后、`commit` 前按原字节记录 Agent 与 Runtime 的五个
-   current/registry metadata 文件，
-   同时记录原本缺失的状态。
-4. `commit` 只复核有界的签名 manifest、准备回执和入口 metadata，再以目录 rename 发布
+3. `commit` 只复核有界的签名 manifest、准备回执和入口 metadata，再以目录 rename 发布
    已准备内容及包内认证的公钥 registry/Runtime lock；不会重读归档或遍历 payload。
-   终态先持久化到 operation staging；控制通道丢失时，同一 operation 的
-   `commit-status` 读取终态，或从已认证准备状态幂等完成中断的 rename/metadata 发布。
-5. commit 后在同一条已固定身份的 SSH lease 上执行 Agent bootstrap/readiness 和 Runtime
+4. commit 后在同一条已固定身份的 SSH lease 上执行 Agent bootstrap/readiness 和 Runtime
    activate。新 Agent 最多完整验证一次，新 Runtime 最多完整验证一次；注册成功后的
    health、capabilities 和 prompt 启动只读取 registry、签名 manifest 与入口 metadata。
-   adoption 失败时停止候选，并把五个 metadata 文件恢复为原字节或原缺失状态。
-6. Main 确认 adoption 后显式执行 cleanup。cleanup 失败只保留待重试的有界 operation，
-   不回滚已经健康的 Agent/Runtime。
+5. Main 确认 adoption 后显式执行 cleanup。cleanup 失败不回滚已经健康的 Agent/Runtime，
+   也不阻塞下一次更新。
 
 这不是两个并行安装管理器，也不存在把 Agent 与 Runtime payload 逐文件走 SFTP 安装的
 第二条路径。两种 acquisition 共享相同的 prepare、commit、adoption、finalize 与 cleanup。
@@ -194,8 +188,8 @@ Host 下载返回明确失败；本次操作不自动切换 acquisition，用户
   Runtime。
 - 每次显式安装或重装都从本次已经校验并解包的准备目录原子替换对应 Agent 与 Runtime
   digest 目录，不为节省本机磁盘写入而重新遍历旧目录，也不使用跨安装硬链接。
-- 操作响应丢失后的同 operation 重试只检查签名 manifest、registry identity 和三份小型
-  trust metadata，不重新读取归档或 payload；正常 cleanup 随后删除准备目录。
+- 操作中断后不续写旧 operation。下一次更新尽力清理其 staging，并从签名候选重新
+  prepare；正常 cleanup 随后删除本次准备目录。
 
 只有真实包体和发布频率证明网络成本仍不可接受时，才另行设计 Agent、Node 和 Runtime
 独立签名组件目录；本功能不提前引入第二套发布协议。
@@ -220,14 +214,11 @@ Host 下载返回明确失败；本次操作不自动切换 acquisition，用户
 
 同一 Host identity 同时只允许一个由用户启动、Main-owned 的准备操作。重复观察者加入
 已有操作，不启动第二次发布；窗口关闭、显式取消、Host identity 改变或 Main 退出时执行
-有界取消。Main 在 commit 前为该 Host 持久化一个不含凭据的 pending operation 记录，
-其中包含五份有界 metadata 的原字节/原缺失快照；
-commit 指令开始后若 SSH 通道、输出或终态丢失，当前操作保留该记录和远端 staging。
-下一次重试或应用重启后的首次操作先对同一 Host identity 执行 `commit-status` 并
-恢复 adoption；恢复中的 Agent/Runtime adoption 失败仍使用该持久化快照回滚。它不会
-重新下载或准备包，也不开始第二条 acquisition。环境健康后再重试
-cleanup，确认清理后删除 pending 记录。
-取消在最终原子切换完成后不再伪装成回滚成功。
+有界取消。Main 只为该 Host 持久化一个不含凭据的 version-1 pending operation ID，用于
+下一次操作开始时尽力清理旧 staging。无论旧 cleanup 成功、目标已变化还是旧记录损坏，
+都删除这条可丢弃记录并开始 fresh prepare；不保存远端 metadata 副本，不续写旧 commit，
+也不跨重启恢复 adoption。当前操作中可确定的失败会立即尽力 cleanup。环境已健康后的
+cleanup 失败不回滚环境，也不阻塞下一次更新。
 
 ## 项目创建与切换
 
@@ -277,8 +268,9 @@ cleanup，确认清理后删除 pending 记录。
   这些路径不会取得安装包、发布组件或通过 SFTP 扫描 payload。
 - Host 卡片即使显示相同版本也保留显式重装操作，用于修复 registry、签名或 payload
   identity 异常；若同一 digest 的 GoodBuddy-owned 目录校验失败，重装会先隔离旧目录，
-  完整发布并验证新目录，失败时恢复旧目录。重装不要求删除 Host、凭据或项目，也不会处理
-  所有者异常、符号链接或非 GoodBuddy 管理路径。
+  并在原子 commit 失败时恢复旧目录。commit 成功后的 adoption 失败保留新发布内容，
+  下次重装清理旧暂存并重新 prepare/adopt。重装不要求删除 Host、凭据或项目，也不会
+  处理所有者异常、符号链接或非 GoodBuddy 管理路径。
 - 由桌面控制面打包有界 one-shot installer，并通过固定短命令 `exec sh -s` 和 stdin
   发送脚本及结构化输入，避免 SSH command 长度限制；既有 package format v1 归档内固定
   Node 负责解码和运行它。
@@ -296,9 +288,8 @@ cleanup，确认清理后删除 pending 记录。
 - 如果 Host 未就绪或版本不兼容，项目仍可在本地选择，但实际远程操作失败；不再走旧的
   隐式安装。
 - 已下载或导入的本地 `.gbagent` 保持可用，不能因加入远程直连而迁移或删除。
-- `0.11.7` 遗留的 version-1 pending operation 没有持久化 metadata 快照，也没有新格式的
-  已解包准备状态；`0.11.8` 只清理其暂存并重新执行一次认证 prepare，不尝试用新 installer
-  续写旧 commit。
+- pending operation 保持 version 1，只记录 Host、目标 identity 与 operation ID，用于
+  尽力清理旧 staging；它不是远端环境状态或恢复日志。
 - 远程直连继续使用现有 package format version 1，不要求归档携带 installer，也不要求
   目录声明额外的 bootstrap 能力元数据。
 
@@ -330,7 +321,6 @@ cleanup，确认清理后删除 pending 记录。
     仍待完成。
 12. Host 不可达或远端目录不存在时，用户仍可从项目浮动管理入口删除本地项目；删除 Host
     会列出并本地清理全部关联项目，但不会连接 Host 或删除任何远端目录和内容。
-13. commit 终态可在通道丢失后用 `commit-status` 读取，或从已认证准备状态幂等完成；
-    Agent 或 Runtime
-    adoption 失败恢复五个 metadata 文件的原字节/原缺失状态；已健康环境的 cleanup
-    失败保留为维护重试，不触发环境回滚。
+13. 中断或 adoption 失败后的下一次更新只尽力清理旧 staging，然后 fresh prepare；
+    pending record 不包含远端 metadata 副本。已健康环境的 cleanup 失败不触发回滚，
+    也不阻塞下一次更新。

docs/development/release-runbook.md

@@ -0,0 +1,292 @@
+# GoodBuddy Release Runbook
+
+Read this runbook only when preparing, publishing, recovering, or verifying a
+desktop or GoodBuddy Agent release.
+
+This is an operator and CI procedure. It does not authorize adding application
+persistence, snapshots, journals, rollback engines, recovery protocols, or
+compatibility layers to automate release operations. Determine release recovery
+from the authoritative GitHub, OSS, workflow, and Git state, then use the
+smallest existing idempotent rerun or a new immutable version as specified
+below.
+
+## Release Packaging
+
+- Unless the user explicitly requests a local Windows package, never run local
+  Windows packaging or launch probes as part of release preparation. In
+  particular, do not run `npm run portable`, Windows
+  `npm run release:package`, direct `electron-builder` packaging, or launch a
+  locally packaged Windows app before publishing a release. Source validation
+  and the native GitHub Actions jobs are the release authorities.
+- After a release is published, confirm only that the expected Windows assets
+  exist in the public release metadata. Do not locally rebuild or launch the
+  Windows package, download or hash published installers, attach browser
+  automation to a packaged app, or perform exhaustive per-asset network probes
+  unless the user explicitly asks for that additional validation.
+- `.github/workflows/packages.yml` is the canonical cross-platform packaging
+  workflow. It validates and builds `out` once, then packages on six native
+  runners: Windows, macOS, and Linux, each for x64 and arm64.
+- The experimental Linux LoongArch (`loong64`) preview is built separately
+  through `build/loongarch-cross` by following
+  `docs/development/loongarch-preview-build.md`. It is not part of
+  `.github/workflows/packages.yml`, the six-runner GitHub Actions matrix,
+  standard release manifests, GitHub Release asset expectations, or the
+  production update index. Do not add it to those paths unless the user
+  explicitly requests a future production-support migration.
+- Run the unified packager with
+  `npm run release:package -- --platform <platform> --arch <arch>`. It only
+  packages for the native host and writes to
+  `dist/release/<platform>-<arch>`.
+- Default deliverables are NSIS and portable ZIP for Windows, DMG and ZIP for
+  macOS, and AppImage, DEB, and RPM for Linux. Every target includes
+  `release-manifest.json` with SHA-256 hashes.
+- `build/build-release.cjs` verifies the unpacked application, `app.asar`,
+  bundled Continue and OpenCode runtimes, executable architecture, and package
+  signatures before atomically replacing a release directory.
+- All desktop build paths, including local `portable`, package the Agent and
+  remote Runtime version locks plus the public signing-key registry without
+  embedding installable Linux Agent or remote Runtime payloads. Managed SSH is
+  optional: users explicitly download a compatible compound `.gbagent` package
+  from Settings or import one offline before GoodBuddy can install or update a
+  Host.
+- Each independently published Linux x64 or arm64 `.gbagent` contains the
+  Agent daemon, pinned Node, and the desktop-maintained compatible OpenCode
+  Runtime. Build both architectures on native GitHub Actions runners from one
+  immutable `agent-v<agentVersion>` tag.
+- Keep the GoodBuddy Agent source, shared protocol/contracts, runtime lock,
+  bundle tooling, and tests in this repository so a desktop commit identifies
+  the exact Agent source it expects. Do not create a separate Agent repository
+  or long-lived Agent release branch unless the Agent becomes an independently
+  released product serving multiple clients.
+- `.github/workflows/agents.yml` is the branch and pull-request build
+  verification workflow for GoodBuddy Agent. It must build Linux x64 and
+  arm64 on native runners from the checked-out commit, acquire the locked
+  official Node archive and locked OpenCode npm archive, verify every locked
+  digest, use only an ephemeral in-memory test signing identity, and verify the
+  resulting compound package and deterministic archive. It must not read
+  production signing secrets, publish installable release artifacts, or modify
+  the checked-in public key registry.
+- `.github/workflows/agent-release.yml` is the only production compound Agent
+  publication path. It requires an annotated immutable Agent tag, the protected
+  `agent-signing` Environment, native x64/arm64 builds, one production
+  GoodBuddy signing identity for every layer of the compound package and
+  catalog, a non-Latest GitHub Agent Release, and synchronized immutable
+  Beijing OSS objects plus the final signed latest-catalog pointer.
+- `.github/workflows/packages.yml` and `release:package` build only desktop
+  products. Missing Agent packages, remote Runtime inputs, or GoodBuddy signing
+  credentials must never block an ordinary desktop package or release.
+- Keep electron-builder invocations on `--publish never`. Main-branch builds
+  run validation and build the production bundle without running the native
+  package matrix. Manual builds upload 30-day GitHub Actions artifacts.
+  Version-tag builds verify and aggregate packages before publishing GitHub
+  Release assets. The macOS jobs sign, notarize, and verify packages when all
+  five Apple credentials are configured. With no Apple credentials they must
+  use the explicit `--unsigned` path, warn that Gatekeeper may block the
+  packages, and still complete; a partial credential set must fail rather than
+  silently downgrade.
+- Keep `ELECTRON_CACHE` and `ELECTRON_BUILDER_CACHE` under
+  `${{ runner.temp }}` in step-level workflow contexts. A cache beneath the
+  repository inherits the root `"type": "module"` and breaks electron-builder's
+  CommonJS macOS icon tool.
+- Tag builds must use `v${package.version}`. The workflow also supports manual
+  dispatch and main-branch changes to release tooling.
+
+### Agent Release Process
+
+- Agent releases use annotated `agent-v${agent-runtime-lock.agentVersion}` tags
+  and are separate from desktop `v${package.version}` releases. Confirm the
+  exact Agent release commit and tag with the user before creating or pushing
+  either.
+- The tagged commit must be reachable from protected `main`. The two native
+  jobs build the compound x64/arm64 packages from the same source and locks;
+  the catalog job rejects missing architectures, changed bytes for an existing
+  version/architecture identity, invalid prior signatures, and incompatible
+  matrix metadata.
+- Agent GitHub Releases are ordinary non-draft, non-prerelease releases but
+  must use `--latest=false`; they must never replace the desktop release marked
+  Latest. Publish immutable packages and the versioned catalog to
+  `agent-releases/v<agentVersion>/` in Beijing OSS, publish the GitHub Agent
+  Release, then atomically update the single `agent-releases/latest.json`
+  pointer to that version's immutable catalog and signature.
+- Do not report an Agent release complete until both public package
+  architectures match the signed catalog by size and SHA-256, the GitHub and
+  OSS catalog bytes/signatures are identical, the application can read the
+  selected source, and GitHub's repository Latest tag remains the desktop tag.
+
+### Tagged Release Process
+
+Every version-tag release must follow this sequence. A branch-only push does
+not require release notes.
+
+1. Confirm that the user wants a release tag and identify the exact release
+   commit and the new `package.json` version. Separately ask whether this
+   release should also receive an experimental LoongArch preview build; never
+   infer that choice from an earlier release.
+2. Find the latest stable version tag reachable before the release commit and
+   inspect the complete commit and file diff from that tag to the release
+   commit. For the first tagged release, inspect the relevant repository
+   history instead.
+3. Draft concise, user-facing release notes in both Simplified Chinese and
+   English based only on verified changes in that range. Use the titles
+   `GoodBuddy <version> 更新内容` and
+   `What's New in GoodBuddy <version>`, with corresponding `功能更新` /
+   `Features` and `问题修复` / `Bug Fixes` sections when applicable. The two
+   language versions must describe the same changes. Do not expose
+   internal-only details, credentials, private content, or unverified claims.
+4. Show the exact bilingual release-note draft to the user and wait for
+   explicit approval. If the release commit or either language version changes
+   after approval, inspect the updated tag range and request approval again.
+5. Write the approved notes to the single entry for the release version in
+   `resources/release-notes.json`. A failed unpublished candidate whose content
+   is carried forward must not retain a duplicate packaged entry.
+6. Verify that `package.json`, the root `package-lock.json` version, and
+   `package-lock.json.packages[""].version` all equal the release version. Run
+   `npm run release:notes:verify`, the required source validators, the
+   production build. The six native CI jobs remain the cross-platform
+   authority; do not add local packaging or packaged-app launch probes unless
+   the user explicitly requests them.
+   If the user requested a LoongArch preview in step 1, build it separately
+   from this exact candidate by following the LoongArch build document, record
+   its size and SHA-256, and keep it outside the standard GitHub/OSS release
+   asset set unless the user separately authorizes publishing it.
+7. Fetch both remotes immediately before tagging. Inspect any remote branch
+   movement instead of overwriting or silently merging it. Confirm the working
+   tree is clean, the candidate tag is unused locally and remotely, and the
+   exact approved commit has not changed.
+8. Only after all previous steps pass, create an annotated
+   `v${package.version}` tag at the exact approved commit. Push `main` to
+   `origin` and `github`, verify both branch SHAs, then push the tag to both
+   remotes and verify each peeled tag SHA (`refs/tags/<tag>^{}`) equals the
+   release commit.
+9. Keep both approved language versions as the single source for the GitHub
+   Release body and the packaged first-open release-notes modal. The modal
+   displays the release notes matching the current interface language and
+   contains no button linking to a full release page.
+10. Observe the tag workflow through publication and complete the public
+    verification checklist below. A successful push is not a completed
+    release.
+
+### OSS Publication Contract
+
+The tagged release job publishes through the GitHub Environment selected by
+`.github/workflows/packages.yml` (`aliyun-oss-release`) and reads the following
+effective GitHub Actions variables. Before a release or same-tag rerun can
+publish, verify that repository-, organization-, or environment-level
+resolution exposes:
+
+- `ALIYUN_OSS_BUCKET=goodbuddy`
+- `ALIYUN_OSS_ENDPOINT=https://oss-cn-beijing.aliyuncs.com`
+- a non-empty `ALIYUN_OIDC_PROVIDER_ARN` matching
+  `acs:ram::*:oidc-provider/*`
+- a non-empty `ALIYUN_ROLE_ARN` matching `acs:ram::*:role/*`
+
+For environment-scoped values, use the exact Environment name from the
+workflow; do not assume a similarly named UI environment such as `Production`
+contains the active variables.
+
+The Bucket and Endpoint are a deployment contract, not interchangeable
+examples. They must stay aligned with the trusted URL checks in
+`src/main/version-checker.ts`, `sites/app.js`, website validation, and related
+tests. A host, Bucket, Region, or CDN migration must update and validate every
+surface together before a new release.
+
+- Use GitHub OIDC and the RAM Role to obtain short-lived STS credentials.
+  Never add long-lived AccessKeys to repository or environment secrets.
+- Keep `ossutil` pinned. Its V4 signing requires the Region; derive it from the
+  canonical Endpoint, verify that the production value resolves to
+  `cn-beijing`, and pass `--region` to every `ossutil cp`, including the final
+  `latest.json` update.
+- Grant the RAM Role only the actions and prefixes required by the workflow.
+  It must be able to write immutable version objects and the final latest
+  pointer without granting unrelated administration privileges.
+- Upload release assets and `site-release.json` under the immutable
+  `releases/<tag>/` prefix first. Verify all 14 installer URLs publicly before
+  creating or publishing the GitHub Release. Update
+  `releases/latest.json` only after the GitHub Release is public and all prior
+  checks succeeded.
+- The expected GitHub Release contains 22 assets: 14 installers (two formats
+  for each Windows/macOS target and three formats for each Linux target), six
+  renamed target manifests, one aggregate `release-manifest.json`, and one `SHA256SUMS`.
+  `site-release.json` is an OSS publication artifact, not a GitHub Release
+  asset.
+
+### Failed Tag Recovery
+
+Classify a failed tag by the external side effects that completed before
+choosing a recovery:
+
+- If no source or release metadata must change, correct only the external
+  configuration and use **Re-run failed jobs** for the same immutable tag. Do
+  not change, move, delete, or recreate the tag.
+- If immutable OSS objects were partially uploaded but their source bytes are
+  unchanged, a same-tag rerun may idempotently re-upload or verify them. Never
+  point `latest.json` at a partially verified prefix.
+- If the GitHub Release is already public but the final latest-pointer step
+  failed, it is a published version. Keep its packaged notes and rerun the
+  failed release job for the same tag; do not classify it as an unpublished
+  candidate.
+- If code or release metadata must change, keep the failed tag immutable,
+  increment the patch version, obtain approval for the revised exact release
+  commit and notes, and create a new tag. Do not reuse the failed version.
+
+When recovering from a version tag whose workflow never published a public
+GitHub Release:
+
+- If a code or metadata change requires a higher version and a new tag, carry
+  the failed candidate's approved user-facing notes forward into the recovery
+  version, then remove the superseded failed version's entry from
+  `resources/release-notes.json`.
+- The packaged first-open modal must show that carried-forward content only
+  once under the recovery version. Never retain both the failed version and
+  its cumulative recovery copy, because users upgrading across them would see
+  duplicate content.
+- Never remove the packaged history for a version that successfully published
+  a GitHub Release. Verify the failed release state before treating an entry as
+  superseded.
+
+### Post-Publication Verification
+
+Do not report a release complete until all of the following are verified:
+
+1. The tag workflow and all six native package jobs succeeded. Verify the
+   recorded macOS signing mode: signed builds must pass `codesign`, `spctl`,
+   and `stapler`; unsigned builds must record the Gatekeeper caveat in the
+   Actions log and job summary. In the final release job, explicitly verify
+   the OSS configuration, OIDC authentication, release-index generation,
+   immutable upload, public asset check, GitHub Release publication, and
+   latest-pointer steps.
+2. The public GitHub Release is non-draft, non-prerelease, marked Latest, and
+   uses the expected tag and title. Its body must exactly match the Markdown
+   generated from the approved packaged bilingual notes.
+3. GitHub release metadata contains exactly the expected 22 uploaded asset
+   names, including the expected Windows x64 and arm64 assets. Do not download,
+   hash, launch, or send individual network probes to published installers
+   unless the user explicitly requests that additional validation.
+4. The Beijing `releases/latest.json` returns HTTP 200, has the expected stable
+   version, exact six targets and 14 installer entries, the trusted Beijing
+   URLs, and the GitHub fallback URL. It must match the immutable
+   `releases/<tag>/site-release.json`. Fetching and comparing these small JSON
+   metadata files is sufficient; rely on the successful publication job for
+   its per-asset public checks.
+5. The live website successfully fetches the index and produces the 14 correct
+   platform/architecture/format links from that metadata.
+6. Both remote `main` refs and both peeled tag refs still equal the approved
+   release commit, and the local working tree is clean.
+
+Never create or push a release tag, and never push a previously created
+release tag, before the release-note draft has received explicit approval.
+
+- Before a push that updates the `github` remote, ask whether the user wants a
+  release tag unless they already specified that choice. A branch-only push
+  does not require a version bump or tag. When the user requests a release,
+  verify that `package.json` and `package-lock.json` contain the same release
+  version, create `v${package.version}` at the exact commit being pushed, and
+  push that tag so the native package matrix and GitHub Release run.
+- Never move or reuse an existing release tag. If `v${package.version}` already
+  exists locally or on a remote at another commit, increment the package
+  version and create a new matching tag before the release push.
+- Verified release baseline on 2026-08-18: commit
+  `60119a4317118fa3f077db0382664f15266a6682`, annotated tag `v0.10.4`, and
+  GitHub Actions run `32038633609` attempt 2 succeeded through all six native
+  packages, GitHub Release publication, Beijing OSS publication, and the final
+  `latest.json` switch.

docs/prd/assistant-experience/assistant-workbar-and-execution-spaces-prd.md

@@ -589,12 +589,11 @@ attach 并读取 current registry，不存在项目中的旧 Host revision 或
 - Agent 与 Runtime 各自维护版本，签名摘要标识精确工件。Host 在解包到准备目录的同一遍
   处理中完成完整 payload 校验，commit 只复核签名 metadata 并原子替换 side-by-side
   目录，不重新读取归档、扫描旧目录或使用跨安装硬链接。
-- commit 终态持久化；控制通道丢失时，`commit-status` 读取终态，或从已认证准备状态
-  幂等完成中断的目录/metadata 发布，不重新下载或准备包。prepare 完成后、commit 前快照
-  Agent/Runtime 五个 metadata 文件；任一组件 adoption 失败恢复原字节或原缺失状态，
-  已发布 payload 不得成为 current。新 Agent/Runtime 各自最多完整验证一次；注册后的
+- Main 只保存清理 operation staging 所需的 operation ID。控制通道中断或 adoption 失败
+  后，下次更新尽力清理旧暂存并重新 prepare，不保存或恢复 Agent/Runtime metadata 副本。
+  新 Agent/Runtime 各自最多完整验证一次；注册后的
   health、capabilities 和 prompt 启动只检查 registry、签名 manifest 与入口 metadata。
-  确认 adoption 后显式 cleanup，cleanup 失败不回滚健康环境。
+  确认 adoption 后显式 cleanup，cleanup 失败不回滚健康环境，也不阻塞下一次 fresh prepare。
 - 握手报告 installation、Daemon boot identity、协议、系统、架构、用户监督器和能力。
 - 在远程执行路径规范化、Git、文件、PTY、进程组和 Runtime 管理。
 - 持久化有界 Agent 到 Main 输出；SSH 断开后 Agent 继续运行，同一 Agent 重连时只恢复