提升双端全量 E2E CI 的首样本稳定性

[leon-zym]

Related: #99
Baseline implementation: #100

背景

PR #100 已把移动端 L4 收敛为可复核的验收事务：clean standalone Release、fresh owned device、唯一 iOS Maestro/XCUITest lifecycle、Photos Picker 语义 readiness、导出断言、设备清理，以及不覆盖 primary failure 的有界证据。其最终 exact-head full run 双端 10/10 通过。

但这不等于标准 GitHub-hosted macOS 上的首样本已经稳定。#99 的 15 次 exact-head fresh iOS targeted 样本为 9/15 通过；失败漂移到 app-service、SpringBoard、addmedia 与 Picker selection-return 边界。高宿主压力的成功、失败样本互相重叠，尚无单一资源阈值或可证伪的恢复动作。

本 Issue 不回退 #100 的真实性与证据契约，而是在其基线之上评估怎样提高首样本稳定率，让 full E2E 既能发现产品回归，也不会被 hosted infrastructure 噪声长期淹没。

开源 RN 项目的公开策略

公开 workflow 显示，主流项目同样面对 Simulator、driver 与宿主长尾；它们通常通过改变执行面和门禁范围治理，而不是证明标准 hosted runner 天然稳定：

• React Native：iOS E2E 使用 macos-15-large，预构建 artifact 后测试；外层 E2E 最多三轮，单 iOS flow 还有内部重试；另有 Maestro Cloud lane。参考 Test All 与 iOS E2E。官方 run 29572874439 在三轮 iOS E2E 后仍失败，说明长尾并非本项目独有。
• Expo：按受影响路径选择平台；iOS/Android 均将 build 与 device E2E 分 Job，以 immutable artifact 连接；清理 Simulator runtime，并对 boot/失败 flow 做有界恢复。参考 Test Suite。
• Mattermost Mobile：iOS build 与 test 解耦，默认按时长拆成多 shard；workflow 明确记录 macos-26 的 Metro/Detox timing issues，并曾回退 macos-15。参考 iOS E2E template。
• Rocket.Chat RN：iOS/Android 各构建一次再把 artifact 分给 shard；对 wedged CoreSimulator 单独分类，并只重跑失败 flow。参考 iOS workflow 与 runner script。
• Bluesky、Rainbow：完整 iOS E2E 使用 macos-26-xlarge，并放在 nightly、手动或带标签的 PR 上；不是每个普通 PR 都在标准 runner 上跑双端 full。参考 Bluesky nightly 与 Rainbow iOS E2E。

这些项目的最终绿色 check 可能包含更强 runner、路径裁剪、分片、缓存、云设备或重试，不能与 PlogKit 当前的“exact SHA、双端 full、fresh device、禁止隐藏 retry、导出与 cleanup 均验收”直接比较。

当前 PlogKit 策略

• 普通 PR CI：静态、单元、render、iOS compile、Android compile。
• 手动 full L4：同一 SHA 双端并行；每个平台在各自 Job 内 clean build 后立即在同一宿主运行 fresh-device acceptance。
• iOS：标准 macos-26（3 M1 cores、7 GB RAM）；系统门禁 → install/seed → 单一 Maestro suite → export assertions → owned-device cleanup。
• Android：标准 Linux + KVM emulator，独立于 iOS。
• 不使用固定 sleep、坐标、隐藏 retry、设备重建或全局 timeout 放宽；成功与失败均保留阶段化证据。

建议方案

第一阶段：同 SHA 对照 build/test 宿主隔离

保持 #100 为控制组，新增实验组：

控制组 A：同一 macOS Job clean build → fresh Simulator E2E
实验组 B：macOS build Job → exact-SHA immutable .app artifact
                         → 全新 macOS Job → fresh Simulator E2E

Job B 的价值不是“构建进程退出后等 CPU 下降”，而是销毁构建 VM，一次性移除其 swap、缓存、后台服务、磁盘活动与会话状态。该设计也能让多个测试样本严格复用同一二进制。但它只是待验证假设：如果 CoreSimulator 在全新标准 runner 上仍有同类长尾，就不应因架构看起来先进而采纳。

约束：

• artifact 必须绑定 commit SHA、Xcode/Expo/RN 输入与 Release 配置，并做内容校验；不允许跨不可信 PR 复用可写 cache。
• 两组不得 retry、重建设备或扩大现有 timeout；失败样本全部计入。
• 每组至少 10 次 fresh iOS 样本；条件允许时使用 20 次，且交错执行以减少时间窗口偏差。
• 记录首样本成功率、失败阶段、阶段 p50/p95/max、总耗时、Actions 分钟与 artifact 开销。
• 只有实验组相对控制组出现具有实际意义且可重复的改善，才修订 ADR 0042 并迁移正式 workflow。

第二阶段：依据第一阶段证据选择

• 若新宿主显著改善：采用 build artifact → fresh test host；再评估是否以同一 artifact 做有界 shard，优先缩短单宿主 device 生命周期。
• 若改善不明显：保持现状，不引入 artifact orchestration；仓库未来迁入有资格的 Team/Enterprise 组织后，再做 standard 与 larger runner 的同 SHA A/B。GitHub larger runners 当前仅面向符合条件的组织/企业，不为个人仓库创建不可运行配置。参考 GitHub larger runners。
• 若仍无法达到可接受首样本稳定率：评估 dedicated/self-hosted Mac 或 Maestro/EAS device cloud；必须单独记录成本、安全、签名、网络和测试语义变化，不能悄悄把 simulator acceptance 替换为不同测试面。

非目标

• 不通过 retry 把首轮基础设施失败折叠成绿色。
• 不继续堆叠 readiness probe、固定 sleep、自动 reboot/rebuild 或更宽 timeout。
• 不把 load、free memory 或 swap 的单一数字当作跳过测试的阈值。
• 不因其他项目的绿色 badge 降低 PlogKit 的 export、cleanup 或 exact-SHA 验收语义。
• 不在本 Issue 中把调查数据复制进长期 ADR；只有正式改变架构时才修订负责该决策的 ADR。

验收条件

• 控制组与实验组使用同一 SHA、同一 Release 二进制输入和一致的 fresh-device验收语义。
• 两组各有至少 10 次未重试样本，成功与失败证据全部保留。
• 报告首样本成功率、阶段分布、总耗时、Actions 成本和 evidence completeness。
• 能判断 build-host 残留是否是 iOS 长尾的重要放大因素，而不是只比较最终绿色状态。
• 若采纳拆 Job，artifact identity、trust scope、retention、失败传播与 cleanup 契约有测试并修订 ADR 0042。
• 变更后 pnpm verify、普通 PR CI、exact-head Android full 与 iOS full 均通过。
• 最终方案保留 primary failure，不引入隐藏 retry、设备重建、固定 sleep 或无证据的 timeout 放宽。

[leon-zym]

来自 #100 P0 最终验收的新证据与执行决定：

• run 31888887580 在 guest health、安装和照片灌入全部通过后，仍于 Maestro/XCTest driver startup 失败；XCTest runner build 被中断。
• 同一失败窗口的标准 macos-26 宿主只有 3 CPU / 7 GiB，load1 超过 455、空闲内存约 100–160 MiB。高压力与失败不能单独证明因果，但已经足以否定“同宿主 clean Release build 退出后，宿主状态自然恢复且适合立即跑 driver”的前提。
• fix(e2e): harden iOS simulator diagnostics #100 的 schema v2、failure boundary、publication 和 cleanup 契约在该失败样本上全部可复核；后续实验可直接复用，不需要再堆 readiness、sleep、retry 或 timeout。

已确认的下一阶段约束：

1. 接受 x86_64 / macOS 15 作为候选执行面。
2. 实验组使用 sealed acceptance package：不仅包含 .app，还包含 flows、fixtures、sidecars、输入快照和 manifest/hash；测试 Job 只消费该不可变包。
3. build Job 与 test Job 使用全新宿主，控制组与实验组必须消费同一 SHA、同一二进制及同一验收语义。
4. 控制 Actions 成本：先做 1 组配对 smoke；通过 package identity 与语义检查后，再按小批次交错扩样，每批复盘后才继续，不直接启动 20+ 长任务。
5. 所有首轮失败计入，不 retry green。只有隔离宿主/候选执行面出现可重复、具有实际意义的改善，才修改正式 workflow 和 ADR 0042。

这条 Issue 从现在起承接“稳定门禁”的真实目标；#99/#100 只作为已完成的诊断基线。

[leon-zym]

首组 macos-26-intel sealed-package smoke 已执行，严格保留首轮结果且没有重跑：

• Workflow run: 31891974380
• Exact SHA: f9a0b58ecc4b9c05d517194b8c0d34a7ad286657
• Draft implementation: test(e2e): isolate iOS acceptance on a fresh host (experiment concluded) #103（仍不可合并，ADR 0042 未修改）

有效控制样本

同宿主 control 是有效失败样本：

• Setup 约 1m33s；sealed x86_64 Release build/package 20m40s；control acceptance 5m13s。
• Package 构建、ABI、快照与同宿主 package identity/content 校验全部通过。
• Simulator create 与 locale 通过；boot 用时 172.8s；随后 ios-app-service-readiness 的唯一 simctl listapps 用尽约 60s deadline，阶段总计 70.2s；Maestro 尚未启动。
• 4 CPU / 14 GiB host 在失败窗口出现 load1 最高约 562.6、空闲内存最低约 60 MiB、swap 仍为 0；telemetry 子探针多次自身超时，因此 telemetry completeness=false。
• execution=true、recorder=true；primary failure 为 E2E_COMMAND_TIMEOUT；publication 完整（12 files、2,531,036 bytes、0 truncation/omission）；Simulator shutdown/delete/absence 全部通过。

这不是资源阈值因果证明，但它是一个很强的样本：即使换成 4 CPU / 14 GiB Intel runner，同宿主 native build 后仍可把 CoreSimulator/app service 推入与 #99 同类的极端长尾。

无效 fresh-host 样本与 harness 缺陷

控制失败后 package 仍按设计上传，fresh-host Job 也按设计启动：

• GitHub artifact 压缩后 53,674,386 bytes；上传约 5s、下载约 9s。
• download-artifact@v8.0.1 验证传输 digest 为 sha256:194d95fb36696b1a2093684ac4c380354c343aa54bddb603bc79bd7b414b1de0。
• fresh Job 总计 3m47s，其中 pnpm install 2m11.7s。
• packaged acceptance 在创建设备前失败：maestro --version 的 JVM 冷启动超过原 15s preflight 上限；旧实现把 ETIMEDOUT 错写成“not found on PATH”。因此没有创建 observation/artifact，也没有产生 fresh Simulator 样本。

该结果不计入实验组成功率，不能用于判断 fresh host 是否改善稳定性。它只证明第一版 experiment harness 的 toolchain preflight 不合格。

已在 #103 后续提交中完成两个回归修复：

1. Linux x64 上的 arm64 build fixtures 显式固定测试架构，避免本地 Apple Silicon 掩盖跨平台失败。
2. Maestro version probe 使用 60s 有界 cold-start budget；ETIMEDOUT 明确为 E2E_COMMAND_TIMEOUT，只有 ENOENT 才报告 PATH 缺失。生产 Simulator、Maestro suite、build/acceptance deadline 均未放宽。

验证：本地 pnpm verify 全绿（orchestration 206：204 pass / 2 platform skip；app 412；render 85）；修复后 Draft PR CI 31893663193 1m24s 全绿。

当前判断

• sealed package、失败传播、artifact transport 与 control 证据链已工作。
• 同宿主残留仍是值得继续证伪的高价值假设。
• fresh-host 方向尚未得到一个有效样本，当前证据不足以扩样、采纳 seam 或修订 ADR。
• 本轮不自动补跑。下一次最小动作若获确认，应只在修复后的 exact SHA 上再执行 1 组配对 smoke；通过后才讨论小批次交错扩样。

[leon-zym]

接手后的实验结论

已复核 #103 的实现、配对样本和公开证据。按照本 Issue 的采纳门槛，fresh-host 隔离实验未通过：

• control 组可进入 UI 自动化，但发现“文本已提交”的断言可能只命中仍打开的输入框；
• fresh-host 组停在 CoreSimulator 初始化，未能稳定进入 App acceptance；
• 因而目前没有证据支持将 cross-host / sealed-package seam 采纳为正式 E2E 路径，也不应合并 test(e2e): isolate iOS acceptance on a fresh host (experiment concluded) #103。

这不证明产品代码是根因；目前可确认的是托管 macOS 上的 CoreSimulator 冷启动仍有长尾。请不要用 retry、固定 sleep 或扩大生产 acceptance deadline 来掩盖该问题，也不再自动启动新的配对样本。

已推送的独立修复

不依赖实验的 5 个提交已推送到 agent/issue-101-e2e-failure-identity，并已通过 pnpm verify：

• Maestro 与 CocoaPods 版本探针区分 cold-start timeout 和 executable 缺失；
• 命令 timeout 保持 primary error，进程终止失败只作次级证据；
• 文本提交 E2E 明确验证编辑面板关闭，消除输入框造成的伪阳性。

可查看 与 main 的比较。

下一步

#101 保持打开，等待执行面决策：优先选择更可靠的专用/更大规格 runner 或设备云；若暂时不可用，完整 iOS L4 应降为定时或手动证据，而不是不稳定的 PR 硬门禁。

[leon-zym]

关闭说明：cross-host 隔离实验不采纳

#103 已完成 #101 所提出的 build/test 宿主隔离假设检验，但有效样本未达到采纳门槛，因此不继续扩样，也不将该 seam 带入正式 E2E 路径。

• 后续的“如何处置 iOS L4 基础设施长尾”决策转移至 决策 iOS L4 E2E 的执行面与基础设施长尾处置策略 #104；
• 已验证、且不依赖实验的 runner / flow 修复在 fix(e2e): preserve cold-start failure identity #105 审阅；
• 本 Issue 关闭原实验，而不是宣称 iOS 基础设施长尾已经解决。

关闭原因为 not planned：该特定 cross-host 方案不再实施。