docs: record the post-release ecosystem verification and what it caught

.agents/docs/2026-08-15-issues-426-427-analysis.md

@@ -631,3 +631,51 @@ ld: cannot find crt1.o / crti.o / -lm
 改为**根本不写 marker**:让「什么都没做」有机会被读成「已经做过」是不必要的风险,
 而不写 marker 的代价只是每次构建重新判断一次(纯内存)。单测
 `ASkippedFixupLeavesNoMarkerBehind` 钉住这一点。
+
+---
+
+# 生态真实验证记录(2026.8.15.2 / 2026.8.15.3)
+
+全部在 `xlings subos use --sandbox` 与宿主机上跑,不是推理。
+
+| 项 | 结果 |
+|---|---|
+| #427 沙箱硬失败 | ✅ 消失。构建推进到真正的位置,诊断链完整:原因 → 后果 → 补救 |
+| #427 全新 SubOS | ✅ `mcpp run` → `fresh-subos-ok`(binding 解析到 `glibc@2.44`) |
+| #426 纯 C 共享库(发布版产出) | ✅ `NEEDED` 只剩 `libc.so.6`,规则为 `c_shared` |
+| 正常 C++ 路径 | ✅ `mcpp run` → `eco-ok` |
+| 两端镜像 | ✅ GitHub / GitCode 四件逐字节相同(两个版本都核过) |
+| 索引 | ✅ `latest` = 2026.8.15.3 |
+
+## ⚠️ 验证抓到的东西:mcpp 给出的补救不成立
+
+2026.8.15.2 修好硬失败之后,那条降级建议**第一次真正被用户看到**,也才第一次被验证:
+
+```
+xlings self update          # 2026.7.27.3 -> 2026.8.14.1
+→ subos_info 仍然不存在
+xlings self doctor --fix    # ▸ healed 129
+→ subos_info 仍然不存在
+```
+
+`xlings subos` 没有 repair / refresh 子命令(`new use list remove info stop`),即
+**已存在的 SubOS 没有任何受支持的途径拿到这个块**;新版 xlings 只在**创建**时写它。
+
+已开 openxlings/xlings#547,并在 2026.8.15.3 把三处措辞改成陈述事实并指向它。
+
+**这句话不是这次新加的** —— 它出自 xlings 写进块里的原始措辞,mcpp 一直在转述。
+把「上游这么说」当成「这是对的」转述给用户,和自己写错一样。而它之所以能一直没被
+发现,恰恰是因为在它前面有一道更早的硬失败挡着:**修好一个缺陷会让它后面那些从未
+被执行到的路径第一次暴露出来**,所以发布后的真实验证不是形式。
+
+## 发布运维:GitCode 上传两次都撞 10 分钟步骤上限
+
+两次发布的 `publish-ecosystem` 都因 mirror 步骤超时而失败:
+
+* 2026.8.15.2 —— 八件其实**全部传完**(422s / 256s / 579s / 398s),超时发生在最后一件
+  之后,属于假失败。核验后直接 rerun 补索引 PR。
+* 2026.8.15.3 —— macOS 那件(7.4MB,最大)确实没传上去。本地 `gtc release upload`
+  补传(首次 502,重试即成),再 ranged-GET + 两端 `cmp` 核验,然后 rerun。
+
+⚠️ **判据必须是 ranged GET,不是 HEAD** —— `mirror_res.sh` 自己写着 GitCode 的 HEAD
+会撒谎。我第一次用 `curl -I` 得到全部 401,险些据此判定「GitCode 一件都没上去」。