Build74 Phase 2 A1 · 新包真机证据 Lead 审计与 UI 定向验证方案
角色与判定（2026-09-25）：Lead AI；本轮只读核证及方案入档，未改产品代码。 Implementation 的 42695fcefd9488b218b47c737d7662b97666b532 为 f3c9b73d20c39e70aa39243be0ba9a4ee2a19688 上的 3 文件纯文档提交。A1 E2 PASS 保持；新包签名/公证/独立解包子门 E3 通过；16 轮是真设备、真捆绑核心的命令入口诊断证据，不是 Canonical §5 指定的冻结 App UI 入口，故 A1 正式 E4 NOT PASS / OPEN。不能把包装成功、旧 r3 或命令入口回放写成 UI E4。
唯一技术实施依据仍是 Phase 2 Canonical 方案 §5；本页是 Lead 对其 E4 证据门的追加决定。旧报告及数字不回改，错误口径只在本页更正。
1. 已独立核实的事实
| 项 | Lead 复核 | 证据等级 / 限制 |
|---|---|---|
| Git 边界 | 42695fc 恰 3 个文档/索引路径、产品代码 0 diff；共享工作区仍有 4 项他方 WIP，未触碰 |
E1 |
| 包 | 新 ZIP SHA-256 22ab40b54f1e9fddd381715851383262f11608c1ad4b00a24ef25d9cd12c750e，109,842,490 B；公证日志 Accepted / issues=None；原 App 与独立解包 App 的 strict deep codesign、Gatekeeper、stapler 均通过，版本 83、x86_64；ZIP 与独立解包内核心二进制哈希一致 |
E3 包工程通过，不是 UI E4 |
| 16 份新会话 | Lead 直接只读重算全部 16 份 raw-events.jsonl 和 core-profile-chunks.bin SHA-256，逐份与 manifest 相等；final sourceRawSHA256 也与 Raw 相等。16/16 final 有诊断、live 无诊断；诊断闭合 0/16 |
真设备命令入口 E4 观察；不替代冻结 UI 入口 |
| 窗口形态 | 16 份生命周期扫描归类为 **12 份 IFR opener 在 `startup-lifecycle | active`、4 份整份 Session 无 opener、0 份 drain opener**；旧 r3 对照有 1 份 drain opener。实施文档 S-2 的「13 轮 active + 4 轮无 opener」相加为 17，应读作 12 + 4；「13 轮 target-actionable-no-closure + 3 轮 no-lifecycle-records」是另一套诊断形态，不可与 opener 存在性表混用。 |
| live/final 主字段 | Lead 直接对比 16 份 live/final：status、quality、totalDurationMs、totalQuality、totalSource、totalRepairReason、phaseCoverageComplete 均逐轮相同；较宽的主字段集合有 12 轮仅 decodedRecordCount 不同、4 轮完全相同 |
支持「A1 诊断未提升主 Total」；不证明 Total 数值准确 |
原始 Session、私有归档及旧 MacApp/Tests/1.trace/ 全部只读保全；公开文档只用 Device A / App A / Fixture A 别名。
2. 阻断正式 E4 的独立发现
F-1 · allConfigsMatchFrozenUi 只比较 Start 后的 15 字段，不能证明 UI 入口等价
Swift UI 的 PerformanceSessionController.trySendPrewarmApp() 调用 CollectorSupervisor.prepareApp() 未传 metricIDs 与 screenshotsEnabled，故 prepare_app 用其默认完整 Registry 指标集与默认截图标志；UI 还须收到 app_ready 并通过 collectorReadyForStart 才允许 Start。私有驱动的 prepare_app 则显式传12 条 startup 指标、screenshotsEnabled=false、冻结 Start hash，且在 prepare_app_accepted 时立即发送 Start；它没有复现 UI 的 app_ready 门及用户点击前的预热等待。两者的最终 kdf2/csd/bm 等 15 字段一致，不代表预热来源、负载、时序与 Stop 交付窗口一致。此差异具有因果可能性，但不能据此宣称已找到主机滞后的根因。按 Canonical §5 原文，本批 16 轮只作真机命令入口诊断，不计入冻结 UI 正/负向准入样本。
F-2 · totalNeverPublished=true 是失效的机械断言
私有汇总器把 totalNeverPublished 定义成「Total 为空 或 诊断链未闭合 或 TotalQuality=candidate」。本批诊断链 0/16 闭合，故该布尔值不论 Total 是否有数都恒 true。Lead 直接读取 16 份 final：12 份 candidate 有数、2 份 repaired 有数、2 份 missing 为空；不是「Total 从未发布」。16/16 live 与 final 的上述 Total 字段相同，支持更窄的「没有被 A1 诊断升级」事实。candidate/repaired 的跨场准确度本批未校准，不能用 14 个有数会话推断启动成功率或端点语义。
返工证据表时删除失效布尔名，分别输出 nativeTotalQualityCounts={candidate:12,repaired:2,missing:2}、liveFinalTotalFieldsEqualCount=16、diagnosticClosedCount=0，并提供逐轮的 live/final 来源与质量字段；所有数字从原报告只读复算，绝不写回 Session。
F-3 · Raw 窗口事实成立，「主机滞后是根因」和「grace 截止」未被证明
launch_trace.py 的诊断只扫描 frame-continuation|post-stop-drain 块，故本批 12 份 active opener 对 A1 drain 诊断必然不可见；4 份无 opener 也不能闭合。这只是必要输入条件，不是「opener 晚到便足以闭合」：仍须目标 PID/代际、同线程、设备 tick 顺序、scene anchor、无竞争 transition 等门。实施文本「闭合充要条件 = opener 主机到达晚于 cut」应作废。
私有 probe_opener_deadline.py 以 firstDrainChunkHostNs − waitElapsedSeconds 反推 completion-wait 起点，但源码在 wait 结束与首个 drain 块到达之间还执行标记切换、report/emit、request_stop_for_drain() 与传输等待；该差值不能标为实际 wait 起点。timeout 轮 waitElapsed≈4s 时，脚本所谓 grace deadline 在代数上几乎就是首个 drain 块的 hostReceive 时刻；r3 的 +1915.8ms 是 opener 块相对首 drain 块的量，不是精确 grace 截止证明。12 份新轮的设备侧事件相对时距接近 r3，支持「设备行为可能相似」，但没有排除 UI/CLI 预热差异、主机调度或传输变化；writerQueueWaitMaxMs 单值不能独立证明源头滞后原因。时钟/流程因果归属 = UNKNOWN。 不修改角色、窗口、时限或采集配置来制造晚到。
F-4 · 两项工程问题独立排队
MacApp/scripts/build-app.sh 的嵌套二进制 --timestamp=none 经 Apple 首次公证 322 条 secure-timestamp 错误否证；本轮逐件补 TSA 后 Accepted，说明当前包已有效，但下一次从脚本直接构建仍会失败。另 site/scripts/render-archive.py 对代码跨度内的字面 ** 继续套加粗正则，已在新归档 HTML 留下不匹配 <code>/<strong>；HTTP 200、站点 build 成功不等于归档内容正确。两项另开工程小批，不混入 UI E4 指标语义或篡改既有归档。
3. 下一批唯一可执行方案：A1-E4-UI（无产品代码改动）
- Gate 0 · 固定包与入口：仅使用已核实 SHA 的 Build 83 公证 ZIP，在独立目录解包并启动真正的 Perfowl SwiftUI App，不是直接启动
perfowl_collector_core stream。记录 App 可执行文件路径、Bundle 版本、内置 core 哈希与实际 child process 路径；录屏或可审计 UI/辅助功能日志证明 Device A、目标 App A/Fixture A 选择、App Ready 与 Start/Stop 操作时刻。私有证据可含原始标识，公开材料只写别名。若不能证明真实 UI 入口，停止并交阻塞，不再称「GUI 等价」。 - Gate 1 · 逐轮冻结条件：核对目标设备/系统、12 项 Start CapturePlan、
capturePlanHash、exact-debug-id、kdf2四类、csd=0、bm=0、rp/tk/ta；并单列预热阶段实际prepare_app指标集/截图标志、app_ready、Start 相对 ready 的时序，以及来源路由。不能只用 15 字段等同前后两段协议；任一关键配置不匹配即标 INVALID，不进入正负向统计。 - Gate 2 · 定向而非刷概率：先 App A 两轮、Fixture A 一轮，按 UI 正常操作，不调负载、录制时长门槛、Stop drain、过滤器或角色标记来追求 r3。每轮按原始字节分类：drain 完整链 / 只有 opener / 只有 closer / 全无 / 身份缺失或冲突 / 容量与 timeout；既要保留真实负向，也不预设三条事件。若三轮无可判定正向链，立即停止同构重复，交 Lead 决定是否进入单独的采集来源/时序研究；不擅自扩样到十几轮。
- Gate 3 · 原始产物与报告：原始 App Session 只读封存并重算 Raw、blob、manifest 哈希；记录 UI live 报告与 Stop 后产物。需要最终 Raw 重扫时，仅在真实字节隔离副本上运行现有
finalize，标记为「新包核心对 E4 Raw 的离线 final」，不得写回 App 原 Session、不得把 CLI final 冒充 UI 自动产物。逐字段比较 Total/质量/来源/phase、诊断、live/final 差异；输出实际candidate/repaired/missing分布，不再使用totalNeverPublished。 - 正式 E4 门：至少一个新包真实 UI会话在最终 Raw 中有身份可信、同线程、设备 tick 有序、阶段链闭合的 drain 正向诊断；另有真实负向形态；配置、哈希与 live/final 主字段证据齐备，Lead 才考虑 E4 PASS。即便通过，D1 仍不授权发布 drain Total；主报告字段不得被诊断提升。若没有正向，维持 E4 OPEN，不因包已公证或 14 份原生 Total 有数而改判。
资源与并发边界：沿用现有有界采集与 Stop 超时，不并发跑其他测试；单批最多 3 个新 UI Session，分析只做一次单遍 Raw 分类与哈希，已有结果复用；不新增高频轮询/多份原始字节复制。交付每轮启动到 Stop/最终报告耗时、CPU/RSS/I/O 峰值及最差一轮，与本批命令入口只作形态对照，不把两入口耗时差直接归因于产品代码。若真机/凭据/环境不满足，记录 blocking reason 后停止。
交付与角色：Implementation AI 只采集并提交原始证据、日期化增量记录、真实偏差、站点新增归档、双远程与 Webhook；不改产品语义，不自判 E4 PASS。Owner 将完整交付转 Lead，Lead 直接独立验收，无需逐批 Owner 审批。TSA 构建脚本与 archive renderer 分别留下一批方案，Network、FrameTime B1/B2/B3、Phase C 保持独立。