heat-nudge 訊號後續強化追蹤：Phase B token-rate / burst 牆 leading indicator / Agent-launch 擴面（residue from #25）

[kiki830621]

Problem

#25（v1.17.0）落地官方 5h utilization leading indicator 後，三項 residue 需要一個活的追蹤點（#25 已 closed，不散落）：

Type

enhancement（追蹤 issue）

三項後續

1. Phase B token-rate：token/min 加權速率訊號。資料前提已 100% 就緒（proxy usage 擷取覆蓋率僅 ~2%（疑 streaming 路徑 usage 沒抓到）— #25 burn-rate Phase B 的資料前置 #26 修復後 usage 全覆蓋），純優先級問題——「耗過快」的 quota 面已由官方水位回答、burst 面待 ②，token 加權屬精緻化。
2. burst/acceleration 牆的 leading indicator：velocity 訊號經 production 負面校準砍除（撞牆前 300s 速率 fable 14 / opus 155，遠低於忙碌期 p95 677/640——07-10 的 429 全是 quota 級；詳見 burn-rate 事前警示：token/請求消耗速率過快的 leading indicator（撞牆是 lagging） #25 修訂版 plan）。重啟條件：出現「官方 utilization 低但仍 429」的真 burst-only 樣本（trip-recorder + rate-state 交叉即可鑑別）。屆時的候選訊號不必是 request-count——並發 stream 數 / token 權重速率可能更貼 07-10 的 8-agent spawn 形狀。
3. Agent-launch 擴面：utilization nudge 目前僅 Workflow launch 觸發——fable session 的 Workflow 被自家 gate deny，正是燒最兇的場景警示到不了（burn-rate 事前警示：token/請求消耗速率過快的 leading indicator（撞牆是 lagging） #25 verify DA finding，誠實邊界已明文於 plugin CLAUDE.md）。擴到 Agent launch 技術上一行 gate 改動，取捨是 advisory fatigue（Agent launch 頻率 >> Workflow）。可考慮只在 utilization ≥ 更高門檻（如 0.9）時才對 Agent 出聲的分級設計。

關係

• rate-limit-proxy Phase 2：依真實 budget 主動排程（delay / 佇列 / block） #7（predictive 排程本體）：本 issue 是訊號層、rate-limit-proxy Phase 2：依真實 budget 主動排程（delay / 佇列 / block） #7 是行動層
• roadmap: per-model 門檻（各 model 桶設不同 MAX / MIN_GAP / FANOUT_WIDE_MIN） #23（per-bucket 門檻 roadmap）：velocity 若重啟，門檻歸 roadmap: per-model 門檻（各 model 桶設不同 MAX / MIN_GAP / FANOUT_WIDE_MIN） #23 架構
• pacing-guard 覆蓋面缺口：main-loop coordinator burn — PreToolUse hook 結構上看不到 fable 消耗 #24（main-loop 結構限制）：擴面做到頂也蓋不到 coordinator 自身消耗

Priority

P3 — 全部 gated on 樣本出現或優先級浮現；#25 的核心價值（quota 牆預警）已上線。

Source: residue from #25 at /idd-close time (Step 3.6)