Jitter CoreDevice 设备发现通道恢复方案

问题与证据边界

Jitter 正式仍为 3/5，整体 37/66。attempt-06 的 Display-only 设备级录制开始成功，但唯一一次 Fixture URL 调用失败；Trace 因中断后未能在5秒停止门内正常结束，留下的部分 Trace 不可用于事件配对。该 attempt 没有产生新 Lab run、Workbench Session 或手机文件写入，失败原件继续保留，不重放其请求。

2026-10-23 的只读诊断发现：USBMux、xctrace 和 xcdevice 均枚举到已选设备；使用 pymobiledevice3 原生隧道只读读取 CoreDevice 信息与进程列表成功。与此同时，devicectl list devices 未列出该已选设备，按记录标识执行 device info details 和只读 device info apps 均返回 com.apple.mobiledevice -402652910，内部函数为 _AMDeviceCreateWithRemoteDeviceWithError。因此当前阻塞位于 Xcode devicectl 的设备发现/远程连接路径。原因尚未证实；不得归因于硬件、锁屏或 Fixture，也不得据此确认参考不可用。

诊断时唯一安装的 Xcode 为 16.4；不存在另一份本机 Xcode 可用于无改动切换。设备详情查询返回的是缓存属性并伴随连接超时，不能当作新鲜通道通过证据。

唯一恢复操作

建立独占私有根目录 /Users/qiance/Perfowl-NewHost-Recovery/20261023-jitter-coredevice-channel-repair-07/，先执行新的只读守卫并保存来源 SHA、真实容量、设备枚举、目标 App 身份、进程生命、活动 Session 与请求/run 状态。旧 Lab 原件、旧请求目录、run 清单和 attempt-01～06 原件全部保留。

若守卫确认同一已选设备仍可经 USB 与 DVT 只读访问、历史 SHA/容量守卫通过、且 devicectl 清单仍缺少该设备，只执行一次：

xcrun devicectl manage pair --device <已选设备标识> --json-output <私有 attempt 收据路径> --timeout 12

此操作仅尝试建立/刷新 Apple CoreDevice 配对元数据；不解除配对、不安装/启动/终止 App、不发送 Fixture URL、不写入 Lab 文件、不创建 Trace 或 Workbench Session。若设备要求人工确认、命令超时/失败或身份变化，立即封存结果并停止；不重试、不改用其他设备。配对可能更新主机与设备的信任元数据，此为本恢复操作唯一允许的状态变化。

完成后仅做一次只读验证：devicectl list devices 必须出现同一已选设备且状态 connected；device info details 必须不再返回远端连接超时；device info apps 必须识别既有 Fixture 安装。另复核设备身份、进程生命、旧 SHA、run 数、活动 Session 与容量。任一项失败即停止，不启动 Fixture 或 Instruments。

时限、资源与后续门

• 单次只读守卫以旧证据数 n 线性复核 SHA，时间复杂度 O(n)；连接命令各最多12秒，只执行一次，不轮询。预计总墙钟时间小于45秒；达到上限即记录超时并停止。
• 不启动资源密集型录制或产生测试数据；本操作没有产品代码变更，不适用产品性能前后基准，也不以命令成功推断指标性能。
• CoreDevice 恢复只解除 URL 控制通道阻塞，不构成 Display 参考准入或 Jitter 轮次。通过后，另立独占 Display qualification attempt：更换 run 前缀；录制自然达到40秒结束，不在 URL 失败时发中断信号；仅在 trace 正常封存且事件、时钟、显示身份与 Fixture 唯一配对全部通过后，才评估后续正式方案。
• Jitter referenceAccuracyValidated=false、referenceUnavailableConfirmed=false、formalFiveRoundsPassed=false 保持不变；不得进入 r5、磁盘读取率或下一指标。

状态

attempt-07 的单次配对命令已执行；配对命令返回成功，但实际 CoreDevice 详情与 App 查询仍超时，设备控制通道没有恢复。此次恢复批次为 partial，不能据配对成功推断可启动 Fixture。

方案增量 · 2026-10-23 · 清单可见但服务查询仍超时

attempt-07 的新鲜只读守卫通过；独立比较确认旧 Lab/request/gate 摘要、run 状态、App 签名与进程生命同 attempt-06 a02 一致。新 devicectl list devices JSON 已匹配同一已选设备，因此按原条件跳过了初始配对分支。随后只读 device info details 与 device info apps 仍返回 -402652910 远端连接超时，前者仅返回缓存信息。设备处于 paired 的缓存标记不足以证明服务连接正常。

Validation Update · attempt-07 a01 · 2026-10-23

• 配对前后独立只读守卫均通过。旧 Lab 保全仍为132文件/23,301,593 B，22个旧 run（20 completed、2 partial）全部 workload 已释放；请求目录66文件/34,086 B、gate 树摘要及旧 run SHA 与基线一致。配对前后没有新 Lab run、没有安装/启动/终止/信号动作，Mac 活动 Session 为0。
• 对同一已选设备执行 devicectl manage pair 一次并返回 success。配对后的 device info details 与 device info apps 仍出现 -402652910 / Timeout while connecting to remote device；缓存 paired 状态不构成服务连接通过。本批不再执行配对，也不复用 devicectl --payload-url。
• 原生 pymobiledevice3 USB/DVT 只读通道仍可获取已安装 App 身份、稳定进程生命与递增设备时钟。对当前版本已接受的13份 P95 冷请求做来源核验：均对应唯一源码摘要，且与签名 Fixture 的 FixtureLabBuild.json 相符；独立复核验证请求与 intent 字节一致、nonce/版本/摘要绑定正确、旧请求树未变。该证据仅支持评估 AFC 冷请求队列与原生 DVT ProcessControl 启动路径，不替代新鲜守卫或实际消费验收。
• 恢复结论为 partial：devicectl 服务查询仍不可用，原因未证；这不证明 Display 参考源不可用，也不归因于手机硬件、锁屏或 Fixture。下一步另立新方案，以新的 run 前缀通过受支持 P95 冷请求队列和原生 DVT ProcessControl 启动一次独占 Display 资格用例；不得重放旧请求、尝试旧 URL 通道或进入正式 r4 前置五轮。