Build49 启动完成实时展示

目标

启动是一次性瞬时过程。CoreProfile 观察到启动首尾端点并满足 5 ms 乱序宽限后，Collector 必须立即向工作台发布 Total 和各阶段结果；常规性能采集继续运行，用户停止采集与最终报告生成均不作为首次展示条件。

已确认根因

Build48 最新真机会话的启动请求、目标身份和 512 MiB CoreProfile 原始数据均存在，但客户端给完整收尾链 10 s。停止后的 drain、Raw 校验和帧分析先消耗约 8.64 s，随后启动分析被终止，launch-trace-report.json 未落盘。独立回放同源数据可恢复 1838.117 ms Total candidate，证明缺口位于实时发布/收尾编排，而非启动首尾数据缺失。

实施方案

1. 实时 CoreProfile 单消费者在 Raw 持久化后增量喂给 Launch Decoder，完整端点满足乱序窗口后立即发出一次 launch_trace(final=false)；发布后释放启动语义缓存，后续只继续同扫投影 Frame Time。
2. Decoder 总体可保持 partial，但 Total 与各阶段按各自边界独立发布；某阶段缺失不清空其他完整阶段。
3. 客户端把实时启动事件登记为 startup 并保存到 append-only Session，工作台和 Review 复用同一结构。
4. 停止后最终回放继续承担 Raw 哈希绑定和迟到事件校验，只发 final=true 覆盖同 generation 快照。

效率与边界

• ingest：每个 CoreProfile record 单次增量扫描，O(N)；仅保留归因记录和生命周期 class，内存 O(K)。
• 完成判定：只在 Initial Frame END 或 5 ms 宽限后的 chunk 重建一次语义，O(K log K)，每个启动实例至多实时发布一次。
• 并发：沿现有单 CoreProfile 消费者执行，重计算放入后台线程；不新增无界队列、不复制整份 trace。
• 目标：首尾端点可用后 1 s 内出现 Total；常规样本继续到达；停止前可观察到启动事件；零新增 bridge live drop。
• 超时：实时发布不依赖 10 s stop timeout；最终报告仍保持独立有界收尾和 partial 语义。

验收

• 单元测试：partial trace 具备完整 Total 时实时发出；阶段值独立保留；缺失阶段仍为 null；source loss 仍全部 fail-closed。
• 集成测试：launch_trace(final=false) 必须在 stop/capture_stopped 之前出现。
• 同源回放：使用最新失败会话验证 1838.117 ms Total 与阶段质量。
• 真机：采集保持运行时直接观察启动面板；记录终端事件到客户端展示延迟、常规样本和 bridge drop。

实施与结果

Decoder 已升级至 core-profile-app-lifecycle.candidate.v5。实时 CoreProfile 路径以一次共享扫描同时产生 Frame Time 与启动生命周期结果；满足 Total 首尾端点和 5 ms 乱序宽限后立即发出 launch_trace(final=false)。客户端将其归类为 startup 事件并立刻更新工作台，停止后 final=true 只负责最终校验。

最新失败真机 Raw 的同源回放在第 43/127 个 CoreProfile chunk 发布 Total 1838.117 ms candidate；该 chunk 的源接收时间比用户停止早 9443.669 ms。一次流式回放中，共享扫描处理 2,475,195 条记录用时 4.382 s，低于同批 chunk 的 6.629 s 到达窗口，估算无处理积压，同时投影 73 个帧事件。为排除单次缓存波动，又以同一 Raw 做 3 轮交错资源基准：双扫描/共享扫描中位耗时为 8.086/7.327 s（下降 9.4%），CPU 时间为 7.380/6.338 s（下降 14.1%），吞吐量为 30.61/33.78 万 records/s（提升 10.4%），最差耗时为 10.347/7.458 s；峰值 RSS 为 231.49/231.73 MiB，块 I/O 均为 0。继续消费发布后的 84 个 chunk 时，总计投影 295 个帧事件，live 启动记录缓存保持为 0，长时常规采集不再继续累积启动语义记录。

设备 A / 目标 App A 命令级 E4 复测在采集仍运行时收到 Total 1832.309 ms candidate，随后继续收到 2 个常规样本才发送停止；bridge liveQueueDropCount=0。六个完整阶段已实时显示自身 candidate 值，三个未形成完整 Span 的阶段保持 missing，整体 trace 如实保持 partial。该次从用户操作到客户端收到启动结果为 10.658 s，其中包含冷启动和设备分块传输；它证明“停止不是触发条件”，但尚未达到计划中的 1 s 展示延迟目标。

验收结论

Python 302/302 通过；Swift 130 项中 127 通过、3 项显式资源基准跳过。E4 命令链已经证明实时结果先于停止且常规采集继续。由于原生窗口像素级验收和 1 s 延迟目标仍开放，本批状态为 implemented · partial。

Build49 x86_64 内测 App 已使用 Developer ID Application 与 hardened runtime 重签，codesign --verify --deep --strict、独立解包、主程序启动及三套随包工具探针通过。公证凭据尚未配置，Gatekeeper 返回 Unnotarized Developer ID，因此该 ZIP 仅作为内部测试包，正式发布、stapling 与 Gatekeeper 门禁保持开放。