Build74 Phase 2 后续最小修复方案（Stop-drain 生命周期补齐 + FrameTime 双时间域）

> 角色 Lead AI（方案阶段） · 2026-09-24 · 判据 judgement = pending-lead-ai · codeChanged = NO > 依据：R3 取证提交 1ef33f7（父 f5da818）之交付物 artifacts/build74-owner-e4-followup-20260924-1232/ > 冻结产品 1ec9462（Build 74）；审计基线 4c1e424 > 本批只交方案，不修改冻结产品、不重打包、不删除任何原始 Session / .trace。

---

0. 授权与边界（先读）

---

1. 一页结论

任务 A：根因已被完整钉死（因果链单因、可机械复算）

四轮（S2 / r1 / r2 / r3）的采集侧遥测结构完全相同：coreProfileCaptureMode = "startup-only"、coreProfileRestartCount = 0、startupCoreProfileCompletionWaitStatus = "timed-out"、reason = "startup-completion-grace-expired"、grace 4.0 s。

实测因果链（r3，主机单调域，相对 launch.requested.raw）：

关键判读：coreProfileStreamRole 由主机侧完成信号决定（realtime.py:4051-4055：role = "frame-continuation" if (prestarted_core is None or startup_semantic_complete.is_set() or startup_rotation_complete.is_set()) else "startup-lifecycle"）。四轮中 startup_rotation_complete 从未置位（restartCount = 0），故翻转由 startup_semantic_complete 单独驱动，实测翻转点落在 t5 之后 316.705 ms，与源码顺序一致。

startup-only 模式下不存在帧续采（restartCount = 0、handoffRestartCompleteNs = null），因此 drain 段携带的仍是启动窗口内的原始记录（实测设备域 +2.25 s / +2.31 s，早于 t5 的主机时刻 8.2 s）。该 frame-continuation 标签是主机侧策略产物，不是关于数据内容的证据——这正是缺陷本体。

任务 A 的定量边界（本方案最强结论）

在冻结解码器上，逐轮清点「位于 frame-continuation+post-stop-drain chunk 内 且 在生命周期命名空间 且 被产品自身 _thread_pids 归到目标线程 且 _lifecycle_actions() 非空」的记录：

r3 的 3 条恰为：0x2B870030（code=12，END UIKit Scene Creation + BEGIN Initial Frame Rendering）与 2 × 0x31CA0006（END Initial Frame Rendering），全部 tid 归属目标线程，opener 早于首个 closer 54.0437 ms。

两条 S2 旁路事实（两者都独立保证负向回归不被破坏）：

1. S2 在 drain chunk 内确实有 9 条生命周期命名空间可产 marker 的记录，但无一条归属目标线程 ⇒ 目标 PID/generation 门天然把它清零；
2. r1 / r2 的 frame-continuation chunk 不含任何 binary chunk（全部为 bplist，零 kd 记录，与 R3 取证一致）⇒ 连清点对象都不存在。

⇒ 「有界 Stop-drain 补齐」的准入增量是 3 / 0 / 0 / 0，可论证为恰好命中 r3 且对三轮负向零副作用。

任务 B：报告映射问题已定位到具体的缺失映射行，且是「映射缺口」不是「数据缺口」

机械证据（同一次 Session d3206bbe…）：

• metrics-derived.jsonl = 0 字节；metricSHA256 = e3b0c442…（空串的 SHA-256）；metricIDs = []；frameCount = 0；formulaVersions = []；而 consumedRawEventCount = 1717、lastConsumedRawSequence = 1717 ⇒ 派生引擎吃满整条流、产出为零。
• 五项 coverage[] 全部 coverage = []、reason = null，且 ios.frame.time 唯一有样本（1686，来自 frameSummary.intervalCount）。⇒ coverage 窗口数组对全部五项都没接线。
• online_report.py:1341-1370 的 _apply_frame_coverage.metric_map **含 ios.frame.time 与 14 个 ios.frame.* 兄弟项，唯独不含上表四条**。
• 四个 metricID 在 metric_engine.py 中完全不出现（该引擎只有 ios.foreground.fps 一条，且源字段是 CoreAnimationFramesPerSecond，属 graphics.raw 路径而非本次的 display.frame-lifetime.raw）。
• display_performance.py:2011-2019 的 DisplayPerformanceProjector 已实现全部五项并写明口径（trailing 1 s / 10 s 滚动 P95 / 硬件 VSync / P95−P50），甚至已内置 FRESHNESS_STALE_HOST_GAP_NS = 1.0 s 的「陈旧但不伪造 0」规则；它被 realtime.py:819 正常喂入，但它产出的值只落在活线样本字典（realtime.py:1074-1097 的 metrics["framesPerSecond"] 等 camelCase 字段），从不进入 coverage[] / sample_count（后者的唯一写入点是 online_report._consume_metric_frame()，只吃 metric-ID 形状的帧）。
• 顶层 dataCompleteness = "complete" 与「5 项里 4 项零样本」并存 ⇒ 报告自相矛盾。

结论：四项 sampleCount = 0 是映射/接线缺口，不是采集缺口——同源同窗的 ios.frame.time 拿到 1686 样本即为反证。修复方向是把 DisplayPerformanceProjector 声明为这四项口径的唯一所有者并接线，而不是去扩 _apply_frame_coverage 的 metric_map（那会造出第二个口径所有者，违反 realtime.py:1013-1015 已写明的「Metric Engine is the sole formula owner」）。

---

2. 任务 A 的完整因果链（已验证，含反例排除）

2.1 证据链

2.2 S2 的 null 与 r3 的 null 是两个不同的缺口（不可混为一谈）

r1 / r2 同理：ignoredTerminalCount = 0 ⇒ Mode A 零候选；且其 drain chunk 全为 bplist。

2.3 明确未定、本方案不升级的三项

1. S2 / r1 / r2 的 opener 为何不在交付字节里（环形覆盖 / 不同 UIKit 路径 / 采集窗口截断，三候选均未排除）；
2. drain 内非目标线程的 31（r3）与 9（S2）条生命周期记录属于谁（另一进程 / 预热侧车 / 其它 target generation 均未区分）；
3. FrameTime 两轴 ≈4.4 倍差的定性成因（见 §8）。

---

3. 任务 A 方案：有界 Stop-drain 生命周期补齐

3.1 设计原则

1. 不改采集侧标定：realtime.py 的 role 判定与 chunk 打标逐字节不动。「有界」体现在解码侧准入，不体现在改标。
2. 准入必须是「补齐」而非「扩权」：drain 记录只能闭合已由保留记录开启的启动阶段；不得凭空开出新的、且结束时仍 open 的阶段。
3. 结构性不动 Mode A：drain 记录永不进入 _markers 与 _ignored_terminal_events，因此 _lifecycle_anchor_ticks() 的取值集合与 Mode A 的 candidates 过滤器在构造上与冻结版逐字节一致。
4. 来源必须可分辨：drain 挣得的端点不得复用 totalSource = "coreprofile-endpoint" + totalRepairReason = "endpoint" 这一「真实配对」标签对（见 §6）。
5. 有界资源：仅在存在候选 drain 记录时才多跑一遍；否则（S2/r1/r2 全轮）零增量。

3.2 四道准入门（AND，全部可机械检验）

上界为何取 15.0 s 而不是 max(启动侧 tick)：后者被实测否定——r3 启动侧 chunk 内最大设备 tick 仅 +1 529.529 ms，而端点记录在 +2 246.6 ms（采集 tap 停止后才从 drain 交付）。因此单边上界不足以表达该窗口，G3 必须写成区间（max(启动侧已见 tick) 之下、launch_start + 15 s 之上）。该结论直接来自实测，非设计偏好。

3.3 结果形态（r3 应然）

• ios.process.startup.initial_frame_rendering_ms 出现（PHASE_METRIC_IDS，launch_trace.py:135）；
• UIKit Scene Creation span 闭合 ⇒ 准入后 unmatchedBeginCount 由 1 归 0，spanCount 11 → 12；
• requiredMissingPhases = []、phaseCoverageComplete = true；
• totalSource = "coreprofile-endpoint-stop-drain"、totalRepairReason = "frame-end-stop-drain"、totalQuality = "repaired"；
• status 仍为 partial / reason = "lifecycle-spans-incomplete"：本方案不置 self._completed = True（见 §3.4）；
• _ignored_terminal_events 与冻结版完全一致（r3 仍为 0 条）。

3.4 为什么不置 _completed

_completed 参与两个语义：total_endpoint_complete（launch_trace.py:1435）⇒ status 可升为 candidate；以及 completionObserved。若 drain 端点被允许升为 candidate，则活线完成信号（launch_trace.py:1224-1228：要求 totalDurationMs is not None 且 totalQuality == "candidate"）将据此关闭启动面板——把一个 drain 挣得的端点当成干净端点。因此：

• 不置 _completed ⇒ status 留在 partial，totalQuality = "repaired" ⇒ 活线完成信号继续等待（与现状一致）；
• 这是刻意保留的诚实性：修复带来的是最终离线报告与阶段覆盖的正确，不是实时完成信号的改变。

3.5 活线仍不会完成的已知后果（必须显式记录，不得隐藏）

launch_trace.py:1211-1212 的活线完成发射带 not is_frame_continuation 前置条件。drain 是本次采集的最后阶段且其 chunk 全为 frame-continuation，故 drain 之后不会再有非 drain chunk。⇒ r3 这类会话在活线 UI 上仍不会自动完成启动面板；本方案只修最终报告。该限制在 §11 风险清单 R6 原样登记，作为后续独立批次的候选议题（不并入本批）。

---

4. 代码变更边界（文件 / 函数 / 常量级）

> 以下为待批准的实施边界，本批一行代码都未改。

4.1 MacApp/Sidecar/perfowl_collector_core/launch_trace.py（唯一必改文件）

明确不动（逐字节）：_lifecycle_anchor_ticks()、_recover_total_endpoint() 的锚点与候选逻辑、_pair_markers() 的 _ignored_terminal_events 分支（:1822-1833）、_process_lifecycle() 的 marker 准入门（:1704-1739）、_lifecycle_actions()（:2345-2378）、consume() 的 chunk 连续性/_minimal_live_scan/target scoping 门（:1072-1182）。

4.2 MacApp/Sidecar/perfowl_collector_core/realtime.py

本批不改。 role 判定（:4049-4054）、startup_semantic_complete.set()（:4813）、startup_rotation_complete.set()（:4386）、drain 上界（:4857-4874）、完成等待（:4776-4801）全部保持冻结。§1 的时序结论是只读核对得到的。

4.3 任务 B 的候选变更边界（本批只登记，需 Lead 另行批准）

---

5. 单元 / Fixture 测试设计

全部为新增测试，不改既有断言。命名建议 tests/test_build75_stop_drain_lifecycle_completion.py（若后续批次号变更，文件名随批次）。

5.1 正向（r3 形）

5.2 负向（必须继续 missing）

5.3 对抗性（提级与扩权探测）

5.4 效率门禁（按 AGENTS.md §工作流程）

• 关键路径：consume() 内每条 drain-chunk 记录多一次「namespace + _lifecycle_actions()」判定；_complete_stop_drain_lifecycle() 只在 _stop_drain_records 非空时运行。
• 实测规模：r3 的 fc+actionable（任意线程）= 31、目标线程命中 3 ⇒ 缓冲上界 31 条（容量 512 有 16× 余量）；S2/r1/r2 均为 0 ⇒ 零增量。
• 复杂度：O(R_drain)，R_drain 有界；无新增全量扫描、无新增数据复制、无新增进程。
• 需补 benchmark：同一不可变 Session 上开关本特性各跑 N 轮，报 total (ms)、ru_maxrss 增量、decodedRecordCount 不变性（三项均须「本批自有增量」口径，未归因数字原样出表）。

---

6. 标签契约与「反事实」防误用

6.1 必须保持的不变式

> totalSource == "coreprofile-endpoint" 且 totalRepairReason == "endpoint" ⟺ 真实配对（非恢复路径）

本方案通过引入两个新 token 保持该不变式：totalSource = "coreprofile-endpoint-stop-drain"、totalRepairReason = "frame-end-stop-drain"。三处既有消费点因此自动正确：

1. totalQuality（launch_trace.py:1568-1572）⇒ "repaired"（不是 "candidate"）；
2. 活线完成信号（:1224-1228）⇒ 要求 "candidate" ⇒ 不触发；
3. _apply_frame_coverage() 的 items/total_item 分支（online_report.py:1063-1068）⇒ 该端点不进入阶段级覆盖的 candidate 通路。

6.2 被否决的反事实

R3 记录的单变量对照曾把 drain chunk 的 role 直接改标，得到 totalDurationMs = 2300.676291、totalSource = "coreprofile-endpoint"、missing = []。

该组合被明确否决，理由有三，且均为结构性而非口味问题：

1. 它把 drain 挣得的端点伪装成干净端点（totalSource/totalRepairReason 落在真实配对标签对）⇒ 违反 §6.1 不变式；
2. 它靠无条件改标 chunk 达成，正是本次被明令禁止的手法；本方案的 3/0/0/0 增量与链闭合门才是「有界」的证据；
3. 该数值在本方案中不得作为真值引用。它只在 §1 / 本节以「被否决反事实」出现；实施后报告中它会以 totalSource="coreprofile-endpoint-stop-drain" + totalQuality="repaired" 出现，与干净端点结构上不可混淆。

---

7. 任务 B 的时间域 / 覆盖度证据方案

7.1 现象基线（R3 已审计，逐字保留）

7.2 已被证据排除的两项、与仍需证明的项

本批只主张：两轴恒定相差 ≈4.4 倍，且产品未标注。不主张任何单一成因。

7.3 证据方案（离线，全部只读、不需要真机）

E-B1 · 用产品自身的投影器把两轴并列出来

DisplayPerformanceProjector.consume(event, host_receive_monotonic_ns=…) + snapshot(now_ns) 是纯函数式接口，可直接离线重放 T2 的 1716 条 display.frame-lifetime.raw（含其 hostReceiveMonotonicNs），并对每次发布导出：

hostReceiveMonotonicNs / presentationTimestampNs /
framesPerSecond / fpsQuality / frameTimeMs / frameTimeP95Ms /
refreshRateHz / framePacingJitterMs / host_gap_ns（投影器内部）

判别力：FRESHNESS_STALE_HOST_GAP_NS = 1.0 s（display_performance.py:2036）已经把「无明显证据」与「源真的空闲」分开。若 refreshRateHz ≈ 60 稳定、且 stale 样本占比与 4.38 倍差相关（而设备轴 87.9% 恰 1× 刷新），则 DEVICE_TIMELINE_QUANTIZED 与 HOST_TRANSPORT_THROTTLED 可被分离：量化解释预测「设备轴丢长间隔」，陈旧解释预测「主机轴有 >1 s 静默段且与 stale 标记重合」。这是本方案最高优先级的可执行项，因为它同时验证 §8 的报告映射修复是否真的能产出这四项。

E-B2 · 覆盖度账本（两轴并列，作为报告新增块）

runtimeMs / sampleCount /
firstSampleHostNs / lastSampleHostNs / observedSpanMs(host) /
firstPresentationNs / lastPresentationNs / presentationSpanMs(device) /
spanRatio / gapCountOver1s / maxHostGapMs / staleSampleCount /
refreshRateHz / p95WindowsObserved / p95WindowsRequired

要求：observedSpanMs 必须与 displayAcquisitionCensus 自身口径可比，presentationSpanMs 必须与 frameSummary.durationMs 可比，并把 spanRatio 与 staleSampleCount 作为一等字段呈现——即「产品既没把 134.9 s 的观测跨度呈现出来」这一缺陷在报告层被关闭。

E-B3 · 交叉一致性门（可机械检验的自证）

E-B4 · 明确不可得的部分（守边界）

无设备侧独立墙钟桥时，设备↔主机的绝对偏斜不可证明（与项目自身 C0「离线结构上无法产出同事件双流配对 witness」的结论一致）。因此：

• 本方案不声称已证明成因；
• 若后续需要定性，唯一可行路径是 E4 期间增补 host 侧可观测桥（例如分段操作时由操作者在宿主侧留下带时刻的分段标记，使每段的 hostReceiveMonotonicNs 区间可与人工时刻对齐），仍不构成设备轴→主机轴的绝对换算；
• 该缺口原样登记，不做「零候选」式断言。

---

8. 四段滚动 / 静止同机测试与时间标记方案

8.1 配置（必须与 T2 逐项一致，否则标 INVALID）

8.2 分段与时间标记（真实打点、不代填）

打点机制（三级，互为独立来源，任一缺失即记为缺口、不补造）：

1. 宿主侧 5 s 心跳账本（主，零产品改动）：录制期间在另一终端运行

while :; do date -u +%FT%T.%3NZ; sleep 5; done > phase-marks.txt， 记录 Session 的 startedAt / endedAt 与 durationMonotonicNs，用两端锚点做一次线性拟合把墙钟心跳映射到单调域。140 s 量级下分辨率 ≤ 1 s，足以切段。

1. 操作者手写四段起止（辅）：操作者自报「滚动/静止」切换时刻（只记整秒），与 (1) 交叉核对；两者不一致时记录分歧，不取平均、不改数据。
2. 信号自证（独立于人工）：静止段的 refreshMultiple 应几乎恒为 1×（设备轴 p50 ≈ 16.64 ms），滚动段应出现 2×–6× 倍数与更宽的 refreshMultiple 取值集合。用 refreshMultiple 的分布跳变独立推断段边界，再与 (1)(2) 对照。三条独立来源一致才认定为有效分段。

8.3 每轮交付物

• Session 目录 + SHA256SUMS（含 core-profile-chunks.bin、manifest.json、report-final.json、display-acquisition-census.json）；
• 段边界账本（心跳原文 + 手写原文 + 由 refreshMultiple 推断的边界，三者并列，含分歧记录）；
• 双轴报告（按 §7.3 E-B1/E-B2 产出）；
• 每轮的 capturePlanHash / effectiveFrameFilter 核对结论。

---

9. 真机验收矩阵

9.1 任务 A

9.2 任务 B

所有判据的最终裁定归 Lead AI；本方案不输出 PASS/FAIL。

---

10. 风险清单

---

11. 诚实性声明（必须在验收时一并读）

1. 负向回归不可能逐字保持：一旦修复生效，r3 的 totalDurationMs 由 null 变为真实值。因此负向回归的唯一正确表述是：**「S2 / r1 / r2 必须继续 missing，且任何轮次、任何情况下都不得出现 *-repaired 之外的虚假干净标签、不得放宽锚点」**。把「r3 仍为 null」写进验收判据，是把已修缺陷当回归基准。
2. 本批零产品改动，故其自身证据等级为 E2（离线构建/测试级），不含任何真机 E4 结论。
3. 不在本批范围内的三项未定项（§2.3）在本方案中保持未定，未以任何方式升级。
4. 未自判：本方案不输出 PASS/FAIL，不宣称任何阶段门禁关闭或开启；judgement = pending-lead-ai。
5. 原始 Session、原始 .trace、他人未提交文档在本批中零读写副作用；全部离线分析在私有归档副本上进行，编号目录只增不删。

---

12. 明确不做的事 / 另开批次

---

13. 复现与证据来源

只读分析脚本（私有归档，编号目录只增不删）

<PRIVATE_ARCHIVE>/build74-owner-e4-followup-20260924-1050/scripts/
  analyze_drain_admission_delta.py    → app-rounds/drain-admission-delta.json   （§1 准入增量 3/0/0/0 + Mode A 复算）
  analyze_startup_delivery_lag.py     → app-rounds/startup-delivery-lag.json    （§1 时序表 + 设备域区间 + §8.2 设备侧依据）
  analyze_startup_rounds.py           （既有引擎：cp / validate_recorded_session / 解码器构造，被上两个脚本复用）
  probe_ifr_pairing.py / lifecycle_code_census.py / ifr_timeline_geometry.py /
  control_ifr_retention.py / analyze_t2_frame.py / session_sha_inventory.py

R3 已审计交付物

artifacts/build74-owner-e4-followup-20260924-1232/
  startup-endpoint-forensics.md   （任务 A 端点取证）
  t2-frame-dual-timeline.md       （任务 B 双时间轴）
  test-matrix.json / session-sha-inventory.json / evidence-hashes.json

产品只读核对锚点（本方案全部时序与准入结论的源码依据，均已逐字节未改）

realtime.py        : 91-94 / 154 / 158 / 160（常量）· 4049-4055（role 判定）· 4776-4801（完成等待 emit）
                     4813（startup_semantic_complete.set）· 4386（startup_rotation_complete.set）
                     4857-4874（rotation 请求 + drain 上界）
launch_trace.py    : 126-135（PHASE_METRIC_IDS）· 947-1062（consume）· 1146-1151（retain_record）
                     1192-1194（saw_completion_marker）· 1336-1350（干净端点 + totalSource）
                     1435-1464（status / publish_total）· 1568-1578（totalQuality/Source/RepairReason）
                     1618-1673（_reset_semantics / _rebuild_semantics）· 1704-1739（_process_lifecycle）
                     1773-1866（_pair_markers）· 1868-1880（_lifecycle_anchor_ticks，不动）
                     1882-1941（_recover_total_endpoint，不动）· 2345-2378（_lifecycle_actions）
adapters.py        : 1108-1135（streamPhase: post-stop-drain）
online_report.py   : 1087-1155（_consume_metric_frame）· 1341-1370（_apply_frame_coverage）
capture_plan.py    : 233-310（MetricCoverage）
display_performance.py : 2011-2036（DisplayPerformanceProjector 五项口径 + FRESHNESS_STALE_HOST_GAP_NS）
realtime.py        : 814-823（投影器喂入）· 902-906（_latest 唯一写入点）· 1069-1097（快照消费）
metric_engine.py   : 141 / 476（仅 ios.foreground.fps，源字段 CoreAnimationFramesPerSecond）

---

14. 交给 Lead 的三个待决点

judgement = pending-lead-ai