P4 工作台指标支持收口方案

目标与边界

本批把已经存在可信原始事实、但仍未完整接入工作台的能力一次收口：StartupTiming、CPU Core Usage、Frame Time 与 GPU Counter。同时把“产品入口是否可选择”和“是否完成 PerfDog 外部数值校准”拆开，避免一个已经可采集的 candidate 指标仍被展示成“部分支持”。

本批不以改标签代替能力。Frame Time 按选择开启 CoreProfile 并完成实时逐帧投影；GPU Counter 按选择启用设备动态 schema、decoder、统一 Raw→Metric 与工作台动态曲线。ThermalStatus 仍需要稳定当前值源，因此保持“条件可用”，不伪造枚举值。

公式先行

指标	原始字段	公式与单位	scope	窗口与缺失	算法版本
Process Observed Running	launch.requested.raw.hostReceiveMonotonicNs、同 generation observed-running/rebound	(terminalNs-startNs)/1_000_000，ms	process	单次 controlled launch；逆序、跨 generation、无终点为 missing；不取整	startup-observation.candidate.v2
Foreground Ready	上述起点、同 generation observed-foreground，或 foreground=true 的 running/rebound	(terminalNs-startNs)/1_000_000，ms	process	同上；轮询误差上界为 pollIntervalSeconds×1000	startup-observation.candidate.v2
CPU Core Usage	PerCPUUsage[i].CPU_TotalLoad	每个有限原值原样输出为 Core i，percent	device	每个 sysmontap 窗口；不求和、不平均、不除核心数；缺项只让该 Core missing	per-core-gauge.v1
Frame Time	CoreProfile RAW v2 kd_buf.timestamp、Mach numer/denom、exact debugid 0x31800318	floor(ticks×numer/denom) 后相邻 accepted timestamp 差 / 1,000,000，ms	foreground-device	首帧 warmup；后台失效；逆序、跨 generation、schema 失败为 missing	core-profile-v2-presented-frame.candidate.v2
GPU Counter	设备 decode-order 与 timestamp + N 个 uint64 counter	非 _ 字段或 require=true 直通；_ 且 require=false 做同 schema 相邻行差分	device	首行差分项 warmup；负差/reset、宽度不符、未知 schema 为 missing；source-native-count	gpu-counter-source-native.candidate.v1

产品支持状态

• 可用：已有 raw → metric → wire → Mac UI 链路；candidate/validated 继续由质量字段表达。
• 条件可用：产品链已接入，但依赖连接方式、供电状态或设备是否返回来源字段；条件不满足时显示明确原因，不写 0。
• 暂未支持：缺实时来源、decoder 或可信定义，入口保持禁用。

CPU Usage、Memory、GPU Usage、Network、Battery Temperature 与 Energy 已经有真机原始事实和工作台曲线，本批把入口状态改为“可用”，但不改变其 candidate 校准等级。Battery 与 ThermalStatus 改为“条件可用”；外供电和 source-missing 仍按现有质量规则显示。

UI 与数据改造

1. Collector 实时样本增加两项 StartupTiming 值、scope、unit 和 quality；只用与归档报告相同的 launch/lifecycle 事件与 monotonic 时钟。
2. Swift wire、Session、CSV 和工作台承接两项启动值。
3. CPU Core Usage 按真机 perCoreCPUUsage 长度动态生成 Core 0…N-1 曲线，不补齐虚构核心，不聚合。
4. 每条曲线显示可见 scope 标签：APP、整机、前台画面；Network 使用样本实际 scope，不再只依赖静态默认值。
5. 修正 FPS/GPU 文案和 scope，明确它们当前是 foreground-device，不是目标 PID 专属。
6. Frame Time 与 GPU Counter 只在对应指标被选择时开启高成本 DTX service；仍只有一个 pymobiledevice3 DTX owner。
7. GPU Counter 使用静态 Registry metricID + 动态 counter dimension，原始值进入 Session、离线派生与 CSV；不执行设备下发 JavaScript。

验收门禁

• Python：启动起点、running、foreground、逆序、跨 generation 和 missing；CoreProfile 分块解码；GPU service 参数、schema、绝对/差分、reset 与离线 Metric；现有全量测试不回退。
• Swift：两项 wire 解码、工作台启动面板、动态分核/GPU 曲线、scope 标签、Session/CSV 和缺值不写 0；全量测试不回退。
• E2：VitePress 构建、Mac release 构建与 ad-hoc 严格签名。
• E4：使用当前连接设备完成 controlled launch，观察 StartupTiming 与分核 CPU 非空；选中 Frame Time / GPU Counter 后分别记录真实来源或明确设备拒绝原因。若设备/目标 App 拒绝启动，只记录失败边界。

后续批次

完成本批 E4 后，指标工作转入条件门禁与精度校准：Battery 需要物理断电 Wi-Fi Session；ThermalStatus 需要稳定 0…3 当前值源；GPU Counter 需要分 SoC/iOS schema 与设备公式研究；Frame Time 需要长时连续性和目标进程归因研究。TinyJank/Smooth 不在“添加指标”列表，仍等待可信定义。