外观
C0-FIX-03 · prepared START、Clock 与 END 证据修复方案
角色：Lead AI 制定方案；Implementation AI 在 Project Owner 明确转交开发指令后实施；Test AI 后续收集真实 E4；Lead AI 独立复审。 基线：HEAD
a3b25e77bf725580c2b4f23b804189551c49ec7c含已验收 C0-FIX-02B0c9f6da。开工必须重新核实 HEAD、git status并隔离现存脏改动。 Gate：C0 E2 PASS；二次真机 E4 诊断有效，C0 总 Gate 仍 PARTIAL/BLOCKED，C1 未开始，C2 未授权。 资料：site/devlog/p4-startup-phase-c-hybrid-total-plan.md、site/devlog/p4-startup-c0-iphone15-e4-test-plan.md、site/devlog/p4-startup-c0-historical-dual-source-reproduction-plan.md。原始记录本机artifacts/c0-e4-dual-source-repro-20260923-003721/、artifacts/c0-e4-iphone15-20260922-163458/。不可修改原始历史 Session。
1. Lead 决策依据、关键修正和本批目标
二次 Test AI 产物 120/120 哈希经 Lead 独立核验，原始 raw-events.jsonl 同场确认：
| Session | 路径与目标 | CP chunks | FrameLifetime | live lifecycle |
|---|---|---|---|---|
e010d1ee | H1 / GUI wire-equivalent prepared | 28 | 91 | partial、1 span |
bc97978a | H1 / GUI wire-equivalent prepared | 29 | 93 | partial、0 span |
c251a56a | Fixture A / 同样 prepared | 24 | 39 | candidate、13 span、九阶段，legacy Total 295.62ms |
9a593d26 | Fixture A / headless | 37 | 0 / 1318 messages | candidate、13 span，legacy 200.79ms |
H1 原版 App Store 签名无 get-task-allow，headless start_suspended=True 被系统拒绝；GUI 等价 prepare_app → start 路径采用非挂起 cold launch 可合法启动。注意 Test AI 运行的是GUI 协议等价驱动，不是真实点击 GUI 的端到端测试；正式 E4 需要额外补实际 GUI 冒烟。不能为测试重签、注入或放宽权限。
重要纠偏：不能把 START 丢失笼统归咎 prepared 路径。相同 prepared 路径下 Fixture A 有完整 13 span，而 H1 两轮仅 1/0 span。需要基于源层时间线、预启动 RAW、PID 绑定、buffer/drop、decoder/profile 比较，确认是否为目标/时序交互、真实丢源或软件回放缺陷。
三个双源 Session 的 CoreProfile 与 ActivityTrace device ticks 窗口不重叠，分别间隔约 0.40、1.56、6.00 秒；二者 numer/denom 同为 125/3，但 CP 来源 device-reported、ActivityTrace 来源 assumed-constant；pairedWitnesses=[]。两流同在一个 Session 不是 shared epoch 的证明。
本批工作包：
- 03A 必做且优先：H1/Fixture prepared START 丢失分类；修有证据的软件缺陷；消除 live 与 C0 离线 Session 投影之间已确定的重建分歧。
- 03B 次之、严格可行性优先：查真实设备时钟 provenance、同事件跨源 witness 是否可获得；可得则最小化实现诊断，不可得交可证伪报告/Clock Proof Amendment 草案，不自行改 Clock Gate。
- 03C 最后：利用现有合法 DTX 的独立 PID/前台信号补有界 END 归因诊断；只有时域和身份链完整才可解除对应 Gate；没有 surface→PID 时
real不可达。
本批不实施 C1：不新增活线 Hybrid evaluator，不修改主 Total/九阶段公式、不改 UI 指标，不引入 unified CoreProfile、第二 kperf owner、重复 ActivityTrace 订阅、WDA/XCTest、截图逐帧替代、IPA 修改。不准给机械 evaluator 任何 observation 自证 E4 的能力。Implementation AI 若遇不可行项，先写清 partial/blocked 交 Lead，不偷改门槛。
2. 03A：prepared START 根因诊断和最小修复
2.1 先建立可重复只读证据表
依据四份新 Session 以及历史 H1 双源 da60988c、6bc48273 的 immutable Raw、capture plan、wire 和 manifest，比对：
- CP RAW-v2 前缀、有效 first/last 内层解码设备 kernel ticks、真实早期 lifecycle debugID、各阶段 BEGIN/END、原始字段、loss markers 和完整性；
- Start click、source-ready、prelaunch activation、
launch_requested/launch_acknowledged、PID bind、target generation、rebind、source epoch、bridge 交接、Stop 顺序； _PrelaunchCoreBridgebootstrap byte offsets、prelaunch ring overwrite、live queue drop、stream gaps；不能把多个相同的外层 chunk deviceMachTimestamp 当作独立时钟锚点；- H1 与 Fixture A 的相同 prepared 参数、decoder profile/OS profile、目标实际启动时序和 iOS prewarm 差异；
- live decoder 的目标绑定、C0 offline projector 的目标绑定/消费顺序、同份 Raw 的
s0Ticks/s1Ticks、round、totalQuality差异。
精确代码入口：MacApp/Sidecar/perfowl_collector_core/realtime.py 约 471–642 (_PrelaunchCoreBridge)，3126–3212 (prepared prepare→start→wait_ready→activate)，3676–3759 (早期 drain_prelaunch_core_until_identity)，3765–3855 (非挂起 launch、bind_target、launch envelope)，3914–3944 (bridge→常规 consumer 交接)；startup_bootstrap.py；startup_c0_feasibility.py 1090–1385；现有 RealtimeLaunchTraceDecoder/Profile。
2.2 五种不能混写的根因分类
| 类别 | 成立的证据 | 允许修复 |
|---|---|---|
| 03A-1 源层早期 BEGIN 未出现 | RAW 中真实缺失，且 source-ready/launch 前后窗口或 lost marker 支持 | 保留 not-observed；若实证是 prewarm 时序 bug 才最小调整，不伪造 S0 |
| 03A-2 RAW 到达但 bridge/ring/queue 丢失 | source offsets/overwrite/drop 与缺段一致 | 修有界交接，不扩大到无界缓存 |
| 03A-3 RAW 完整、live decoder 绑定或 profile 错误 | 原始事件+PID/gen/profile 确能恢复 span | 修绑定时序/重排/有证据 profile，不增加猜测 debugID |
| 03A-4 live 有、offline 重放缺失 | 同一不可变 Raw，live 和 offline 因 bind 顺序/元数据差异产生不同结果 | 只修 C0 projector，保证旧 Session 缺证 fail-closed |
| 03A-5 H1 与 Fixture 启动轨迹真实不同 | kernel 样本能证实目标/OS/启动状态差异 | 标兼容性边界并保留 partial/missing |
R4 prepared Fixture A 的 live 13 span 是强制不回归基准；H1 1/0 span 的改善只能来自修复后真实样本，不能设定无依据的百分百恢复目标。
2.3 Offline replay 的具体可审计契约
现有 collect_c0_observations_from_session() 新建未显式 target bind 的 decoder，将原始 CP chunks 全部 consume 后读 report；但 live 在 launch ack 后 bind_target(launched_pid, generation=1)。这是待 E2 确认的结构性疑点。修复必须按真实 raw sequence 和事件时间重建：
- bootstrap/header 与 prelaunch chunks，保留必要 RAW-v2 offset/state；
- 遇真实
launch.requested.raw用其 PID、generation、source/reconnect epoch 绑定 decoder；如 payload 无 PID，不得把 manifest 自述当强证明，须根据独立target_identity事件/manifest 可验证来源审计； - 继续按传输顺序消费 CP chunk，同时尊重 chunk 内核事件时间、既有 reorder/profile watermark；不能假定一个 chunk 内全部发生在 bind 之后；
- 输出 quality、S0/S1 ticks、candidate phase list、缺失根因及
projectionDisagreement；旧历史缺字段需兼容并 fail-closed； - 原始 Session 绝对只读；
launch-trace-report.json是 comparator，不可直接复制它的数值到新的 observation 来冒充原始证明。
03A E2 必测：同 Raw 的 live/offline 对照、跨 chunk 半事件、缺 PID/错 PID/晚绑、相同 PID 不同 targetGeneration、prelaunch gap、queue drop、sourceEpoch/reconnect、Stop 交接、不同合法 profile，以及旧 C0-FIX-02B 六种伪造 claim 6/6 只为 E2。若源未采到早期事件，则 live/offline 同样 missing 合格，但START Gate 仍未通过。
3. 03B：Clock proof feasibility，不能用假设替代真值
3.1 独立来源字段普查
仅通过现有 CoreProfile RAW、ActivityTrace FrameLifetime、合法 DeviceInfo/DTX 及已固定的 pmd3 协议字段列清：
rawField、clockName、timeUnit、sourceProvenance、deviceOS、sourceEpoch、reconnectGeneration、observedTs、是否设备原生上报、与 START/END ticks 关系。
优先调查 ActivityTrace 是否真实返回和 end_time 同域的 device mach timebase/clock-id。如果 125/3 只是 decoder 注入常量，不许标记 device-reported；复制 CP 的 timebase 到 ActivityTrace 也不能自动证明它们同 epoch。
寻找同一个原生事件在两条既有 raw 流里可独立匹配、含 device ticks 的可能性；若只出现“两个事件时间很近、同 surface 或 frameSeed 类似”，不得填 pairedWitnesses。任何诊断性非 FrameLifetime identity 只能在现有隐私、源权限内做短窗口字段普查，不能放宽正式 END 白名单。
若真实 same-event witness 不可得，可研究替代的共享设备时钟身份证明（具有可信系统协议/API 文档、独立 E4 反例和误差界），形成 Clock Proof Amendment 提交 Lead。Implementation AI 本批仅提交备选设计和诊断，不得自行把正式 Gate 从 same-event 改为“时基相同+时间差合理”。
3.2 建议有界诊断和计算门禁
独立诊断保存 clockProofCandidate.method = same-event/device-clock-identity/none、raw reference/clock provenance、unique inner CP ticks、ActivityTrace ticks、device 内层有效窗口、host receipt 窗口、witness 原始键、source/reconnect generation、clock reset/rate drift，失败原因明确为 unproven。C0 原 pairedWitnesses 在没有同事件时继续为空。
若出现真正可审计 same-event proof，按现有 evaluator 反例和正式计划核验：至少 3 个相互独立的真实同事件样本，逐组时间残差不超过现行 2ms 默认阈值；每侧真实有效设备时钟窗口 ≥30s，时钟锚点必须是不同内层事件、至少 8 个；rate 相对误差不超现行 0.1% 默认门槛；reconnect generation 1 重新校准。采集 wall time 30s / 相同外层 chunk tick / 单端 30s 不满足。
测试必须拒绝：相同 125/3 但 epoch 偏移；host arrival 拟合伪证；不同事件近邻伪证；复制 raw 伪造 captureId；重复 chunk 外层时间戳；Generation 0 证明复用到 Generation 1；缺失/rate outlier/时钟复位。无法达到真机 Gate 时只交 unproven 与独立改案，不产生 Hybrid 数值。
4. 03C：独立前台证据和 END attribution（只加有界证人）
现有 composition.py:TargetIdentityResolver.resolve() 通过 ProcessControl Bundle→PID、DeviceInfo proclist 和必要时 execname_for_pid 交叉确认身份，读取进程 foregroundRunning is True。它独立于 FrameLifetime 候选，可做前台瞬时观察，但不自动证明过去某帧呈现时目标前台。
允许复用单一 owner、现有 target_identity/attached 信息，按状态变化或启动 ack/首次 END 候选前后做最多有限次有界异步复查。诊断 foreground-evidence.raw 仅留 source、target PID/gen、host 观测起止、foreground true/false/unknown、bundle→PID 二次核实、source epoch、reconnect generation、失效原因。超时、PID 被重用、foreground 变更或证据不完整即 unknown，不得推导更早时刻的前台。
只有在有可验证的设备↔host 时间关系或完整顺序证据，且前台证据确实覆盖指定 END 呈现时刻、没有中间切 App/overlay/rebind/reconnect 时，才能将 round 级 foregroundVerified 从 false 变 true。没有这种时域证据时新增快照只作 diagnostics，现有 End Gate 保持 target-foreground-unverified，即使 frame.foreground=true 也不能给自己作证。
surfaceID→PID 必须由真实系统映射事件、时域/target-generation 绑定和负样本反证证明；displayID 相同、surfaceID 稳定、frameSeed 连续、最接近启动时间的第一帧 不是映射。无映射时 real 不可达；candidate 仅在独立前台、单一可归因 surface、全部 generation/epoch/quality/clock 门禁确实通过时可能存在；多个无法消歧 surface => ambiguous-first-presented-surface。
E2 负控：系统 UI、其他 App 抢前台、notification/keyboard/overlay、多 surface、A→B rebind、reconnect、PID 复用、旧 frame 回流、source gap/out-of-order、foreground snapshots 缺失、假 frame foreground=true；必须 0 错归因。未执行人工 E4 negative controls 时 falseAttributionCount=0 必须与 labelledNegativeControlCount=0 / not-measured 并列，不得标为通过。
5. 限定文件、效率和公式治理
| 位置 | 最多允许的变更 |
|---|---|
MacApp/Sidecar/perfowl_collector_core/realtime.py | 有证据的 03A 原生 bind/bridge bug；03B/03C 有界诊断。不得实现 C1 |
startup_bootstrap.py | 只有发现真实 prefix/offset bug 才改 |
startup_c0_feasibility.py | 原始顺序 replay、诊断扩展；必须机械 E2，保留 C0-FIX-02B 全套反例 |
display_performance.py | 仅识别真实设备时钟 provenance；不放宽 FrameLifetime whitelist、不改 FPS/FrameTime |
composition.py | 优先复用已存在的 DTX target resolver；只在必要时扩展独立前台来源字段 |
MacApp/Sidecar/tests/ | raw 反例、回归、性能、有界与脱敏单测 |
site/devlog/、internal/current-ai-handoff.md | 本文尾部添加实施/偏差/验收/遗留记录；实现结束按 AGENTS 更新 index/必要知识页 |
生产热路径复杂度每事件 O(1)，END 候选 ≤64，诊断只写事件驱动有界摘要，不复制整份 FrameLifetime raw；前台观察不能在每帧启动新 Task/Process，也不能增加 Start 同步等待。沿用 Phase C `10 硬预算：新增 kperf owner 0、重复 ActivityTrace subscription 0、Start 同步额外 p95 ≤5ms、evaluator p95 ≤1ms、≥240 events/s、新增 RSS ≤2MiB、ActivityTrace 额外持续带宽不得超过 0.10MiB/s；任何需 Startup-only Frame observer 的超时仍 ≤10s，但不在 C0 开启正式 observer。测试必须给变更前后 CPU/RSS/峰值 I/O、延迟/吞吐、队列高水、长任务/最坏 Stop 与磁盘增量数据。出现明显 FrameTime/FPS 或 Phase B prewarm 回退即停止。
公式不变：仅当 START/END 已证明同一设备时钟且来源、generation、epoch、END 归因均合格： deltaTicks = endMachTicks - startMachTicks； deltaNs = floor(deltaTicks * timebaseNumer / timebaseDenom)； hybridTotalMs = deltaNs / 1_000_000。 本批仍禁止发出任何 Hybrid 值；S0/S1/S2/S3 优先级及 real/candidate/repaired/missing 语义全部沿用 canonical Phase C 第 5～8 节；如证据证明需要改指标公式，先提交文档 Amendment、等待 Lead/Owner 明确同意，不能在本批顺手改计算。
6. 实施分批、E2 验收与 E4 前置门禁
严格按 03A→03B→03C、每包独立可回滚提交；每包完成后先同本文尾部追加带日期的 Implementation Update（原因、实际改动、偏差、测试结果）。如 03A 发现真实早期 BEGIN 从未出现，提交根因与 partial 分类后停止并交 Lead，不允许加“可靠推断 S0”算法绕行。03B 同事件 witness 不可得同理：保留证据并暂停 Gate 语义变更，交 Lead 决定是否启动 Clock Proof Amendment。
最小 E2：
- 历史 C0 focused 111/111 无回退；原来 6/6 伪造
captureId在所有origin下仍是 E2/0 E4。 - 固定 R1/R2/R4/R5 脱敏 replay 与历史 H1 对照；不得直接提交含真实身份的旧 Raw。测试覆盖 bridge/offset/drop、PID bind、source epoch/reconnect、Stop 竞态、partial profile、live/offline 一致或有证据不可复原的
missing。 - Clock 所有错误 epoch/伪同事件/常量 provenance/reconnect 反例均 fail-closed。foreground false/missing + frame 声称 true 仍
selectedEnd=null，无 surface mapping 时real=0。 - Sidecar 最新 full regression、受影响 Swift tests、性能前后配对基线、知识库契约、
git diff --check、npm run build；如遇历史已知 flood fairness flake（上次同口径 964/1），需两树同条件对照，不能称本批 0 failures，也不可未调查直接忽略。 - 若修改产品代码，遵守 AGENTS Developer ID 签名/公证/stapling、校验、可安装产物路径；受本机证书、法务或网络阻断需诚实
partial/blocked。
E4 只在 Lead 审完 E2 后由 Test AI 执行：先实际 Mac GUI 1 轮确认 wire-equivalent 的端到端一致；然后 Device A H1 prepared 3 轮、Fixture A prepared 3 轮，全部 Startup + FrameTime、full，逐轮复验 START/FrameLifetime、前台快照和源时间线。只有稳定获得符合证明条件的双端时，再做原正式 C0-1 双源各自有效内部时钟窗口 ≥30s及 Gen 1 reconnect 重新证明；正式 C0-2 Fixture A 与 App A/B/C 各≥10 次合法冷启+≥10 有人工标注负对照，C0-3 S0–S3 census 不减数量、不伪造 S2。若必要 instrument 在新包仍缺失，停止扩大矩阵。每轮 Raw/manifest/人工 labels/SHA 原样保留。
7. 停止/回滚、交付与 Lead 决策权
立刻停止：必须增加第二 kperf owner/ActivityTrace stream 才有数据；只能从 host request 拼 START；同钟 proof 仅依赖常量或非同事件；前台只靠 FrameLifetime 自证；任何产品变更污染原有 legacy Total/FrameTime；假 PID、跨 generation、false attribution >0；性能门槛失败；需要触碰 WDA/IPA 重签/目标注入；需要修改历史 Raw 才能“重放出”缺失数据。
回滚只关闭本批新 C0 诊断或被证明回归的最小修复，保持 Phase A/B dedicated source/prewarm/原主值。Lead 按 原始证据 → source diff → focused → full/benchmark → 可安装包 → Test AI E4 → 独立 C0-1/2/3 Gate 顺序验收。C0-FIX-03 开发完成 绝不自动 C0 PASS，C1/C2 不解锁。
Implementation AI 在本文末尾写 Implementation Update · 日期，逐包陈列 exact commit/文件 diff/独立 E2/未达问题；报告 H1 与 Fixture 原因链、live/offline 结果、clock witness 原始来源与替代 Amendment、前台时域是否真正可靠、surface mapping 是否成立、前后性能、完整测试、产物 SHA/签名公证状态、独立 E4 测试说明。仅窄范围提交，按 AGENTS 双远程 push 与 webhook；绝不 git add -A 混入既有脏工作区，敏感真实 Bundle ID/UDID/证书信息只留本机。结尾：Implementation complete/partial; C0 Gate requires Lead AI independent E4 verdict.
Implementation Update · 2026-09-23 (Implementation AI · C0-FIX-03)
基线 a3b25e77bf725580c2b4f23b804189551c49ec7c（含已验收 C0-FIX-02B），共享脏工作区中 MacApp/ 开批前无他方改动。三个工作包严格按 03A→03B→03C 执行，每包只动必要文件。本批未发出任何 Hybrid 值，未修改任何 Gate 判定，未触及 C1/C2。
03A · prepared START 丢失根因与最小修复
结论先行：H1 与 Fixture A 的差异是两件事叠加，其中只有一件是本批可修的缺陷。
（1）可修缺陷 —— 离线投影从未绑定 target（已修）。collect_c0_observations_from_session() 构造 RealtimeLaunchTraceDecoder(emit_completed_trace=False) 后从未调用 bind_target()。而 _process_lifecycle() 在 _target_pid is None 时对每条记录 early-return，于是 launchStartTimestampNs 恒为 None，End Gate 对每一帧判 start-timestamp-missing，最终 selectedEnd=null / endQuality=missing。
同一份不可变 Raw 上的对照实验（artifacts/c0-fix03-20260923/03a-experiments.json）：
| 轮次 | bind=None spans | bind=PID spans | bind=None total | bind=PID total |
|---|---|---|---|---|
| R1 H1 prepared | 0 | 1 | None | None |
| R2 H1 prepared | 0 | 0 | None | None |
| R4 Fixture A prepared | 0 | 13 | None | 295.623541 |
| R5 Fixture A headless | 0 | 13 | None | 200.786083 |
修复方式：用真实 launch.requested.raw 信封上的 target_pid/target_generation 绑定（即 live 路径 bind_target(launched_pid, generation=1) 所依据的同一事实）。绑定来源可审计且不含原始 PID（隐私红线）：targetBinding.bindingSource / bindingPidSourceField / bindingCandidateCount / bindingPidConflictCount / bindingWitnessed / targetRecordCount。不读回 launch-trace-report.json——那是派生的对照物，读回等于让投影与它本应独立复现的报告互相印证。payload 无 PID 时 fail-closed，记 target-binding-unavailable-in-recorded-session，绝不把 manifest 的 identityStatus 自述升格为 PID。
（2）不可修部分 —— H1 的 on-target 相位集合本身残缺（属 03A-1，如实保留 partial）。 绑定之后 R1/R2 恢复了真实 launchStartTimestampNs，Start Gate 转 pass，但 totalMs 仍为 None。原因是目标线程上根本不存在后续相位（artifacts/c0-fix03-20260923/03a-on-target-actions.json）：
| 轮次 | on-target actions | 终态 0x31CA0006 |
|---|---|---|
| R1 H1 | begin:SI×2, end:SI×1, begin:SRI×1（仅 3 类） | 0 |
| R2 H1 | begin:SI×2（仅 1 类） | 0 |
| R4 Fixture A | 8 相位 begin+end 共 16 类，13 span | 14 |
两轮 H1 的 manifest 均为 startupCoreProfileCompletionWaitStatus=timed-out 且 openPhases 非空，两轮 Fixture A 均为 completed 且 []——是采集窗口的真实差异，不是解码器产物。且 prelaunchRingOverwriteCount=0、liveQueueDropCount=0，故不是 03A-2 的 ring/queue 丢帧。
排除的两个假设（都经实测证伪，未写入任何交付物）：
kd_buf：逐字符KD_DEBUG_ID_OFFSET差一个字段struct.calcsize('<'+f)证明L为 4 字节、values[7]正落在字节 48，KD_DEBUG_ID_OFFSET = 48正确。_pair_markers命中终态后break截断后续记录
确定性反例（6 项新增，tests/test_startup_c0_feasibility.py::C0ProjectionTargetBindingTests）：绑定可审计；无 PID 时 fail-closed；绑定不冒充完整性；绑定来源永不提升 E2；有绑定但目标无相位时如实无 start；未完成快照不得冒充冻结报告。
03B · 跨源时钟证明与同事件 witness 可行性（不改 Gate）
- END 侧
125/3是解码器常量，不是设备读数。 FrameLifetime payload 的machTimebaseNumer/Denom就是FrameLifetimeDecoder._numer/_denom（发射点即"machTimebaseNumer": self._numer），构造默认125/3，而生产路径上set_timebase()调用数为 0。改set_timebase(1,7)会直接改变落盘值而设备毫无参与 → 自证常量。故维持assumed-constant，不标device-reported。对照：CoreProfile 的timeConfig125/3来自启动 wire 协议，是真设备报送。 - 同事件 witness 不可得（capability gap，非 failure）。 两族 anchor 都只带
(reconnectGeneration, source, hostMonotonicNs, deviceTicks)，且都打在到达时刻，各自带 transport delay；合并成单一有序列表会系统性制造假clock-reset-detected。产品未记录任何"双流可见的内层事件"。pairedWitnesses恒空 →cross-source-epoch-unproven不可清除。 - 30s 窗口不是阻塞点。 R1 = 37.72s、R4 = 36.45s，
sourceEpochCount=1，均满足 ≥30s；clock-anchors-insufficient/clock-window-below-30s属可配置项，与 epoch 缺口性质不同。 - 产物
artifacts/c0-fix03-20260923/03b-clock-census.json。按方案 §6 保留unproven，未自行修改 Clock Gate；是否需要 Clock Proof Amendment 交 Lead 决定。
03C · 独立 foreground / END 归因证据（不改 Gate）
- Session 确实携带独立前台证人：
lifecycle.observed.raw带foreground: true、自有observedPID/observedGeneration、identity_status=verified与host_receive_monotonic_ns，来自 sysmontap 进程观察源，与 FrameLifetime 是不同源，因此不是待选帧自我加冕。其 PID/generation 与launch.requested.raw一致（R1/R4 均为 true）。 - 但仍不足以提升
foregroundVerified，缺三项：① 该证人只有 host 时间、无 device Mach ticks，无法在不依赖 Clock Gate 已拒绝的同源证明下与 CoreProfile/FrameLifetime 设备钟定序；② Session 未记录任何surfaceID → PID映射事件（推断即循环证明）；③ 候选帧与证人时刻的完整排序未建立。 - 另观察：两轮均出现多个 surfaceID（R1
[60, 691]、R4[441, 691]），正是方案 §4 的ambiguous-first-presented-surface场景，进一步支持 fail-closed。 - 故 End Gate 保持
target-foreground-unverified，selectedEnd=null；falseAttributionCount=0与labelledNegativeControlCount=0 / not-measured并列报告，不把"未测"写成"零误判"。产物artifacts/c0-fix03-20260923/03c-foreground-census.json。
测试与性能（E2）
- C0 focused：
test_startup_c0_feasibility120/120 +test_perfowl_launch_traceOK（合 165 项，含 6+3 新增反例）。历史 C0 focused 与 6/6 伪造captureId契约测试全绿。 - Sidecar full regression：970 tests，3 failures，全部落在已知计时 flake 家族。已按门禁纪律做 base×ship 交错配对各 4 轮（
artifacts/c0-fix03-20260923/03a-flake-attribution.json）：失败集合在两棵树上都逐轮漂移（base：∅→{flood,shipping}→{flood,shipping}→{flood}；ship：{flood,shipping}→{flood}→{flood}→{flood}），且 base 同样失败同样测试。test_event_loop_heartbeat_monitor_basic在 8 次配对中 0 次复现。结论措辞：可归因回归 0；3 项仍标记 host-load 待空闲复核，不写"0 失败"。 - 性能前后对照（同一 benchmark，
artifacts/c0-fix03-20260923/03a-bench-ship.json）：collectMsPerFrameP95 = 0.339ms（预算 1.0）、throughput median 4280 ev/s（预算 ≥240）、rssDeltaMiB在预算内（C0 自有增量 0.41 MiB，属阶段归因后的本批增量），三项 budget 全 true。 - 零生产热路径开销：
realtime.py本批字节未变（git diff为空），新增 ActivityTrace 订阅 0、新增 kperf owner 0、新增 CoreProfile 录制 0。C0 仍是纯离线读者。 git diff --check干净；swift build --disable-sandboxBuild complete；受影响 Swift 侧无源码改动。
相对方案的偏差
- 方案 §6 预期"历史 C0 focused 111/111"；实测该文件现为 120 项（本批 +9，且此前批次已增加），合 165 项全绿，无回退。
- 方案 §2.3 说"如 payload 无 PID，不得把 manifest 自述当强证明"。实测 PID 不在
raw_payload而在RawEventEnvelope.target_pid；两种来源均已支持并分别命名来源字段，manifest 自述仍不升格。 - 方案 §6 的三项 flake 复核未在空闲主机上完成 → 结论保持"待独立复核"，未宣称干净。
- 03A 未按"发现真实早期 BEGIN 从未出现即停止"中止，原因是该缺陷（投影未绑定）先被证实且可修；修完后 H1 仍为
partial，已如实提交根因与分类，未添加任何"可靠推断 S0"的绕行算法。
未解决 / 交 Lead 决策
- C0 Gate 仍 PARTIAL/BLOCKED；
cross-source-epoch-unproven与clock-timebase-provenance-unverified（END 侧常量）为真实 capability gap，前者需 Clock Proof Amendment，后者需真实设备报送 END 时基的仪器。 - H1 prepared 的 on-target 相位残缺属采集窗口侧（
timed-out+ 非空openPhases），需 Test AI 在真机侧判定是目标应用行为还是采集覆盖，Implementation AI 不自行判定。 surfaceID → PID无映射事件，ENDreal本批仍不可达（最强candidate）。- 三项计时 flake 待空闲主机复核。
- 本批已按 AGENTS 窄范围提交与双远程推送；站点构建与可安装包/签名公证状态见提交记录与交付说明。
Implementation partial; C0 Gate requires Lead AI independent E4 verdict.
Lead Code Audit · 2026-09-23 (Lead AI · C0-FIX-03)
审计对象：78a59be97f955c12ce3766256d803f61d3e54aeb（基线 a3b25e77）。审计方式：只读，未修改任何代码、Gate 阈值或 evaluator 规则；未宣布 C0 PASS；未进入 C1/C2。产物 artifacts/c0-fix03-20260923/lead-audit-c0-fix03.json。
R1 · launch_trace.py 的 target binding（PASS）
target_identity_audit()是解码器状态的纯读取（_thread_pids/_target_record_count），无副作用、不赋予任何 evidence level。bind_target()在真实绑定与幂等早返回两条路径上都写入binding_source，标签不会丢失。binding_source仅作 provenance：evidence字段全仓库唯一写入点是硬编码常量EVIDENCE_RECORDED == "E2"。EVIDENCE_TRUE_DEVICE == "E4"只出现在其定义（"never emitted"）与evidenceTrueDeviceAssignedBy的描述性标签位置。bindingWitnessed源自_target_record_count > 0，而该计数只在_process_lifecycle的归属守卫（_target_pid is None or _thread_pids.get(tid) != _target_pid）通过之后自增；thread→pid 映射只由设备解码记录0x07000004/0x07000008构建。结论：target binding 不升级为 E4 evidence。
R2 · startup_c0_feasibility.py 的 PID 来源（PASS）
- PID 取值优先级：
envelope.target_pid（RawEventEnvelope类型化属性）→raw_payload.targetPID→raw_payload.targetPid；首者即活线路径所依据的同一事实。 - PID 由设备上报，非 host 请求：
realtime.py两条分支的 PID 均来自resolver.request_launch()→ DTXProcessControl.launch()的返回；host 只提供bundle_identifier。host 侧 "launch request" 并不命名 PID。 - manifest 自证不被采用：
TARGET_BINDING_SESSION_MANIFEST已定义但不可达；构造含identityStatus/pid/bundleID的 manifest 风格载荷，探测结果为bindingSource="none"（无绑定）。 - Fail-closed：无 PID →
pid=None、bindingSource="none"+ notetarget-binding-unavailable-in-recorded-session；零/负 PID 被拒。 - 歧义显式化而非被折叠：PID 冲突时
bindingPidConflictCount自增（探测 C4：candidates=2、conflicts=1）。 - 隐私红线保持：
targetPID既不在targetBinding块内，也不在整份 observation 内。
R3 · evidence level 提级（PASS，0 violation）
对绑定面做 8 项对抗性提级探测，全部无法把 evidence 移出 E2（evidenceAssignedBy 恒 offline-evaluator、captureProvenanceClaimPromotesEvidence 恒 false、judgement 恒 pending-lead-ai）：注入 targetBinding.evidenceClaim="E4"、observation.evidence="E4"、captureProvenanceClaim.evidence="E4"、膨胀 bindingWitnessed+targetRecordCount、声明 true-device-capture-claim-unverified、自报 implementationAiDeclaredGate="passed"、声明 dynamicTargetAttributionReady=True、伪造 s0Ticks+startTimestampNs。该不变式是结构性的，不只是被断言的。
R4 · 修复前后 replay（Lead 独立复算，非采信实现方 JSON）
方法：在修复前树（git archive a3b25e77）与出厂树上分别重跑 collect_c0_observations_from_session() + evaluate_c0_feasibility()，输入为四份不可变原始 Session。
| 轮次 | 修复前 start | 修复前 startGate | 修复后 start | 修复后 s0Ticks | 修复后 startGate | selectedEnd | endQuality | evidence |
|---|---|---|---|---|---|---|---|---|
| R1 H1 prepared | null | failed | 593121011525625 | 14234904276615 | passed | null | null | E2 |
| R2 H1 prepared | null | failed | 593231841357458 | null | failed | null | null | E2 |
| R4 Fixture A prepared | null | failed | 593396849270208 | 14241524382485 | passed | null | null | E2 |
| R5 Fixture A headless | null | failed | 593475176243416 | 14243404229842 | passed | null | null | E2 |
关键判读：
- 缺陷被独立复现：修复前四轮全部（含 Fixture A 的 R4/R5）丢失
launchStartTimestampNs⇒ 该缺陷是投影级的，非 H1 特有。 - R2 是诚实的反例：
launchStartTimestampNs已恢复，但s0Ticks/s1Ticks仍为null，startGate正确地维持failed（start-all-sources-missing）。绑定没有制造一个 start。 - 两树 evidence 均为
E2：修复改变的是投影能看见什么，而非它可主张什么。 selectedEnd与endQuality在每一轮都保持null/missing⇒ End Gate 未被触动。- 03B/03C 未引入任何 Gate 变更（diff 中无 Gate 常量被增/删/改）。
独立旁证：03a-on-target-actions.json 显示 R1 targetRecordCount=11337、11 个被见证线程，却只有 3 个生命周期动作类、spanCount=1；R2 为 187 / 1 线程 / spanCount=0；而 R4 有 18 个动作类。且 prelaunchRingOverwriteCount=0、liveQueueDropCount=0、lossFree=true。⇒ H1 目标确实在场，但其线程集本就不产生完整启动相位序列，属 on-target 行为而非取数丢失。
R5 · 回归归因（可归因回归 0）
- C0 focused：
test_startup_c0_feasibility独立复跑 120/120 OK。 - 全量：973 tests / 1 failure ——
test_realtime_consumer_fairness.DisplayPipelineBenchmark.test_benchmark_shipping_policy_steady_120hz_7200_frames（已知计时 flake 家族）。 - 判为不可归因：同一测试在未修改的基线树
a3b25e77上同样失败（隔离 4/4），且在出厂树上失败集漂移（FAILED/OK/FAILED/FAILED）；被审提交仅改launch_trace.py、startup_c0_feasibility.py及其测试，而该 benchmark 只导入contracts/display_performance/pmd3_backend/realtime，与改动零代码路径交集；realtime.py字节未变。
R6 · 范围完整性
MacApp/ 下仅 3 个文件被改；realtime.py 未触及；Gate 阈值与 evaluator 规则未被修改；Gate 常量无增删改。审计全程只读，未产生任何工作区改动。
Lead 裁定
- 代码审计：PASS。
- 03A Gate：PASS —— 可证的投影缺陷已修复并被 Lead 独立复现；残余的 on-target 相位残缺如实保留为
03A-1 partial，未被升格、未被掩盖。 - 允许进入 Test AI 真机 E4：是。 下轮 E4 的任务边界应聚焦：Clock 侧真实跨源同事件 witness 的可获得性、END 侧
surfaceID → PID映射事件与设备报送 END 时基的仪器可得性，以及在真机上判定 H1openPhases/timed-out究竟属目标应用行为还是采集覆盖。 - C0：未 PASS（
cross-source-epoch-unproven与target-foreground-unverified两项真实能力缺口仍在）。C1 未开始，C2 未授权。 未修改任何 Gate。
C0 Gate remains PARTIAL/BLOCKED; Test AI device E4 authorized; Lead AI verdict pending that round.