Build74 Phase 2 A1 · 新包真机证据 Lead 审计与 UI 定向验证方案

角色与判定（2026-09-25）：Lead AI；本轮只读核证及方案入档，未改产品代码。 Implementation 的 42695fcefd9488b218b47c737d7662b97666b532 为 f3c9b73d20c39e70aa39243be0ba9a4ee2a19688 上的 3 文件纯文档提交。A1 E2 PASS 保持；新包签名/公证/独立解包子门 E3 通过；16 轮是真设备、真捆绑核心的命令入口诊断证据，不是 Canonical §5 指定的冻结 App UI 入口，故 A1 正式 E4 NOT PASS / OPEN。不能把包装成功、旧 r3 或命令入口回放写成 UI E4。

唯一技术实施依据仍是 Phase 2 Canonical 方案 §5；本页是 Lead 对其 E4 证据门的追加决定。旧报告及数字不回改，错误口径只在本页更正。

1. 已独立核实的事实

原始 Session、私有归档及旧 MacApp/Tests/1.trace/ 全部只读保全；公开文档只用 Device A / App A / Fixture A 别名。

2. 阻断正式 E4 的独立发现

F-1 · allConfigsMatchFrozenUi 只比较 Start 后的 15 字段，不能证明 UI 入口等价

Swift UI 的 PerformanceSessionController.trySendPrewarmApp() 调用 CollectorSupervisor.prepareApp() 未传 metricIDs 与 screenshotsEnabled，故 prepare_app 用其默认完整 Registry 指标集与默认截图标志；UI 还须收到 app_ready 并通过 collectorReadyForStart 才允许 Start。私有驱动的 prepare_app 则显式传12 条 startup 指标、screenshotsEnabled=false、冻结 Start hash，且在 prepare_app_accepted 时立即发送 Start；它没有复现 UI 的 app_ready 门及用户点击前的预热等待。两者的最终 kdf2/csd/bm 等 15 字段一致，不代表预热来源、负载、时序与 Stop 交付窗口一致。此差异具有因果可能性，但不能据此宣称已找到主机滞后的根因。按 Canonical §5 原文，本批 16 轮只作真机命令入口诊断，不计入冻结 UI 正/负向准入样本。

F-2 · totalNeverPublished=true 是失效的机械断言

私有汇总器把 totalNeverPublished 定义成「Total 为空 或 诊断链未闭合 或 TotalQuality=candidate」。本批诊断链 0/16 闭合，故该布尔值不论 Total 是否有数都恒 true。Lead 直接读取 16 份 final：12 份 candidate 有数、2 份 repaired 有数、2 份 missing 为空；不是「Total 从未发布」。16/16 live 与 final 的上述 Total 字段相同，支持更窄的「没有被 A1 诊断升级」事实。candidate/repaired 的跨场准确度本批未校准，不能用 14 个有数会话推断启动成功率或端点语义。

返工证据表时删除失效布尔名，分别输出 nativeTotalQualityCounts={candidate:12,repaired:2,missing:2}、liveFinalTotalFieldsEqualCount=16、diagnosticClosedCount=0，并提供逐轮的 live/final 来源与质量字段；所有数字从原报告只读复算，绝不写回 Session。

F-3 · Raw 窗口事实成立，「主机滞后是根因」和「grace 截止」未被证明

launch_trace.py 的诊断只扫描 frame-continuation|post-stop-drain 块，故本批 12 份 active opener 对 A1 drain 诊断必然不可见；4 份无 opener 也不能闭合。这只是必要输入条件，不是「opener 晚到便足以闭合」：仍须目标 PID/代际、同线程、设备 tick 顺序、scene anchor、无竞争 transition 等门。实施文本「闭合充要条件 = opener 主机到达晚于 cut」应作废。

私有 probe_opener_deadline.py 以 firstDrainChunkHostNs − waitElapsedSeconds 反推 completion-wait 起点，但源码在 wait 结束与首个 drain 块到达之间还执行标记切换、report/emit、request_stop_for_drain() 与传输等待；该差值不能标为实际 wait 起点。timeout 轮 waitElapsed≈4s 时，脚本所谓 grace deadline 在代数上几乎就是首个 drain 块的 hostReceive 时刻；r3 的 +1915.8ms 是 opener 块相对首 drain 块的量，不是精确 grace 截止证明。12 份新轮的设备侧事件相对时距接近 r3，支持「设备行为可能相似」，但没有排除 UI/CLI 预热差异、主机调度或传输变化；writerQueueWaitMaxMs 单值不能独立证明源头滞后原因。时钟/流程因果归属 = UNKNOWN。 不修改角色、窗口、时限或采集配置来制造晚到。

F-4 · 两项工程问题独立排队

MacApp/scripts/build-app.sh 的嵌套二进制 --timestamp=none 经 Apple 首次公证 322 条 secure-timestamp 错误否证；本轮逐件补 TSA 后 Accepted，说明当前包已有效，但下一次从脚本直接构建仍会失败。另 site/scripts/render-archive.py 对代码跨度内的字面 ** 继续套加粗正则，已在新归档 HTML 留下不匹配 <code>/<strong>；HTTP 200、站点 build 成功不等于归档内容正确。两项另开工程小批，不混入 UI E4 指标语义或篡改既有归档。

3. 下一批唯一可执行方案：A1-E4-UI（无产品代码改动）

1. Gate 0 · 固定包与入口：仅使用已核实 SHA 的 Build 83 公证 ZIP，在独立目录解包并启动真正的 Perfowl SwiftUI App，不是直接启动 perfowl_collector_core stream。记录 App 可执行文件路径、Bundle 版本、内置 core 哈希与实际 child process 路径；录屏或可审计 UI/辅助功能日志证明 Device A、目标 App A/Fixture A 选择、App Ready 与 Start/Stop 操作时刻。私有证据可含原始标识，公开材料只写别名。若不能证明真实 UI 入口，停止并交阻塞，不再称「GUI 等价」。
2. Gate 1 · 逐轮冻结条件：核对目标设备/系统、12 项 Start CapturePlan、capturePlanHash、exact-debug-id、kdf2 四类、csd=0、bm=0、rp/tk/ta；并单列预热阶段实际 prepare_app 指标集/截图标志、app_ready、Start 相对 ready 的时序，以及来源路由。不能只用 15 字段等同前后两段协议；任一关键配置不匹配即标 INVALID，不进入正负向统计。
3. Gate 2 · 定向而非刷概率：先 App A 两轮、Fixture A 一轮，按 UI 正常操作，不调负载、录制时长门槛、Stop drain、过滤器或角色标记来追求 r3。每轮按原始字节分类：drain 完整链 / 只有 opener / 只有 closer / 全无 / 身份缺失或冲突 / 容量与 timeout；既要保留真实负向，也不预设三条事件。若三轮无可判定正向链，立即停止同构重复，交 Lead 决定是否进入单独的采集来源/时序研究；不擅自扩样到十几轮。
4. Gate 3 · 原始产物与报告：原始 App Session 只读封存并重算 Raw、blob、manifest 哈希；记录 UI live 报告与 Stop 后产物。需要最终 Raw 重扫时，仅在真实字节隔离副本上运行现有 finalize，标记为「新包核心对 E4 Raw 的离线 final」，不得写回 App 原 Session、不得把 CLI final 冒充 UI 自动产物。逐字段比较 Total/质量/来源/phase、诊断、live/final 差异；输出实际 candidate/repaired/missing 分布，不再使用 totalNeverPublished。
5. 正式 E4 门：至少一个新包真实 UI会话在最终 Raw 中有身份可信、同线程、设备 tick 有序、阶段链闭合的 drain 正向诊断；另有真实负向形态；配置、哈希与 live/final 主字段证据齐备，Lead 才考虑 E4 PASS。即便通过，D1 仍不授权发布 drain Total；主报告字段不得被诊断提升。若没有正向，维持 E4 OPEN，不因包已公证或 14 份原生 Total 有数而改判。

资源与并发边界：沿用现有有界采集与 Stop 超时，不并发跑其他测试；单批最多 3 个新 UI Session，分析只做一次单遍 Raw 分类与哈希，已有结果复用；不新增高频轮询/多份原始字节复制。交付每轮启动到 Stop/最终报告耗时、CPU/RSS/I/O 峰值及最差一轮，与本批命令入口只作形态对照，不把两入口耗时差直接归因于产品代码。若真机/凭据/环境不满足，记录 blocking reason 后停止。

交付与角色：Implementation AI 只采集并提交原始证据、日期化增量记录、真实偏差、站点新增归档、双远程与 Webhook；不改产品语义，不自判 E4 PASS。Owner 将完整交付转 Lead，Lead 直接独立验收，无需逐批 Owner 审批。TSA 构建脚本与 archive renderer 分别留下一批方案，Network、FrameTime B1/B2/B3、Phase C 保持独立。

Implementation Update · 2026-09-25 · A1-E4-UI 真 UI 三轮采集与证据收口

> 关联合同：本文件 §3 Gate 0–3。裁定依据：三轮真实 UI Lead 裁定（93ec9c5）。基线 c95657c275a524c0a7c7a279a9e097db1700fadc，本轮产品代码零改动，只新增本机私有采集/分析工具与公开文档。以下数字全部由只读复算得出，实施方不自判 E4 PASS。证据母本保留在本机私有归档；公开材料只用 Device A / App A / Fixture A 别名。

I-0 · Gate 0 入口与环境前置

• 包与入口：只用已核实 SHA 的 Build 83 公证 ZIP（109,842,490 B，SHA-256 22ab40b54f1e9fddd381715851383262f11608c1ad4b00a24ef25d9cd12c750e）在独立目录解包并启动真正的 Perfowl SwiftUI App（CFBundleVersion=83、x86_64）；codesign --verify --deep --strict、spctl、stapler validate 在解包副本上均通过。App 可执行文件 SHA-256 5c1b8aaeaa5d15f110d727fe05a501272786ad37441b4d0a24582a37ff05f28b；内置核心 Contents/Resources/Tools/x86_64/perfowl_collector_core 12,413,616 B，SHA-256 fe4884286200d9b42edec2dc7d73985ab5340afede06e0300c3597c6384ade1d，与 Lead 先前核验副本逐字节一致。
• 设备与目标：Device A（iPhone15,4 / iOS 17.0 / build 21A327 / USB）在线，设备档位与本方案冻结档一致；目标 App A 与 Fixture A 均已安装（原始标识只留在私有归档）。启动 6 秒后观察到 App 自带的 pymobiledevice3 设备枚举子进程，确认子进程来自包内工具而非系统路径。
• 真实 UI 入口：通过辅助功能标识（perfowl.device.picker / perfowl.app.picker / perfowl.capture.toggle）驱动，逐轮记录设备行选择、App 行选择与 Start/Stop 按压（AXPress，axError=0），辅助功能授权在本轮驱动前已生效。录屏与截图证据可用。本轮入口是 SwiftUI 真机界面，不是直接驱动 core 的命令轮次。
• 环境阻塞（如实记录）：本轮屏幕被锁屏 3 次（约 12:19 / 13:22 / 17:21），锁屏期间 App 窗口不可寻址；第 3 次锁屏时 caffeinate -d -i -s -u 仍持有 PreventUserIdleDisplaySleep 且显示器电源为 USABLE，屏幕仍被锁 ⇒ caffeinate 不足以维持可用，锁源不在系统/显示器空闲休眠路径。每次驱动 UI 前必须先人工确认 SCREEN_UNLOCKED。

I-1 · 三轮原始形态（Gate 1 冻结条件 + Gate 2 分类）

判定轴是字节流里的 begin:Initial Frame Rendering（IFR opener）：r3 的唯一 opener 与出厂报告选中的 IFR span 终点在同一 active 窗口；frame-continuation|post-stop-drain 窗口内 opener 数为 0。

I-2 · r1 判 INVALID 的根因：默认 UI 指标组不含 Startup Timing

r1 并非采集失败，而是侧边栏指标组未含 Startup Timing：PerformanceSessionController.scopedCapturePlan(for:) 由用户勾选的指标组决定 startupEnabled/screenshotsEnabled/requestedMetricIDs，而 WorkbenchMetricCatalog.defaultSelection 默认的 10 组不含 .startupTiming 与 .screenShot。因此默认勾选必然得到 startupEnabled=false、coreProfileCaptureMode="none"，不会产生 CoreProfile blob，也不会有 App launch-trace-report.json。r1 的 capturePlanHash=21201d15…、26 项请求指标、无 blob、离线 final status="missing"/reason="target-lifecycle-events-missing" 均与此一致。r1 按合同标 INVALID，不进入正负向统计，也不计入第二个有效 App A 样本。

I-3 · 冻结配置核验（Python 独立复算，两轮有效）

r2/r3 逐字段与本批冻结的 UI 15 字段一致（自产物独立复算，非采信自报）：launchMode=controlled-cold-launch、startupEnabled=true、screenshotsEnabled=false、coreProfileRawRetention=full（source=wire）、frameFilterExperiment=exact-debug-id、requestedFrameFilter=0x31800318、effectiveFrameFilter=["0x1f070000","0x2b870000","0x31ca0000","0x2bdc0000"]、callstackDepth=0、bm=0、rp=100、csd=0、tk=3、kdf2=[520552448,730267648,835321856,735838208]、ta=[[3],[0],[2],[1,1,0]]、capturePlanHash=f9f5407724bdf97769f439a27ff4e87597fbfbdae77b5c8fc72b5bb9b79a8c3b。两轮 capturePlanHash 相同，且与上一批命令入口会话的冻结 hash 相同 —— 即配置层等价，但不等价于入口等价（见 I-4）。

I-4 · 原始 UI 产物 / 出厂报告 / 隔离 replay 的三层区别

• 原始 UI 产物：UI 会话把核心输出放在 <Session>/collector-core/（collector-core/manifest.json 为 perfowl.raw-session/1），会话根 manifest.json 是产品会话 manifest。App 自身写 launch-trace-live.json 与 launch-trace-report.json：r2 43 键 / r3 45 键，均不含 stopDrainLifecycleDiagnostics 块。
• 出厂（App）报告：r2 status=partial、totalDurationMs=null、totalQuality=missing、requiredMissingPhases=["Initial Frame Rendering"]；r3 status=candidate、totalDurationMs=271.42775、totalQuality=candidate、totalSource=coreprofile-endpoint、phaseCoverageComplete=true。r3 的 Total = traceEndTimestampNs − launchStartTimestampNs = 271427750 ns，是report-layer 的 active 窗口原生端点配对候选，不证明跨工具端点准确性。
• 隔离 replay（离线 final）：离线 finalize（stop_drain_diagnostic=True 分支）只在真实字节隔离副本上运行，先做真字节复制（symlink 会被产品 ReplayValidationError 拒绝）。三轮全部 offline_wrote_into_session=false、published_intact=true ⇒ 未回写原会话、未改产品字节。stopDrainLifecycleDiagnostics 只在离线分支产出 ⇒ UI 自动产物无该块、离线 final 有该块，两者必须分别标注。
• live vs final 主字段：r2 20/20、r3 20/20 相等。离线 final vs App final 主字段：r2 20/20 全等；r3 17/20，差异仅 decodedRecordCount（App final 699,407 vs 离线 1,148,197，因离线重扫范围不同）、liveComplete、liveRevision。

I-5 · 原始哈希（只读复算）

三轮的 pristine / manifest / 离线重算三处 rawSHA256 逐轮相等；blob 的 pristine 与 manifest 亦相等。

I-6 · 目标指标的发布状态，以及替换 totalNeverPublished 的三项判据

合同目标指标 ios.process.startup.app_launch_total_ms 只在 report-final.json 的 coverage[] 落地（metricManifest.metricIDs=[]、metrics-derived.jsonl 0 字节、其 SHA-256 为 e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855）：r1 未请求该指标；r2 valueQuality=missing（reason=lifecycle-spans-incomplete，sampleCount=0）；r3 valueQuality=candidate（sampleCount=1）。故 r3 是启动报告与覆盖账本含一项 candidate，不是「已生成一条 derived metric 时间序列」。

已按合同删除失效判据 totalNeverPublished，改列三项：

• nativeTotalQualityCounts = {candidate: 1, missing: 1}（r1 未请求该指标，不计入）
• liveFinalTotalFieldsEqualCount：r1 = 0/0；r2 = 20/20；r3 = 20/20
• diagnosticClosedCount（离线 stop-drain chainObservedClosed=true 轮数）：0/3

I-7 · 启动至 Stop / 最终报告耗时 / 资源峰值

unknown 的原因：宿主机 CPU/I/O 因宿主程序策略拒绝 ps（/bin/ps 与关闭沙箱均被拒），且本轮采样未收 proc_pid_rusage；设备侧四个指标族因冻结的 startup-only 选择未被请求，产品自记为 valueQuality=missing。两者都不补造 0。 r1 无 handoff* 是因为它没有捕获 CoreProfile，未进入 stop-drain handoff 路径。

I-8 · 原始会话封存与不可变性（Gate 3）

三轮原始 App Session 只读封存（逐文件记录 relPath/bytes/mtime/SHA-256，30/35/35 个文件）；封存后全量复核 100/100 重算一致、MISMATCHES=0、mtime changes=0 ⇒ 三次锁屏与三次离线 finalize 都没有改动任何原会话。

I-9 · 未达门槛与交付边界（不自行宣布 PASS）

正式 E4 门要求至少一份新包真实 UI Raw 中出现身份可信、同线程、设备 tick 有序、阶段链闭合的有界 post-stop-drain 诊断。本轮 diagnosticClosedCount=0/3、选中 opener/closer 全为 null ⇒ A1 正式 UI E4 = OPEN / NOT PASS。三个额度都已用完（合同「单批最多 3 个新 UI Session」），有效 App A 仅 r2 一轮 ⇒ Gate 2 预设样本构成未完成，原样记缺口，不把 INVALID 的 r1 计成第二个有效 App A。按 Lead 裁定：不授权第 4 个 UI Session，停止同构采集；本轮不再改产品代码、不调录制时长/负载/过滤器/角色/Stop 时限、不用离线改字节制造正向。下一步「采集窗口/来源时序差分取证」由 Lead 另拟方案。

同时如实记录本批的两项口径更正（Lead 独立复核，93ec9c5）：① r3 的 rejectedEventCount=14 与 rejectReasons 求和 6 不同单位（前者为 target-layer event，后者为跨预筛/身份/线程/链的 reason 次数，一次 no-opener 可拒整组），不是账本缺陷；② r3 唯一 IFR opener 在 startup-lifecycle|active、drain 内 0 个 opener ⇒「原生端点配对成功而有界 drain 不闭合」是两个不同窗口的预期差异，不是同一证据链自相矛盾。

Implementation Correction · 2026-09-25 · A1-E4-UI 交付口径更正（Lead 文档收口 R1）

本节按 Lead 独立交付审计（deaf8d7）的「唯一最小返工合同」追加。上方 §1–§3 与 I-0…I-9 的已发表数字一律不回改；下列条目只更正口径与覆盖范围，不改动任何原判：r1 配置 INVALID、r2 totalQuality=missing、Fixture A 的 271.42775 ms 仅为 active 窗口原生端点 candidate、离线有界 drain 诊断闭合 0/3、A1 正式 UI E4 = OPEN / NOT PASS。

C-1 · r1 的设备指标不是「未请求」，而是「有设备观察值但配置 INVALID」

I-7 表格把三轮的「设备侧 CPU/内存/磁盘/网络峰值」统一记 unknown，并把原因写作「冻结的 startup-only 选择未被请求」。该口径只对 r2/r3 成立，对 r1 不成立，现按原始 metrics.csv 复算分列更正：

原因：r1 未选中 Startup Timing 组 ⇒ startupEnabled=false、26 指标、captureMode=none，其 metrics.csv 走的是完整 Registry 指标集路径，四族因此被真实请求并拿到设备观察值；r2/r3 走冻结的 startup-only 档位，四族确实未被请求，产品自记 valueQuality=missing。因此：

• r1 的这四族不得与 r2/r3 并列解释成「未请求 / unknown」；r1 是有观察值的一轮，只因配置 INVALID 而不纳入可比 startup 样本。
• 宿主侧 CPU% 与磁盘 I/O 峰值三轮仍为 unknown（宿主程序策略拒绝 ps，且未收 proc_pid_rusage）——本项不受此次更正影响。
• 两侧都不补造 0。

C-2 · Gate 3 的 100/100 一致性只能证明「封存之后到复核之时」

I-8 记「封存后全量复核 100/100 重算一致」。现补时序边界：封存清单 out/session-freeze.json 的生成时刻（17:27）晚于三份 out/ui-analyze-*.json（17:24–17:25）。故该结论只能证明：

• 在 session-freeze.json 生成之后、至本次复核重算之时，三轮原始 Session 的 30/35/35 个文件逐字节未变（重算缺文件 0、哈希不一致 0、字节不一致 0、mtime 变化 0、未声明文件 0）。

它不能外推证明「会话采集结束 → 封存清单生成」这一更早区间未变，也不能外推证明封存清单所描述的更早任何时点。该更早区间未取证，记 unknown。

C-3 · 「Stop → 最终报告」耗时仍为 unknown，原因是缺同轴绝对时间戳

I-7 只交付了「UI 按压 Start → Stop」的区间长度与若干相对耗时，未交付「Stop 之后到最终报告落盘」的耗时。本轮不补造，理由如下：

• out/resource-and-timing.json 顶层键只有 batch 与 rounds；全文件唯一的绝对时间键是 rounds[].startStop.uiPressStartUtc、rounds[].startStop.uiPressStopUtc 与帧时间 frameTimeMs。
• rounds[].finalReport 只含相对耗时：handoffRequestedToDrainCompleteSeconds、writerDrainDurationMs、checkpointMaxDurationMs 等，不含与 uiPressStopUtc 同轴配对的绝对时间戳。
• 可用的绝对时间源只有文件 mtime 与辅助功能按压调用返回时刻；前者标记写盘完成，后者标记辅助功能调用返回，二者与「Stop 停止采集」以及「最终报告对外可见」都不是同一事件边界，相减得到的是无定义量。

结论：该项记 unknown。要闭合需（另批）由产品自身在 Stop 与 final 报告落盘两处各写一个同轴绝对时间戳。handoff requested→drainComplete 与 requested→stopAck 只有 r2/r3 有值（r1 未捕获 CoreProfile，未进入 stop-drain handoff 路径），且均为相对区间，不能替代上述端点。

C-4 · 本次文档与归档返工记录

• 已发布的 docs/architecture/perfowl-p4-build74-phase2-a1-e4-lead-audit-and-ui-verification-plan-2026-09-25-a1-e4-ui-update.html（源快照，SHA-256 4bce9f34…）不回改；本次为同一源文档新增快照 docs/architecture/perfowl-p4-build74-phase2-a1-e4-lead-audit-and-ui-verification-plan-2026-09-25-a1-e4-ui-update-r1.html，并只把 site/devlog/index.md 时间线当前节点的归档链接改指新快照。
• §2 F-4 的渲染缺陷（代码跨度内的字面双星号被继续套加粗正则，产出不匹配的 <code> 与 <strong>）在新快照渲染时作了一处可复现的局部转义修正；未修改通用渲染器 site/scripts/render-archive.py，其永久修复仍另批。具体替换次数与源/初渲/修正后 SHA 记于本次交付回报。
• site/devlog/index.md 的 P2 行中，本批 implementation 更新由「证据」列尾移入「状态」列（列位修正，文字内容不变；既有历史段不回改）。

Implementation Correction · 2026-09-25 · R2（r1 请求集口径与绝对时间字段）

本节按 Lead 独立 R1 审计（100c431）的「唯一 R2 最小返工合同」在 C-4 之后追加。C-1 / C-2 / C-3 的原始文字与全部已发表数字均不回改；下列两条只更正其表述，技术裁定与 unknown 结论不变。

R2-1 · r1 不是「完整 Registry 指标集路径」，而是「UI 默认 10 组请求的 26 项非 startup 配置」

C-1 把 r1 metrics.csv 的成因写作「走的是完整 Registry 指标集路径」。该表述不准确，更正为：

• 原始 Session 只读复算：r1 的 collector-core/capture-plan.json 记 requestedMetricCount = 26、capturePlan.policyVersion = "all-supported.v1"；r2 与 r3 均为 requestedMetricCount = 12（冻结的 startup-only 档位）。
• 这 26 项来自产品 UI 的默认 10 组（WorkbenchMetricCatalog.defaultSelection：CPU Usage、Memory Usage、Display Performance、Network、CPU Core Usage、Thread Count、CSwitch、Wakeups、Disk、GPU Usage）。逐组展开并集＝26 项唯一指标（3 + 5 + 5 + 4 + 1 + 1 + 1 + 1 + 2 + 3），包含 CPU / 内存 / 磁盘 / 网络四族，不含任何 startup 指标（故 r1 startupEnabled=false、无 CoreProfile blob）。
• 因此精确表述为：r1 走的是「UI 默认 10 组所请求的 26 项非 startup 配置，含这四族」，不是「完整 Registry」（本仓库 Registry 合同数为 66）。
• 其余原判不变：r1 metrics.csv 54 行且四族为 candidate 观察值；r1 配置 INVALID、不纳入可比 startup 样本；r2（47 行）/ r3（52 行）四族确为未请求 missing。

R2-2 · 承认 hostResources.window.first/last 是绝对 UTC 时刻；frameTimeMs 是时长

C-3 称 resource-and-timing.json「全文件唯一的绝对时间键」仅为 rounds[].startStop.uiPressStartUtc、rounds[].startStop.uiPressStopUtc 与 frameTimeMs。该表述有两处错误，更正为：

• 该文件另有绝对时刻字段 rounds[<label>].hostResources.window.first / .last，取值为 ISO-8601 UTC 时刻；三轮都有（逐轮取值留在私有证据，不写入公开材料）。
• frameTimeMs 不是绝对时刻，而是 rounds[].deviceMetrics.columnsWithNumericValues 下的一个时长列（毫秒）。
• 同时承认 uiPressStartUtc / uiPressStopUtc 与 hostResources.window.first/last 都是真实的绝对 UTC 字段。但四者对目标耗时都不是已验证的事件端点：

• hostResources.window 是宿主资源采样窗口的两端——设计上它开始于 Start 之前、结束于 Stop 之后，因此既不是「Stop 实际停止采集」的事件，也不是 final 报告落盘或对外可见的事件；
• uiPressStopUtc 是辅助功能按压调用返回的时刻，不属于上述任一事件；
• 文件 mtime 标记的是写盘完成，同样不属于上述任一事件。

• 结论不变：没有经验证的同轴 Stop → final 两端时间戳，该耗时保持 unknown。不得把 mtime、辅助功能返回时刻或宿主采样窗口端点相减来「冒充」该耗时。要闭合仍需（另批）由产品在 Stop 与 final 报告落盘两处各写一个同轴绝对时间戳。