历史未执行草案；当前门禁与下一动作以最新 devlog 为准。原始会话标识仅保存在私有证据。

Build 74 · 2026-09-24 上午两轮真机问题定向验证方案

执行角色：Test / Research AI；最终验收：Lead AI。执行目标是回答已有真实 Session 暴露的问题，不是新一轮产品开发。执行者应先完整阅读本文，再核对本机证据和设备状态。状态基线：Build 74 E2 PASS；Owner E4 PARTIAL / NOT FINAL PASS；Phase C Hybrid Total FROZEN，C0 BLOCKED（current-source feasibility CLOSED），C1/C2 不放行。

0. 冻结对象、实验边界与任务优先级

产品源码基线 1ec94623f3623d37be206f82e114a6b441547db5，整理后的本地与双远程 main=4c1e424acaf6c8ee2b0941d3091b207e671fcf90（后者仅含后续文档）。唯一授权的内部测试 ZIP：

MacApp/dist/Perfowl-Build74-1ec9462-x86_64-signed-test.zip

其 SHA-256 必须等于 3a557cc0c0c666f90736c34fa9b633adb646a92a55ecfdae095c41f349a5dbc1。该包具有 Developer ID 签名和 Hardened Runtime，但未经公证，只限内部测试。测试中不能改包、改 product code、重签或用另一包混测。

本次对照的两条既有真实 Session：

别名	原始 Session	设备	实际采集	时长
S1	SESSION_A	设备 B / 系统版本留私有证据	多指标，Startup OFF，Screenshot 持久化 OFF	约 95 s
S2	SESSION_B	指定 Device A，设备 A / 系统版本留私有证据	多指标，Startup ON，Screenshot 持久化 OFF	约 35 s

原始位置均位于本机 ~/Library/Application Support/Perfowl/Sessions/<session-id>/。S1 为兼容性/异常参考，不是 S2 的同设备 A/B，也不能替代 Device A 正式 E4。若本次执行时指定 Device A 未 USB 接入、Developer Mode/配对不满足，仍先完整做离线审计；真机阶段标 BLOCKED_DEVICE，禁止自动换 设备 B。

执行优先级：

• P0-A：S2 Startup 的首帧 END 与 sceneWillEnterForeground 为什么缺失；4 s completion grace 是否相关。
• P0-B：S1/S2 的 FrameTime 原始事件时间跨度和上游 callback 间断是否意味着持续操作时存在数据断续。
• P0-C：两轮 Device Network 采样为候选全零、Process Network 非零，但无 network.device.raw 的原因；Build 74 cooperative fairness 是否真正进入有效负载。
• P1：FPS/FrameTime 相关指标、GPU 候选值、截图预览异常与数据质量补充。已验证的 Stop/seal 无需为刷成功率重复空跑。
• P2：勾选 Screenshot 后持久化、断线重连、30 分钟长测。这三项尚未由上午两轮覆盖；先交付 P0 结果，再由 Lead 决定是否进入扩展 E4。

不得重复已经完成的 CoreProfile 参数 A/B。历史 site/devlog/p4-startup-kdebug-ring-buffer-experiment.md 已有 2026-09-16 真机证据：bm=1 3/3 阶段完整，但每轮仍出现 2–3 次 CPU0 设备丢失 episode；bso=2M/8M、bsoc=8M/核 均未消除设备端丢失；bso=32M/64M 触发 5 s ready timeout。小样本不可证明 bm 永远无用，但本轮不授权重跑 bm/bso/bsoc、全开 17 组过滤器、开启 sampling trigger，或自行解冻 Hybrid。Instruments.app 对照由另一份专项方案负责：site/devlog/p4-build74-instruments-subscription-and-startup-endpoint-differential-audit-plan.md。如果新 .trace 已就绪，可共享只读证据清单，不能再执行重叠的参数试验。

1. Phase 0 — 只读预检与证据保全

在任何真机操作前：

1. 读取 AGENTS.md、internal/current-ai-handoff.md、internal/build74-user-manual-e4-test-guide.md 和 artifacts/build74-owner-e4-lead-review-20260924.md。检查 git status --porcelain、HEAD、当前占用/并发进程，不要复位/清理他人的 worktree、文档或会话。
2. 分别检查 S1/S2 的 manifest.json、session-plan.json、capture-plan.json、quality.json、product-seal.json、collector-core/manifest.json、report-final.json、startup-report.json（存在时）、frame-report.json、display-acquisition-census.json、raw-events.jsonl、frame-events-live.jsonl、core-profile-chunks.bin（存在时）和 metrics.csv。
3. 将两条 Session 的重要原始文件的大小/SHA-256、文件缺失项及原始 report-seal 记录在仓库外私有 ~/Perfowl-Local-Archive/build74-owner-e4-followup-20260924-<time>/baseline-manifest.json。读取可以直接在原位置进行；如果需要二次转换/离线重放，复制到独立目录，不能覆盖原始 Session。磁盘不足则只存可复现 SHA 与路径，不强制复制全部历史文件。
4. 扫描其他 AI 正在使用的 artifacts/ 与站点方案，但不能修改其未提交工作。避免在其他 Instruments 会话录制时同时启动 Perfowl：二者可能争用同一 iOS 性能采集资源。
5. 对真机设备按原会话 deviceIdentifier 在本地安全比较、设备 A、iOS 17.0、USB、配对、Developer Mode、目标 App 安装、ZIP hash 逐项检查。最终脱敏报告不得打印原始 UDID、个人设备名或私有 App 数据。设备标识不匹配时，不得宣称与 S2 是同一设备。

输出 preflight.json：历史 Session 2/2 可用性、设备是否就绪、源配置身份、签名 ZIP SHA 和可执行场景。历史 S2 的 status=completed 和 productSessionDurable=true 是数据持久化结论，不是 Total 或 FrameTime 连续性 PASS。

2. Phase 1 — 必做的离线根因取证

2.1 P0-A：Startup 首帧终点／4 秒宽限

S2 已知事实：Dedicated Startup ready 且目标动态归属 ready，约 142 万 decoded records 中有 25 条 target lifecycle records，7 个阶段有 candidate 值；sceneWillEnterForeground() 的 BEGIN 未闭合，Initial Frame Rendering 未观测，traceEndTimestampNs=null、totalDurationMs=null。9 月 24 日 09:44:21.215 发出启动请求，09:44:27.511 记录 startup-completion-grace-expired，等待本身为 4.061 s，不是“App 启动超过四秒”。启动窗口中另有一次设备端 lost marker；host buffer/queue drop 仍为 0。

特别注意 collector-core/manifest.json 中 startupCoreProfileCompletionWaitOpenPhases=['sceneWillEnterForeground()']，startupCoreProfileCompletionWaitExtended=false。实现只在 didFinishLaunchingOpen=true 时执行扩展；必须区分“有其他阶段未闭合”和“用户实际启动超过 4 s”。完整保存 29 个 chunk，core-profile-chunks.bin 约 91 MB；完成等待超时后仍收到 3 个 chunk，不能仅看 host receipt 时间推断真实 kernel event 时间。

执行步骤：

1. 从原始 core-profile.chunk.raw 核验设备实际 effectiveCoreProfileConfig / 签名：S2 实际 bm=0、四个过滤类别 0x1F070000 / 0x2B870000 / 0x2BDC0000 / 0x31CA0000、samplingTrigger=false、csd=0。不可直接从当前 HEAD 假设原轮配置。
2. 按时间线枚举 29 chunk：索引、hostReceiveMonotonicNs、原始 kernel min/max、size、raw SHA、是否在完成等待超时之后；核实报告中 3 个尾部 chunk 与事件实际涵盖窗口。
3. 查项目现有 replay / startup / startup-e4-audit 等真实 CLI --help 和现有测试，不可编造调用参数。将冻结 parser 对 29 chunk 的离线重放输出到新目录，与 live、final 三层逐字段比较，不覆盖原报告。
4. 从已存原始 kernel event 中定向定位：首帧 BEGIN/END debugID、丢失 marker、sceneWillEnterForeground() 的配对情况、unknownLifecycleFingerprints（尤其可疑的未映射代码）、thread/PID/target generation 与完整 start/end 证据。分别给出 RAW_PRESENT / RAW_ABSENT / UNDECODABLE / WRONG_TARGET / OUTSIDE_WAIT，不要把“解码结果没有”偷换成“原始数据一定没有”。
5. 将 3 个超时后 chunk 与超时前结果分别 replay；仅在 RAW 能证明尾块中有真实目标终点时，才给出“延长/调整 completion grace”的候选证据。若尾块无目标 END，则禁止只因发生过 timeout 就延长 4 s。
6. 检查设备 lost marker 在启动起点、各阶段、首帧期内的精确 kernel time 与 CPU。一次 marker 只证明存在丢失 episode，不得声称恰好丢失 First Frame END。sourceQuality.lossFree 与 device lost marker 口径不同，不能用 host 无丢失覆盖设备端证据。
7. 如果 Apple Instruments 新录制 .trace 已归档，仅比较同一终点定义的可证事实。跨源 FrameLifetime 与 CoreProfile 没有原生时钟 epoch 和 surface owner 证据时，Hybrid END 仍必须 missing。

输出 startup-endpoint-forensics.json + startup-29-chunks.csv：以 DEVICE_NOT_RECORDED / RECORDED_BUT_DECODER_MISSED / TARGET_ATTRIBUTION_FAILED / END_AFTER_COMPLETION_GRACE / ENDPOINT_SEMANTICS_DIFFER / INSUFFICIENT_EVIDENCE 分类，逐条列原始 offset、来源和反证；任何新的 Total 只能来自真实可配对的端点，原始阶段总和 815.41 ms 不能替代 Total。

2.2 P0-B：FrameTime 上游间隙与时间域

S1（设备 B）：655 条 FrameLifetime，host callback 观测 93.83 s、source presentation min–max 12.86 s、最大 host receive 间隙 1.57 s；S2（设备 A）：154 条、host 29.50 s、source presentation 4.39 s、最大 host 间隙 5.64 s。两轮 delivered=consumed、pending=dropped=undrained=0，队列深度最大 1。S2 consumer wake→dequeue P95 28.41 ms，不能据 sourceGapCount=0 宣称整段 Session 的帧数据连续。

执行步骤：

1. 从原始 frame-events-live.jsonl 构造两个独立时间轴：hostReceiveMonotonicNs 与 presentationTimestampNs；按 sourceEpoch/reconnectGeneration/targetGeneration/displayID/surfaceID 分组，检查 timestamp 倒退、截断、重复/重放、跨 surface 混算与单位。无原生同 epoch 证明，不得直接将 host 与 device timestamp 相减。
2. 每秒聚合 host 实际收到的 FrameLifetime 数、有效 frameTimeMs 数、FPS / GPU 非零样本，标出 500 ms / 1 s / 5 s host 接收间隙。分辨连续 render interval、界面静止停止提交、上游积压分批回传和设备数据流中断，不得假定目标屏幕始终滚动。
3. 使用 display-acquisition-census.json 逐层分解 tap callback → filter → pump enqueue → queue wait → adapter → realtime → ingress，列所有最大间隙对应 classifiedLayer 及前后事件。核对前段出现的 1.57/5.64 s 缺口是否真实来自上游 callback，以及 P95/Max 排队延迟。
4. 核实 frame-report.durationMs 的源码定义，避免把它误当 host 实际覆盖时长。对每条分类附 sample window 与确切算法/时间域。

输出 frame-continuity-s1.csv、frame-continuity-s2.csv、frame-census-comparison.md。两机只能做各自源链质量判断，不可用其不同 iOS/机型产生绝对性能优劣结论。

2.3 P0-C：Device Network 零值与 fairness 可观测性

两条 Session 里 Process Network 有非零原始数据（S1 Process RX 峰约 3.81 MB/s；S2 约 1.92 MB/s），但 Device Network rate 为 candidate 全零（S1 93 组、S2 30 组），且两轮 network.device.raw 都为 0 条。当前事实不足以证明 Build 74 Device Network fairness 曾在高负载下真实触发。

执行步骤：

1. 检查 capture-plan/session-plan/capabilities/coverage 是否请求、准备并成功启动 pmd3.device-network.raw，其 DTX service com.apple.instruments.server.services.networking 是否有有效订阅、异常、fallback、适配器结束状态及 stop 日志。
2. 从 collector-core/raw-events.jsonl、上游设备源序列、metric_engine.py 与 device_network_aggregation.py 追踪 Device 网络指标从实际原始字节到 100 ms aggregate 与 1 s sample 的路径；区分 SOURCE_UNAVAILABLE、NO_RAW_EVENT、VALID_ZERO、AGGREGATION_LOST、HOST_DROPPED。若无源事件却投影 candidate 0，生成独立的数据语义问题条目，不得把零冒充真实空闲。
3. 查真机运行时是否已有 networkFairnessYieldCount、最大 burst、drop、吞吐的原始诊断证据。字段未记录即 NOT_INSTRUMENTED，不能以源码存在计数器就宣布 E4 fairness PASS。
4. S1/S2 Process 网络的不同设备数据不可直接做 byte-conservation 跨机比较；仅对同一 Session 同一来源/相同计算窗口对账。

输出 device-network-provenance.json 与 network-fairness-evidence.md。若 Device 网络源无法订阅或根本无流，请先查环境/协议兼容性，不要直接修改公平性调度器。

3. Phase 2 — 基于离线结论的最小真机复测

本阶段仅在指定 Device A USB 配对/版本/目标 App/ZIP SHA 全部通过且没有 Instruments 同时占用底层服务时执行。以单设备、原始同机同系统记录为正式比较口径。用户已经授权针对问题做验证；执行者可以按以下固定矩阵执行，但不得自改代码或切换产品二进制。如果前一场景揭示阻断性 P0，及时停止剩余依赖场景并交付已得证据。

顺序	场景	轮次和动作	必答问题
T1	Startup only	3 次独立冷启动，每轮不勾选 FrameTime；保存各自完整原始 Session，不挑选最好一轮	Dedicated 是否在每次冷启动前完成 recording + SOURCE_ACTIVE barrier；9 阶段/首帧 END/Total/设备 lost marker 与 4 s grace 的逐轮关系
T2	FrameTime only	1 次 120 s；0–30 s 连续滚动、30–60 s 静止、60–90 s 连续滚动、90–120 s 静止；保存操作开始/结束的主机时间标记，若隐私允许保存目标屏幕录制	上游 500ms+ gap 是否只出现在静止期，是否在明确滚动期间也出现；纯 Display 的 P95/Max 与 FPS 曲线是否连续
T3	Startup + FrameTime	3 次冷启动，其中 1 次启动后继续 120 s 按 T2 相同的滚动/静止分段，其余两轮 30–60 s 即可	Startup 独立源与 ActivityTrace 并采是否互相影响；缺 END、首次 FrameTime 延迟或持续性缺口是否较纯单项再现
T4	Network only	1 次约 180 s；30 s 无操作 → 120 s 可控目标 App 下载/加载（避免私有数据上传）→ 30 s 停止	Device 原始网络源是否出现、速率是否跟真实流量变化、是否把 unavailable 误显示成 0
T5	Network + FrameTime	仅在 T4 有真实 device 原始事件时做 1 次约 180 s；同样控制流量并持续滚动	有有效上游输入时，networkFairnessYieldCount/burst/drop 是否可观测，FrameTime 是否被 Device Network 饿死

执行 T1/T3 时，设备重启/预热/强杀目标 App 的具体步骤要统一，记录 cold/warm 定义和实际操作，不得把多轮中较好的一轮替换较差的一轮。起点不能人为改用启动命令时间并谎报为 kernel BEGIN。保留每轮真实 App 状态和选择的指标；不要让屏幕录制干扰采集而又不记录该变量。

T2/T3 的所有分段必须留下主机时间标记（以同一 monotonic clock 或可核对的 timestamp）；如果没有视频，至少有执行脚本/人工真实操作日志以及时间戳，避免再次无法区分 App 静止与上游丢事件。第 30/60/90 秒各阶段的界面操作要真实可复现。新测试的 source presentation 与 host receipt 分别统计，并与同一 run 的实际操作窗口比较。

T4/T5 的实际网络动作必须能在目标 App 内观察到下载/刷新活动；如果 Device 源一直没 raw，就在 T4 直接输出 DEVICE_NETWORK_SOURCE_UNVERIFIED 并跳过 T5（不可为观察 fairness 虚构数据）。若省电、后台、权限、网络断连会影响场景，单独记录。

4. Phase 3 — P1/P2 补充项目，不得冒充已验证

若 Phase 2 各 P0 源链可用，再推荐补齐如下独立问题，本批不因已有两轮完成状态而自动判 PASS：

1. GPU 与 FPS：GPU graphics raw 在 S1/S2 分别有 94/31 条，CSV 有部分非零候选；这只能说明候选采集存在，不等于 GPU Counter 全指标已校准。将 graphics 与 GPU Counter 分开验证，未支持时必须 missing。
2. 截图：上午两轮均未勾选持久化，S1 实时预览 92 次且失败 1 次、S2 28 次且失败 0 次、保存图片 0。另取至少一次勾选截图的 60–90 s Session，核对约 1 Hz、实际数量/时序、清晰度、黑屏率、Stop 归档；未经执行不得写已 PASS。
3. USB 重连：在单独 Session 中受控拔线/重连，检查 sourceEpoch、reconnectGeneration、PID/Session 归属与 closeout，不把老代数据并入新代。
4. 30 分钟长测：优先等 P0-B/P0-C 可证，之后按既有 internal/build74-user-manual-e4-test-guide.md 执行 FPS + FrameTime + CPU + Memory + Network + Screenshot，记录曲线连续性、磁盘和内存增长、drop 与最终 drain。
5. Stop/seal 基线：S1/S2 均 droppedEventHighWater=0、hostDroppedEventHighWater=0、ingressUndrainedAtSeal=0、dataCompleteness=complete。后续受控新测试核实这些不变量保持，但不得把它们作为 FrameTime 全时段覆盖或 Network 有效值的替代证明。

P2 是否继续由 Lead 根据 P0 结果再授权；执行 AI 本次完成前两阶段及 P1 的证据分析即可交付，不得为了“十场景全覆盖”强行扩大实验导致混淆变量。

5. 结束门禁与停止条件

检查	本批达到什么才可声称验证成功	不满足时必须怎样写
Startup	单轮真实 kernel START+END 可配对，明确 Total 来源；各轮报告完整阶段数、缺失分类及 exact same-run 证据	若端点缺失，missing；若原始数据不在，只写设备丢失“可能”而非“已证明丢的就是 END”
FrameTime	在确认持续操作窗口内，host 回调/上游 presentation 时间域清楚、覆盖合理，关键 gap 都能定位且无伪装连续；同负载比较单源与并采	不把 sourceGapCount=0 或队列 dropped=0 解释为 FrameTime 连续。若存在 gap，写发生在操作/静止哪段、原因证据层
Network	network.device.raw 非零且有与流量动作对应的数值，raw→aggregate→sample 守恒；若高流量足以触发 fairness，诊断计数可核验	无上游 raw 则 UNAVAILABLE/NOT PROVEN，即使进程网络非零或设备 rate candidate 全零也不能宣称网络正常或公平性 PASS
GPU/Screenshot	只按实际已选/真实返回的数据分类，计数及 SHA 可追踪	未选择/不支持写 NOT_TESTED/UNAVAILABLE
可靠性	原始 Session durable、final raw seq == consumed、writer/drain 无隐性丢失	发现 stop/persistence 失败，立即转 P0 并停后续无关负载轮

任何高风险持续设备丢失、应用/系统异常、采集源失控、温度异常、权限不匹配、其他 agent 同时修改相同目录，都应停止依赖测试并保全已有记录。不得手动把缺失 Total 填 0、以 815ms 阶段和冒充 Total、以首条 FL 冒充本 App 的 first frame，或跨 Session 拼接启动端点。

本批测试最多 T1 3 + T2 1 + T3 3 + T4 1 + T5 1 共 9 条新 Session；遇阻提前结束，不为了完成轮次数量反复空跑。T5 依赖 T4 可见有效设备网络。所有冷启动轮必须原样保留失败/缺失案例，不能多轮择优后只提交最好结果；可额外提出后续大样本方案，但本批小样本不能声称统计稳定率。

6. 输出目录、材料与交接格式

原始数据继续保存在 Perfowl 本机 Sessions；本批私有分析目录：

~/Perfowl-Local-Archive/build74-owner-e4-followup-20260924-<time>/

目录至少含：

• preflight.json：配置、版本、真实场景可达性和原始文件 SHA。
• baseline-manifest.json：S1/S2 及新 Session 的 source-backed hash/size；source-evidence-inventory.md，标注 Instruments 对照是否可用而不重复其专项实验。
• startup-29-chunks.csv、startup-endpoint-forensics.json、startup-live-vs-replay.md。
• frame-continuity-s1.csv、frame-continuity-s2.csv、frame-census-comparison.md；每个新增 Display run 同样生成独立时间轴和人工活动分段日志。
• device-network-provenance.json、network-fairness-evidence.md。
• test-matrix.json：场景 T1–T5 的实际状态 PASSED/FAILED/BLOCKED/SKIPPED、sessionID、设备别名、开始结束时间、指向原始证据的可解析路径。
• final-audit.md：一页根因结论 + 每一 P0 的证据、反证、未证部分、是否值得修复及最小变更建议。独立列 P1/P2 未覆盖项。
• SHA256SUMS.txt：必须验证覆盖本次输出的每个关键分析产物；原始 Session 单独核验，不需要复制 91 MB blob 到公开仓库。

必要时仅将完全脱敏的 final-audit.md、矩阵和证据哈希摘要放进新的 artifacts/build74-owner-e4-followup-<timestamp>/，禁止提交未经清洗的 UDID、设备名、原始 Session、目标 App 私有内容或 Instruments .trace。不得覆盖 9 月 24 日上午原始 S1/S2 及此前 blocker 证据。仓库已有未提交的 Instruments 参数差分方案，不能顺手 git add -A。

执行 AI 的最后回复固定格式：role=Test/Research AI；productCommit=1ec9462；auditBaseline=4c1e424；originalSessions=[S1,S2]；newSessions=[实际 ID]；deviceVerified=YES/NO；P0-A/P0-B/P0-C 各自 PROVEN/REPRODUCED/NOT_PROVEN/BLOCKED 和关键 raw 证据；SHA256SUMS path + sha256；final-audit path；remainingP1/P2；codeChanged=NO；judgement=pending-lead-ai。由 Lead 再次独立核验原始 hash、时间轴和结论，决定是否授权最窄修复。执行 AI 不得自己宣布 Build74 正式 E4 PASS。