出货
每格计数单位不同，不可相减异常与告警
Error 自动展开 · Warning 点击查看 · 此刻快照二级页与抽屉
首屏拿走的明细都在这里（降级不是删除）：展开哪一个才读哪一个，不展开不发请求。全链 trace · OC-5 — 由顶部搜索框驱动；#trace=<key> 深链会自动展开这里
全链 trace
media-service client_read：GET /v1/flow/runs/:id · /v1/flow/metrics?flow_run_id= · /v1/jobs/:id ｜ delivery-service client_read：GET /v1/contents?source=youtube&source_id= · /v1/contents/:id · /v1/deliverables?content_id= · /:id · /:id/events · /v1/publications/:id在顶部搜索框输入任一键：YouTube vid（11 位）或链接 → 决定论 run_bilidub_<vid> + delivery 自然键 (youtube, vid)；或 run_… / dlv_… / cnt_… / pub_… / job_…。拼出 media run 八段（状态 / attempt / 排队 / 执行耗时 / 产物签名 URL）→ delivery content → deliverables（审计事件）→ publication（bvid），合成一条时间线；每个对象带 raw JSON 折叠。BV 号反查待 delivery-service 提供按 external_id 查回执的端点（缺口已立项）。只读。
抽屉 · 配音流水线明细 · OC-3 — 在飞 run 全表 / 各段 task_type 耗时 / error_code 分布 / 重跑 attempt>1 / workers 心跳
配音流水线健康 · OC-3
这一层是明细，口径跟首屏不同：窗口 = 现在往回 24h / 7d（每个端点的 since），而首屏的状态带与异常告警是不带窗口的此刻快照。耗时 = finished_at − exec_started_at（执行钟，不含排队/领取）；RTF = Σexec / Σvideo_seconds（flow/metrics，D6 口径：一个 flow_run 算一个 video）；workers 心跳 > 3 × lease（120s）或无心跳标红；在飞 run 只拉前 30 条的段级详情（attempt）。只读：重试 / 取消 / 重启节点走各服务 CLI（由 Agent 按手册执行）。
在飞 run（最老的在上）
各段（task_type）：耗时 · 失败 · 重跑 · RTF
失败 run 与 error_code 分布
workers（心跳）
抽屉 · 交付与发布明细 · OC-4 — 6 个 deliverable 状态拆分 / 发布清单（近 3 个 UTC 日 · 只看最新 20） / failed 原因 / 对账点名 / gate 明细
交付与发布 · OC-4
delivery-service · client_read = producer key：GET /v1/deliverables?status&limit · /v1/publications/:id · admin：GET /v1/ops/reconcile · /v1/gatesdeliverable 状态机 awaiting_artifact → ready → claimed → published | failed（前两态可 canceled）。计数 = 每个状态一次列表（服务端单次上限 500，命中即显示 ≥500）；发布清单 = 最新 published 行按回执 published_at 分到「今日 / 近 3 个 UTC 日」，只列最新 20 条（每行一次 GET /v1/publications/:id，单次最多 20；撞上上限时表头写「只看最新 20，另 N 条未列」——窗口内的条数照实写，不假装列全了）；一行只有 dlv_… / 账号 / 时间，要查具体某一条走顶部 trace 搜索框；失败原因 = error_code 分布 + 最近点名；对账点名与 gate 冷却来自 admin 面快照——这两处的**当前**信号已经在首屏②层以 reconcile_named / gate_cooldown 出现，这里是它们的全表。没有任何写操作——重试 / 取消 / 开闸走 delivery-service 自己的 CLI（Agent 按手册执行）。
二级页 · 消耗明细 · OC-2 — events / images / chars / audio_ms / exec_ms / services 分列，7 个 group_by 维度，30d 与自定义窗口
跨服务消耗 · OC-2
每个 cost 值旁的「价来源」= 这行的钱按什么价结的（media-service v1.14 / #73）：catalog@v<N> · <node_class>（执行节点 × 认领时钉住的价目表版本）或 default（节点没上报 node_class，按 task_type 缺省价）。查不到价的行 cost_usd 是 null，不是 0：金额里不含它们，另单独计「无价 N 条」（unpriced_events）。角标来自同窗口的第二次聚合 group_by=<dim>,price_source（单独一次请求：它超 500 组只影响角标，不影响本表）；没有这个维度的服务显示「—」。
抽屉 · 告警全表 · OC-6 — 已按环节拆散进首屏②层；这里是原始全表 + 处置键图例
告警摘要 · OC-6
media-service admin: GET /v1/alerts（hardcap / ladder 近 7 天 + 当前 · pricing 计价告警）· /v1/workers?limit=1000 · delivery-service admin: GET /v1/ops/reconcile · /v1/gates把只在 Resend 邮件和 Worker 日志里的信号汇成一页，按严重度排序：critical（仍超硬闸执行 / 硬闸切过且已 failed / 日历阶梯耗尽 / 阶梯输入过期 / 对账 unpollable / 对账 failed_upstream / dead_lease 冷却 / busy 节点心跳过期）→ warning（阶梯跨阈值 / 对账快照过期 / 频控冷却 / idle 节点心跳过期）→ info。每条带稳定的「处置键」→ config/remedies.json（人读说明 + 将来 Agent 写操作手册里的命令名占位）。计价（media-service #73）：price_missing（结算时查不到价——节点没报 node_class / 价目表里没这个 class / 没有 active 价目表 / 没有执行钟）与 price_sync_anomaly（每日价目同步拒绝 promote）按 (reason, 对象) 归并成一条（服务端每小时最多记一条，7 天可达上百行），另有「价目表同步长时间没有记录」。只显示不处理：重试 / 取消 / 开闸 / 重启节点都不在本页。