修复 macOS 渠道发布挑中残留产物，改为构建期核对包内版本与渠道身份

- build-macos-ci：构建前按后缀清空 macos/ 下的 *.app.tar.gz / *.sig / *.dmg / *.dmg.sha256，构建后读 Info.plist 核对版本与渠道身份，生成清单后再断言选中本轮更新包
- 新增 macos-release-identity.mjs 与单测：回归用例直接用线上 dev-mac 里那份 0.1.139 release 身份包
- prepare-macos-codex.test：残留清理断言改成按后缀全覆盖，并校验清理在构建前、身份核对在验签前
- Jenkinsfile.ai-game-creator-shell-macos-build：mac Job 增加身份守卫用例
- check:agc-update-channel-manifests：下载后解出 mac 包内 Info.plist 核对版本与身份，并按 2026-09-21 决策只要求 darwin-aarch64
- 文档：两份里程碑按现行决策修正口径并记录线上缺陷，decision-log 记决策与边界，pitfalls 记录「按目录扫描挑产物会选中残留」

docs/project-memory/plans/【里程碑】AGC macOS渠道更新落地-2026-09-17.md

@@ -36,10 +36,10 @@
 
 ## 验收标准
 
-- [ ] `dev-mac` 渠道清单包含两个 macOS 平台条目且指向同一个 universal 安装包与签名，对象在 OSS 上一致可下载。
+- [ ] `dev-mac` 渠道清单指向真实可下载的 arm64 更新包，且清单版本、包内版本与包内渠道身份三者一致（原「两个 macOS 平台条目指向 universal 产物」口径已被 2026-09-21「macOS 只出 arm64 单架构」决策取代；2026-09-28 只读核对发现线上 `0.1.142` 清单指向的其实是 `0.1.139` 的 release 身份包，见文末本轮核对）。
 - [ ] macOS 客户端能完成一次真实更新：检查、下载、安装、重启后运行新版本，且升级后产物仍是 universal 包。
 - [ ] 覆盖写渠道 latest 指针后，旧版本 macOS 客户端可升级到新版本；Windows 与 macOS 渠道互不干扰。
-- [ ] 未签名或未公证产物在发布阶段失败关闭，或在不满足条件时明确记录为未验证项而非静默通过。
+- [x] 未签名或未公证产物在发布阶段失败关闭，或在不满足条件时明确记录为未验证项而非静默通过（更新包 minisign 签名在 `build-macos-ci.mjs` 上传前用产物内公钥强制复核，缺签名/验不过即中止；Apple 代码签名与公证当前是 `adhoc`，按本条的第二种方式记录为未验证项，首装需 Gatekeeper 手动放行）。
 
 ## 证据要求
 
@@ -57,8 +57,13 @@
 
 ## 本轮核对（2026-09-28，线上 dev-mac 清单只读核对）
 
-- 第 1 条（`dev-mac` 清单含两个 macOS 平台条目且指向同一 universal 安装包与签名）**仍未勾选，并且这次拿到了线上反例**：
-  - `npm run check:agc-update-channel-manifests`（新增的只读核对脚本）拉取 `https://agc-dev.oss-rg-china-mainland.aliyuncs.com/agc/dev-mac/latest.json`：`version=0.1.142`、`pub_date=2026-09-24T11:35:31Z`、`commit=c07c10c0c`，`platforms` 只有 **`darwin-aarch64`**，因此「同时提供两个 macOS 平台键」判 FAIL。
-  - 同一份清单的对象与签名本身是自洽的：产物 `agc/dev-mac/0.1.142/陶泥儿 Release.app.tar.gz` 315,510,533 字节（HEAD 200）、`.sig` 420 字节且与清单内签名文本一致，下载后字节数一致、用 `tauri.conf.json` 里烘焙的 updater 公钥验签通过（`alg=ED`，`keyId=cb883447e3e87c4e`）。也就是说缺的不是签名可信度，而是 **universal（双平台键）发布**。
-  - 时间线解释：这次 `dev-mac` 发布（2026-09-24 `c07c10c0c`）早于 universal macOS 改造；同期 `dev-win` 已经发到 `0.1.154`（2026-09-28，commit `76cdb96c5`）。要让线上清单符合契约，需要用 mac 构建机重新发布一次 `dev-mac`。
-  - 待复核观察：该 `dev-mac` 更新产物文件名是「陶泥儿 **Release**.app.tar.gz」，而同一渠道的首装 DMG 是「陶泥儿**开发版**_0.1.142_aarch64.dmg」。channel-identity 约定 `dev` 渠道展示名为「陶泥儿开发版」，重发时要确认 mac 更新产物用的是渠道身份而不是 release 身份，避免同一台机器上并存/覆盖行为与预期不符。
+**先纠正口径**：本文件第 1 条原来写的是「两个 macOS 平台条目指向同一个 universal 包」，但 2026-09-21 决策（decision-log）已经把 macOS 改回 **arm64 单架构**，清单只登记 `darwin-aarch64`——线上单架构本身不是问题。本轮真正查出来的是另一件事：**清单指的包根本不是这一版、也不是这个渠道身份**。
+
+- `npm run check:agc-update-channel-manifests`（本轮新增的只读核对脚本，`AGC_UPDATE_VERIFY_DOWNLOAD=1` 会下载产物）对线上 `dev-mac/latest.json` 的核对结果：
+  - 清单自洽的部分（都 PASS）：`version=0.1.142`、`pub_date=2026-09-24T11:35:31Z`、`commit=c07c10c0c`；`platforms` 只有 `darwin-aarch64`（符合 2026-09-21 单架构决策）；更新包对象 315,510,533 字节与 `.sig` 420 字节都存在，清单签名与 `.sig` 文本一致；下载后字节数一致、用 `tauri.conf.json` 里烘焙的 updater 公钥验签通过（`alg=ED`、`keyId=cb883447e3e87c4e`）；首装 DMG `陶泥儿开发版_0.1.142_aarch64.dmg` 存在。
+  - **两处真 FAIL**：把更新包解开看 `Contents/Info.plist`，里面是 **`CFBundleShortVersionString=0.1.139`**（清单写的是 0.1.142）和 **`CFBundleIdentifier=world.genarrative.ai-game-creator.release` + `CFBundleName=陶泥儿 Release`**（本渠道应为 `world.genarrative.ai-game-creator` / `陶泥儿开发版`），产物文件名也叫「陶泥儿 Release.app.tar.gz」。
+  - 结论：`dev-mac` 渠道当前给 arm64 客户端提供的更新包是**旧版本 + 另一个渠道身份**的包。这既让「升级后版本没变」成立，也可能把 release 身份的应用装到 dev 渠道用户机器上，违反渠道安装身份隔离约定。第 1 条保持未勾选。
+- 根因与修复（本轮已落地，见 decision-log 2026-09-28 条目）：
+  - 根因：`build-macos-ci.mjs` 之前只删「本轮要写的文件名」，构建目录里上一轮遗留的 `陶泥儿 Release.app.tar.gz` 不会被清掉；而 `generateUpdateManifest()` 是**扫描目录按优先级挑产物**，于是挑走了那个残留文件。
+  - 修复：构建前按后缀清空 `macos/` 下的 `*.app.tar.gz`、`*.app.tar.gz.sig`、`*.dmg`、`*.dmg.sha256`；构建后读产物 `Contents/Info.plist` 断言版本与渠道身份；生成清单后再断言清单选中的就是本轮更新包。守卫逻辑在 `apps/ai-game-creator-shell/scripts/macos-release-identity.mjs`，单测 `macos-release-identity.test.mjs` 用线上那份 0.1.139 release 身份包做回归（`node --test` 59 passed，含新增 6 条）。
+- 仍未完成：需要用修好的 mac 管线重新发布一次 `dev-mac`（把 `latest.json` 指到本轮的新对象），然后重跑 `npm run check:agc-update-channel-manifests` 才能把第 1 条勾上。发布需要 Jenkins 凭据与授权，本地无法执行。

docs/project-memory/plans/【里程碑】AGC更新发布管线渠道化-2026-09-17.md

@@ -36,7 +36,7 @@
 - [x] 渠道清单版本来自统一总号；显式传入的号低于本渠道当前清单版本时构建失败关闭，另一个渠道清单不受影响（原「按渠道独立递增」口径已由 2026-09-20 总版本号方案取代）。
 - [x] 渠道与目标平台不匹配、缺少签名私钥或私钥密码错误时发布失败关闭，不产生半成品清单。
 - [x] 发布后 OSS 上安装包、签名与渠道清单三者一致：清单内地址指向已存在的对象，签名与安装包匹配（2026-09-28 只读核对已发布的 `dev-win` / `dev-mac` 渠道，两个渠道的产物都下载后验签通过，见文末「本轮核对」）。
-- [x] universal macOS 产物的两个平台键指向同一对象同一签名，不存在只挂单一架构键或指向不存在对象的情况。
+- [x] universal macOS 产物的两个平台键指向同一对象同一签名，不存在只挂单一架构键或指向不存在对象的情况。（清单构建器对 universal 目标仍按此契约工作；但 2026-09-21 决策已把 macOS 发行改成 arm64 单架构，线上 `dev-mac` 按该决策只登记 `darwin-aarch64`，这条的线上口径以 macOS 里程碑第 1 条为准。）
 - [ ] Jenkins 归档与日志中不出现签名私钥内容，凭据只注入构建进程。（静态核对：`jenkins/Jenkinsfile.ai-game-creator-shell-build` 用 `withCredentials` 注入 `TAURI_SIGNING_PRIVATE_KEY` / `..._PASSWORD`，归档 glob 只含 `bundle/**/*.exe|*.sig|latest.json|legacy-latest.json|release-notes.txt` 与 `.jenkins-source-commit`，没有私钥文件；真实 Jenkins 运行的日志脱敏仍需一次 CI 构建取证。）
 - [x] 未显式指定渠道时按目标平台取默认渠道，且 `--no-bundle` smoke 路径仍不读远端版本、不改版本、不生成清单。
 
@@ -70,5 +70,5 @@
   - **`dev-win`（v0.1.154，`pub_date=2026-09-28T13:24:53Z`，commit `76cdb96c5`）**：清单 `windows-x86_64` 指向 `agc/dev-win/0.1.154/陶泥儿开发版_0.1.154_x64-setup.exe`（165,984,391 字节，HEAD 200）；`.sig` 对象 436 字节且与清单内签名文本一致；下载后字节数与 HEAD 一致，`sha256=7867734e3991…` 与旧协议指针 `agc/latest.json` 的 `sha256`/`size` 完全一致；用公钥验签通过（`alg=ED`，`keyId=cb883447e3e87c4e`）。
   - **`dev-mac`（v0.1.142，`pub_date=2026-09-24T11:35:31Z`，commit `c07c10c0c`）**：清单 `darwin-aarch64` 指向 `agc/dev-mac/0.1.142/陶泥儿 Release.app.tar.gz`（315,510,533 字节，HEAD 200）；`.sig` 对象 420 字节且与清单签名一致；下载后字节数一致、用同一公钥验签通过。
   - 结论：两个渠道的「安装包 ↔ 签名 ↔ 渠道清单」三者一致成立，条目 3 关闭。
-  - **顺带发现的真实状态差异（留给 macOS 里程碑）**：已发布的 `dev-mac` 清单只有 `darwin-aarch64` 一个平台键，而当前代码的 universal 约定要求两个 macOS 平台键指向同一对象同一签名；这次发布（0.1.142 / `c07c10c0c`，2026-09-24）早于 universal 改造，需要用 mac 构建机 re-publish 一次才能让线上清单符合契约。
+  - **顺带发现的真实缺陷（已在 macOS 里程碑与 decision-log 记录）**：线上 `dev-mac/0.1.142` 清单只登记 `darwin-aarch64` 是符合 2026-09-21 单架构决策的；但它指向的更新包解出来是 **0.1.139 的 release 身份包**（`world.genarrative.ai-game-creator.release` / 陶泥儿 Release）。这一条本条验收没覆盖（本条只看「地址存在 + 签名匹配」），本轮已把「包内版本与渠道身份」加进 `check:agc-update-channel-manifests`，并在 mac 构建入口补上构建期身份断言。
 - 条目 5（Jenkins 归档与日志不含私钥）仍是未勾选：静态可证部分已记录在验收行上（`withCredentials` 注入 + 归档 glob 不含私钥文件），真实 Jenkins 运行日志需要一次 CI 构建取证。

docs/project-memory/shared-memory/decision-log.md

@@ -9697,4 +9697,15 @@ CI 上 `background_agent_runtime_recovers_stale_running_before_pending_task` 在
 - 决策（错误 envelope 与成功 envelope 同一份 meta）：`AppError::into_response` 之前固定按「无请求上下文」构造错误响应，错误 envelope 里没有 `meta.requestId` / `meta.operation`，而成功 envelope 有，客户端在报错时拿不到可用于排查的 requestId。现在 `attach_request_context` 用 `tokio::task_local!` 的 `CURRENT_REQUEST_CONTEXT` 把上下文作用域套住整个 handler，错误转换读同一份上下文；脱离请求任务（单测、后台任务）时退回无上下文形状。取证：`check:game-distribution-owner-isolation` 新增成功/失败 envelope 两条断言，修复前 `requestId=` 为空失败、修复后 23 项 PASS。
 - 决策（envelope 一致性按可消费取证）：TS 侧没有 envelope 的类型镜像，只有 `packages/shared/src/http.ts` 与 `src/services/apiClient.ts` 的运行时守卫，因此这一条按「客户端能一致消费真实 envelope」取证（字段名 `ok` / `data` / `error.code` / `meta.apiVersion` / `meta.requestId`），不是类型级镜像；字段门禁比对的是名字而不是值类型。- 影响范围：`server-rs/crates/api-server/src/modules/game_distribution.rs`、`scripts/check-game-distribution-owner-isolation.mjs`、`scripts/check-game-distribution-upload-safety.mjs`、`scripts/check-game-distribution-upload-resume.mjs`、`package.json`、游戏分发里程碑取证。
 - 决策（写入必须显式下发对象级 ACL）：`platform-oss` 的 `OssObjectAccess` 之前只用于日志，对象继承 bucket 默认 ACL，公共读 bucket 上「private」对象可被匿名直取。现在内部 PUT、分片追加与直传 policy / 表单三处都下发 `x-oss-object-acl`（`Private` → `private`，`Public` → `public-read`）；`OssAppendInternalObjectRequest` 新增 `access`，`DirectUploadTicketFormFields` 新增 `x-oss-object-acl`。验证：`cargo test -p platform-oss` 76 passed；`E2E_REQUIRE_PRIVATE_BUCKET=1` 的媒体链路 E2E 里直传封面与发行包对象匿名直取都 403（65 项 PASS）。- 验证：本地真实栈三个脚本全部 PASS（越权隔离 23 项、上传安全 24 项、分片续传 prepare 8 项 + resume 9 项、媒体链路 44 项）；分片续传中途杀掉 api-server 进程（PID `53844` → 重启 `7728`）后仍从 `8,388,608` 偏移续传成功；`cargo test -p api-server -- package_` 6 passed 与 `game_distribution` 27 passed、`npm run lint`、`check:encoding`、`check:doc-index`、`git diff --check`。
-- 边界：证据来自本机 dev 栈与 dev bucket；生产域名、CDN 缓存窗口与真实客户端安装版的自动上传仍未验证。
+- 边界：证据来自本机 dev 栈与 dev bucket；生产域名、CDN 缓存窗口与真实客户端安装版的自动上传仍未验证。
+
+## 2026-09-28 macOS 渠道发布必须核对「包内版本 + 渠道身份」，不能只验签
+
+- 背景：用只读核对脚本 `scripts/check-agc-update-channel-manifests.mjs` 检查**已发布**的 OSS 渠道清单时发现，线上 `dev-mac/latest.json`（`version=0.1.142`、`commit=c07c10c0c`）指向的更新包解开后是 `CFBundleShortVersionString=0.1.139`、`CFBundleIdentifier=world.genarrative.ai-game-creator.release`、`CFBundleName=陶泥儿 Release`。签名验签、对象存在、`.sig` 与清单文本一致这些都对——错的是**版本与渠道身份**：dev 渠道的 arm64 客户端会被指向一个旧版的 release 身份包。
+- 根因：`build-macos-ci.mjs` 以前只清理「本轮要写的确切文件名」，mac 构建目录里上一轮/其它渠道身份留下的 `*.app.tar.gz` 不会被删；`generateUpdateManifest()` 是按目录扫描 + 优先级选产物，于是选中了残留文件。mac 构建机复用 workspace，这类残留会长期存在。
+- 决策（构建期失败关闭）：mac 发布入口在构建前按后缀清空 `macos/` 下的 `*.app.tar.gz`、`*.app.tar.gz.sig`、`*.dmg`、`*.dmg.sha256`；构建后读 `.app/Contents/Info.plist`，断言 `CFBundleShortVersionString` 等于本轮发布版本、`CFBundleIdentifier`/`CFBundleName` 等于该渠道安装身份；生成清单后再断言清单选中的更新包就是本轮那一个。任一不符直接中止，不写 OSS。
+- 决策（只读核对也要看包内身份）：`check:agc-update-channel-manifests` 在 `AGC_UPDATE_VERIFY_DOWNLOAD=1` 时下载 mac 更新包、解出 `Info.plist` 做同样断言；同时按 2026-09-21 决策断言 mac 渠道只登记 `darwin-aarch64`（不再要求 universal 双键）。
+- 决策（口径回归）：macOS 现行契约是 arm64 单架构（2026-09-21 决策），里程碑里「两个 macOS 平台键指向 universal 产物」的旧文字按现行决策改写；不得据此重新切回 universal，除非按该决策给出的恢复路径补齐按架构的 Node 运行时。
+- 影响范围：`apps/ai-game-creator-shell/scripts/build-macos-ci.mjs`、新增 `apps/ai-game-creator-shell/scripts/macos-release-identity.mjs` 与其 `.test.mjs`、`apps/ai-game-creator-shell/scripts/prepare-macos-codex.test.mjs`、`jenkins/Jenkinsfile.ai-game-creator-shell-macos-build`、`scripts/check-agc-update-channel-manifests.mjs`、两份里程碑与本文件、pitfalls。
+- 验证：`node --test macos-release-identity.test.mjs prepare-macos-codex.test.mjs verify-updater-signature.test.mjs build-release.test.mjs cargo-features.test.mjs` → 59 passed（新增 6 条，回归用例直接喂线上那份 0.1.139 release 身份 plist，必须抛错）；`npm run check:production-ops`、`check:encoding`、`check:doc-index`、prettier、eslint、`git diff --check` 通过；只读核对对线上 `dev-win` 全 PASS（含 158 MiB 产物下载验签与旧协议 sha256 一致），对线上 `dev-mac` 精确报出上面两条 FAIL。
+- 边界（未完成）：修复只保证「以后再发不会再错」，线上 `dev-mac/latest.json` 仍指向那份坏包；需要一次带 Jenkins 凭据与授权的 mac 重新发布，然后重跑只读核对才算了结。Apple 代码签名与公证仍是 `adhoc`。

docs/project-memory/shared-memory/pitfalls.md

@@ -6099,9 +6099,10 @@ Cocos Creator 根目录由 `package.json.creator.version` 与普通 `assets/`
 - **根因**：这个 harness 用桩 `systemctl` 驱动巡检脚本，Windows 上 `spawn systemctl` 直接 `ENOENT`，服务态检查不可能通过；它验证的是 Linux + systemd 的生产形态。
 - **做法**：本机只跑 `npm run check:production-health-patrol-env`（本轮 OK）确认巡检变量口径；`check:production-health-patrol` 留给服务器/CI 复核，别据此判定巡检脚本本身坏了。
 
-## 2026-09-28 渠道清单的单元测试绿不等于线上清单符合契约：`dev-mac` 线上仍是单架构
+## 2026-09-28 线上 dev-mac 的更新包是「上一版 + 另一个渠道身份」：清单扫描选中了构建目录残留产物
 
-- **现象**：`build-release` 的单元测试里 `universal uses the Mac channel and the same signed artifact for both architectures` 一直是绿的，但线上 `https://agc-dev.oss-rg-china-mainland.aliyuncs.com/agc/dev-mac/latest.json`（`version=0.1.142`、`pub_date=2026-09-24`、`commit=c07c10c0c`）的 `platforms` 只有 `darwin-aarch64`。测试证明的是「代码会这么发」，不能证明「线上已经这么发」。
-- **判据**：用只读脚本核对已发布对象，而不是看单测——`npm run check:agc-update-channel-manifests`（`AGC_UPDATE_VERIFY_DOWNLOAD=1` 时下载产物验签）。本轮实测：`dev-win` 与 `dev-mac` 的安装包都存在、`.sig` 与清单签名文本一致、两个产物都能用 `tauri.conf.json` 的公钥验签通过（`alg=ED`，`keyId=cb883447e3e87c4e`），但 `dev-mac` 的「两个 macOS 平台键」判 FAIL。
-- **做法**：任何「线上对象/清单契约」条款都用只读核对脚本取证；发现线上落后时，先确认这次发布对应的 commit 与时间（本轮 mac 发布早于 universal 改造），再用目标平台的构建机重发，不要在 Windows 上伪造 mac 清单。
-- **附注**：该 `dev-mac` 更新产物叫「陶泥儿 Release.app.tar.gz」，而渠道首装 DMG 叫「陶泥儿开发版_0.1.142_aarch64.dmg」；`dev` 渠道展示名约定是「陶泥儿开发版」，重发时一并核对 mac 更新产物的渠道身份。
+- **现象**：线上 `https://agc-dev.oss-rg-china-mainland.aliyuncs.com/agc/dev-mac/latest.json`（`version=0.1.142`、`commit=c07c10c0c`）把更新包指向 `陶泥儿 Release.app.tar.gz`；下载解开看 `Contents/Info.plist`：`CFBundleShortVersionString=0.1.139`、`CFBundleIdentifier=world.genarrative.ai-game-creator.release`、`CFBundleName=陶泥儿 Release`。同一份清单的首装 DMG 却是 `陶泥儿开发版_0.1.142_aarch64.dmg`。也就是说签名是真的、对象也在，但**版本与渠道身份都是错的**。
+- **根因**：`build-macos-ci.mjs` 以前只 `rmSync` 「本轮要写的确切文件名」，构建目录里上一轮（或其它渠道身份）留下的 `*.app.tar.gz` 不会被清；而 `generateUpdateManifest()` 是**扫描构建目录、按优先级挑产物**（同名优先级再按字典序），于是挑走了残留的 release 身份包。mac 构建机是复用 workspace 的，这类残留会长期存在。
+- **判据**：只读核对要**打开产物看身份**，不能只看「地址存在 + 签名匹配」。`npm run check:agc-update-channel-manifests`（`AGC_UPDATE_VERIFY_DOWNLOAD=1`）现在会解出 mac 包的 `Info.plist`，断言「包内版本 == 清单版本」且「包内 identifier/产品名 == 本渠道身份」；本轮对线上取样得到两条 FAIL，正是这个缺陷。
+- **处理（2026-09-28 已修）**：构建前按后缀清空 `macos/` 下的 `*.app.tar.gz`、`*.app.tar.gz.sig`、`*.dmg`、`*.dmg.sha256`；构建后读 `.app/Contents/Info.plist` 断言版本/identifier/产品名；生成清单后再断言 `release.artifact` 就是本轮那一个。守卫在 `apps/ai-game-creator-shell/scripts/macos-release-identity.mjs`，回归用例直接用线上那份 0.1.139 release 身份包（`node --test` 59 passed）。
+- **教训**：凡是「按目录扫描挑产物」的发布步骤，都要么先清空同类产物、要么按本轮预期路径断言；只删「本轮要写的名字」等于把上一轮的坏包留在候选集里。还有一条更一般的：核对线上清单时，先看 decision-log 的现行口径（这里 macOS 已是 arm64 单架构），别拿过期里程碑文字当契约。