chore: prepare GoodBuddy 0.12.0 release

Update the desktop version, approved bilingual release notes, and synchronized English and Chinese feature matrices for the 0.12.0 candidate.

Release preparation now runs local tests, type checks, and lint without a local production build, then requires the main-branch CI build before tagging. The package matrix uses a native Windows arm64 runner and validates managed Python on every target without adding extra license files to the desktop package.

docs/development/release-runbook.md

@@ -12,12 +12,13 @@ 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.
+- Unless the user explicitly requests it, never run a local production build,
+  desktop package, or launch probe as part of release preparation. In
+  particular, do not run `npm run build`, `npm run build:bundle`,
+  `npm run portable`, `npm run release:package`, direct `electron-builder`
+  packaging, or launch a locally packaged app before publishing a release.
+  Local tests, type checks, and lint plus the main-branch and native tag 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
@@ -141,23 +142,24 @@ not require release notes.
    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.
+   `npm run release:notes:verify`, `npm test`, `npm run typecheck`, and
+   `npm run lint`. Do not run a local production build, packaging command, or
+   packaged-app launch probe unless the user explicitly requests one.
    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.
+7. Commit the approved candidate and confirm the exact release commit with the
+   user. Fetch both remotes, inspect branch movement instead of overwriting or
+   silently merging it, then push that commit to `main` on `origin` and
+   `github`. Require the candidate commit's main-branch GitHub Actions source
+   validation and production build to succeed before tagging.
+8. Fetch both remotes again immediately before tagging. Confirm the working
+   tree is clean, both remote `main` refs still equal the approved commit, the
+   candidate tag is unused locally and remotely, and the exact approved commit
+   has not changed. Only then create the annotated `v${package.version}` tag at
+   that commit, 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

docs/features/local-tool-environment/progress.md

@@ -5,8 +5,8 @@
 | 项目 | 内容 |
 | --- | --- |
 | 文档类型 | 功能进度 |
-| 状态 | 已实施，跨平台验收中 |
-| 版本 | 0.3 |
+| 状态 | 已实施，发布候选 CI 验收中 |
+| 版本 | 0.4 |
 | 日期 | 2026-09-02 |
 | 关联入口 | [工具执行环境](./README.md) |
 
@@ -17,8 +17,9 @@
 快照应用到新启动的本机 Runtime 与 stdio MCP。Windows x64 已完成真实托管 Node 和原生
 地址托管 Python 安装验证。
 
-该实现尚不能视为六平台发布验收完成：六个 OSS 镜像对象已发布并公开回读验证，但
-Windows ARM64、macOS 和 Linux 工件仍需原生 CI 验证，第三方许可证资源也尚未随包落地。
+六个 OSS 镜像对象已发布并公开回读验证。托管 Python 继续按需下载，Desktop 发行包不额外
+带入许可证文件。标准六平台打包任务已改用目标架构原生 Runner，并在打包前执行托管 Python
+的真实安装、SSL、pip 和 venv 探针；`0.12.0` 候选仍需通过这组 CI 才能完成对应跨平台验收。
 
 ## 已完成
 
@@ -60,8 +61,8 @@ Windows ARM64、macOS 和 Linux 工件仍需原生 CI 验证，第三方许可
 ## 待完成验收
 
 - [x] 发布六个平台/架构的字节完全相同 OSS 镜像对象并公开回读校验。
-- [ ] 将 CPython、PSF 和 python-build-standalone 适用许可证资源纳入发行包及构建校验。
-- [ ] Windows ARM64、macOS x64/ARM64、Linux x64/ARM64 原生 CI 安装、SSL、pip、venv 探针。
+- [x] 确认托管 Python 保持按需下载，Desktop 发行包不额外带入许可证文件。
+- [ ] Windows ARM64、macOS x64/ARM64、Linux x64/ARM64 原生 CI 安装、SSL、pip、venv 探针；工作流已接线，等待 `0.12.0` 候选运行结果。
 - [ ] 最低 Windows/macOS/glibc 支持矩阵和 Windows NuGet 签名核验。
 - [ ] 真实 JavaScript/Python SKILL 成果及 Node/Python stdio MCP 调用。
 - [ ] 自定义 Node/Python 在产品 UI 中的真实选择和任务执行。
@@ -71,12 +72,17 @@ Windows ARM64、macOS 和 Linux 工件仍需原生 CI 验证，第三方许可
 
 - 当前机器只能原生验证 Windows x64。其余五个平台必须由对应原生 CI 执行，不能用本机
   mock 代替。
-- 许可证文件和来源清单尚未进入 `resources/tool-environment`，发行合规验收未完成。
 
 ## 已验证证据
 
 ### 2026-09-02 完整实现
 
+- 发布准备确认不把按需下载的托管 Python 许可证文件加入 Desktop `extraResources`、解包
+  校验或 Portable ZIP 必需文件，避免该额外资源改变现有编译和打包路径。
+- 六平台打包矩阵在 `npm ci` 后先断言 Runner 架构，再执行
+  `GOODBUDDY_RUN_LIVE_TOOL_ENVIRONMENT=1` 的托管 Python 安装探针；Windows arm64 改用
+  `windows-11-vs2026-arm` 原生 Runner。发行资源与目录聚焦测试 `47/47` 通过。
+
 - `npm run typecheck` 通过。
 - `npm run lint` 通过。
 - `npm run build` 通过，Main、Preload 和 Renderer 生产 bundle 成功。

docs/features/local-tool-environment/technical-design.md

@@ -119,11 +119,11 @@ ELECTRON_RUN_AS_NODE=1 <process.execPath> <arguments...>
 - Windows x64 原生工件来自官方 `python` NuGet 包，Windows ARM64 来自官方
   `pythonarm64` NuGet 包。
 - macOS/Linux 原生工件来自 Astral `python-build-standalone`。
-- 目录包含版本、平台、架构、字节数、SHA-256、许可证、原生 Target 和 OSS Target。
+- 目录包含版本、平台、架构、字节数、SHA-256、原生 Target 和 OSS Target。
 - OSS 对象直接复制原生工件字节，不重新压缩或转换。
 - 安装包不无条件携带完整 Python。
 
-具体发行包和版本必须在实现前完成六平台工件、许可证、维护状态和 pip/venv 可用性核验。
+具体发行包和版本必须在实现前完成六平台工件、维护状态和 pip/venv 可用性核验。
 
 目录示例：
 
@@ -144,7 +144,6 @@ type ManagedToolArtifact = {
       url: string
     }
   }
-  licenseFiles: string[]
 }
 ```
 
@@ -342,7 +341,7 @@ Renderer 不能提交 PATH、环境变量、下载 URL、摘要、安装目录
 - Python SKILL 与 MCP。
 - 自定义解释器。
 - Ask/Execute、重建、取消和退出。
-- 六平台打包和许可证。
+- 六平台打包。
 
 这些阶段是开发顺序，不是可长期发布的残缺功能。合并能力前完成普通用户和专业用户的完整
 生产路径。