外观
数据质量语义与 0 值判定准则：捍卫测试数据的科学与诚实
在自动化性能测试与日常评测中，最容易诱导误判的莫过于**“伪造连续性”**——为了让图表曲线看起来连贯好看，将未采集到的数据、系统预热期数据或外接电源状态下的异常数据，全部硬编码填充为“0”。
Perfowl 从创立之初便确立了**“数据诚实底线”**： 不知道、尚未就绪、物理不适用与真实为 0 是四件截然不同的事实。在 Perfowl 的监控图表与导出报表中，每一个数值都严格携带明确的质量语义（Quality Semantics）。
1. 核心质量语义字典
| 质量标签 (Quality) | 物理含义与触发条件 | 界面呈现策略 | 典型场景示例 |
|---|---|---|---|
valid | 数据完全有效，满足采样时基、身份绑定与计算门禁 | 正常绘制数据点与曲线 | 目标 App 稳态运行时的正常 CPU/内存/帧率点 |
candidate | 基于系统原值或已归档公式生成的候选数值；质量标签本身不证明真机 E4、跨源校准或长期稳定性 | 按对应指标的门禁呈现，并保留候选标识 | 启动端点值已计算，但端点身份或稳定性尚待独立验收 |
warmup | 基线预热期：差分算法或首帧间隔需要前置参照点 | 留空（不连线，不填 0） | 计数器采样首点、启动后首个 FrameTime 间隔点 |
missing | 数据源缺失：当前时刻未收到有效数据包 | 留空或断线呈现 | 锁屏、进程退出、网络接口临时无响应 |
counter-reset | 计数器归零重置：累积计数器发生回绕或进程重启 | 留空并重新触发 Warmup | 目标 App 闪退崩溃后重启拉起 |
not-foreground | 非前台状态：被测应用已退入后台或处于锁屏 | 显式置空，曲线平滑中断 | 目标 App 切到后台时，前台 FPS/GPU 自动置空 |
external-power-connected | 外接供电保护：设备插在 USB 数据线上处于充电态 | 显式置空横杠（-） | USB 模式下电池放电电流与整机放电功率置空 |
not-applicable | 条件不适用：特定架构或现代系统未触发此流程 | 显式标注 N/A | 纯 SwiftUI 应用未触发 AppDelegate 传统生命周期 |
2026-10-03 · 质量与证据是两条轴
candidate 描述这一数值的质量状态，E1–E4 描述支持结论的证据等级，两者不可互相推导。同一指标可以有已留存的历史真机观测，同时当前版本的新增采集路径仍只有 E2 验证；要宣称其稳定性提高，仍需针对当前产品路径完成独立的真实 UI E4 对照。missing 表示未取得可用值，不能写成数值 0。App Launch Total 当前口径与本次同步记录分别说明具体边界。
2. 0 值的合法性与判定准则
在质量分析中，何时可以记为“0”，何时必须保持“空值（null）”？Perfowl 制定了严密的判定铁律：
2.1 允许作为合法 0 的场景（真实的零负荷）
必须同时满足：目标身份明确 + 采样窗口有效 + 系统底层明确返回 0：
- 目标应用在当前采样窗口内完全没有网络收发，Socket 增量字节确实为 0；
- 界面处于完全静止无操作状态，且无任何定时器重绘，Core Animation 新帧数为 0；
- 在多核 iPhone 上，某个指定的能效小核当前负载确实为 0.0%。
2.2 绝对禁止写成 0 的场景（必须保持空值 null）
- 采样刚开始的首个采样点（缺少前值基线，绝不能填 0 引发假卡顿）；
- 目标 App 已经退入后台，将此时的 FPS 显示为 0（会严重拉低前台运行的平均 FPS）；
- 手机通过 USB 连接电脑，将电池放电电流显示为 0 mA（违背物理常识）；
- 目标 App 发生了崩溃闪退，将崩溃期间的 CPU 补为 0（掩盖了异常现场）。
3. 为什么严禁“填 0”？一个典型缺陷误导案例
在早期的测试实践中，曾有测试工具在 App 切入后台时将 FPS 自动补为 0。
- 后果：用户在前台流畅操作了 50 秒（60 FPS），随后切入后台静置了 50 秒（被伪填为 0 FPS）；
- 致命误导：导出的测试报告显示该 App 的“平均 FPS”仅有 30 FPS，直接被验收平台判定为“严重不合格”！
- Perfowl 的严谨对策：切入后台瞬间，前台指标标记为
not-foreground并彻底断线。前台运行的平均 FPS 依然是纯净的 60 FPS，真实还原前台交互品质。
4. 独立参考的时间与状态证据
采样起点、某次系统接口的读取区间、数据送达电脑的时间，是三个不同事实。参考文件有一个时间戳，不代表同一行的所有字段都在那个时刻被读取；用最近点、接收时间或插值补齐，不能自动变成数值准确性证据。
独立比对应同时核对目标身份、scope、原生时钟域、对应来源窗口，以及参考每次读取的begin/end区间。一个值由多个接口构成时应保留每个接口的边界，不能将它们假定为同时的快照。计数器差分还需前后两次各自的区间、重置和首点缺失；仍缺窗口的数值保持候选，不记为校准通过。
自有参考的apiReadIntervals把原接口返回状态和逐次mach读取区间分开保留：complete只表示八个声明观测槽齐备，不证明八次读取成功；reportedStatus=null表示状态未知，不能读成成功或0。某些task读取的状态含字段布局校验，不等于未经处理的内核返回。时钟顺序、值的形状、身份/窗口与独立误差，仍需分别验证；状态成功不替代这些门。
这不改变产品的质量词表，也不表示现有54项已获得数值校准。参考实现与证据边界仅有E2主机/编译证据，真实设备和五轮稳定性需另验。
累计计数率的读取不确定性
独立参考累计值的前次读取区间为[a,b]、本次为[c,d]，需严格c>b。两个实际读取时刻未知，但其间隔在[c-b,d-a]内；按原生时间基准转换后，非负增量ΔC对应率范围为[ΔC/Δt_max,ΔC/Δt_min]。应保留精确上下界，不选中点作为真值。任一组件计数重置、API状态未知/失败、时间逆序、首点缺previous或跨区间重叠，均不填零或跨缺口补值。
这个范围只反映API查询时间不确定性，不替代内核累计值的实际更新窗口、产品来源身份或质量验证。两个系统接口形成的gauge 也保留两组读取边界，不假定同时快照。G50消费者仅E2工具与本地参考签名验证，尚无手机部署或产品同窗口精度通过。
参考范围的保守数值容差
当独立参考只确定r∈[L,U]时，固定容差t(r)=max(A,R×abs(r))（A≥0、0≤R<1）不能再加上参考不确定性。产品值x须对范围内每个可能r满足abs(x-r)≤t(r)，其允许交集为[U-t(U),L+t(L)]；交集可能为空。不能使用更宽的[L-t(L),U+t(U)]、只选中点或一个有利参考值。多core每项分别判，不能平均掉坏项。G51全54数值门保留原metric容差、原Float精度和缺槽，仅E2数学验证。
数值在容差内不证明参考本身正确、原scope/来源窗口一致或固定五轮连续有效。申报相同单位/算法也不替代真实源身份。对于枚举，即使原数值容差允许相邻代码，代码同一性和语义映射仍要单独验证；source-native 成本/原温度负值的合法性也由原来源合同决定，不能由误差数学反推物理含义。
软件对账精度与独立参考误差须分开
以原单位解释容差，再评估参考的测点/时间/不确定性；同源数值逐字复制或公式精确重算不是物理精度。若relative=0、absolute=A，参考范围[L,U]必须至少满足宽度不超过2A才存在保守允许交集；设备/仪器规格未知就保留准确性待验。USB输入与电池侧、外壳与电池传感器不是相同测量对象，通信方式不充当参考仪器。
G52审计发现原帧时间方案文字0.5µs与机器5e-7ms（0.0005µs）相差1000倍。它是规范冲突而不是产品实测误差；旧规范、旧报告与机器阈值保留，当前依旧不宣称校准，后续统一须明确新合同与变更影响。
本页版本记录
| 日期 | 修订 | 来源 |
|---|---|---|
| 2026-10-06 | 登记帧时间文字/机器容差单位矛盾；区分对账精度和独立参考测点/不确定性，原标准保持 | G52 |
| 2026-10-05 | 明确参考范围须按全范围原容差交集判定；数值关系/枚举同码与真实独立精度分列，原阈值与指标语义不改 | G51 |
| 2026-10-05 | 加累计计数率的严格API读取上下界；区分legacy sample-start算术与时序准入，未改产品公式或质量词表 | G50 |
| 2026-10-05 | 区分采样起点、API读取区间与接收时间；参考完整/状态/精度分别判定，不改变指标公式或质量标签 | G49 |
5. 相关指南深入阅读
2026-10-06 G58 · 参考运行成功与产品校准分开
自有参考50.1.0在原设备A实际产出181行逐API区间，每个API reportedStatus0；六gauge181/三CPU与context delta180可做来源自身算术，首previous缺点保留。API成功不证明同scope系统语义、产品采样窗口或独立精度。Dense/Clock完整尾与报告缺槽0只覆盖它们自己的来源，7201提交/呈现配对只覆盖本surface；不能提升成产品/整机连续100%。完整54账本及其它本工具缺槽保留，产品五轮/原数值误差仍pending。实机来源与范围。
2026-10-06 · 呈现时间与回调时刻的参考边界
墙上时间、媒体呈现秒、原生ticks与宿主收到消息时刻不是同一个量。已有Date墙钟→mach读界不能直接用于Metal呈现时间；呈现回调里记录的mach ticks表示回调发生时刻，不是画面呈现时刻。独立参考应分别记录真实呈现秒和该媒体时钟的原生读界，保留断点/不确定范围；参考记录完整并不自动证明与产品同scope、同窗口或数值可信。默认关闭的媒体原生读界与精确消费者已完成E2本地验证，但当前手机未部署；全54项校准与五轮100%仍未完成。来源与实施门。
2026-10-06 · 媒体时钟观测交集不是连续时间映射
独立媒体读取用原生ticks前后界，binary64量化以半ULP建模，候选偏移为[begin×numer/(denom×10^9)−m−ULP(m)/2, end×numer/(denom×10^9)−m+ULP(m)/2]；逐点交集为空、改变时间基、漏槽/断点、错schema/类型或不完整封存就拒绝。半ULP不是API硬件误差界，相容也不证明观察间恒定offset、产品同scope/同window或指标准确。sourceWindowBound与independentAccuracyPassed保持false，不插值/最近点/hold-last，不用回调receipt代呈现。原Date钟与UTC算术不变。实际来源、控制与成本。
2026-10-06 · 本地参考包身份与实机来源分别验收
源码编译、签名DER/entitlements、独立IPA解包与安装元数据是不同事实。CODE_SIGNING_ALLOWED=NO不保证编译目录没有旧签名附件；构建参数接收也不保证固定plist版本已更新。只有新clean包的实际metadata/全树与签名核对才讨论候选身份，不能把本地包ready或旧安装版本当新参考实机数据。62.1.0仅本地包就绪，原设备仍50.1.0、当前退出unknown；sourceWindowBound/independentAccuracyPassed保持false。本批来源与边界。
Sysmontap 进程片段目标准入 · 2026-10-06 G74
共享CPU、Physical/Real/Virtual Memory、线程数、两种调度率和两种磁盘率共9项。显式目标只按整数/字符串目标键选行；键缺失、行内pid矛盾或非法行时，对进程片段显式发布9项missing /null以替换旧值，不从唯一其他行借值。不存在Processes的系统片段保持原行为、不冒充目标丢失。Realtime辅助累计计数在缺目标片段清空，不继续显示旧计数。
无目标的历史单行兼容只保留身份未证的非可信诊断；Physical Footprint和四项差分率不发布身份未证的数值。其他4项gauge可保留identity-unverified数值但不能视为有效候选。正常目标的8项其他公式与计数器差分/时间窗口/基线保持；此次不将候选升级为独立准确性通过，不改变66项/非启动54项台账。详见G74方案。
2026-10-16 · 关闭边界计数与消费者竞态（限定场景验证通过）
表现与范围：帧订阅停止时，已送达=已消费且实时队列为空，却记录undrainedAtClose=1。本次E4原件出现1072/1072帧、零drop而剩余1；E2确定性调度五次复现同一矛盾。旧关闭方法在cancel/join pump之前取队列深度，等待期间消费者仍可能完成一个已经被唤醒的取件，导致残留计数过时。这是关闭快照时序问题，不是静止必丢帧或所有缺值已解决的证明。
判断与避免：保留送达/消费/drop/实时pending/关闭剩余原始字段分别核对；先停止生产者并join，再同步采样实际队列深度、扣除本订阅自己的terminal控制项。不能强行把剩余填0或只用两个累计数相等消除真实积压；也不能把本地零drop外推到系统源完整性。测试应同时覆盖消费者已经被唤醒但未恢复、真正未消费的积压、terminal尾项及重复关闭。
当时状态：本节首写时修复先落方案，产品软件/新包E4尚待（结果见下方同日增量）；历史数字不回写。方案、复现与后续证据。
同日验证增量：关闭相关126项软件回归通过，嵌入177代码5项通过；确定性旧/新各5000次旧全误记1、新全0，真实积压与溢出负控仍可见。内部177在G五个全新正常UI轮中共5290实际帧全消费、pending/drop/关闭剩余均0、正常Stop durable。结论仅覆盖本次关闭计数修复与受控静态/动画恢复，不证设备端完整性或全App永久稳定。历史F2失败与1072/1072/剩余1原件保留，不回写。
2026-10-17 · 微基准失败、线程CPU与端到端延迟分别解释
表现：相同帧过滤代码，孤立小集合通过，完整集合的50000噪声过滤wall651.082ms超过500ms；全测试方法线程CPU383.453ms，GC仅1.332ms，不能直接认定解码器CPU超标或GC是主因。全方法CPU包含过滤CPU，故同窗过滤至少约267.629ms未在该线程CPU执行；这只是停等/调度的下界，不能识别具体抢占者，也不保证实际采集不会受到影响。
复现与避免：保留原完整失败；固定一次小集合对照和一次完整诊断，记录wall、thread CPU、GC与解释器观察状态；性能诊断与编译/网站构建串行。核热路径源码同一版本，不通过放宽阈值、关闭GC或选择最快轮来抹除失败。尚缺因果时不盲改产品；数值/队列/丢失的真机门仍单独验收，离线7200帧零drop不等于系统源完整性。
证据边界：上述为E2宿主诊断，不是新E4；本次同标志Release后续构建131.674秒成功，前180秒冷尝试超时仍保留，后续成功不反写成冷构建131.674秒。已验指标源码闭环与全产品性能风险应分栏报告，不能互相替代。固定对照与证据。
本指标非到期不等于缺源 · 2026-10-18
上下文切换率1Hz的新发表政策明确区分not-due与missing：全局500ms样本不删；只有此指标非due时null/not-due，图形略过但导出保留，既不算有效点也不算丢点。due无新源仍missing/断线，固定分母不能按事后缺值缩小。CPU等不使用此省略规则；不得将未知空值自动标非到期。数值公式、source TTL与显示间隔分别登记，1秒显示不延长1.5秒来源新鲜期。本场景五新轮限定E4，非通用所有指标的空值填充机制。来源。
来源节拍不等于产品发表节拍 · 2026-10-18
表现：来源平均约0.52秒更新，若产品要求每0.5秒都取得真实新值，会出现缺口；重复缓存只能把曲线画连续，不能增加来源证据。
机制与避免：常规产品默认1000ms发表，来源仍可按500ms或原生事件高频采集；原始差分用设备时间，来源TTL用host receipt，ready锚定发表网格分别记录。一个原始来源窗口最多发表一次；来源缺失继续missing，合法0、not-due和真实断线不混淆。
验证方法：检查正常GUI direct/prewarm的真实argv、Session计划及Wire元数据；用旧半秒/新全秒网格兼容控制与实际模型/CSV/JSONL逐点核对，再以新真机固定机会表验收，不能隔行筛旧点或挑相位。
范围：当前软件E2与中断1Hz四完整轮E4成立，专项仍4/5未验收；FPS逐帧及启动事件不强造每秒事件，历史已验指标不重开五轮。来源TTL/原始公式未因调发表节拍而放宽。方案 · 结果。
快机上的历史对照必须先证明负载前提 · 2026-10-18
表现：ARM恢复的离线软件回归中，历史per-event调度模拟器在120倍压缩生产时钟下仍能跟上，P50仅0.425ms，未形成测试声称的积压；同文件当前策略绝对门通过。旧机曾出现积压，不代表相同名义频率在每台宿主都会形成同一竞争条件。
判断与避免：先保留原失败，分开检查“对照是否形成有效压力”和“当前实现是否达到绝对门”。需要共享事件循环压力时，在两路径加入同样、固定且有界的竞争工作，保留积压前提、送达/drop/尾段和改善门；不删断言、不调参数直到通过，不将对照模拟器不足直接判为产品数值错误。性能测试与编译、站点构建串行。负载配置、宿主、原始分布、CPU与wall均须留下来源。
证据边界：当前定位为E2软件实验负载问题，固定竞争负载修复后的回归结论见来源批次增量；不能由此升级任何指标E4或改变27/66。新开销观察也须保留全部样本与预定热身界线，不能筛掉坏帧后缩分母。对应开发记录：新机attempt及恢复验证。
| 修订 | 日期 | 内容与来源 |
|---|---|---|
| 宿主压力对照补充1 | 2026-10-18 | 补充快机上的对照负载前提、等负载与不筛样方法；同上恢复devlog，E2限定。 |
exec前后资源高水位不能只看退出值 · 2026-10-18
表现与已验证机制：验收执行器在同PID exec释放SDK堆后进入标准库离线复核，诊断的SDK阶段峰值104,431,616B，而exec后wait4退出值100,974,592B；仅使用退出值会漏掉前镜像峰值。外层实时峰值104,300,544B也可能因采样错过短峰，不能独自替代高水位。该事实限定当前macOS/执行器，不能外推所有平台内核行为。
判断与避免：SDK阶段在关闭全部服务后、exec前记录自身高水位，最终收据取前后阶段最大值，并保留外层live/exit原始值。总wall与192MiB预算贯穿两阶段；capture成功仍须离线完整原件、导出语义及数值核对后才算轮完成。失败不重新Start或Stop，不以释放堆掩去已超限事实。
证据与限制：a01第3轮201,834,496B资源失败完整保留，不由离线解析成功改判；新a02诊断与当前一轮支持修复的环境适用性，不代替完整五轮验收。软件对照未复现原峰，SDK堆贡献仍非唯一根因定论。来源：修复方案与实际证据，E2资源核对/E3执行环境。
| 修订 | 日期 | 内容与来源 |
|---|---|---|
| exec资源连续性1 | 2026-10-18 | 分阶段高水位、外层采样与总预算分别保留；同上a02方案。 |
构建资源证据：可回收对象、RSS与完整功能分别核对 · 2026-10-19
表现与已验证事实：完整站点索引序列化后，生成器闭包可能继续保留MiniSearch对象；失败Error的惰性stack也可能保留生成函数。解除引用与WeakRef控制可证明对象可回收，但实际major GC后heapUsed下降数百MB时，RSS仍可能只降约32MB，整棵构建进程树继续超预算。不能把heapUsed、单进程峰值或退出时已回收CPU当总资源门。
判断与避免：保留失败收据，分别核对象可达性、宿主RSS与全树资源；将已完成且不再共享对象的阶段串行放入短进程，可在退出时释放阶段资源。通信只传下阶段真正消费的元数据，已落盘代码/资产不再复制进checkpoint；保留SHA、阶段顺序、总超时与首失败停止。固定第三方源码的适配必须锁版本、源SHA和替换锚点，漂移即拒绝；不能直接改node_modules后隐瞒差异。
完整性与边界：采用同输入小站对照、按实际URI/字段/词频归一确证的搜索插入顺序差异；不能随意忽略不同文件。真实全站另核预期页、全部索引与浏览器搜索/延迟加载图功能。当前小站有额外耗时与RSS，全站15.003秒/聚合1,507,000,320B满足原预算；仅当前Node24.19.0/VitePress1.6.4的E2，不能推广任意依赖升级，也不证明线上已发布或任何真机指标通过。来源：完整方案与结果、生命周期失败。
| 修订 | 日期 | 内容与来源 |
|---|---|---|
| 构建资源证据1 | 2026-10-19 | 增补对象回收/RSS分离、阶段元数据及真实规模完整性核对；E2限定，来源同上。 |
软件测试证据：编译、装载和实际方法执行分别核对 · 2026-10-19
表现与机制：独立Swift命令可以成功编译产品Core，却尚未找到XCTest模块；只补框架路径还可能仅解析Objective-C头、缺Swift断言overlay。平台专用入口不存在、动态装载找不到XCTestCore也都发生在测试方法执行前。本批实际遇到这些前置失败，不能把它们记为断言失败，也不能把Core构建或测试二进制生成当作方法通过。
判断与避免：从当前SDK读取真实Frameworks、Swift overlay及PrivateFrameworks路径，使用本平台测试套件入口；固定产品/测试源码与复用产物SHA，分别保留编译和运行收据、峰值、退出状态及实际executionCount/failureCount。强制预期方法数，避免空套件exit0误报；前一失败及超限不因后续成功被覆盖，不提高门槛掩盖失败。
范围与限制：当前Mac独立cadence类7方法/0失败、运行15,597,568B通过E2，产品与测试源码未改，手机调用0。该结论只支持对应图形质量处理软件控制，不是全回归通过、手机兼容性或指标五轮验收。来源：写入率方案中的窄复核与原失败记录。
| 修订 | 日期 | 内容与来源 |
|---|---|---|
| 软件方法执行证据1 | 2026-10-19 | 区分编译/装载/执行、预期方法数与源码/产物SHA，E2限定；来源同上。 |
增量 · 2026-10-20 · 资源释放需要可核实返回值
测试工具的线程finished只描述执行结束；发布workloadReleased还需核对其拥有资源的实际关闭结果。自有Lab19接收器将listener/client每个close的返回码和errno写入独占收据，worker结束且全部返回0才closed；未确认关闭保持失败，避免在未知EINTR后重复close而误关复用的FD。消费者须拒绝“closed=true但close返回非零”的自相矛盾收据，即使所有文件SHA重新核同；本批已做此软件反控，未在OS层制造真实close失败。
超时应使用单调时间及有界唤醒；完整进程树采样聚合RSS与time -l单进程高水位应分别标明，不能将后者冒充前者。协议工具还应记账已收但未准入的有界前缀，不能用合法正文计数掩盖已收到的其他字节。以上适用于拥有明确FD/worker生命周期的内部工具，E2源审/host控制不替代手机或产品资格。来源：Lab19实现与复核。
2026-10-20 · 覆盖安装的意图、结果与数据保全分开记录
问题与机制：安装请求返回成功、安装元数据版本改变、旧数据源SHA一致和资源关闭成功是四项独立事实。若写入意图仅在内存，进程中断后无法判断请求是否已发送；若最终close错误不影响completed，就会把未完整收尾误记为成功。文件名/size/mtime一致也不能替代当前源SHA。
判断与避免：写入前先固定输入和候选SHA，以独占新文件持久化一次意图并fsync，再dispatch；结果未知保留unknown，不能自动重试。每call追加日志、阶段原子checkpoint，保持installed事实与completed判据分离；提前关闭与最终关闭都纳入门禁。先全源流式SHA与独立host副本核同，再覆盖安装；覆盖后重新读取旧源SHA，并完整枚举树、核metadata与关闭状态。历史副本只作存储复用候选，实际源不符就停，不按旧stat跳过当前源读取。
范围与证据：当前安装器16个软件控制验证持久化失败/重复意图/未知结果/源漂移/关闭失败/树漂移等分支，20000-call追加日志基准约0.067秒、相对无日志增加约0.060秒，E2；该基准不等于手机吞吐或I/O峰值。2757文件/3879024186B当前源读取与独立副本SHA核同属于E3读取/E2保管；安装和指标资格须另以实际收据判断。来源：发送率方案。
采集启动许可与上下文交接 · 2026-10-24
监视器已启动、请求已发布和应用已显示Ready，是不同时间的观测。模型往返或上下文交接可能使请求或监视器先过期；旧的Ready截图或guard成功收据不能授权过期后再开始。TinyJank本次a02因先超时后Start而失败；a03及a04的启动前保护拒绝或许可过期没有形成有效新轮，均完整保留、不补轮拼接。此为已验证的执行衔接问题，不是手机硬件或指标公式缺陷证据。
可复用的执行方法：先确认工作台空闲就绪，再将准备、等待原进程终态、启动监视器及只读guard放在同一有界调用；guard使用单调时钟验证准备年龄、请求余量和监视器新鲜度，给出绝对启动截止。紧接的唯一UI操作先取新鲜状态并核截止，再执行Start并记真实时间/次数。超过截止则不点击，保全请求与全部失败数据后建立新独占attempt。不能通过放宽数值门、复用前轮或重发旧请求抵消编排失败。
本方法仅保护测试执行时序，未修改产品公式、质量词表或手机请求期限。隔离反控通过为E2；本次运行收据及失败现场为E4执行证据，均不等于当前指标正式验收。来源：TinyJank方案与带日期实施增量。版本历史增量：2026-10-24，新增启动许可、真实UI时间及交接过期处理。
交互回执失败的层级归因 · 2026-10-26
表现与机制：主机桥接器读到EOF或等不到回执，并不能证明手机系统服务失效。以heredoc提供启动代码后exec正式Runner，可能使Runner继承普通文件stdin；终端canonical模式也可能阻断大型单行AX JSON。前者可用活动进程fd0类型取证，后者可用真实PTY及相同桥接读取器对照复现。
判断与避免：在任何合同预留或设备动作前要求交互TTY；仅在进程上下文切换有界非canonical输入，退出恢复终端配置；以直接脚本或python -c入口保持终端stdin。协议仍校验nonce、动作、完整消息和原始AX，不能用放宽超时或伪造回执补偿。EOF、主机回执超时、Apple RPC错误应分别记录；没有相应证据时不外推根因。
适用范围与限制：a06活时fd0普通文件证明主机启动错误；a05仅有主机回执超时，具体stdin原因未证。真实PTY 8/64/256KiB完整消息、非TTY拒绝与正常/异常配置恢复通过；旧canonical对8,208字节超时、新模式完整接收约1.4毫秒，均为E2，不代表指标通过或手机吞吐。Darwin重入canonical自动设置的PENDIN属于内核输入重处理瞬态，配置恢复审核需区分该位。来源：网络方案与验证增量。版本历史增量：2026-10-26，新增输入通道前置检查与分层归因。
2026-10-26 · 跨工具转抄与真实数据源分开归因
25秒及60秒纯主机桥接挑战均因回执未送达而超时；无损压缩内容仍不足以消除模型与工具往返延迟。当前验证的方法是在同次CUA真实观察/必要操作中将完整AX保存为私有文件产物，由一次性主机PTY转发器送达原桥接器。采用独占0600临时文件写完关闭后原子发布，固定目录fd、防symlink、nonce/action/大小/稳定读取及单次发送，避免半写、错绑或重放。GUI仍只通过CUA，文件I/O仅保存观察产物，不使用其他UI控制通道。真实回执14.58秒通过原25秒期限、完整AX与响应SHA核同，属于E2主机链路；Session实际时长与指标固定窗口必须另以原件验收。原跨工具复制失败不归因手机或数值算法，不能通过扩大Session上限抵消。来源：网络方案与传输资格增量。版本历史增量：2026-10-26，补充完整产物原子发布与跨工具延迟边界。
2026-10-26 · 来源健康、参考资格与正式验收分别判断
- 来源新鲜与唯一消费：依据本指标原生序号/窗口和生命代际判断；其它指标的新消息不续命。主机到达新鲜不证明设备积分窗已知，也不能重复旧事实凑满1Hz。
- 空值的原因分别保留：未选择、未到期、warmup、断源、负哨兵、前台未准入不是合法0；未知原因不要推断成锁屏或硬件故障。静止无新呈现不能只凭时间推进填0。
- 参考先验资格：同层、同scope、同时间窗、完整端点集合和OFF/ON扰动均要成立；相似API可能同源。参考调用失败或超成本只拒绝该路线，不自动判产品错误。
- 无参考正式通过的限定政策：先完成本项候选参考调查和可行用例设计，确认当前没有合格参考，再按Owner授权完成无异常完整测试，保留
NO_REFERENCE_ACCEPTED_OWNER_POLICY及referenceAccuracyValidated=false。Owner已明确计入正式通过、不新增复核门；不能推广到仍有异常、只做软件自测或尚未完成五轮的项。刷新率的Owner直接已知例外决定另列，不伪装标准五轮通过。
问题复现、避免方式与证据见实验方法、参考候选用例、帧派生合同。本批E1梳理，原来源E2/E3/E4各自限定；55/66及11项暂停不变。
版本历史增量：2026-10-26，补来源/参考/验收三类判据，不改质量词表、公式或已验状态。
2026-10-29 · 首段空白、共享停顿与单指标断点分别定位
表现：首次点晚、多个来源同窗出现长间隔，与单项偶发空值可能同时发生；“一条曲线有缺口”不足以证明公式错误。
已验证机制与判断方法：先分开记录 Session 开始、Collector ready、目标身份核准、各来源首个有效窗口与真实发表点。共享事件循环同步处理大二进制 payload 可拖慢多个来源；先 Base64 后用原 bytes 覆盖会产生必然浪费。局部封装 E2 对照已证明提前剥离原 bytes 能消除这份分配，但不等价于已查明全部停顿。异步解析仍需有序、单次在途、取消后待收尾与明确超时诊断，不以后台化掩盖未完成工作。
逐槽核对：优先用原始发表回执关联原始窗口、派生值和产品结果。仅按 host receipt 对 Raw 重放不包含原消费者完成/调度顺序，结果差异不可直接定性为投影丢值。本次四项累计率各58槽的原始回执为49新窗口、7过期、2已消费，196个有效值与端点/公式/派生/产品核同；既有1.5秒新鲜度和单次消费规则保留。不同指标的新消息不为另一指标续命，缺失不补零、不复用旧值或直接扩大TTL。
帧源边界：ActivityTrace 有大量消息不代表收到 FrameLifetime；UIKit 更新或事务提交不能改名作呈现帧。静态无新帧、来源尚未匹配和源切换空窗分别保留，未取得有效原生窗口时不从其它统计借造P95/刷新率。
适用范围与限制：这是本次故障原件的E1/E4输入审计及局部E2修复验证，不是新版本真机连续性或所有目标应用来源覆盖通过。复现与本批状态见首段与连续性修复。版本历史增量：2026-10-29，补首响应分段、共享停顿与逐槽归因方法，不改公式或正式55/66状态。
2026-10-30 · 局部来源就绪超时不等于整场无数据
表现与机制：内部235的失败原件持续约6秒，普通样本0但保存了2张截图。start_accepted后约5秒出现startup_source_unavailable和顶层裸TimeoutError。代码审计及软件复现确认：本地启动源就绪等待耗尽，被现有错误分类漏判为致命异常；普通采集尚未启动即退出。默认启用启动扩大了此路径的触发范围，但不证明设备断线、应用错误或bootstrap未到的底层原因。
判断与避免：将Start接受、来源准备、首样本与终态分开对齐，同时检查截图附件；错误分类保留来源与阶段。局部就绪预算耗尽只影响对应启动端点，健康指标应继续；缺失端点保持missing，不记为零时长或启动成功。软件候选使用专用就绪超时类型，保留5秒预算；源自身裸超时、合同错误和任务取消不应被泛化吞掉。prepared/direct入口分别注入无首包条件，验证普通数值持续发表、正常Stop及无遗留源任务。
适用范围与版本历史：2026-10-30增量，E1失败输入审计及E2软件复现/修复；不代表设备来源已恢复或新版本E4通过，不变更任何指标公式、55/66或余11项暂停状态。来源与验证记录。