ci: preserve the macOS bootstrap compiler during a clean rebuild

.agents/docs/2026-11-05-heterogeneous-build-implementation-plan.md

@@ -310,3 +310,160 @@ platform 0.23.7 的一致版本组已在本地准备，待两个前置公开后
 `/home/speak/workspace/mcpp-885-realpath-and-final-core-diagnostic-evidence.tar.gz`，
 152 个文件，SHA256 为
 `4d7b783c27bb25dc75c354af72e98dc4b47037ab75043f792a28dceeeb10083a`。
+
+## 13. 核心最终审查与发布启动（2026-11-05）
+
+核心 PR #888 的最终提交 `850bbf53b5cf8a98dc8b6e3da894da77059cfbc4` 已通过完整
+CI `41947858860` 第 4 次尝试：74 项成功，1 项不适用的 iOS 清单跳过。Windows
+与 macOS 的 E2E 1015 均实际通过 Unicode 通道及清理控制。ARM 交叉构建早先
+遇到 runner 关闭，SIGTERM 143 日志保留；另一次清理挂起的失败未取得日志，原因
+仍未证明。最终相同提交的 ARM 构建及 QEMU 运行通过，没有修改测试或交叉目标。
+
+完整 CI 成功后，另行逐项完成用户要求的生态审查，覆盖通用核心与插件边界、每个
+消费者的普通依赖闭包、宿主/目标分离、版本与协议兼容、五种 action 角色、取消
+及失败后的通道清理、实际依赖版本中的有界文件读取、中英文说明、平台覆盖、
+TLS 和交叉封装。核心没有阻塞发现；插件进度写入的 Windows UTF-8 问题在 #52
+处理，不把未通过完整性能验收的引擎视为已完成。审查记录为
+`/tmp/mcpp-885-core850-post-ci-ecosystem-review.json`。
+
+#888 已于 2026-11-05 03:13:21 UTC 合入，提交为
+`1e6d1b3f9c68510af7d2d5b68bbf7aaef1a89e73`。合入树与被审查提交的树一致。
+对应 main CI `41960218833` 已先取消并确认终止，随后在合入提交创建
+`v2026.11.5.1`，启动 Release `41960453765`。本检查点只证明发布已启动；完整
+资产、双端镜像、索引传播、实际公开安装、bootstrap pin 和 main CI 重启仍须按
+第 6 节的顺序闭环。
+
+## 14. 已公开依赖组与消费者边界（2026-11-05）
+
+musl 0.27.6、LLVM runtime 0.18.7 与 platform 0.23.7 已分别合入、发布并进入
+公开索引。三份源码的 GitHub/GitCode 字节一致。普通 GLOBAL/CN 消费者实际
+通过 C++/import std、ThinLTO、TLS 线程隔离、canonical path 及 ARM 交叉封装
+控制；这些消费者不使用本地路径或索引重定向。三个发布后 main CI 分别为
+`41956257730`、`41956262835`、`41956268179`，共 24 项检查成功；验证时没有
+`MCPP_SOURCE_REF`。核心默认保持已验证的 0.23.6，显式 0.23.7 集成另有实证。
+
+插件 #52 的 `26ff5430eda7a957bffe39ca6869801ad5d1b672` 完整 CI
+`41959654833` 六项全部成功。Windows ACP 1252 上普通 CRT `getenv` 的确丢失
+Unicode 通道字节；辅助写入端已改用 os.env 的 UTF-8 接口。Windows 原生、macOS
+及 Linux 的关闭、Unicode 写入与不可写路径控制通过。插件最终新核心集成 pin
+和发布仍等待核心版本公开可安装。
+
+引擎 #16 的 `a13953808f4ec4704288adca3ae095ba858bce86` 已使用公开 platform
+0.23.7。冻结 Linux 对照 `41959812911` 运行原始工作负载，16 个语义会话、就绪、
+热 CPU、缺页及路径对等通过；冷 CPU 分别为 15.08 / 12.32 = 1.224（x64）和
+10.65 / 9.11 = 1.169（ARM64），仍高于 1.15。不得据其他检查通过提升台账或
+发布，也不重跑未修改的性能检查寻求偶然通过。服务器 #75 的原生构建和测试
+归档共 34 项成功；严格引擎候选接纳仍拒绝未合格的上游。
+
+## 15. 当前产物的逐进程定位（2026-11-05）
+
+以 a139 对应的原生与 universal 资产 SHA、ZIP CRC、包内身份和 ELF 成员位置
+固定输入。两路完整冷工作负载均包含 304 个单元、三个文件和 176 个编译 worker，
+实际语义就绪通过。strace 按 PID 分类，独立 snapshot 后台进程另记；跟踪后的
+CPU 与耗时不作原性能门槛的替代。当前 image 的 `fstatfs` 共 1,050 次，较上一轮
+约 68,000 次明显减少，证明 realpath 修正确实进入了当前产物。
+
+每个 image worker 除 owner-death 监视外，还由 Linux 后端的单位内存监督启动
+一个线程，立即遍历整个宿主 `/proc`，打开每个可见 PID 的 `stat` 再判断进程组。
+该观察属于宿主运行器的后端实现，不需要在通用 mcpp 核心添加进程或 HPC 语义。
+
+实验原型先以 `getpgid` 排除确认属于其他组的进程；查询失败仍读原记录，可能的
+组成员仍从同一份 RSS 记录复核进程组。原型保留全部进程组成员、首次立即采样、
+100/200/500 ms 的原采样间隔、组内内存求和与全组终止。实际组件控制包括成员
+加入/退出、组长结束后的成员、EPERM/ENOSYS 后备和合计超限时终止所有成员而
+保留其他组；全部通过。一次采样的 `stat` 打开数从 37 降到 2，12 组交替组件
+CPU 中位比为 0.244。该结果仅属于组件。
+
+两份相同编译参数、仅后端过滤逻辑不同的运行器，随后对同一 a139 image 运行
+原始 304 单元、三个文件、176 worker 的完整冷工作负载。八组交替测试的冷 CPU
+中位数为基线 5.600 s、候选 5.385 s（比值 0.962）；公开运行器对照为 5.575 s。
+完整生命周期 CPU 中位数为 5.639234 s 与 5.4300145 s。就绪时间中位数为
+3.880 s 与 4.034 s，没有得到就绪时间改善的证据。所有语义会话通过，单组测量
+存在波动；这些本地结果不能证明原 CI 的冷 CPU 门槛已通过。
+
+Linux 后端改动、0.24.2 版本及说明复用同一 PR #50，提交为
+`6bd65128c53d1bc1fc99f2ddcb984e12325b3490`。另一个冻结诊断
+`41966671816` 在 Linux x64/ARM64 上运行原生引擎、公开运行器、同参数基线和
+候选运行器；保留原工作负载、三次热会话与未修改的接纳脚本。诊断不提升引擎
+台账，也不替代正式生产者的完整资格；后端尚未发布。
+
+另以同一批 BitstreamReader/Support ThinLTO 对象和当前 176 份 PCM，比较最终
+LLD 的默认、显式 O2 与 O3。默认产物与显式 O2 字节一致；十二组交替组件测试
+中 O3/O2 的 CPU 中位比为 1.013，没有得到该组件的优化收益证据，未据此修改
+引擎链接参数。该组件沿用实验中的 platform 0.23.5，其结果不推广到完整引擎。
+
+## 16. 运行器后端的采用依据与发布次序（2026-11-05）
+
+冻结诊断 `41966671816` 两个 Linux job 已成功，资产 ZIP 的 SHA256、CRC 与展开
+文件已逐项核对，并用 a139 的未修改脚本重新计算六组接纳结果。x64 同一宿主的
+公开运行器冷 CPU 为 15.45 / 13.05 = 1.184，同编译参数基线为
+15.33 / 13.05 = 1.175，均失败；过滤候选为 14.77 / 13.05 = 1.132，通过。
+ARM64 候选为 10.99 / 9.89 = 1.111；该轮公开和基线运行器也通过，分别为
+1.126、1.124，不能把 ARM64 的通过全部归因于过滤。两宿主共 32 个语义会话
+通过，候选的就绪、冷热 CPU、缺页及路径对等均按原门槛通过。这是采用修正的
+对照证据，不是正式生产者或联合 UX 的资格提升。
+
+后端 PR #50 的 GCC/LLVM 完整 CI `41966412791` 已通过，随后另行审查资源、
+错误、组成员、ABI、跨架构与说明，合入为
+`59a3a59b53625f144b17c96e8a3b07eb617cef1a`，并发布 0.24.2。GitHub/GitCode
+源码同为 164569 字节，SHA256 为
+`bfe9f4fc34b9d2c4d321939bb00f4da7c8f444abb38bb12756da7b5d57717ee9`。
+索引 PR #713 已准备并提交，实际公开源码消费者、精确锁与本地 lint 通过；尚须
+合入、发布索引并确认普通客户端可安装。
+
+运行器改动复用原 #885 全局审查产生的 openkal-image PR #25。其 okprof 环境
+传递修正已有五项完整 CI 通过；合入当前 main 0.4.4 后，保留 Windows 映射尾部
+修正，再准备四包同版 0.4.5、Linux 0.24.2 与说明。公开依赖未完成索引前不推送
+要求安装该版本的最终 CI。预编译运行器仍使用正式 hosted 平台与同一精确版本
+组，不通过更换运行库或跳过版本组检查缩短发布链。
+
+核心 Release `41960453765` 的两项生态 canary 与 Linux x86_64 静态包已通过，
+ARM64、macOS 与 Windows 正在并行构建。完整镜像、索引和实际安装尚待完成，
+bootstrap pin 和已取消的 main CI 因此尚未前移或重启。
+
+## 17. macOS 发布自举生命周期修正（2026-11-05）
+
+Release 的 Windows 构建成功，macOS job `127048731858` 在第二阶段失败。第一阶段
+实际输出 2026.11.5.1，随后从 `target/.../bin/mcpp` 调用 `build --no-cache`；清理
+删除了正在自举的编译器路径，Ninja 再调用该路径生成依赖记录时报告文件不存在。
+这是发布流程的编译器生命周期问题，不能按基础设施波动原样重跑。
+
+发布流程先将第一阶段可执行文件复制到 RUNNER_TEMP，再执行原来的清理重建。
+实际候选编译器与 LLVM 23.1.3 的 import std 小工程复现了负向控制：编译器位于
+输出目录时被删除并失败；同一编译器复制到目录外后，完整清理重建通过，生成
+程序实际运行输出 `stage1 lifetime held`。该 Linux 控制不能替代修复后 macOS
+发布 job 的原生验证。
+
+已上传的 Linux x86_64 与 Windows 资产保留。修复后的 macOS 构建仍取原 tag
+的源码，完成原部署版本、静态 libc++、路径、封装及 smoke 检查；发布清单和
+镜像继续要求其他三个平台的实际构建成功，不以补建单个平台替代整组发布门槛。
+原 tag、源代码和此前通过的核心 CI 身份保持可核对。
+
+## 18. 发布资源的本地镜像与索引收尾（2026-11-05）
+
+修复后的原生 macOS job、原发布的其他三个平台与两项生态 canary 均已成功。
+恢复流程 `41969495679` 的源码校验、macOS 构建、完整发布清单和生态发布四项
+全部成功；tag 仍指向 `1e6d1b3f9c68510af7d2d5b68bbf7aaef1a89e73`。
+四个平台安装包已独立下载并核对清单哈希与封装。
+
+用户指定后续资源在 GitHub 产出时立即使用本地 gtc 补齐 GitCode，不等待 CI
+mirror。该流程已补齐本次全部 21 项发布资源，包含安装包、别名、校验文件、
+源码、脚本与清单；每项均实际 GET 下载并校验 SHA256。此前 GitCode 下载为
+404 的 Linux x64 与 ARM64 包，本地上传分别耗时约 11 s 与 13 s。资源已有且
+字节相同则保留，同名内容冲突须查明，不以删除重传处理。
+
+索引 PR `openxlings/xim-pkgindex#1108` 的三个 latest 条目、四个平台资源地址
+及 SHA256 已与完整清单核对，合入为
+`785e62895aa4216361f031424033394f6ef8ba4e`。按用户此前指定的本地直接发布
+流程完成双端资产和指针，实际公开下载的索引包为 1758038 字节，SHA256 为
+`e35e26ec319db22e7fbfb2f98cb158a61e3eff5162778187940764cbf285053b`。
+随后 GLOBAL 与 CN 两种配置的隔离客户端均从普通公开索引安装精确版本和
+latest，实际执行输出 `mcpp 2026.11.5.1`；安装后的 ELF 与公开安装包逐字节
+对应，SHA256 为 `cb665b0ceb1856a1e588faba183c3de29b9f5b455d6e9fd2944d14175235bced`。
+客户端保留产品自身的镜像回退行为。bootstrap pin 在这些验证之后前移，核心
+同一收尾 PR #889 继续要求最终提交 CI 和生态审查；完成后重启 main CI。
+
+运行器源码 0.4.5 已复用 PR #25 发布，Linux 0.24.2 和四个 image 包 0.4.5 的
+索引分别经 PR #713、#714 合入、发布并通过普通客户端验证。musl 0.27.7 复用
+版本组推进的 PR #85；runtime 0.18.8 与 platform 0.23.8 继续按公开前置依赖
+依次验证。源码对照诊断不能替代引擎正式生产者与联合 UX 的资格验证。

.agents/skills/mcpp-release/SKILL.md

@@ -209,6 +209,25 @@ multipart/无断点续传，**单文件拆不开** —— 这正是必须先把
 再回调 GitCode API，回调失败就返回 `code:400 ... EOF`，而**对象其实已落盘**。
 判定上传成功**只能靠回探下载 URL**，脚本就是这么做的。
 
+### 本地 GitCode 补齐（2026-11-05 用户指定流程）
+
+每个发布资源在 GitHub 产出后立即下载到本地，以本地已配置的 `gtc` 补齐
+`xlings-res/mcpp` 的同版本 GitCode release，不等待 CI mirror。资源集合取自
+GitHub release 的实际资产清单，包括版本安装包、无版本别名、校验文件、源码、
+安装脚本与发布清单；后续新增资源继续补齐。资源镜像 tag 不带 `v`。
+
+```bash
+gtc release upload xlings-res/mcpp <local-verified-asset> --tag <YYYY.M.D.N>
+```
+
+上传前校验本地文件的来源、大小和 SHA256；GitCode 已存在且下载校验一致的
+资源直接保留。缺失资源可并发上传，上传后实际 GET 下载并复核大小和 SHA256，
+不以 `gtc` 的退出码代替下载回验。同名资源内容不一致时先查明原因，不删除或
+覆盖既有发布字节。记录每项资产的来源、哈希、上传及下载验证结果。
+
+本地补齐与 CI 构建、mirror 并行进行。索引发布仍要求四个平台构建成功、完整
+发布清单通过以及所有被索引资源实际可下载；这些条件满足后可继续索引收尾。
+
 ### 发布后的收尾（必须做完，否则用户装不到）
 
 ```bash

.github/workflows/release.yml

@@ -538,6 +538,12 @@ jobs:
           "$MCPP" build
           STAGE1=$(find target -path "*/bin/mcpp" | head -1)
           STAGE1=$(cd "$(dirname "$STAGE1")" && pwd)/$(basename "$STAGE1")
+          # --no-cache removes target/, including the stage-1 compiler. Ninja
+          # invokes that compiler again for dependency scanning, so keep the
+          # bootstrap outside the tree the second stage is about to clear.
+          STAGE1_COPY=$(mktemp -d "$RUNNER_TEMP/mcpp-stage1.XXXXXX")/mcpp
+          cp "$STAGE1" "$STAGE1_COPY"
+          STAGE1="$STAGE1_COPY"
           "$STAGE1" --version
 
           # Stage 2: this release's mcpp rebuilds itself — flags.cppm's

.xlings.json

@@ -1,5 +1,5 @@
 {
   "workspace": {
-    "mcpp": "2026.11.3.1"
+    "mcpp": "2026.11.5.1"
   }
 }