SW-1 R2 Lead 独立裁定与 R3 只读时序取证方案（2026-09-28）

1. 裁定先行

本页承接 R2 真实 App UI 合同 §3。Lead 对 Test AI 私有批次 sw1-r2-true-ui-20260928-1720 的原始 Session、操作日志、进程来源、封存清单、核心清单、原生报告及离线定位器作了只读独立复核。审计时本地 main 与两个远端均为 21b84da44caee66e3f1e98091a5d8261a0a52593；共享区原有四项他方未提交内容未动。私有证据不上传，公开只称设备 A 与目标 App A。

R2 正式真实 UI E3 的入口与配置取证 = SATISFIED；SW-1 有界延长效果 = inconclusive；启动时间获取稳定性提高 = NOT PROVEN；A1 正式 UI E4 = OPEN；Phase C Hybrid = FROZEN。 这不是 SW-1 产品 PASS，也不是窗口假设的阳性或阴性。OFF→ON 两轮额度已用，不追加同构会话。

两轮确实经 App 的 perfowl.capture.toggle 各触发一次 Start/Stop；每轮核心均由对应 App 进程派生、路径位于同一个已公证的实验包，产物落在本批 Session 库。OFF 无实验变量，ON 变量为 1，核心清单分别读回 Enabled=false/true。两轮冻结启动指标 12 项、plan/hash、四类过滤与核心配置相同，来源 start/stop/restart 均为 1/1/0。独立重算批次清单 282 项、两轮各 35 项封存清单，SHA-256 与字节数均零差异；原始 Session 与隔离副本各 35 个文件逐字节一致。Test AI 的 105/105 是执行方断言计数；Lead 复核的是上述关键门和原始字段，不将其写成自己逐项重跑 105 项。

准备阶段曾在目标应用未选中、按钮禁用时发生一次失败的 AX 操作，没有产生 Session。Owner 当次裁定该准备事件不占 R2 轮次；正式 OFF/ON 两轮均在 Ready 且按钮启用后完成。该准备事件保留为驱动守卫反例，不抹去，也不计成第三轮有效样本。

ON 的 ExtensionStartedMonotonicNs、deadline、结束时间及耗时均为空值；因此新增等待没有发生。按 R2-2，不能据两轮端点或报告差异推断效果，更不能宣称稳定性提高。两轮原生报告均为 partial、requiredMissingPhases=["Initial Frame Rendering"]。离线 OFF 等价回放的主字段差异为空，但它不是 App 原生报告，也不证明另一轮的窗口效果。

1.1 两处证据解释修正

1. startupSceneWindowExperimentOpenPhasesAtDecision=[] 在现有实现中仅在延长成功应用时赋值；ON 未应用时的空数组，不证明检查点“所有阶段都关闭”。ON 失败原因与 startup_completion_wait.openPhases=["sceneWillEnterForeground()"] 只能证明本次检查点未见必需的 UIKit Scene Creation。不能进一步断言该阶段从未出现、何时关闭，或来源必然丢失。
2. 离线定位器两轮均给 ABSENT，同时各有目标 opener 1 / closer 3。源码的保守判决因全流存在未知线程端点（OFF 4、ON 3）压住 PASS，随后落入 ABSENT/no-target-endpoint 回退标签。此标签不等于“原始字节里零端点”，而端点计数也不等于同身份、同代际、合法有序闭合链；原生报告继续 missing。R3 必须核对每个候选的顺序和归属，不把回退标签当事实解释。

1.2 同域时序的上界，而非单事件时刻

Lead 从两轮 raw/collector-000001.jsonl 的 startup_completion_wait.monotonicNs 与 collector-core/raw-events.jsonl 的 CoreProfile chunk hostReceiveMonotonicNs 独立相减；源码中两类读数均取自主机 time.monotonic_ns()。含目标 opener 的 post-stop-drain chunk 分别在 OFF 检查点后约 1788.330 ms、ON 检查点后约 3718.953 ms 被主机收到；两轮另有较早 active chunk 的 closer。这里比较的是容纳端点的整块收到时间，不是单条 kdebug 事件独立收到时间，也不是设备 tick 与主机时钟相减。两轮都没有实验延长；这些差值不建立“延长保留端点”的因果关系。端点的实际主机接收边界、合法配对、检查点前阶段演化仍待 R3 逐项确认。

2. R3 唯一下一动作：先只读查清时序与归属

执行角色：Test AI 负责有界只读取证，Lead 独立解释与下一 Gate；Implementation AI 暂不改产品。 复用这两份已封存 Session 和既有定位器，不新采会话、不重新构建/公证、不新增 worktree/venv、不改默认开关、drain、过滤、Total、质量或源重启。直接保全 Test AI 批次的 SHA 清单；R3 的派生结果另置同一私有批次下的独立子目录，不写回原 Session/封存文件。

1. 时间轴：逐轮列出 App UI Start/Stop、launch requested、4 s 等待检查点、source stop/drain、各 CoreProfile chunk 的主机接收时间与 active/post-stop-drain 标签。所有跨事件减法先核对单调时钟同域；设备 tick 另列，禁止混减。记录检查点前后是否有可用的阶段快照；若只有检查点最终快照，早期阶段打开/关闭时刻标 unknown。
2. 端点归属：对定位器报告的每个目标 opener/closer 列出 chunk 序号、块内偏移、设备 tick、线程绑定证据、来源代际和事件顺序；未知绑定端点单列，不借最终映射或另一进程拼链。对同一 chunk 的多端点也按真实字节顺序检查，不能以 chunk 共存替代合法配对。
3. 原生与离线差分：逐字段对照 App 原生 IFR 阶段缺失原因与离线定位器的端点列表，确定是阶段边界、顺序、身份、窗口还是字段语义导致分歧；结论必须指出哪条原始字节和哪个原生字段支撑。若现有格式没有单事件主机接收时刻或检查点原始 snapshot，明确列为不可识别项，不反推值。
4. 停止门：一旦发现哈希漂移、来源/代际混用、时钟域不明，立即标 partial 并停止因果推断；不通过补刷、加长时间或加压填洞。R3 只决定下一取证分支，不裁产品 PASS。

2.1 资源与验收边界

R3 对每份外置 blob 与 Raw 分析一遍、分析前后哈希各一遍，均为顺序读取，复杂度 O(总字节)，两份 blob 合计约 349 MiB（366 MB），不复制整棵 Session，不并行争用设备；流式读取内存目标 ≤ 64 MiB、单份分析上限 120 s，超限停下并交出已完成的部分证据。用已有封存清单重算 SHA/size，报告分析前后不变；不得把旧封存时刻前的不可变性向前外推。交付包括别名化时序表、逐端点证据、原生/离线差分、明确的 unknown、耗时/RSS/I/O 实测与 SHA 复核，交 Lead 独立裁定。

R3 后的条件分叉：若现有字节能判清阶段检查点与端点失配，Lead 再决定源/线程/代际的最小修复方向；若关键边界缺测，Lead 先另行定稿仅记录“决策点阶段快照、同域截止与拒绝条件”的默认关闭、低成本遥测合同，经 E2、签名公证后才考虑另一批有预算的真机验证。本页不授权产品遥测实现或新 UI 轮次。Network、FrameTime、首页与 Hybrid 均不并批。