Frame Pacing Jitter 正式验收方案

最新正式结论 · 2026-10-23： Jitter新完整5/5、600/600有效、888行核同，正式38/66；无完整独立参考标记、物理精度未校准。见五轮结果。下方旧增量为历史检查点。

当前增量 · 2026-10-23： 正式37/66；旧Jitter参考协议3/5及r4失败保留。e01有28条非元数据事件，但实际Trace仅0.331324秒并断连，不能覆盖10秒窗；资源观察完整通过。当前环境没有可用完整独立对照，已按Owner政策冻结新无参考五轮，当前0/5；五轮均无异常后才计38/66并标记，物理精度不声明通过。保存原件保留，无需用户操作；网站/Webhook欠项partial，公证暂缓。 当前参考决策与新五轮合同。历史结果原样保留。

截至2026-10-22方案建立时：本批由同一 AI 承担方案、实现、测试与分离复核，不创建子代理；正式进度37/66，Jitter尚未开始真机五轮（0/5）。Owner授权在确认参考不可用且产品数据无异常时按无参考政策验收。该历史快照不描述后续新attempt。

历史计划状态 · 2026-10-23（r3通过后、r4执行前）： Jitter ios.frame.pacing_jitter正式 3/5，整体仍 37/66。r3固定120个1Hz槽120/120 valid；Raw oracle 187/187样本消费链与Collector/CSV逐行一致，7,239个FrameLifetime无未消费尾部；预冻结Metal物理参考窗主审计与独立复算7/7合格。Metal全窗报告仍partial（129/141），未宣称全部有效窗完成物理校准；referenceAccuracyValidated=false、referenceUnavailableConfirmed=false、formalFiveRoundsPassed=false。当时工作台有188张r3后新产生的未保存截图预览，r4 Start会清除；先前对177张预览的授权仅用于r3，因此r4发布/Start待Owner决定。继续同一独占attempt，不重放旧轮、不进入磁盘读取率。

历史状态 · 2026-10-23（Frame Lifetimes进程名attempt-03后）： r4完整采集与独立复核已结束，但7个冻结Metal参考窗仅6/7合格，长尾阶段方向门失败，roundQualified=false；Jitter仍 3/5、整体 37/66。唯一失败窗有FrameLifetime未配对Metal presentedTime，根因未归因。进程名attach短测在DVT/xcdevice守卫可用时仍因Cannot find process matching name结束且未生成trace；只拒绝该配置，referenceUnavailableConfirmed=false、referenceAccuracyValidated=false。当前Perfowl工作台有203张r4后新生成、未保存预览；Owner此前只授权清除r4开始前188张。下一步只读诊断xctrace进程解析与设备通道；不重复全进程、PID或进程名配置。正式同场采集前仍需处理预览并做新鲜守卫，不重放或拼接r4，也不进入r5/下一指标或磁盘读取率。完整资格与交付状态见第24节。

当前状态 · 2026-10-23（d01分离复核后）： 正式37/66、Jitter3/5。Display短录制达到2.337262秒时间限制，但连接错误日志及资源读取覆盖门失败，不准入。Perfowl已正常退出，203张易失预览按Owner自主清理授权清除；保存Session、Raw、Lab及失败Trace保留，不需用户操作。下一步先补全观察器异常分类，再设计录制前启动可控负载、录制中无设备动作的不同资格配置。参考不可用尚未确认，不进入r5或下一指标。详见通道方案与d01结果。

1. 验收范围与历史边界

验收 metricID 为 ios.frame.pacing_jitter，foreground-device，单位毫秒，来源 activitytrace-framelifetime。历史 FPS、FrameTime、P95 和屏幕刷新率的正式结论不重开；本次只测试 Jitter 对 FrameTime 窗口的派生、质量状态、实时发布、落盘和报告链。P95 仅作为同源窗口依赖核对，不重复做 P95 五轮验收。

唯一用户知识页为帧节奏抖动。当前冻结公式仍是最近 10 秒有效 FrameTime：

window = (T - 10,000,000,000 ns, T]
n < 5  => null / warmup
P50    = median(window)
P95    = nearest-rank percentile(window, 0.95)
Jitter = round(round(P95, 6) - P50, 6) milliseconds

偶数样本的 P50 是中间两值均值。P95 和最终 Jitter 各按现有 Python round(value, 6) 规则取 6 位小数。窗口边界、舍入、FrameTime 有效性与 P95 共用，不另造第二套样本分母。不得将全 Session 标准差、1000 / FPS、CADisplayLink 调度值或 GPU 完成时间替代 Jitter。

底层原始事实是 ActivityTrace DTX activitytracetap 的 com.apple.coreanimation / IOMFBServer / FrameLifetime，由自研 ActivityTraceFrameLifetimeRawAdapter 和 FrameLifetimeDecoder 处理。单帧区间从 endMachTicks - previousPresentationMachTicks 以该事件的 Mach timebase 换算为毫秒；缺前驱、非正值、断链、source-gap、sourceEpoch/reconnect/目标代际边界均按源质量处理，不能从旧值补点。派生 Jitter 的独立复核从保全的 Raw 事件、timebase、身份、时间戳、质量与实际发表 cut 重算，不把产品 receipt 当期望值。

新实时 Jitter 应从与 P95 完全相同的有效连续窗口取值。使用现有 P95FrameWindow 的已验证输入、窗口和 freshness 状态，在其有序样本上附加计算 median 与 Jitter；不改变 P95 输出、公式、质量或窗口。让 Jitter 沿用它的目标身份、target generation、sourceEpoch/reconnect、前后台、display、source-gap/discontinuity、来源错序、采集 drop、host freshness 和样本数门；目标/前台状态变化必须在状态更新时立即生效，不依赖中间恰好出现一次 UI snapshot。旧的 DisplayPerformanceProjector 和历史未带新来源策略的回放保持原有兼容路径。

2. 当前离线发现与待补项

• DisplayPerformanceProjector 已计算 10 秒 nearest-rank P95、median 和 P95-P50；既有 test_display_performance.py 覆盖数值、4 点 warmup、窗口淘汰、前后台、reconnect、sourceEpoch、多屏隔离和 golden fixture。
• 新产品 P95 使用 P95FrameWindow 按严格 Raw 来源、身份、时间窗和连续段过滤。复用该状态可避免 Jitter 与当前 P95 收到不同的有效样本集合；对 Jitter 的独立原生算术仍必须另行复算。
• 当前 Frame Report v4 的实际 analyze_display_frames() 汇总没有 Jitter 字段，虽然历史开发记录称其含 P95-P50。本批在报告中补充一个带 quality、样本数、P50/P95、窗口边界和算法标记的“最后完整 10 秒窗口 Jitter”对象；这是报告末端派生摘要，明确不是整段 Session 的统计分布，不改变实时 MetricSample。
• MTLDrawable.presentedTime 是候选独立物理参考：Apple 将它定义为 drawable 实际显示在屏幕上的 host time；值为 0.0 表示尚未呈现或关联帧已丢弃。保留每条原始记录与 0 哨兵，不能为了提高覆盖率删行、换成回调到达时间或用请求 Hz 拟合。候选资格需要同窗时钟桥与 FrameLifetime 事件对应；缺一条均不能称为整屏独立精度校准。

当前针对显示链、报告链和 Apple 物理参考均没有完成 Jitter 专项 E4。自有 Metal 是有条件的参考候选，不预先判定已合格或不可用。若新实验仍不满足同层、同窗、全事件对应，可按原合同再调查实际可用的 Apple compositor 工具；只有确认当前没有合格的独立物理参考，且五轮产品数据/来源/覆盖均无异常，才按 Owner 政策正式计入并标记 NO_REFERENCE_ACCEPTED_OWNER_POLICY、referenceAccuracyValidated=false、ownerReviewRequired=false。原件或数据异常不能解释成“无参考”来跳过失败。

3. 可控 App 用例与参考配对

复用已存在的自有 Metal fixture LabP95 配方 p95-tail-v1，不改第三方目标，不额外安装新 App，也不重用旧 run 或旧 Session：

阶段	时长	请求/刺激	Jitter 用例目的
基线	20 秒	请求 30Hz，固定 512×512 Metal clear	观察稳定节奏及实际呈现分布
正常	40 秒	请求 60Hz，同一画布	建立正常 60Hz 窗口
长回调尾部	40 秒	请求 60Hz，每 12 次请求延迟 80ms	验证长帧尾部提高 P95 与 Jitter，原始刺激和实际呈现分开核算
恢复	40 秒	请求 60Hz，无人为延迟	验证 10 秒窗退出尾部后回到正常分布

请求速率和 80ms 睡眠只证明施加了测试刺激；实际渲染、GPU 完成和实际上屏各自单独保留。每轮实际 Metal presentedTime 与产品原生 FrameLifetime 用设备时钟/Host-time bridge 对齐。对比只取各阶段边缘之外完整 10 秒窗口；要求入选窗口内所有产品 FrameLifetime 有效样本与独立上屏记录完成双向对应，时钟误差界与窗口重叠有收据，并完整保留未匹配、0、负数、缺失和失败记录。任何一项未覆盖的窗口只记候选/不合格，不以局部对应推断整机参考合格。

分布方向门：长回调阶段的独立上屏 Jitter 应高于正常 60Hz 段；恢复阶段应回落到正常段附近。比较阈值在开始真机 attempt 前由已冻结测试程序从无刺激控制数据确定，并固定写入 attempt 计划；不得看到结果后选择阈值。公式准确性另外由独立 Raw oracle 对每个实际发表时点逐值核对，不能用上述场景趋势门替代算术复核。

4. 共享实现与边界控制矩阵

软件阶段至少覆盖：

1. 精确排序向量：5 点最小有效窗口、奇数/偶数 median、nearest-rank 边界、重复值、6 位舍入与数学零；4 点必须 null/warmup。
2. 同窗边界：正好位于左边界的样本淘汰、右边界样本保留、未来帧拒绝、滚动窗口淘汰；host 倒退、样本重复、source/native 时间倒序、host 静默超过 P95 freshness 门均不输出旧 Jitter 为 valid。
3. 生命周期与来源：目标 PID/generation 重绑、sourceEpoch/reconnect 变化、前后台来回且中间不请求 snapshot、display 隔离、source-gap/discontinuity/unsupported quality、重复或缺 Raw sequence、任一 dropped event。首个边界事件后不能带入上一段的 P50/P95/Jitter。
4. 脏值和合同：None、NaN/Inf、bool、零/负 FrameTime、伪造时间戳或 timebase、payload/envelope identity 不符；来源 epoch 必须是正整数、reconnect generation 必须是非负整数，target PID/generation 仅允许缺失或正整数，禁止把字符串、bool、浮点数或越界值强制转换/夹到默认值；缺值保留 null 与真实 quality，不补 0。
5. 端到端链：真实 RawEventEnvelope → ActivityTrace decode/source policy → RealtimeMetricProjector → Workbench/PerformanceSample → SQLite、JSONL、CSV、coverage/final report。每个消费者值、quality、数量和顺序核同；最终 frame-report.json 里的最后 10 秒摘要与独立 Raw oracle 一致。
6. 兼容门：未带新来源策略的历史 FrameTime replay 和 CoreProfile Frame Report v3 不变；P95 数值/receipt、FPS、单点 FrameTime、Refresh Rate 及源开销与本批之前逐项比对，不能顺手调整旧指标语义。

5. 性能、并发及超时

• 热路径继续单一 source consumer 拥有窗口；不新增线程、设备服务、订阅、磁盘访问、高频轮询或全 Session 拷贝。Jitter 在 P95 已筛选的有序列表上取中位数和相减，发表计算 O(1)；不另维护第二个排序表。
• 帧事件速率最高按 120Hz 规划，10 秒约 1,200 点；沿用 P95FrameWindow.MAX_POINTS=4096 硬上限和失效策略，状态 O(k) 且有界。插入沿用现有排序列表 O(k)，snapshot 最坏 O(k log k)，不新增每帧排序。
• 独立离线 oracle 流式处理实际事件；每个发表 cut 只对其最多 4,096 个有效点做排序，时间 O(m·k log k)，内存 O(k) 加有界输出。它不运行在产品采集进程中，不增加手机负载。
• 并发策略为一个采集 consumer 串行维护状态、一个 seal 后离线复核进程；禁止并发写同一 attempt 文件。每个软测子进程 120 秒 / 192MiB 硬限，包构建与安装若后续需要按仓库规则独立限时。首个失配即停相关 suite 并保留原始失败样本，不靠重跑覆盖。
• 以当前真实规模及 120Hz×10 分钟和 1 小时有界合成上限基准，对比改前/改后 wall、首响应、逐帧消费 mean/P95/max、CPU、RSS 与 I/O。目标：追加 Jitter 的消费成本不高于现有 P95 窗口成本；完整处理 mean/P95 ≤1ms、相对 wall/CPU ≤1.15、RSS 增量 ≤8MiB；Jitter snapshot 不增加超过 0.1ms 的 CPU 计算。无可测 I/O 明确记 unknown，不写 0。

6. 正式五轮与停止规则

手机可操作后，先按每批准入规则核现有 Jitter Lab/请求目录、所有历史数据与导出 SHA、App 实际空闲、真实枚举容量、可用空间、签名/版本/来源；任何容量/证据无收据不得启动。新 attempt 必须另存本方案采用时的 HEAD/SHA、逐文件源码 pins、工具版本、权限/手机通道和私有 attempt 根；使用新 run 前缀和实际容量收据。

五轮各使用一个全新 App 生命和产品 Session、一个新 run 名、140 秒固定配方、实际 presentedTime 与完整产品 Raw。每轮 Start/Stop 均一次，产品Session最终durable，Raw消费/丢弃/未排空守恒，保留首尾与过渡；各轮不能拼接。固定产品发表机会取每轮开始后的前 120 个预定 1Hz 槽，至少119个槽有当轮真实产品样本且最大有效槽间隙≤2秒；Jitter 为 10 秒窗口，所有有效值由独立 oracle 逐点复算。若实际 CapturePlan 不是 1Hz 或没有固定槽，开始前必须根据真实方案重新冻结采样窗口，不能事后挑样本。

要求五轮来源/范围/公式/值/quality/导出异常为0，长尾/恢复方向符合固定合同，原生 Raw arithmetic、全部实际消费者、CSV、JSONL、SQLite和最终报告核同。首次失败则整 attempt 按方案失败并完整封存；不删坏样本、不重复某轮、不拼接历史、不提前进入下一指标。若合格独立物理参考在测试后仍不存在而其余门全通过，才依Owner政策正式验收并保留精度未校准标记；独立参考若合格则按事前冻结的每窗 tolerance 验证。

7. 原始计划阶段快照 · 2026-10-22（实现前）

现有聚焦软件基线命令使用 Python 3.12 arm64 venv，test_display_performance、test_online_report、test_frame_report_v4 共 38 项通过（E2）；不包含本方案新增测试、独立 oracle、效率对比或任何手机读写。第一次未设置 PYTHONPATH=.. 的本地命令导入失败已作为运行命令环境错误保留，不作为产品测试失败。

下一动作当时为追加最小实现决策并完成离线实现。此处的 38 项聚焦基线和未完成清单保留为本方案立项时的快照；后续实现及验证结果见本文件的增量记录，不回改历史数值。

8. Minimal Implementation Decision · 2026-10-22

保持 activitytrace-framelifetime-jitter.v1 公式与 10 秒样本集合；不改 P95FrameWindow 的 source admission、P95 算术、质量标签或输出。该窗口已经持有同一份按时间戳入队、按数值有序的有效 FrameTime。实现仅在 snapshot() 对当前选中窗口顺序表计算 median；使用现有 rounded nearest-rank P95 计算最终 Jitter，并把 P50/Jitter 数值及质量作为 additive receipt 字段。RealtimeMetricProjector 在新 p95PublicationPolicy source path 激活时，用该收据覆盖 Jitter，确保 Jitter 与 P95 的来源、身份、10 秒 cut、sampleCount、reset 和 freshness 完全一致；未标记历史输入继续使用已有 DisplayPerformanceProjector 兼容路径。不得改 P95 原有值/receipt 字段或其它四个 display 输出。

Frame Report v4 的 ActivityTrace 汇总新增 summary.framePacingJitter 对象。它仅描述报告中最后一个 primary-display、连续、有效 FrameLifetime 段的 (lastPresentationNs - 10s,lastPresentationNs]，包含值、quality、P50/P95、样本数、边界和 source anchor；不对 CoreProfile v3 增加字段，也不把整 Session 统计误作滚动指标。seal 后独立按 normalized event 行扫描并有界保留至多 4,096 个点；实时 report consumer 不额外复制或排序事件。

测试实现将扩展 test_p95_frame_window.py 的原生整数 oracle，完全从 endMachTicks/previousPresentationMachTicks/numer/denom 与每次实际 snapshot cut 重建 P95、P50、Jitter；另在 test_frame_report_v4.py 验证报告末窗及边界质量。兼容控制比较有/无新 policy 下 FPS、FrameTime、Refresh Rate 与旧历史 Jitter。产品 reference candidate 仍只有 LabP95 实际 presentedTime，本次不修改其 App、配方或证据；真机 attempt 仍须新前缀、五个新 Session 与实际双向事件资格。

实施前后按 120Hz×10分钟和 1小时有界合成负载比较同一 Python 3.12 环境，记录处理 wall/CPU/RSS、事件 mean/P95/max 和首响应；Jitter snapshot 的额外排序/分配数必须为 0，单点算术增量目标≤0.1ms，产品窗口总资源继续满足第5节。源码和测试改动完成后将实际实现、差异、命令、结果、遗留 E4 门与当前 37/66 追加到本 devlog；当前方案不授权手机操作，手机仍须 Owner 可操作后另起专用 attempt。

9. Implementation / Validation Update · 2026-10-22

当前状态：E2 实现与软件门通过，Jitter 正式验收仍 0/5、整体 37/66。 Owner 暂不方便操作手机；本增量没有读取或写入手机、安装、启动、分配真实 run，也没有把参考状态判作“无合格参考”。Metal presentedTime 候选仍待真机同窗资格核验，不能用这批软件结果替代五轮。

实现范围：

• P95FrameWindow.snapshot() 在不改变 P95 数值、source admission 或 freshness 门的前提下，从既有有序样本附加 median、Jitter 与质量收据；RealtimeMetricProjector 仅在新 P95 source-policy 路径发布该 Jitter，旧未标记回放维持旧 projector。
• ActivityTrace Frame Report v4 增加最后连续主显示窗口的 Jitter 摘要；Raw 派生行现在携带目标 PID/generation 与 display 身份，身份边界会重新 warmup。非数值、bool、NaN/Inf、零/负与过大 FrameTime 均 fail closed。CoreProfile v3 没有新增字段。
• 方案中的额外独立 Raw 解算仍由 test_p95_frame_window.py 的整数 timebase oracle对每个实际 snapshot cut 复算；该 oracle不读产品 receipt 作为期望值。Frame Report 汇总另由独立测试向量覆盖末窗、身份变化、source-gap 和脏数值。

验证证据（E2）：

• Python 3.12 arm64 聚焦命令（工作目录 MacApp/Sidecar/tests）PYTHONPATH=.. ../../.sidecar-build/venv-py312-arm64/bin/python -B -m unittest test_p95_frame_window test_frame_report_v4 test_display_performance test_online_report：最终 56 项通过，0.242s。独立复核发现封存报告的 identity/display 类型之前经过 int() 强制转换或默认值夹取；方案第4项先补严格类型合同，再改为拒绝布尔、字符串、浮点和无效范围并清空当前摘要窗口，20类损坏输入由新增回归覆盖。
• Sidecar 全量命令（工作目录仓库根）MacApp/.sidecar-build/venv-py312-arm64/bin/python -B MacApp/scripts/run-core-tests.py --native-library MacApp/.sidecar-build/native-arm64/_native_bplist.cpython-312-darwin.so：2874 项通过，131.869s，0 failures / 0 errors / 0 skips，exit 0。不带 --native-library 的首次默认回归因可选 C 扩展未加载而有 15 errors / 10 failures；按 runner 的 arm64 扩展入口重跑后全通过。该首次失败是验证环境未加载可选扩展，不是 Jitter 产品失败。
• 窗口隔离基准以基线 19023514 的旧 P95FrameWindow 与当前实现，对 120Hz 等效输入、每第 12 帧注入 80ms 长帧、每 120 事件调用一次 snapshot。72,000 事件时 wall/CPU：基线 0.184403/0.183790s，当前 0.182291/0.181508s；432,000 事件时 1.128776/1.121908s，当前 1.120988/1.115600s。432,000 事件逐帧 observe 抽样 mean/P95 为基线 2047/2834ns、当前 2039/2792ns；snapshot mean/P95 为基线 1613/2625ns、当前 2057/3250ns，增量约 0.444/0.625µs，低于 100µs 目标。RSS 峰值基线/当前 54.844/55.109MiB，增量 0.265MiB；I/O unknown（纯内存输入）。首 120 事件覆盖 1716.667ms 合成源时间，首次有效值的计算 wall 为 0.305ms；不是 GUI/产品调度端到端响应测量。
• 知识库门检查通过 66 项 Registry/Canonical/导航合同；43 条既有内容风险提示为 WARN。Node v24.19.0 arm64 下的最终 npm run build exit 0、26.071s，归档同步766个HTML；新增归档文件已出现在构建产物中。存在既有大chunk advisory，不是构建失败。生产网站未发布，Cloudflare/Webhook配置欠项按Owner授权保留 partial。
• 按Owner此前的本机内部测试授权生成 arm64 Build 209 候选。第一个包目录因构建脚本未收到 PERFOWL_PYINSTALLER_PYTHON 而在 Sidecar 冻结前失败，原目录保留；第二个独立目录使用已存在的 Python 3.12 arm64 / PyInstaller 6.22.3 环境成功构建。当前钥匙串没有 Developer ID Application identity，本包按内部授权用 Apple Development 签名，不用于外部发行；App 与 DMG 的 codesign --verify --deep --strict、hdiutil verify 及只读独立解包树比较均通过，冻结 Collector Core probe ready，PyInstaller archive 中已核见 frame_derivation、p95_frame_window、realtime 模块。DMG 136,181,616 bytes，SHA-256 832adf41286a01475e84f103f83610fca75d3638b4c596270d32f578bc8f22a8。Gatekeeper exit 3（未公证候选），未安装、未启动；手机调用0。公证按Owner决定继续暂缓，正式 Developer ID/GPL 发行门保持开放。

相对方案的偏差：分离复核新增一项实现修正：封存报告的来源 epoch/reconnect/PID/generation/display 身份字段此前允许类型强制转换或错误值落回默认身份；依方案已补严格整数门与测试，非法值清空当前末窗并输出 null/unsupported-schema。另生成签名的内部候选用于后续本机验证，但因钥匙串缺 Developer ID、当前手机不可操作且本包未公证，不进行安装/启动，不把候选包称作已部署。产品五轮与独立 Metal 物理参考资格必须等手机可操作后进行；本增量没有新建或启动测试 attempt。报告摘要使用封存后的 normalized event 行，不复制产品热路径，也不代表独立物理精度校准。公证继续暂缓，仅内部测试。

下一动作：手机可操作后先完成新的独占 attempt 文档、完整旧数据 SHA 保全、真实容量与手机通道准入；之后按本方案创建新 run 前缀并执行完整五轮。若五轮无异常且事前/事后确认无合格物理参考，才按 Owner 政策记为通过并附 NO_REFERENCE_ACCEPTED_OWNER_POLICY；若找到可用参考则按冻结同窗门验精度。没有满足其中任一条件前不更新正式数至 38/66。

10. Independent Per-Publication Raw Oracle · 2026-10-22

真机测试前再补一项离线执行工具，避免只凭合成单测验证 Jitter、却没有可复用的真实 Session 逐发表点审核器。自有 LabP95 已通过 MTLDrawable.addPresentedHandler 保留实际 presentedTime、其原始 Double 位型、drawable ID 与回调 Mach 时间；本项不改测试 App 配方，也不把旧 run / Session 作为 Jitter 验收数据。工具只审核新 Jitter attempt 封存的 FrameLifetime Raw envelopes 与 Collector kind=sample 行。

实现放在 internal/acceptance/jitter_1hz/raw_oracle.py，不得导入 Perfowl 产品模块。按原始整数 endMachTicks、previousPresentationMachTicks、numer/denom 重建 FrameTime；按 Raw 消费时钟逐步推进到每个真实 sample cut；独立重建 P95/P50/Jitter 和质量，并逐项核对 MetricSample、窗口 receipt、身份、窗口端点、来源序号与 freshness。窗口和最小样本数仍以既有合同为准，不把产品 receipt 当期望值；身份/来源边界先清窗口，缺失、乱序、source-gap、drop 和 stale 不填数。

算法为 Raw 一次线性扫描、每个发布 cut 对最多 4,096 个保留样本排序，时间复杂度 O(N + M·K log K)，窗口状态有界 O(K)，审核输出有界于实际 sample 数 M。只做本机离线读，I/O 不写成 0；结果明确 referenceAccuracyValidated=false，不得据此通过物理精度或五轮指标门。边界回归覆盖 4/5 样本、奇偶中位数、左开窗口、refresh-gap、stale freshness、receipt/发布值篡改及损坏身份。实现后按真实 120Hz 等效规模测 wall、CPU、RSS 与处理吞吐，确认它只延迟封存后的审核、不影响采集热路径。

11. Independent Raw Oracle Implementation / Review Update · 2026-10-22

E2 离线审计器完成，Jitter 正式验收仍 0/5，整体正式 37/66。 Owner 暂不方便操作手机；本增量没有读取/写入设备、安装、启动或创建 attempt。Metal presentedTime 仍是待资格核验的真实参考候选，既未证明合格，也未证明不存在。

实现位于 internal/acceptance/jitter_1hz/。工具从已封存的 display.frame-lifetime.raw 和同 Session 的 Collector kind=sample 行工作，不导入产品模块。它逐发表点按 Raw 消费时钟重建来源窗口，使用原生 Mach ticks/timebase 独立计算 FrameTime、nearest-rank P95、中位数与 Jitter，再核对产品值、quality 和 receipt。Raw envelope 的适配器序列 sequence 与 payload 的来源 adapterSequence 分开处理：分离复核发现产品 receipt 的来源序号来自 envelope sequence，此前工具误取 payload adapterSequence；已改正并增加序号刻意不同及错收据拒绝用例。源 epoch/reconnect/timebase 边界允许 envelope sequence 重新起始，但同一来源段内必须严格递增。未消费尾部仍单独计数，不混入已发表窗口。工具所有结果均保持 referenceAccuracyValidated=false、physicalCalibrationPassed=false 和 formalFiveRoundsPassed=false。

合成合同测试现为 15/15 通过（Python 3.12.10 arm64，约 0.001 秒）；覆盖四/五点门、奇偶 P50、精确左边界、freshness、source-gap、合法正零、Raw 尾部、收据/发布篡改、envelope 与 payload 序号分离及来源边界序号重启、非 sample 行和多显示 fail-closed。py_compile、AST 解析与 git diff --check 通过。测试不包含真机采集或参考物理精度结论。

120Hz 等效合成审计基准（输入生成器与 sample 行均在内存，Python heap 用 tracemalloc 记录；I/O unknown）结果：

输入规模	发布点	wall / CPU	吞吐	Python heap 峰值	进程 RSS 峰值增量
72,000 Raw（10 分钟）	600	3.015728 / 3.013948 秒	23,874.8 Raw/s	691,823 bytes	1,785,856 bytes
432,000 Raw（1 小时）	3,600	18.273823 / 18.264486 秒	23,640.4 Raw/s	2,839,727 bytes	7,405,568 bytes

工具对 Raw 做单次线性消费，并在每个 sample cut 对最多 4,096 个窗口点排序；复杂度 O(N + M·K log K)。运行时保留最多 50,000 个 sample 输入与等长审计输出，以及 K≤4096 窗口，故实际总内存为 O(M+K)；输入上限为 2,000,000 Raw/50,000 samples。该审核封存后运行，不进入采集热路径；命令仅在结束时返回完整结果，没有渐进首响应指标，本次不虚报。基准为合成内存负载，不代表文件 I/O 或产品端到端耗时。

下一动作保持不变： 手机恢复可操作后，先文档化新独占 attempt、重新核对并 SHA 保全旧数据、核实真实枚举容量与手机通道，再使用新 run 前缀与实际容量收据完成完整五轮。软件检查通过不等于指标通过；没有完整五轮与独立参考/无参考政策门证据前，不增加正式计数，也不进入磁盘读取率。

12. Sealed Session File Adapter · 2026-10-22

为避免真实复核前由人工临时筛选行，审计器增加只读 Session 文件入口：从标准 Session 根目录读取 collector-core/raw-events.jsonl 与 raw/collector-000001.jsonl，只把第一文件中的 FrameLifetime Raw envelope 和第二文件中的 kind=sample 行交给既有独立算术核。校验 manifest.json 内存在 Session 身份，但报告不写出 Session ID；报告记录两个源文件在同一次扫描中计算出的字节数、SHA-256、JSONL 总行数及被选中的事件/样本数。

输入根、固定相对路径每层均拒绝符号链接；缺文件、无效 JSON、单行超过8MiB、任一JSONL超过4GiB、输出覆盖和把报告写入 Session 源目录均 fail closed。输出为新建 JSON 文件，不修改 Session；审计失败时写入明确的失败收据，未完整读取的文件不提供可用 SHA-256。时间复杂度为 JSONL 一次扫描 O(R+S) 加独立窗口复算 O(N+M·K log K)；单行解析缓冲限定 8MiB，样本输入/结果 O(M)、窗口 O(K)。文件扫描会包含原始文件系统 I/O，需另测并如实记录，不能沿用纯内存基准冒充文件端到端结果。

该入口只证明选定封存 Session 的复算结果与输入文件指纹；不自行证明 Session 的完整文件集合、容量准入、attempt 独占、真实参考资格或五轮门。调用者仍须按正式 attempt 收据先核对全 Session 原件和 SHA，再运行此只读入口；工具报告自身仍固定 formalFiveRoundsPassed=false、referenceAccuracyValidated=false。

13. Session Adapter Implementation / Independent Review Update · 2026-10-22

E2 文件入口实现与分离复核完成；Jitter 正式验收仍0/5，整体37/66。 Owner 暂不方便操作手机，本批未查询或访问手机、未安装/启动 App、未创建 attempt。Metal presentedTime仍是待资格核验候选：合格参考和确认不存在合格参考这两个判断都未成立。

分离复核发现第12节的首版入口仅确认外层 manifest 有非空 Session ID，且其 Raw 文件指纹没有绑定到 Collector 自己的封存 manifest。实现已收紧到完整的一致性链：要求外层 Session manifest 匹配目录身份且为已完成、持久化状态；校验 product-seal.json、core-seal.json、collector-core/report-seal.json 的 Session/状态/序号/哈希关联；collector-core/manifest.json 必须声明 completed、verified identity、原 Raw 文件 SHA/字节数/事件数与 event-type counts。Raw JSONL 仅扫描一次并同时计算 SHA、行数和类型计数，再与该 manifest 对照；Collector sample 行继续校验 wire/schema/Session ID，最终 sample 数还与产品 Session manifest 核对。报告只输出各 manifest 的字节数和 SHA，不输出 Session ID。

所有 Session 相对路径通过目录描述符逐级打开并对目录/文件使用 no-follow；文件需为普通文件、读取期间 inode/size/mtime/ctime 稳定。重复 JSON object key、缺失/超界/不匹配文件、源目录内报告输出和已有输出均 fail closed。报告使用 O_EXCL 新建、0600 权限并同步文件与父目录。限制仍为每个 JSONL≤4GiB、单行≤8MiB、manifest≤16MiB；读入 Raw 行只保留当前行，样本和逐点复核结果为 O(M)、窗口为 O(K)（K≤4096）。整次执行复杂度 O(R+S+N+M·K log K)，哈希与 JSON 解析同一次 Raw 扫描，不进入采集热路径。

合成软件合同测试 22/22通过（Python 3.12.10 arm64）：包括原15项 Raw 算术合同，以及 Session seal 关联、Raw manifest SHA/计数对照、Session 身份、根/文件/嵌套目录符号链接、重复 manifest key 和只新建报告等文件入口控制。py_compile 与 git diff --check 通过。测试只证明离线工具合同，不证明任何真机指标或物理参考精度。

针对同一120Hz等效合同，另外以临时封存目录实测 JSONL 文件解析、SHA 扫描和 Raw 重算。下表的生成时间单列；审核吞吐及 bytes/s 只计审计阶段。RSS为该基准进程的高水位，含 Session 生成阶段；首响应为整份报告完成时返回。临时文件在命令结束后删除，产品数据未使用。

输入规模	Collector samples	审核读取字节	生成 wall/CPU	审核 wall/CPU	审核吞吐	读取吞吐	进程 RSS 峰值
72,000 Raw（10分钟）	600	98,170,282 B	0.620 / 0.616 s	1.005 / 1.002 s	71,617 Raw/s	97.6 MB/s	23,805,952 B
432,000 Raw（1小时）	3,600	592,482,567 B	3.611 / 3.572 s	6.065 / 6.049 s	71,229 Raw/s	97.7 MB/s	46,530,560 B

这是 Python 标准文件 I/O 下的合成 E2 基准，不外推为真实设备 Session 的文件系统表现；没有修改产品热路径，因此不存在产品前后性能差值。之前内存 oracle 的 tracemalloc 基准含不同的对象生成与跟踪开销，不能当成本文件入口的前态值。seal 交叉检查不提供 manifest 的外部签名；真实attempt仍须另做全 Session 文件清点与外部 SHA 保全，本工具 per-file pins 不代替原件链保全。

Node v24.19.0 arm64 下完整 VitePress client/server/render 构建通过；66项 Registry/Canonical/知识门合同通过，43条既有内容风险提示仍为 WARN，归档同步768个HTML。构建有既有大chunk advisory。生产站点与Webhook仍按Owner授权保留partial，不以旧页面代替本批页面。机器可读记录见 internal/handoff/jitter-session-audit-adapter-validation-2026-10-22.json，归档快照为 /archive/validation/p4-jitter-session-seal-audit-2026-10-22.html。

下一动作不变： 等手机可操作后，先形成新独占 attempt 文档，重新核对并 SHA 保全旧数据、真实枚举容量及手机通道；然后创建新 run 前缀并完成五轮。软件工具通过不计作 Jitter 正式通过；参考候选合格或已穷尽确认无合格参考、且五轮产品数据无异常后才能决定计数，之前不得进入磁盘读取率。

14. Animation Hitches 辅助参考候选调查 · 2026-10-22

为缩短手机恢复后的参考资格判断，先核查本机是否存在可用于进一步调查的 Apple 工具；本节只记录候选与准入边界，不变更第6节正式五轮合同。

• 本机只读环境检查：xcodebuild -version 为 Xcode 16.4 / build 16F6；xcrun xctrace list templates 列出 Animation Hitches 与 Metal System Trace。Apple 文档说明 Animation Hitches 可显示 Frame Lifetimes 与 vsync 时间线；xctrace export 对已生成的 .trace 按 --toc 或 XPath 输出 XML。来源：Understanding hitches in your app、Xcode command-line tool reference。
• 同轮检查 xcrun simctl list devices available 仅显示 unavailable 的 iOS 18.6 runtime，没有可启动模拟器；本次未构建模拟器 App、未录制 trace、未访问手机、未创建 attempt。
• 当前版本的工具路径已在刷新率资格中实际失败：5秒 Animation Hitches探测峰RSS 933,773,312 bytes，高于805,306,368-byte硬门；同批trace表导出在192MiB与384MiB RSS限额下均失败并产出0-byte文件，监督结论为passed=false。完整历史见刷新率工具资格记录。该失败不证明硬件故障或trace中无帧数据，但足以拒绝当前配置；不得用更宽RSS上限重跑同一探测或把0-byte导出当空数据。
• 本机具备模板与导出命令，不说明该模板能导出可供本指标使用的逐帧原始呈现时刻；也不证明时钟映射、目标身份、foreground-device scope、来源独立性或 Jitter 公式等价。它当前是 存在但被既有资源门拒绝的辅助候选，除非之后提出有证据的低开销配置并另行文档化，否则不进入本轮候选集合。Apple 的 hitch 诊断值不得当作 P95-P50，轨道截图不得代替原始逐帧记录。
• Jitter正式attempt仍先按第6节核验自有Metal presentedTime；若它失败，Animation Hitches当前配置不能作为直接回退。只有出现符合既定RSS门、能保存新trace且导出逐帧事件的可行配置，才另行评估每个入选10秒窗口的时钟映射、目标/显示身份和与产品FrameLifetime的双向完整对应。任一必需字段或事件缺失即拒绝该参考，不据此改变“尚有/无合格参考”状态。

本次仅增加候选可用性信息，整体正式 37/66、Jitter 0/5 不变。当前手机不可操作，故候选的导出格式与物理参考资格仍未验证；不得提前认定无参考或进入磁盘读取率。

15. Metal 逐窗物理参考审计器合同 · 2026-10-22

目标与输入边界

手机暂不可操作期间，先实现可复用的离线审计器，用于正式 Jitter attempt 产生新证据后判断自有 Metal presentedTime 能否对照 Jitter。它不访问设备、不改 Fixture、不调用产品实现，也不把既有 P95/刷新率批次转作 Jitter 验收数据。历史封存记录只可用于工具格式与候选机制的诊断，不能计入新五轮。

工具读取一个已封存 Perfowl Session 与一个独立 LabP95 run。Session 输入必须先通过现有 seal chain 和 Raw oracle；随后同一组 FrameLifetime envelopes、Collector sample rows 与 Fixture 六原件（plan.json、gate.json、events.json、requests.json、presented.json、summary.json）均逐字段校验 schema、行列、计数、文件大小和类型。文件在读取期间改变、JSON 重复 key、符号链接、缺文件、未知列、额外/缺失请求或记录均 fail closed。报告不写 Session ID、目标 PID、设备标识、drawable ID 或路径。

时钟、配对与 scope

候选时间统一到设备 Mach 绝对纳秒：FrameLifetime 使用 endMachTicks × numer // denom；Metal 使用 IEEE-754 presentedTimeSeconds 与同一份 Fixture timebase 得到的最近整数纳秒。必须满足 Fixture begin/end clock bracket 都完整、media 时间落入对应 mach_absolute_time 调用括号、时间基相同，且每条 presented callback 的 begin/end 位于该请求 commit 之后。不得拟合偏移、线性回归、按请求 ID 推测设备帧、按回调到达顺序重排或用 requestedHz/GPU complete/CADisplayLink 补值。

Fixture 的 summary.endMach 是停止新工作时的边界；已经提交的 drawable 按既有关闭合同最多 drain 1 秒。因此 presented 时间可晚于该边界，但不得超出1秒 drain 界或其回调返回时刻；不以超过上限的尾部放宽采样窗。

在排序后做全局单调一对一时间匹配，固定最大差 100,000 ns，来源为 Fixture 既有双钟 bracket 的 0.1ms 硬界；每个端点候选必须唯一，重复、歧义或超界均拒绝对应窗口。对每个 Raw FrameLifetime，Metal presentedTime 还必须与其 endMachTicks 对应；Metal 前驱时间必须与 Raw previousPresentationMachTicks 对应。任何 0、负数、null、NaN、倒退值或未匹配记录保留在拒绝计数中，严禁过滤后宣称完整。

物理参考只按 Raw oracle 独立重建的每个有效发表窗口 (windowLeftNs, windowRightNs] 审核。入选窗口内所有产品 FrameLifetime 事件（包括 warmup/断点锚点）与所有 Metal 原始上屏行必须双向一对一、同一 displayID/source epoch/reconnect/timebase；窗口内所有产品 Raw 行都用于完整范围配对，但只有 Raw oracle 标记为 valid 的区间行进入两边的 Jitter 样本集合，因此 Warmup 锚点必须配对却不计作 Jitter interval。Raw oracle 有效样本数必须与 Metal 独立 interval 数一致；每个入选 interval 的前驱行都必须存在并相互配对。多 display、身份切换、缺失/额外事件、前驱断链、display 范围不可证明或引用窗口跨源代际均标该窗不合格；不以相邻窗或其他轮次补齐。

独立重算与判定

Metal 参考 FrameTime 由连续两个 presentedTime 的绝对时间戳差换算为毫秒、按六位小数 round；窗口选择、n < 5、P50、nearest-rank P95 与 Jitter 都依知识页冻结公式独立重算。合格窗还要求参考与 Raw oracle 的 Jitter 差不超过 0.400002 ms：每个端点的最大 0.1ms 配对误差导致区间误差上界0.2ms，P50与P95误差合计上界0.4ms，另容纳两次六位舍入的2ns。此门不得按看过的结果调宽。

报告逐发表点记录资格/拒绝原因、FrameLifetime 与 Metal 行数、唯一配对/未配对/歧义数、窗口边界、独立重算的 P50/P95/Jitter 与差值；只保留非敏感计数和数值，不回写源。单轮只能得 qualified / partial / not-qualified，工具永远固定 referenceAccuracyValidated=false、formalFiveRoundsPassed=false、referenceUnavailableConfirmed=false。五轮中所有预期有效发表窗口都合格且差值通过，才可由后续五轮聚合门标为物理精度校准；部分窗口可帮助诊断，但不能冒充完整校准，也不自动等于“没有参考”。

资源与软件反例

一次性串行离线操作；Fixture 原件最大2MiB沿用既有上限，Session Raw最多读取96MiB、Collector rows最多32MiB、Fixture frames最多25,000、产品发表行最多500、单行最大8MiB，单进程120秒/192MiB RSS。经 seal 的 Session Raw 与样本在同一遍扫描，最多保留25,000个FrameLifetime行；复杂度 O(F log R + M·K log K)（对F个产品帧二分匹配、M个有效发表窗各排序至多K=4,096个点），内存 O(F + R + M) 且受输入界限约束；没有设备端开销。Fixture 既有实现可能先记录新 phase 的首个 request、再写 phase-begin 事件；审计不把这一边界顺序差异误作丢帧，所有趋势窗口仍须按完整10秒落在单一刺激阶段内。验收测试必须包含准确匹配正例、超容差/歧义、双向额外帧、丢行、presentedTime=0、坏bits、时钟 bracket 缺失、display/source 切换、窗口开闭边界、Raw 前驱不一致、公式误差刚好在容差内/外，以及输入篡改。软件通过只证明工具按合同拒绝/接受受控输入，不改变 Jitter 正式状态。

手机恢复后的 Fixture 用例

五轮均使用新 App life、新 Session、新 run 前缀，保留既有140秒四段工作负载（20秒30Hz基线、40秒60Hz正常、40秒每12次请求延迟80ms、40秒60Hz恢复）。每轮按实际产品 CapturePlan 先冻结1Hz发表机会与 10秒窗口 cut；同一轮 fixture 与 Collector 需时间重叠，不能拼接历史 run。独立 Raw oracle 先逐点审核产品 Jitter；本审计器再对每个 quality=valid 的实际 cut 做完整物理参考审计。首个产品异常按正式方案停止并保全；参考不合格只保留候选/不合格事实，不放宽容差或删样本。当前历史可见的 Metal 行与 FrameLifetime 行数不一致，且曾有0哨兵，因此必须用新轮次原件重新判断；这些历史数据不构成 Jitter 五轮证据，也不预先确认 Metal 合格或不存在参考。

本合同先于实现写入。实现与合成/历史格式反例验证完成后，追加本方案结果、修订知识页与恢复入口；手机不可操作期间 Jitter 继续0/5、整体37/66，不创建 attempt，也不进入磁盘读取率。

16. Metal Reference Auditor Implementation / Separation Review Update · 2026-10-22

离线实现和合同复核完成；Jitter 正式验收仍0/5、整体正式37/66。 Owner 暂不方便操作手机。本批没有访问手机、安装或启动 App、创建 attempt，也没有把历史 P95/刷新率 run 用作 Jitter 证据。MTLDrawable.presentedTime 是否为合格独立参考尚未判定；没有确认参考不存在。

实现位于 internal/acceptance/jitter_1hz/audit_metal_reference.py。输入先通过封存 Session seal chain 与 Raw oracle，再读取独立 LabP95 六件原件；窗口按 Raw oracle 实际发表 cut 审核。每个窗口的全部 FrameLifetime 行（包括 warmup/断点锚点）都与 Metal presented 行作唯一、双向配对；只有 Raw oracle 的 quality=valid interval 进入 Jitter 分布，warmup 锚点只在作为 valid interval 前驱时提供前驱时间。时钟桥、0/无效位型、事件缺失/额外、身份/显示切换和差值超界均拒绝对应窗口，不在审计时重写源文件。

分离复核补强了 Fixture 输入树与报告保全：run 目录通过 O_DIRECTORY|O_NOFOLLOW 打开并由目录描述符固定；六个子文件仅相对该句柄以 no-follow 方式打开，核读前后普通文件身份/大小/时间及目录变动；报告排除输入树、用 O_EXCL 新建为0600文件，并同步报告与父目录。另从原始 continuousBefore/AfterMach 与 before/afterMach 重算 offset 下/上界并逐字段核 Fixture 声明，精确整数复核0.1ms宽度门；Mach timebase 按 Fixture UInt32 合同限界。新反例覆盖原始行缺失、presented 位型损坏、时钟 bracket 缺失/未通过/边界与offset篡改、source epoch切换、根目录/单文件符号链接及100µs匹配边界。

验证结果（E2，仅离线软件合同）：聚焦目录完整合成套件 52/52通过，py_compile、git diff --check 通过。Metal 匹配基准使用 7,210 FrameLifetime/Metal 行和 120 个重叠发表窗口；三次报告的 wall/CPU、吞吐及RSS记于机器结果。输入纯内存合成数据，未计文件I/O，无设备动作；这证明实现的资源形态，不代表实际 Session 或 Metal 参考有效。Node v24.19.0 arm64 下知识门66项通过、完整VitePress client/server/render构建通过，归档同步769个HTML；产物确认本批知识页、开发记录、归档和索引入口均存在。43条既有内容风险提示与大chunk advisory保留；按Owner授权生产站点未发布，Cloudflare/Webhook配置欠项仍记partial。

知识沉淀： warmup/断点锚点必须配对以验证窗口完整性，但锚点自身不是 Jitter interval；见Canonical Jitter 知识页。原件、输出隐私与适用范围见仓库内部运行说明 internal/acceptance/jitter_1hz/README.md。机器结果见 internal/handoff/jitter-metal-reference-auditor-validation-2026-10-22.json；归档快照为 /archive/validation/p4-jitter-metal-reference-auditor-2026-10-22.html。

下一动作： 手机可操作后，先写入全新的独占 attempt 和 run 前缀，重新核实并 SHA 保全旧数据、实际目录容量及手机通道，再执行完整五轮；先对每轮产品 Raw 逐发表点重算，再审计所有 valid 窗的物理参考。只有五轮产品数据无异常且 Metal/其他独立参考实际可用，或已确认不存在任何可行的独立对照路径，才按 Owner 的无参考规则计数。当前手机不可操作，保持离线准备，不进入磁盘读取率。

17. Sealed Session to Metal Audit Integration Follow-up · 2026-10-22

在第16节 Metal 审计实现的分层合同覆盖之外，增加了端到端合成测试，实际经过 audit_session_and_run()：完整产品/Core/Collector seal chain → 封存 Raw 文件审计与逐发表点 Raw oracle → LabP95 六件 Fixture 校验 → 同一有效窗口的 FrameLifetime/Metal 双向配对与独立 Jitter 复算。

正例使用新生成的临时 sealed Session 与对应合成 Metal run，唯一窗口返回 qualified，且每条窗口内 FrameLifetime/Metal 行完整配对；审计报告仍将物理精度、参考缺席和五轮验收全部置为 false。反例在窗口内将一条 presentedTime 改为零哨兵，完整输入仍可审计，但候选返回 not-qualified，保留无效行计数，不确认“无参考”。两个临时树在测试结束后删除，不读取历史 run 或设备数据。

Python 3.12.10 arm64 下完整目录命令 python3 -B -m unittest discover -s internal/acceptance/jitter_1hz -p 'test_*.py' 54/54通过；Metal 模块单独发现 30/30通过；py_compile 与 git diff --check 通过。分离复核发现直接导入另一个 TestCase 会被 unittest discover 重复收集，故共用 sealed Session 构造逻辑改由普通辅助函数暴露；最终计数无重复。Node v24.19.0 arm64 下调用 scripts/build-staged.py 完成 VitePress client/server/render 全构建（22.859 秒），知识门66项通过，归档同步770个HTML；43条既有内容风险提示和chunk advisory保留。生产站点未发布，Cloudflare/Webhook配置欠项继续按Owner授权记partial。新增测试不进入产品采集热路径，因此本次不重跑 Metal 匹配基准；前节7,210行/120窗口资源测量继续作为工具基准。证据等级为E2，仅证明审计入口的合成联通与拒绝合同。

本增量未读取或操作手机、安装/启动 App、创建 attempt，也未使用旧数据作 Jitter 证据。整体正式 37/66、Jitter 0/5，Metal真实参考资格仍未判定。手机可操作后仍先文档化全新独占 attempt、重核并 SHA 保全既有数据、实枚举容量与手机通道，再使用新 run 前缀完成五轮；软件测试结果不进入指标正式计数，继续不进入磁盘读取率。机器记录追加于 internal/handoff/jitter-metal-reference-auditor-validation-2026-10-22.json。

18. Raw Sequence Reservation Repair Plan · 2026-10-22

诊断结论

在保全的 r1 上，仅在内存审计副本中绕过三类来源序号收据差异后，独立 Raw 算术、质量与其余收据检查均通过：7,228 个 Raw 帧、182 个发布样本、140 个 valid 样本、其余质量分布为 warmup 1 / stale-source 40 / source-gap 1。被绕过的差异仅有 lastRawSequence 182 项，以及 firstSourceSequence / lastSourceSequence 各 140 项；磁盘原件和 SHA 未改。缺陷发生在实时顺序：显示事件先以适配器本地 sequence 进入 RealtimeMetricProjector，之后 RawSessionRecorder.append() 才分配 Session 全局 envelope sequence，故 receipt 与同事件 Raw envelope 的序号不同。

同一组 140 个有效产品窗口还对保全快照内 18 个旧 Metal run 做了离线候选检查。11 个符合当前审计器 schema 的 run 均为 not-qualified、0/140 窗口合格、0 个唯一 Raw/Metal 时间匹配；另 7 个因旧 schema/合同无法由当前审计器读取。它们不构成 r1 同窗对照，也不证明新的并行 fixture 不可用；不得据此宣布独立参考已不存在。原始 r1 仍失败且不能计入五轮。

最小修复决定

仅修复 Raw 全局序号与实时 projection 的身份绑定，不改 FrameTime / P95 / Jitter 公式、刷新率语义、采样窗、质量门或 receipt schema：

1. RawSessionRecorder 增加线程安全的全局序号预留。预留仅在 OrderedRawIngress 完成容量校验并接受事件后发生；超限拒绝不消耗序号。SessionWriter 将预留号交给单写入者，Recorder 只按严格 FIFO 消费下一预留号。未预留的直写在有未消费预留时 fail closed；finalize 检查预留与已消费数量相等，存在尾项不得封成 completed。
2. Ingress item 同时保留原始 adapter event 和该事件的 global reservedSequence。只有 FrameLifetime 的即时 projection 副本把 envelope sequence 设为预留号；在复制前将原始 event sequence 写入 payload adapterSequence（仅当字段缺失），既有 source-local 序号保持原义。落 Raw 仍用原事件与同一预留号，由 recorder 完成标准 envelope normalization。
3. FrameLifetime 热路径先做有界 ingress 接纳，再把接纳返回的同一序号 projection event 交给 RealtimeMetricProjector；失败/overflow 时不更新 projector。事件循环不等待落盘，不新增线程、队列、设备服务或同步 I/O。其他实时指标与 report 使用原有单写入者及消费次序。

验收与效率门

新增定向回归覆盖：预留 FIFO、拒绝 overflow 不预留、source-local adapterSequence 与 global envelope sequence 分离、预留未消费时禁止直写/finalize、同一显示事件的实时 Jitter/P95 receipt 与最终 Raw sequence 完全一致、非显示路径/历史无预留路径兼容、预留失败不发布、刷新率现有 receipt 与值不变。测试需覆盖实际 OrderedRawIngress → SessionWriter → RawSessionRecorder，不能仅 mock sequence assigner。

在改动前固定采集 120Hz 等效 72,000 与 432,000 Raw 事件的既有有界队列处理 wall/CPU、入队至首次 projection 响应、事件 mean/P95/max、吞吐、RSS 峰值及 I/O；改动后同机、同解释器、同数据和重复次数复测。沿第5节资源门：处理事件 mean/P95 ≤1ms、wall 与 CPU 比值 ≤1.15、RSS 增量 ≤8MiB、投影新增计算 ≤0.1ms；未测的 I/O 记 unknown。至少一次有效合成样本逐字段对照含 Refresh Rate 的旧消费者基线。聚焦 suite 与 Sidecar 全量测试均需通过；不把离线通过外推为真机可用。

实现前基线已在 Python 3.12 arm64 上测量两次。负载由现有 NativeStream 生成 120Hz FrameLifetime，真实 RealtimeMetricProjector 与 OrderedRawIngress 运行，使用仅计数 writer 隔离采集热路径；不序列化 Session，I/O 记 unknown。72,000 事件 wall 998.501 / 1,176.067ms、CPU 984.469 / 1,079.157ms、吞吐 72,108 / 61,221 Raw/s；入队加投影抽样 mean 8.241 / 5.896µs、P95 25.833 / 9.917µs、max 179.083 / 84.500µs；投影本身 mean 5.873 / 4.040µs，首次投影 33.042 / 32.042µs。432,000 事件 wall 6,123.092 / 6,104.827ms、CPU 6,073.446 / 6,047.852ms、吞吐 70,553 / 70,764 Raw/s；入队加投影 mean 6.564 / 6.304µs、P95 11.542 / 10.750µs、max 43.292 / 44.458µs；投影 mean 4.504 / 4.272µs、首次投影 29.084 / 28.792µs。macOS ru_maxrss 原生字节折算后，峰值 RSS 两次分别为 72,000 事件 46,792,704 / 46,891,008 bytes、432,000 事件 78,200,832 / 76,546,048 bytes。这些数字是本地合成热路径基线，不含磁盘 writer 和真机负载；下一增量按相同 harness 与解释器复测，并对 raw writer reservation/FIFO 另做端到端功能测试。

完成修复和独立复核后，才可基于手机目前可操作的状态，创建一个全新的独占 attempt、重新核对与 SHA 保全旧数据、确认设备枚举容量/通道收据及可用空间，然后重新执行完整五轮。r1 不重放、不拼接、不修补入正式轮次。新五轮须同步采集新的 Metal fixture，审计器不能用不同时段历史 run 替代。软件/实现阶段不进入磁盘读取率，也不增加正式计数；当前仍为 37/66，Jitter 0/5。

19. Projection Sequence Override Efficiency Amendment · 2026-10-22

对第18节的实现路径做了受测修订，原始 Raw 序号预留和 FIFO writer 合同不变。首个工作树版本在每个显示帧上为 projection 复制完整 payload 并构造 envelope 副本；按同一基准两次复测，72,000 帧 wall/CPU 从中位数 1,087/1,032ms 增至 1,489/1,468ms（约 +37%/+42%），432,000 帧从 6,114/6,061ms 增至 9,084/9,001ms（约 +49%/+49%），超出 15% 效率门，故该拷贝设计不接受。

改为只把预留的整数 raw_sequence_override 传入 RealtimeMetricProjector.consume()，并仅传给 P95FrameWindow.observe() 和 RefreshRateSource.observe() 的序号/receipt字段；它们都继续读取原始同一 RawEventEnvelope 与其原 payload。Ingress item 保留原 event、reservation 与可选整数，不复制 event 或 payload；Recorder 将原 event 与 reservation 一起持久化。这样 Jitter/P95 和 Refresh Rate 收据可绑定同一 global Raw 序号，其他显示数值/质量继续走原始事件；source-local adapterSequence 仍由 Recorder 从源 envelope 补入，未被 projection 修改。

重新验收除第18节门项外，还要求实际 P95/Jitter 与 Refresh Rate receipt 的 lastRawSequence 均匹配其保全 Raw envelope；无 per-frame event/payload copy。优化版仍必须重新跑基线同规模的两次 72,000 / 432,000 负载，不以改善单个 microbenchmark 抵销总热路径退化。若优化版仍超过 1.15 wall/CPU 或 8MiB RSS 增量，继续优化或停止该修复，不创建正式 attempt。

20. Session-Global Raw Sequence Repair · Implementation / Independent Review · 2026-10-22

E2 修复与独立复核通过；正式验收保持37/66、Jitter 0/5。 根因是实时 projector 先消费 FrameLifetime，Raw recorder 后分配 Session-global envelope sequence，导致实时 P95/Jitter receipts 与对应 Raw envelope 错位。修复不改公式、质量门、采样窗或 receipt schema。

RawSessionRecorder 现在可线程安全预留全局序号并只允许单 writer FIFO 消费；未消费 reservation 时禁止旁路 append 和 completed finalize。OrderedRawIngress 在容量准入后预留序号，SessionWriter 传递到 recorder；FrameLifetime projector 只接收这个整数 override，用同一编号生成 P95/Jitter 与刷新率 receipts，source-local adapterSequence 仍保留在 Raw payload。Ingress 在 worker 启动前已有接纳项时 fail closed，避免新 writer 无法补造既有序号。正常 in-flight append 状态与持久化 poison 状态分离，producer 可与 writer 并行预留后续号。

分离复核覆盖 Raw FIFO/顺序拒绝/未消费 finalize、overflow 不消耗编号、实时投影 receipt 与 Raw envelope 一致、source-local 序号保留、刷新率与历史值/quality 不变、in-flight 预留可行及 writer 真实失败后拒绝新预留。扩展专项 84/84、Jitter 离线目录 54/54、规范 arm64 Sidecar runner 2880/2880 通过（0失败/错误/跳过）；6个改动 Python 文件 py_compile 和 git diff --check 通过。首次未加载可选 native 扩展的裸 unittest discover 运行出现16个失败/错误，其中15个属于未加载扩展、1个旧 GC 测试仍按先入队后启动新 writer；改用规范 runner 显式加载扩展并将兼容控制限定为旧 writer 后，完整回归全绿。

效率对比来自同一 Python 3.12 arm64、相同120Hz等效输入及 OrderedRawIngress → RealtimeMetricProjector 合成热路径，baseline 源文件逐个核同 Git HEAD 9619767bdf99e1a9e862881644940021f39498f6。每规模两组配对；wall/CPU 为中位数，RSS 为进程峰值中位数：

输入规模	Baseline wall / CPU	修复后 wall / CPU	增幅	RSS 峰值 Baseline → 修复后	修复后事件 mean / P95	I/O
72,000	1,013.112 / 999.381 ms	1,056.900 / 1,041.064 ms	+4.32% / +4.17%	67,256,320 → 46,727,168 B	7.481 / 21.917 μs	unknown
432,000	6,373.315 / 6,307.283 ms	6,396.267 / 6,326.205 ms	+0.36% / +0.30%	100,057,088 → 77,365,248 B	6.759 / 11.708 μs	unknown

所有 wall/CPU 配对均低于15%门，mean/P95远低于1ms；配对的新增首投影响最大约12.292 μs，projector 单点 max 的最差配对增量约92.416 μs（低于0.1ms门）。120Hz首个有效窗口约1.395–2.431ms。两个规模都没有复制 Raw envelope 或 payload。基准使用计数 writer，不做磁盘 I/O，因此 I/O 记 unknown，不能把热路径结果外推为真实 Session 性能或设备准确性。

2026-10-22只读检查中，标准安装版 Perfowl 当前窗口显示 Capture 已完成、182个样本与183张尚未保存的截图；本批未关闭应用、未覆盖安装或触碰这些现有数据。Owner确认手机自动锁定关闭；正式 attempt 前仍需新鲜核定 USB/目标 App、实际设备容量与真实 CapturePlan，并重新保全旧目录。r1失败原件不重放；新五轮须同步生成 Metal Fixture。软件通过不等于指标通过，也不增加正式计数。机器结果见 internal/handoff/jitter-raw-sequence-repair-validation-2026-10-22.json。

21. Metal 时钟域与 Raw 样本段对齐修正计划 · 2026-10-23

发现与证据边界

本节是审计器修正方案，先于代码修改。2026-10-23 attempt-03 的 r1 Session 与 Fixture 原件已经各自封存、SHA 复核通过；首次 metal-reference-audit-a01.json 保留，不覆盖。该报告的 0/7,235 匹配不能用作参考不可用结论。

静态代码与 r1 原件共同显示旧审计器混用了时钟域：Fixture 的 presentedTimeSeconds 是 MTLDrawable.presentedTime 的 host time；Fixture 同时用 CACurrentMediaTime() 证明它处于 mach_absolute_time() 域。ActivityTrace Raw 的 endMachTicks 则与 Fixture continuousBeforeMach/continuousAfterMach 及其 continuous − absolute offset 相符。两端必须使用同一份已核验 offset intersection 后再比较。Apple 对 MTLDrawable.presentedTime 的定义、Apple 对 CACurrentMediaTime() 的定义、Apple Mach 时钟说明支持这些 API 的时钟定义；本轮具体映射仍以 Fixture bracket 和保全原件为证。

从两组 bracket 只读重算出的 offset intersection 为 110,827,409,877–110,827,409,887 ticks；按 125/3 ns/tick 换算，宽度为 416.667 ns。在报告之外、仅于内存中将 Metal absolute host time 映射到 Raw continuous domain 后，r1 有 7,200/7,207 个 Metal 点唯一对应 FrameLifetime；但这还不是最终合同，因为旧审计器又把整个10秒墙钟范围内的Raw/Metal行都视为产品实际采用的样本。

Raw oracle 的 firstSourceSequence、lastSourceSequence 和 sampleCount 才是每个 Jitter 发布值真正使用的 FrameLifetime 连续段。其 windowRightNs 按样本 cut 外推 host 消费延迟，因此该时间范围可能包含尚未被该样本消费的后续帧；source discontinuity 也会清空旧段后从新锚点重新累计。把墙钟范围内所有行都要求匹配，会错误拒绝产品并未用于该值的帧。修改后仍须严格完整核对该值实际使用的每个区间端点及其前驱，并拒绝所选连续段内任何缺失、额外、歧义或超差 Metal 行；不放宽100µs端点界、0.400002ms Jitter差值界、Raw oracle、窗口、公式或质量门。

修正后的逐窗合同

1. _load_run 只接受 begin/end bracket 都完整、native bounds 可独立重算、timebase一致且 offset 区间有交集的 Fixture。把两端重算后的 offset intersection（tick 与 ns）传入 Metal 审计；匹配需对整个 offset uncertainty interval 保守满足100µs，不能对每条记录各自挑一个有利 offset。Jitter 间隔仍由 Metal 原始绝对时间差计算，常量 offset 不参与间隔。
2. 对每个 quality=valid Raw oracle check，以 (windowLeftNs, windowRightNs]、firstSourceSequence…lastSourceSequence、quality=valid、身份和 sampleCount 独立重建其产品 interval 集。重建数量和两端序号必须与 oracle 收据严格一致；不从其他轮次、旧帧或 Metal 回调推补样本。
3. 从第一条所选有效 interval 的 previousPresentationMachTicks 唯一寻找其实际 Raw 前驱锚点；锚点与每个所选 endpoint 均须映射到唯一 Metal presentedTime。锚点到最后 endpoint 之间的 Metal 行必须与所选 Raw interval endpoint 顺序连续一对一，不容许漏帧、额外drawable、重复或歧义；仅忽略所选 segment 之前/之后且不参与该值的记录，并在报告中保留数量。
4. 对这些配对 endpoint 间隔独立计算 FrameTime、P50、nearest-rank P95 与 Jitter；完整保留0、负值、缺行、质量边界、未匹配计数。单轮工具仍固定 referenceAccuracyValidated=false、referenceUnavailableConfirmed=false、formalFiveRoundsPassed=false；只记录逐窗资格，不能把单轮工具输出当指标 PASS。

固定真机用例

attempt-03 r1 只用作修正可行性诊断，不计入新五轮，也不据其结果选择每轮窗口。新 attempt 在手机动作前另立独占文档、run 前缀及全部收据。其140秒Fixture四阶段保持 20/40/40/40 秒；每轮预先指定 7 个 Jitter 参考窗口：

阶段	固定参考 cut	实际10秒窗口	目的
30Hz baseline（20秒）	phase begin +15秒	+5至+15秒	控制基线
60Hz normal（40秒）	+15、+25秒	+5至+15、+15至+25秒	正常段复测
80ms long-callback（40秒）	+15、+25秒	+5至+15、+15至+25秒	长尾响应
60Hz recovery（40秒）	+15、+25秒	+5至+15、+15至+25秒	恢复检查

每个固定 cut 必须唯一绑定到距离目标不超过0.5秒的真实1Hz quality=valid 样本，且完整10秒窗口落在单一 phase 内；缺失、重复、无效或未落在该边界均判该轮参考失败，不改选相邻好窗。其余所有发布样本仍必须逐点通过 Raw oracle 和实际消费者核同。五轮合计35个预先指定的物理对照窗必须全部通过100µs端点界、0.400002ms差值界及前驱/范围合同；未选窗口不宣称物理校准。阶段方向门固定为：每轮两个长尾窗的 Jitter 都高于该轮两个正常窗的最大值，恢复窗均回到正常窗最大值 +5ms以内。阈值与窗口不得在正式 r1 开始后更改。

实现效率与验证要求

单次封存离线审核；最多25,000个FrameLifetime、500个发布样本及10,000个Fixture帧，原件只读不变。FrameLifetime按envelope sequence与end ticks建立一次索引，Metal时间排序一次；每个window以二分定位选中Raw段和时间候选，并只处理最多4,096个实际 interval。总时间复杂度 O(F + S log F + M log M + W·(log F + K log M))，空间 O(F + M + S)，无设备端开销、无网络、无完整文件多次扫描。仍沿用单次进程120秒/192MiB RSS界。

代码前先覆盖非零offset与误差不确定度边界、正确/错误前驱、selected segment外部行、段内额外Metal行、missing/duplicate/0/倒退、Raw count/序号边界及多display/source切换。改后对同一封存 r1 生成新命名 a02 诊断报告，不修改/替换 a01；用独立内存脚本复算35个固定合同窗（只作方案可行性，不计formal attempt），并对照7,235 Raw、7,207 Metal、179 samples。用相同的7,210帧/120窗基准及真实封存规模测 wall、CPU、RSS；I/O记真实测量值或 unknown。测试工具修正不改产品实现与正式计数。

状态门： r1参考仍为诊断中的partial；正式仍 37/66、Jitter 0/5。在本节实现/分离复核、attempt-03停止记录、新独占attempt文档和手机新鲜容量/证据/通道守卫全部闭合以前，不启动新正式轮、不重放r1、不进入磁盘读取率。

22. Metal 时钟域/样本段修正实现与正式 r1 复核 · 2026-10-23

本节记录第21节修正方案的实际实现与首轮结果。第21节原先将attempt-03 r1规划为诊断；随后正式计划a01及preflight amendment a12已冻结 purpose=formal 并指定唯一正式run jitter-formal-20261023-a04-r1，amendment a13/a14证明它仅发布一次、Start一次、Stop一次。本节以该正式合同和原件为准；不把a01独立报告里陈旧的“diagnostic/no formal credit”标签当作轮次性质。

实际实现

• audit_metal_reference.py按(display,target generation,source epoch,reconnect,timebase)分组Raw序号；每个发表窗使用Raw oracle实际firstSourceSequence…lastSourceSequence连续段及真实前驱，窗口外Raw/Metal行不混入该值。Metal host绝对钟映射到FrameLifetime continuous钟时使用Fixture双钟括号交集，并要求整个offset不确定区间均满足100µs端点界。
• 每轮增加固定7个阶段参考cut和相位方向门：30Hz baseline +15秒，60Hz normal +15/+25秒，80ms long-callback +15/+25秒，60Hz recovery +15/+25秒。阈值、目标cut及0.400002ms差值上限冻结；不补选相邻样本。
• raw_oracle.py为每个有效窗报告目标/显示/源代际/timebase身份字段，README.md同步实际合同；对应合成反例覆盖时钟不确定区间、序号重启、额外/缺失行和固定cut唯一性。没有改产品采集公式或产品安装包。

测试、分离复核和性能

Python 3.12 arm64下 python3 -B -m unittest discover -s internal/acceptance/jitter_1hz -p 'test_*.py' 60/60通过；git diff --check通过。真实r1 session-raw-audit-a03核对7,235帧、179样本、141 valid、尾部0；valid cut跨度140.245447秒，最大间隔1.437339秒。逐点消费者复核179/179通过：Raw oracle期望值/quality/window与Collector Metric、metrics.csv、窗口收据一致，报告Jitter coverage为valid/141，封存Report各序号边界7236相同。

固定参考窗主审计 metal-reference-audit-a06：全窗结果partial，129/141个valid窗口物理候选合格，12个未选窗口不主张参考；预先固定的7/7窗均通过，phase direction gate通过，参考Jitter与Raw结果最大差0.000001ms。独立脚本metal-reference-independent-review-a02重新核对同一7窗，结果一致；它以独立脚本实现Raw连续段、前驱、双钟区间和Metal间隔复算。更早a01保留，但它的reviewScope字符串未随正式r1分类更新。

实际封存数据规模三次配对中位基准以HEAD 6dcb6c85d4575147715206167069f88a4d5ab35e为基线：旧版wall/CPU/RSS 0.245299秒/0.240742秒/98,648,064B，新版0.281602秒/0.277673秒/102,875,136B；变化+14.80%/+15.34%/+4.29%。I/O unknown。当前一次主审计远低于120秒/192MiB硬上限；增量约36ms，属一次性本机离线复核，不进入设备热路径。分离固定窗复算用时37.589740秒、CPU37.036472秒、峰值RSS94,240,768B，I/O unknown，也在同一上限内。第一次性能报告a01把macOS ru_maxrss字节误乘1024，保留但不采纳；更正后的a02为正式性能证据。

r1 判定与后续门

r1在预先冻结的7窗参考合同与逐点Raw/Metric/CSV合同下合格，计入 1/5。它不是完整Jitter验收：总体保持 37/66，referenceAccuracyValidated=false、formalFiveRoundsPassed=false，且未宣称全部141窗完成物理校准。Frame Report v4从本轮7,235条保全事件独立派生的末窗为source-gap、valueMs=null、sampleCount=0；这是显式缺值，未写成0。线上Collector report-final.coverage另有Jitter valid、141样本；两类报告字段不混为一谈。

下一步仍为同一attempt内r2：新鲜只读核手机通道、目标App life、旧数据SHA/请求状态、设备实际剩余容量、主机剩余空间、Session活动状态和a04-r2前缀冲突；全部通过后才启动新Session、新App life和新run。Owner确认手机永不锁屏，不再询问解锁。五轮完成前不进入磁盘读取率。Cloudflare/Webhook欠项按既有授权留partial，公证暂缓，仅本机内部测试。

23. r3 正式轮次资格复核增量 · 2026-10-23

保全与通道收据

r3 使用新Session与唯一Fixture run。Mac Session completed，32个文件共27,986,054 B；CapturePlan为19项、包含Jitter，1 Hz、controlled cold launch，启动专项与截图持久化均关闭。会话原件与私有副本逐文件SHA一致、源树稳定、无符号链接。手机Fixture六件原件共1,153,796 B；请求intent/claimed镜像和单独GateStatus均与run内对应收据匹配。保全前211个手机原件（21,059,992 B）重哈希无差异，r3期间没有设备写入；结束后实际容量仍超过空间门。

Fixture在140.012565秒结束并写入7,211条记录，completed、workloadReleased与idleRestored均为true。原件、冷请求和GateStatus的独立SHA复核通过。

产品数据与冻结参考窗判定

Session seal chain与Raw oracle通过：7,239个FrameLifetime、187个samples、141个valid、未消费尾帧0。Raw oracle、Collector与CSV对全部187行的值、质量、身份、窗口及序号逐项一致；封存Report/Raw/Metric/SQLite序号边界一致，Report v4的缺失末窗保留为source-gap和null。

准备段后固定120个1 Hz验收槽为样本序号21–140；120/120均valid，没有调度跳槽，最大实际窗口间隔1.479725083秒。Metal全窗审计为partial（129/141），只表示其余窗口不主张物理参考。预先冻结的7个固定参考窗由主审计与独立脚本复算均7/7合格，相位方向门通过；没有按结果改窗。

结论： r3计入正式 3/5；Jitter整项仍未通过，保持referenceAccuracyValidated=false、referenceUnavailableConfirmed=false与formalFiveRoundsPassed=false，总体仍37/66。独立固定窗复算wall/CPU/RSS为41.463357秒/40.798501秒/95,109,120 B，低于120秒/192 MiB上限；I/O为unknown。Node v24.19.0下VitePress client/server/render全构建30.697秒，知识门66项通过、归档同步772个HTML；43条既有内容风险提示和大chunk提示保留。未发布网站。证据和逐项SHA索引保留在私有attempt-03 rounds/r3/及attempt-plan-amendment-a41.md。

下一步门禁

当前工作台有188张r3后新产生的未保存预览；已保存Session不包含截图序列。Start r4会清除这批预览。此前Owner授权的是r3开始前177张预览，因此在Owner确认如何处理这批新预览前，不发布r4请求、不启动r4 Session。确认后执行新的只读守卫和独立审查，再按原五轮合同运行r4。此增量不构成Jitter指标PASS，也不进入磁盘读取率。

24. r4 固定 Metal 参考窗资格复核增量 · 2026-10-23

采集、保全与产品数据

Owner授权清除r4开始前188张未保存预览后，唯一冻结run已完成一次Start、完整采集、Stop和自然seal。Session completed，32个文件/28,249,772 B、203样本、203.898秒；Session seal chain与独立SHA/路径集合复核通过。CapturePlan SHA-256为208907c6285fa8b77790c2973f314b2fb2010f0e570ea22583b247911b2b1d19，与冻结计划一致。

Raw oracle复核7,242条FrameLifetime、203个样本、141个valid、未消费尾帧0。固定120个1Hz验收槽（样本21–140）120/120有效，无跳槽。Raw oracle、Collector Metric、CSV的203行逐点一致，值、quality、窗口、身份及序号链无差异。Fixture耗时140.00247225秒，7,208条记录；保全独立复核通过，workload释放且idle恢复。手机既有220份、22,215,979 B证据SHA无差异，本批保全过程手机写入0。

Metal资格与轮次判定

七个预先冻结物理参考窗中，主审计和独立脚本复算均为6/7合格。未通过窗位于long-callback阶段+25秒：Raw侧有一条FrameLifetime没有对应Metal presentedTime，审计标记为unpaired-frame-lifetime。该固定窗不合格，禁止临时换窗。当前原件只证明两源该处无法一对一配对；原因未证，不能据此定论为硬件故障或软件故障。

长尾阶段因此仅有一个可用参考窗，没有满足两个长尾窗均高于正常段最大值的冻结方向门；恢复段两个窗合格。全141个valid发表窗中110个通过物理配对，Metal全窗结果仍为partial。Fixture也报告referenceQualified=false。独立资格收据最终为roundQualified=false、metricAcceptance=false；r4不计轮次，Jitter维持3/5、整体37/66，referenceAccuracyValidated=false、referenceUnavailableConfirmed=false、formalFiveRoundsPassed=false。这不是“参考缺失所以通过”的情况：已有候选参考被实际测试，但r4固定合同窗未全部合格，且没有证据证明不存在合格参考。

异常保全与下一步

Fixture保全a01继承r3的7,211条记录硬条件，因本轮实为7,208而拒绝；a02完成保全并通过独立复核。Session保全a01错误指向旧Session ID，失败收据保留；a02重新绑定当前Session并通过。Metal独立复核有一个重复启动实例因报告目标已存在而退出，另一个完整报告已读取并通过。本轮所有原始失败收据继续保留，未覆盖。

当前Perfowl工作台出现203张r4新生成的未保存截图预览，截图持久化数为0；下一次Start会清除这批预览。Owner本轮授权只覆盖开始r4前的188张旧预览。取得对当前203张的明确处理决定前，不发替代请求、不Start新Session；其后须用新鲜只读守卫和全新run重试r4。不得重放本轮或拼接数据，不进入r5/下一指标或磁盘读取率。主要证据在私有attempt-04 rounds/r4/下；公开快照不包含设备身份或个人标识。

25. 未配对帧事件诊断与独立参考候选用例 · 2026-10-23

后续独立离线复算确认：失败窗中的未配对FrameLifetime事件发生在Fixture刻意延迟约81.015125 ms的主线程回调期间、下一drawable提交前；该事件距前一Raw FrameLifetime约16.639708 ms、距后一条约66.553125 ms，而相邻Metal presentedTime 相隔约83.192833 ms。双钟offset不确定区间宽度583.333 ns。复核源文件哈希前后一致；私有mode-0600收据 gap-diagnosis-independent-a01.json 保存于attempt-04 rounds/r4/。

这证明该固定用例里FrameLifetime与逐drawable presentedTime的覆盖范围不同，但不能确定FrameLifetime代表重复扫描、其他Surface或哪类系统行为；不归因为硬件或产品故障。r4依旧不计轮次，正式Jitter 3/5、整体 37/66，referenceUnavailableConfirmed=false、referenceAccuracyValidated=false、formalFiveRoundsPassed=false。

本机只读工具清单可见 Frame Lifetimes 与 Display 仪器；完整Animation Hitches配置的既有5秒探测峰RSS为933,773,312 B，超过805,306,368 B硬门，故不重试同一设置、不放宽上限。下一候选用例先做最小Frame Lifetimes trace配置的短时工具/导出准入；记录RSS、trace字节数、停止/导出时间及原始逐帧字段。准入通过后，以新独占attempt、新Session和新Fixture run并行运行既有140秒LabP95配方，复用原固定七窗、双钟不确定度、100 µs端点界、0.400002 ms Jitter差值界与方向门；要求所有入选FrameLifetime端点和前驱唯一配对、无额外或缺失行。仪器必须提供可导出的实际逐帧时间及目标/显示身份；仅有hitch汇总、图形轨道或vsync频率不够。候选不通过则保留原始失败trace并拒绝，不改门槛。

同步新采集前仍须取得Owner对当前203张未保存预览的处理决定并完成新鲜守卫。本诊断没有手机操作、新Session或新Fixture采集。用例细节与证据范围。

Frame Lifetimes 独立仪器准入 a01 / 单进程方案增量 · 2026-10-23

一次只含 Frame Lifetimes、面向全部进程的Blank模板2秒录制，在开始后0.891658秒由xctrace以SIGABRT结束；部分trace为53,248 B，无法导出TOC（Document Missing Template Error）。系统崩溃报告显示XRTapAgent stop itinerary栈，但根因未证。进程树RSS、trace字节、时间和主机/设备空间均在门内；这是当前全进程录制配置失败，不能归因于硬件或产品，也不构成参考不可用确认。原件和独立复核保存在私有 20261023-jitter-frame-lifetimes-qualification-01/。

为减少全进程目标集合，下一步为单独的 Frame Lifetimes 准入attempt：在新鲜设备守卫证明唯一目标App进程PID稳定、所有Lab run终态且workload释放后，仅对该PID执行一次2秒 xctrace --attach 记录。沿用805,306,368 B RSS、134,217,728 B输出、45秒总时限和10GiB/预计新增量两倍空间门；使用全新trace路径。该窄scope测试只检查仪器连接、停止、trace可读、逐帧表/字段及资源，不启动产品Session、不运行Fixture、不改参考或指标门，也不计formal轮次。失败时保留原件并停止，不重试该配置。

当前正式Jitter仍3/5、整体37/66，r4不计轮次，referenceAccuracyValidated=false、referenceUnavailableConfirmed=false、formalFiveRoundsPassed=false。当前203张未保存预览不清除；正式同场采集前仍需Owner决定其处理方式。

Frame Lifetimes PID attach 结果与进程名准入方案 · 2026-10-23

attempt-02用新鲜DVT读取到的稳定目标App PID做单进程attach；xctrace报告找不到该PID。前后DVT读数确认PID未变化。输出监视器同时遇到临时trace路径消失竞态，故没有留下trace，且本尝试的RSS、wall和输出峰不能认证。独立复核a02确认手机22个受管Lab run目录摘要和workload状态、Mac Session集合与设备容量门前后不变；全手机文件系统写入状态保持unknown。完整复核见私有 20261023-jitter-frame-lifetimes-qualification-02/independent-review-a02.json。

后续若继续该候选，须另建attempt并修复监视器竞态，使用Xcode CLI支持的进程名参数 --attach <name> 附着到新鲜DVT身份守卫确认的单一目标App可执行文件。新trace限2秒，沿用805,306,368 B RSS、134,217,728 B输出、45秒时限和实际容量门；不启动/结束App、不启动Workbench、不发Lab请求。a01全进程配置和本PID配置均不重跑。正式Jitter仍3/5、整体37/66，不改变r4结论、公式或参考状态；仍未进入下一指标。

Frame Lifetimes 进程名 attach a01 执行与独立复核 · 2026-10-23

attempt-03按新鲜守卫确认的目标App进程名执行2秒Frame Lifetimes录制。Xcode CLI帮助确认--attach <pid|name>是受支持语法；本次命令在0.651478秒后以exit code 19结束，stderr为Cannot find process matching name，未生成trace。守卫记录xcdevice目标可用、Lockdown/DVT与签名身份检查通过、目标进程存在且生命稳定；xctrace设备状态仍为connecting。这说明工具无法在本次状态下解析该名称，不足以判定硬件、产品或参考源问题。

独立复核a03验证了守卫收据绑定、进程生命、22个既有run终态及释放、Mac活动Session为0、真实容量门、无新增受管手机写入/run/Session、预览变更为0。录制峰RSS为103,383,040 B，退出峰RSS为90,947,584 B，输出峰为4,487 B，墙钟0.651478秒；监视器无异常，预算均通过。未生成trace，故未达到仪器准入。全手机文件系统写入仍为unknown。私有证据及mode-0600分离复核收据位于/Users/qiance/Perfowl-NewHost-Recovery/20261023-jitter-frame-lifetimes-qualification-03/。

不重试该进程名配置，也不重跑此前的全进程与PID配置。当前仍没有一条参考不可用确认：Jitter正式3/5、整体37/66，referenceAccuracyValidated=false、referenceUnavailableConfirmed=false、formalFiveRoundsPassed=false。203张未保存预览保持原样；正式配对采集前仍须取得处理决定并执行新鲜守卫。下一动作是只读诊断xctrace进程解析与设备连接状态；只有通道/目标可见性出现新的独立证据，才评估新的不同配置。不得进入r5或下一指标。

Frame Lifetimes Instruments GUI attempt-04 验证增量 · 2026-10-23

新鲜只读守卫通过后，Instruments GUI仅配置Frame Lifetimes，录制停止后的界面时长为4秒，并显示 No Graphs / No Data。xctrace export可读取coreanimation-lifetime-interval的16个字段定义，但没有逐帧事件行；字段结构可读不等于存在可用参考数据。

本次独立观察器墙钟45.059414秒，超过45秒硬上限0.059414秒，因此本配置不准入且不重试。观察峰RSS为205,406,208 B；观察器停止时输出峰9,248 B，但随后Trace保存未纳入该观察区间。最终Trace为7,184,430 B / 84个文件。手机容量后读数较前置守卫减少1,724,416 B，无法归因；全手机文件系统写入仍为unknown。私有分离复核为attempt-04 independent-review-a01.json。

工作台实测仍有203张未保存预览；Owner授权清除的188张与当前数量不一致，全部保留且没有启动会清除预览的Start。attempt-04结果及E4证据边界见独立准入记录。Jitter仍3/5、整体37/66，r4不计轮次，所有参考与正式五轮标记保持false；不进入r5、下一指标或磁盘读取率。

26. Display 仪器替代候选资格方案 · 2026-10-23

Owner最新授权：测试数据可由我自主判断和清理，不必因测试数据再次请求批准。该授权只覆盖可识别的测试数据；封存Session、Raw、Lab原件、失败Trace及保全副本仍依证据规则保留。当前203张未保存预览保持原样，本次候选资格不启动会清除它们的Workbench Start。

Frame Lifetimes GUI attempt-04因45秒资源观察墙钟超限而未准入，不重试同配置。替代候选改为仅配置Instruments Display 仪器。Apple文档说明该仪器记录显示与垂直同步事件，但不预判其事件行、时间字段、显示身份或独立精度；完整测试用例与固定门见Display候选准入方案。

本次只运行一次35秒资格用例（新jitter-displayqual-20261023-a01前缀），不启动Workbench Session、不计Jitter轮次；旧r4与全部旧数据不重放、不拼接。新鲜容量、通道、目标生命、历史SHA及run冲突守卫通过后，才执行唯一Display Trace。只有导出真实事件行并与Fixture presented记录满足既有时间／唯一配对门，才另立全新Session与140秒正式r4复测方案。Jitter仍3/5、整体37/66；无论本次候选成功与否，都不直接确认为参考不可用或进入下一指标。

27. Display PID attach 启动失败与设备级资格方案 · 2026-10-23

attempt-05 a01在record-start通知前以exit code 21失败，原因字符串为 Cannot find process for provided pid。DVT在前置和后置只读守卫中均观察到同一稳定目标App进程生命，因此现有证据仅说明这条 xctrace --attach 路径不能解析该目标；没有启动Display录制、没有发送资格URL、手机写入0、新run 0、Trace 0、活动Session 0。资源观察器记录的是失败启动阶段18.193643秒，峰RSS240,222,208 B、probe输出峰10,490 B，不是录制资源证据。

a02只读守卫因要求可用字节逐次完全相等而拒绝，守卫条件超出方案冻结空间门；a03/a04使用“Data/Disk总容量一致且两次可用空间样本分别满足10GiB及双倍预算”后通过。a05后验确认旧Lab 132文件/23,301,593 B、22个旧run终态释放、旧清单摘要未变，手机写入0、无新run/Session，203张预览未变。

仅拒绝attempt-05的PID attach方式；本次没有事件数据，不能准入Display，也不确认参考不可用。新建独占的设备级 --all-processes 资格方案及run jitter-displayqual-20261023-b01，沿用Display-only模板、40秒录制上限、35秒Fixture资格请求、45秒观察器和既有事件配对门：设备级资格方案。当前Jitter仍3/5、整体37/66；不进入r5、下一指标或磁盘读取率。

28. Display c02 资格及设备服务恢复观察 · 2026-10-23

c02唯一35秒资格run完整封存，六件239,883 B、1,502条record，workload释放且idle恢复；旧23个run及请求/gate均SHA不变。Trace实际0.343416秒、断连结束，2,475 B导出只有时钟/显示元数据各1行，逐帧事件0；独立保全审查通过但参考资格失败，正式轮次+0。完整数字、资源门、解析修正与原始时序证据边界见冷启动方案的c02增量。

Owner授权自主清理测试数据后，在95个Session全终态时退出Perfowl以释放DVT预热连接；203张内存预览清除，保存数据不变，不再等待清理授权。新鲜只读诊断随后观察到CoreDevice隧道connected、实际详情/App查询成功，尚不代表录制恢复。下一步按无控制动作短录制方案验证通道；Jitter仍3/5、整体37/66，参考不可用未确认，不进入r5或下一指标。

2026-10-23 · e01与新无参考五轮决策增量

正式37/66；旧Jitter参考协议3/5及r4失败保留。e01有28条非元数据事件，但实际Trace仅0.331324秒并断连，不能覆盖10秒窗；资源观察完整通过。当前环境没有可用完整独立对照，已按Owner政策冻结新无参考五轮，当前0/5；五轮均无异常后才计38/66并标记，物理精度不声明通过。保存原件保留，无需用户操作；网站/Webhook欠项partial，公证暂缓。 当前参考决策与新五轮合同。新独占五轮从0/5开始，尚未采集；不修改旧3/5、r4参考失败或历史门槛。

正式验收增量 · 2026-10-23 · 新完整五轮5/5

正式38/66、剩28项。Jitter全新无参考协议5/5通过，固定600/600槽有效、888条Raw/Collector/CSV逐点一致，五轮长尾与恢复方向及SHA保全通过（E4）。标记NO_REFERENCE_ACCEPTED_OWNER_POLICY，物理精度未校准；旧3/5及r4失败不改。下一项按原顺序为平均FPS。网站/Webhook及远程同步欠项单列，公证暂缓，仅内部测试。 五轮证据与交付。前述0/5、3/5及失败资格均为当时历史事实。