启动时间稳定性优化开发方案 v1：独占采集窗口与独立端点账本 ​

本方案承接启动时间稳定性重评，把“先验证双 Tap 争用，再解除 Total 对阶段完整配对的依赖”细化为可执行开发批次。当前仅完成方案与口径入档，没有修改产品代码，也没有把稳定获取状态升级为 validated。进入 SSO-0/SSO-1 实现仍需用户明确批准。

1. 决策 ​

采用 SSO（Startup Stability Optimization）双主线方案：

1. 采集源主线：以当前配置完成 G0 对照；若证实 ActivityTrace 与启动 CoreProfile 同窗会降低准确 Total 成功率，则把启动窗口改成 Startup 独占 Trace Window，Startup stop → drain → release 后再启动 ActivityTrace。全程只有一次目标 App launch，不通过第二次启动补数据。
2. 解码主线：引入 Independent Endpoint Ledger（独立端点账本），System Interface BEGIN 一经目标身份和 generation 验证即独立留存，不再要求第一阶段 END 存活后才能参与 Total；九阶段 span 配对与 Total 端点计算分离。
3. 准确性主线：首帧 END 身份不足时不升格为精确值。frame-end-repaired 单候选默认降为待验证的 repaired；真正首帧 END 丢失但后续帧存活的反例加入永久回归。
4. 条件探索：只有前两条落实后仍未达到门槛，才执行 ActivityTrace 单源启动事务普查 G2；没有目标实例与首帧语义证据就停止，不把整机 FrameLifetime 替代目标 App 首帧。

1.1 为什么不直接选其他方案 ​

2. 目标、非目标与成功定义 ​

2.1 目标 ​

• 提高普通已安装 App 单次受控进程冷启动的 准确 Total 成功率，优先消除工具自身制造的争用和解码错误。
• 保持无侵入边界：不改目标包、不注入、不重签、不嵌 SDK、不依赖 WDA/XCTest Runner。
• 保持一次测量恰好一次 launch；缺真实端点时继续留空。
• 将“源未武装、设备侧丢事件、归属失败、端点歧义、报告/UI 丢失”分层记录。
• 采集、解码、封存、展示都能追溯到同一 endpoint evidence 和 source schedule。

2.2 非目标 ​

• 本方案不承诺生产 App 九阶段每轮 9/9；条件回调仍可能 not-applicable。
• 本方案不把 candidate 自动升级为 validated。
• 本方案不改变 App Launch Total 的两个定义端点，也不引入新的替代指标。
• 本方案不顺带修复 Display、Closeout 或其他在途问题；只与其建立明确串行边界和回归测试。
• G2 不是本轮必做实现，只有触发条件满足才立项。

2.3 稳定性的正式分母 ​

令 N_all 为所有已接受并发起的启动测量请求；源未武装、launch 失败、等待超时、缺报告均进入失败分类。用户主动取消单列，并同时报告含取消和剔除取消两种口径。

P_numeric = N_with_any_numeric_total / N_all
P_exact_candidate = N_with_identity_valid_paired_endpoints / N_all
P_phase = N_with_all_required_phases / N_all
P_source_ready = N_startup_source_armed / N_all

其中 P_numeric 只代表有值率；repaired、ambiguous、start-substituted 不并入 P_exact_candidate。在没有同义参考校准前，名称保持 exact_candidate，不称最终 ground truth。

3. 冻结的架构 ​

3.1 单 Session Trace 生命周期状态机 ​

新增 Session 内部的轻量状态机 StartupTraceWindowGate（名称可在实现时按现有模块风格调整），不新建第二 DTX owner：

idle
  → startup-arming
  → startup-active
  → startup-completing
  → startup-draining
  → startup-released
  → display-arming
  → display-active
  → closing

强约束：

• 同一时刻最多一个受控 trace tap 处于 active/arming/draining。
• startup-released 必须来自 CoreProfile subscription 关闭、drain 结果落账和 tap release 完成；仅收到 completion marker 不算释放。
• Startup 源武装失败时，不阻塞其他指标：启动显式 missing/startup-source-unavailable，随后允许 Display 进入 display-arming。
• Startup 等待超时也必须先有界 stop/drain/release，再进入 Display；不因超时跳过资源释放。
• Session Stop 在任何状态优先，取消待启动的 Display，不为完成串行切换而拖延关闭。
• 不调用第二次 ProcessControl launch。

3.2 G0 对照模式 ​

SSO-0 仅增加可审计的实验策略和时间线，不先改变默认生产策略：

策略只能由内部实验配置选择，默认值保持当前行为，配置和最终 resolved 值进入 manifest。正式切换生产默认值必须由 G0 E4 决策门通过。

3.3 G0 必需的源时间线 ​

新增 startupTraceSchedule 诊断块，所有时间使用 host monotonic，仅用于调度审计，不与设备 Mach tick 混算启动耗时：

{
  "policy": "serial-startup-then-display",
  "startupTapArmBeginNs": 0,
  "startupTapReadyNs": 0,
  "launchRequestedNs": 0,
  "startupEndpointObservedHostNs": null,
  "startupWaitFinishedNs": 0,
  "startupStopAckNs": 0,
  "startupDrainFinishedNs": 0,
  "startupReleasedNs": 0,
  "displayTapArmBeginNs": 0,
  "displayTapReadyNs": 0,
  "overlapDurationMs": 0.0,
  "displayCoverageGapMs": null,
  "transitionStatus": "completed|partial|cancelled",
  "reason": null
}

公式：

overlapDurationMs = max(0, min(startupReleasedNs, displayStoppedNs)
                          - max(startupTapArmBeginNs, displayTapArmBeginNs)) / 1e6

displayCoverageGapMs = (displayTapReadyNs - launchRequestedNs) / 1e6

若任一必要时间戳缺失，对应值为 null，不补 0。串行模式验收要求 overlapDurationMs == 0；Display gap 必须在 UI/报告披露，不能把未采集窗口描述成完整覆盖。

4. 独立端点账本 ​

4.1 数据结构 ​

在 RealtimeLaunchTraceDecoder 内新增有界 endpoint evidence，而不是复制全部 Raw：

LaunchEndpointEvidence
  kind: system-begin | initial-frame-opener | frame-terminal
  machTicks
  timestampNs
  debugID
  threadID
  targetPID
  targetGeneration
  sourceEpoch
  reconnectGeneration
  arrivalSequence
  decoderProfileVersion
  selectionState
  selectionReason

sourceEpoch/reconnectGeneration 需由 consume() 调用链显式传入或从可信 envelope 读取；字段不可得时保持 null，不得默认成 1 后参与“同源”证明。每类端点候选有固定上限，建议起点≤8、opener≤16、terminal≤32；超限时 endpointEvidenceTruncated=true，Total 不得升格为 clean candidate。

4.2 起点选择 ​

System Interface BEGIN 的原始 marker 在完成目标线程归属后立即进入端点账本，不等待 System Interface END。

选择合同：

1. 目标 PID、generation、source epoch 必须匹配当前 launch。
2. machTicks 位于本轮 CoreProfile 窗口，且不晚于所选 frame opener/terminal。
3. 只有一个合法起点时选中，startSelectionReason=unique-system-begin。
4. 多个合法起点时沿用并显式记录当前 profile 的“同线程重复 BEGIN 取最后一个”规则；缺少后续边界约束时降为 duplicate-system-begin-unresolved，不静默任选。
5. 无 System BEGIN 时，最早 dyld/Static BEGIN 仍可作为诊断性 start-substituted，但保持 repaired，不进入准确成功率。

修复后的 Total 起点直接取选中的真实 system-begin.machTicks，不再从完整 System Interface span 反推。

4.3 终点选择与降级规则 ​

Initial Frame END 仍要求与本轮目标身份、generation、epoch 一致。以下规则冻结：

• code=12 opener 与 terminal 正常配对：保持 candidate，但在完成跨源校准前仍是候选，不使用“已证明绝对首帧”的措辞。
• opener 缺失，仅锚点后一个 terminal：repaired-single-terminal-unverified；不再称“精确恢复”。
• opener 缺失，多个 terminal：repaired-multiple-terminals-ambiguous，不进入准确成功率。
• opener 存在但观测到设备丢事件 marker 落在 opener→terminal 窗口：增加 endpointLossEvidence=true，Total 可保留诊断值，但 endpointIntegrity=loss-observed。
• 真正首帧 terminal 缺失、后续 terminal 存活的 E2 反例必须保持非精确；任何启发式阈值都只能形成新的 candidate profile，不能直接覆盖当前定义。
• terminal 不存在：Total 为 missing。

设备丢事件 marker 为 0 只表示“未观测到丢失证据”，不把它用作无损证明。

4.4 报告兼容 ​

保留现有字段供旧客户端读取：totalDurationMs、totalQuality、totalSource、totalRepairReason。新增：

endpointIntegrity:
  paired-candidate
  paired-with-loss-evidence
  start-substituted
  single-terminal-unverified
  multiple-terminals-ambiguous
  evidence-truncated
  missing

endpointEvidence: {...}
endpointEvidenceTruncated: Bool
startupTraceSchedule: {...}
displayCoverageStartsAfterStartup: Bool

旧报告缺少新字段时 Swift 解码保持可选；不得把缺字段回填为 paired-candidate。UI 主结果继续显示数值和现有 repaired 提示，同时增加“端点完整 / 端点待验证 / 端点存在丢失证据”三级说明。导出保留全部审计字段。

5. 公式、单位、窗口与质量语义 ​

5.1 App Launch Total ​

令选中的真实 System BEGIN 为 S，同一目标实例的 Initial Frame END 候选为 E：

durationNs = ((E - S) × machNumer) // machDenom
AppLaunchTotalMs = durationNs / 1_000_000

• scope：process
• unit：milliseconds
• clock：设备 Mach absolute time
• window：单次受控 launch；不跨轮、不跨 generation、不跨 source epoch/reconnect
• 聚合：每轮一个端点差，不是九阶段求和，不做平滑
• 取整：内部保留整数纳秒和原始 ticks；UI 可格式化，但不回写原值
• 合法值：严格大于 0；0/负值为端点错误，置空
• 缺失：起点、终点、身份、profile、timebase 任一必要条件不成立时为 missing 或 repaired，不补值
• reset：无计数器 reset；新 generation 重新建账本

5.2 误差方向 ​

若用晚起点 S' > S：

errorMs = -((S' - S) × numer // denom) / 1e6

若把后续帧 E' > E 当首帧：

errorMs = ((E' - E) × numer // denom) / 1e6

两种错误可能偶然抵消，所以“数值与预期接近”不是正确性证据。

5.3 质量优先级 ​

missing/global-gate
  > evidence-truncated
  > identity/generation/epoch mismatch
  > loss-observed or terminal-unverified
  > start-substituted / multiple-terminals-ambiguous
  > paired-candidate

高优先级异常不得被低优先级成功条件覆盖。phaseCoverageComplete 与 endpoint integrity 正交保存。

6. 代码范围 ​

6.1 SSO-0：争用验证与调度审计 ​

SSO-0 不修改默认产品策略。E4 结论通过后，另一个窄批次才把默认值切为串行。

6.2 SSO-1：独立端点账本 ​

6.3 SSO-2：生产默认切换（条件批次） ​

仅在 G0 满足决策门时：

• Startup + Display 默认策略从 overlap 改为 serial。
• CapturePlan/Registry 不改 source ownership；只改实际 start 时序。
• UI 在 Startup 结束前将 Display 标记为 pending-source-window，而不是普通 missing。
• Startup release 后 ActivityTrace 首事件到达才结束 warmup。
• 单独记录 Display 未覆盖的启动区间，报告不宣称全 Session coverage。

6.4 SSO-3：知识与实现记录 ​

实施批次必须同步：

• 本文追加带绝对日期的 Implementation Update / Validation Update；
• 更新 app-launch-total.md 的 endpoint integrity、版本历史与证据等级；
• 若 Display coverage 语义改变，同批更新对应 Display Canonical 页面；
• 更新 site/devlog/index.md 时间线、P2 阶段和未关门门禁；
• 已完成批次生成新的 docs/architecture / docs/validation 快照，不回改历史归档。

7. 实施批次与批准边界 ​

本次用户指令批准的是“形成开发方案并入档”，不是产品实现授权。后续“继续分析/把方案写细”仍停留在文档；只有“按 SSO-0/SSO-1 开发”才进入代码。

8. 测试策略 ​

8.1 单元测试 ​

端点至少覆盖：

1. clean control；
2. System BEGIN 存活、System END 丢失——Total 必须仍使用原始 BEGIN；
3. 重复 System BEGIN 的确定性选择和 unresolved 降级；
4. code=12 存活、真正首帧 END 丢失、后续 terminal 存活——不得计入 exact candidate；
5. code=12 丢失、单 terminal——single-terminal-unverified；
6. 多 terminal——ambiguous；
7. opener→terminal 窗口有设备 loss marker；
8. loss marker=0 不自动升格；
9. cross-generation/sourceEpoch/reconnect 拒绝配对；
10. evidence 超限 fail-closed；
11. 无/非法 timebase、E≤S、未知 profile；
12. 旧报告无新字段仍能解码显示。

Trace Window 状态机至少覆盖：

• 三种 G0 policy 的 start/stop 顺序；
• Startup source unavailable 后 Display 正常启动；
• completion、grace timeout、absolute timeout 三种 release；
• Stop 发生在 startup-active / draining / display-arming；
• ActivityTrace start 失败不反向污染已完成 Startup；
• 串行模式 overlap 精确为 0；
• 不发生第二次 ProcessControl launch；
• 慢 drain/忙 tap 仍受现有 deadline 约束。

8.2 集成与回放 ​

• 用 fake DTX/tap 记录 start/stop/release 调用顺序，验证单 owner 与零重叠。
• 对冻结启动 fixture 做 old/new 同 Raw 回放，除已修复反例和新增质量字段外，其他阶段数值逐项一致。
• 对仍存在且 hash-valid 的真实 Raw 逐份回放；不可用的历史 134 份只保留历史统计，不伪装为可重跑集合。
• Raw→launch report→online report→Swift decode→presentation 端到端合同测试。
• 断开、截断、乱序 chunk、late attribution、主机队列 drop 和 device loss marker 分别注入。

8.3 G0 真机实验 ​

固定同设备、同系统 build、同 App 版本、同其他指标选择。每个 App 内采用 A/B/C 交叉均衡顺序，轻/重目标和静置后首轮/连续轮分层；每个 cell 起步 30 轮，只作筛查。

主指标：P_exact_candidate、terminal presence、endpoint integrity、source armed、device loss marker、启动等待时长、Display coverage gap。辅助记录温度、电量、网络、旧进程终止状态和可识别预热状态。

串行决策门：

• C 相比 A 的准确端点成功率有可重复提升，且提升不是由 App/轮次顺序解释；
• C 的 overlap=0，Startup host drop=0；
• Display release 后能稳定进入 active，coverage gap 被正确披露；
• 无新增 launch、死锁、stop 超时或整体失败率回归。

30 轮筛查的 Wilson 区间仅用于方向判断。若差异不稳定或 B/C 无改善，SSO-2 停止，不为“看起来合理”切默认。

8.4 准确性校准与最终稳定性门 ​

• 可控 Fixture：通过已知延迟、延迟首内容、启动画面、多 scene、动画和后台抢前台等正负例校准端点身份；开发签名环境与生产 App 结论分开。
• 普通 App：测可得率、内部一致性和错误分类，不把不同轮次的参考 trace 当逐轮真值。
• 平台分层：至少按 OS profile、设备代际、轻/重 App、静置首轮/连续轮分层。
• 准入目标：每个声明支持的关键分层 P_exact_candidate ≥ 99%；要让零失败样本的单侧 95% 下限达到约 99%，需约 300/300，不能用总体混合样本替代分层样本。
• 误差目标：存在同义参考时，绝对误差 P95≤max(5 ms, 1%)、max≤max(20 ms, 3%)；没有同义参考则不宣称该误差门已关闭。

任何错 App、错 generation、错首帧、跨 epoch 配对都算正确性失败，不仅是离群点。

9. 轻量化与性能门禁 ​

9.1 复杂度和资源预算 ​

9.2 基准要求 ​

实施后必须使用相同全尺寸 Raw 对比旧/新：

• 解码 wall time、CPU time、事件吞吐、RSS 峰值、I/O 峰值；
• 首个阶段 revision、设备 terminal→主结果就绪、长启动完成时间；
• 正常、洪流、乱序、截断、15 s 最差等待；
• 状态机 10,000 次合成循环无资源泄漏；
• endpoint 改动的解码 P95 回归≤5%，新增内存符合上表；
• 串行策略必须报告 Display 首事件延后量，不能只报告 Startup 改善。

未达到预算或缺少前后对比时，状态保持 partial。

10. 风险、护栏与回滚 ​

每批一个窄提交；禁止强推。历史 Session 和已发布 devlog 数字不重写。

11. G2 条件分支与停止条件 ​

触发条件：完成 SSO-1，且 G0/SSO-2 仍使声明平台的 P_exact_candidate 达不到目标，同时缺失主要集中在 terminal identity。

G2 只运行 ActivityTrace 单源 census：先统计 schema/子系统/事件名，不保存日志正文；发现候选后再验证目标 PID/launch transaction/scene/surface 身份、设备时钟、首帧语义和独立丢失路径。

满足下列任一项即停止：

• 两个代表性系统 build、轻/重目标均无目标级启动事务身份；
• 只有整机 FrameLifetime，无法证明属于目标 launch；
• 端点与 CoreProfile/Fixture 语义不一致；
• 新源资源开销或与其他采集源冲突不可接受。

G2 若形成新定义，必须使用新的 metricID 和 Canonical 文档，不覆盖当前 App Launch Total。

12. 交付与发布门禁 ​

每个产品代码批次完成后按项目规则执行：

1. 匹配单元、集成、全量 Python/Swift、知识门禁与 VitePress 构建；
2. 真实规模性能前后对比；
3. 本地窄提交；
4. 当前分支同一提交双远程推送尝试；
5. Developer ID 对 App/容器签名，提交 Notary，成功后 stapling；
6. codesign --verify --deep --strict、Gatekeeper、独立解包/安装、universal 架构、dSYM UUID、SHA-256；
7. 真机 E4 与原生 UI 录证；
8. delivery webhook；
9. 汇报下一阶段与整体进度。

证书、Notary、网络、设备或 GPL-3.0 法务门禁缺失时如实标记 partial/blocked，不把内部测试包描述为正式交付。

13. 本方案的验收清单 ​

• [ ] 用户明确批准 SSO-0/SSO-1 开发。
• [ ] 公式和质量语义已在本文冻结；实施时 Canonical 同步。
• [ ] G0 三模式均有 resolved policy 和源时间线。
• [ ] 串行模式 trace tap overlap=0，且恰好一次 launch。
• [ ] 原始 System BEGIN 存活、phase END 丢失时 Total 使用真实 BEGIN。
• [ ] 首帧丢失/后续帧存活反例不计入 exact candidate。
• [ ] 旧报告兼容，新字段缺失不被填成成功。
• [ ] E2 全量、基准和知识站构建通过。
• [ ] E4 筛查决定是否进入 SSO-2，而不是凭设计推断切默认。
• [ ] 支持矩阵达到分层统计门后才升级稳定性结论。
• [ ] App/DMG、签名、公证、stapling、安装、哈希与 webhook 独立完成。

14. 下一阶段与整体进度 ​

下一阶段：等待用户明确回复“按 SSO-0/SSO-1 开发”。获得批准后先做 SSO-0A 调度诊断与 G0 三模式，不直接切默认；随后做 SSO-1A 独立端点账本和永久反例测试。

整体进度：研究和开发方案已完成入档；产品现状仍是“可获取但不稳定，端点正确性存在开放门禁”。稳定方案实现、真实设备因果验证、分层准确率、性能、原生 UI、正式签名公证与分发合规均未关闭。