pacing-guard 覆蓋面缺口：main-loop coordinator burn — PreToolUse hook 結構上看不到 fable 消耗

[kiki830621]

Problem

Original text (使用者觀察，2026-07-07 一個 Fable 5 session 撞上限後):
「這邊不該用 fable5 吧，怎麼沒有檔下來」
「claude-hot-limit 要設」

pacing-guard 是掛在 Workflow 上的 PreToolUse hook。它結構上無法觀測 main-loop 的 token 消耗——PreToolUse hook 只在 tool 被呼叫時 fire，而 main-loop 的每個 turn 不是一次 tool invocation。所以一個 Fable 5 session 反覆做重度 coordinator 工作時，guard 擋得到 Workflow 啟動、卻擋不到 session 自己燒的 Fable 5 quota。

Type

bug（coverage gap — 結構性，非 tuning）

實證 incident

本 session（PsychQuant/logos 的 #57 round-1+2、#58、#59、#61 五輪 6-AI IDD verify）在 #61 verify 進行到一半時撞上 Fable 5 usage limit。過程中：

1. 每一輪 verify，claude-hot-limit 的 FABLE×WORKFLOW guard 都正確 deny 了 Tier 1（pai-ensemble via Workflow）——working as intended。
2. 於是 fallback 到 Tier 3 manual Agent fan-out（5 個 reviewer + codex-call），加上 main-loop coordinator（session 本身）被 idle-notification 反覆喚醒，每次讀 8–13 KB findings 檔、render master report、merge。
3. 五輪累積下來，quota 由 main-loop + Agent fan-out 兩條 guard-看不見的路徑燒完。

「怎麼沒擋下來」的答案：guard 擋掉 Workflow 之後，工作沒有消失，只是流向 guard 看不見的 main-loop。擋掉最貴的那條路，反而把負載趕到一條完全沒有計量的路上。

根因（為什麼是結構性的）

• PreToolUse hook 的觸發面 = tool invocation。
• main-loop 的 token 消耗不是 tool invocation，沒有任何 hook surface 對應「assistant 即將在 Fable 5 上花 main-loop token」。
• 因此任何以 PreToolUse-based gating 為基礎的方案都覆蓋不到這條路徑，包含把 gate 擴到 Agent（那是 fable×Workflow gate — F5/F7/F8/F10 (6-AI verify follow-up of #18) #21 F5 的範圍，另一條路）。

與 #21 F5 的關係（互補的兩半）

#21 F5（Agent side-door）處理的是「parallel Agent fan-out 不觸發 fable gate」——那是一個 PreToolUse 可觸及的面（你可以把 gate 擴到數 Agent blocks）。

本 issue 是互補的、更難的另一半：main-loop coordinator burn，PreToolUse hook 結構上到不了。兩者一起才構成完整的「所有 guard 看不見的 fable 消耗面」。

Scope / 可能方向（都不是 Workflow gate）

• rate-limit-proxy（rate-limit-proxy Phase 2：依真實 budget 主動排程（delay / 佇列 / block） #7 / 部署 Phase 1 rate-limit-proxy：launcher + ANTHROPIC_BASE_URL 導流 + 觀測期（blocks #7；sister concern from #7） #8）是結構上正確的家：proxy 在 ANTHROPIC_BASE_URL 導流層看得到實際 token spend，不分來源面（main-loop / Agent / Workflow 一視同仁）。這是唯一能量到 main-loop 消耗的機制。→ 本 issue 很可能是 rate-limit-proxy Phase 2：依真實 budget 主動排程（delay / 佇列 / block） #7 的一個 motivating use-case，而非獨立可修項。
• Session-level advisory（best-effort）：Fable 5 session 啟動一個已知重度的重複 workflow（如 IDD 多輪 verify）時，SessionStart / 週期性 telemetry 發一次性 nudge「coordinator 考慮切便宜 model」。但 hook 無法強制 main loop 離開 Fable——只能提示，決定權在使用者 + doctrine。
• 累積預算 telemetry：當 session 的累積 Fable 5 main-loop spend 過門檻時 warn。同樣是提示、非硬擋。

誠實邊界

這條在 PreToolUse hook 的能力範圍之外，所以它多半不是「在 pacing-guard.py 補幾行」能修的，而是要嘛歸給 rate-limit-proxy（#7 家族），要嘛降級成一條 doctrine/telemetry 的 advisory。建 issue 的目的是把這個結構性缺口明確記錄下來，避免下次又以為「guard 有裝就會擋」。

Source: 使用者於 2026-07-07 Fable 5 session 撞上限後提出（/idd-issue）。Sister 到 #21 F5（Agent side-door，PreToolUse-reachable 的另一半）、#7/#8（rate-limit-proxy，結構上正確的計量層）。

[kiki830621]

Diagnosis

Type

bug（coverage gap — 結構性）。但診斷結論是：這條在 pacing-guard（PreToolUse hook）能力範圍之外，不是「補幾行 code」能修的——issue body 自己已正確自診，本 diagnosis 確認並定 disposition。

Root Cause

PreToolUse hook 的觸發面 = tool invocation。main-loop coordinator 每個 turn 的 token 消耗不是 tool 呼叫，沒有任何 hook event 對應「assistant 即將在 Fable 5 上花 main-loop token」。因此任何 PreToolUse-based gating 都覆蓋不到這條路徑（含把 gate 擴到 Agent——那是 #21 F5 的另一半，PreToolUse 摸得到的那半）。

Impact

Fable 5 session 做重度 coordinator 工作（如 IDD 多輪 verify 的 merge/read/report）時，guard 擋得到 Workflow 啟動、卻擋不到 session 自己燒的 Fable quota。實證：PsychQuant/logos #57–#61 五輪 6-AI verify，FABLE×WORKFLOW gate 每輪都正確 deny Tier 1（Workflow），但工作 fallback 到 Tier 3 Agent fan-out + main-loop 反覆喚醒，quota 由兩條 guard-看不見的路徑燒完。

Strategy（disposition — 三選一，非 pacing-guard code fix）

• (a) 歸給 rate-limit-proxy Phase 2：依真實 budget 主動排程（delay / 佇列 / block） #7（rate-limit-proxy）：proxy 在 ANTHROPIC_BASE_URL 導流層看得到實際 token spend、不分來源面（main-loop / Agent / Workflow 一視同仁）——是唯一能量到 main-loop 消耗的機制。pacing-guard 覆蓋面缺口：main-loop coordinator burn — PreToolUse hook 結構上看不到 fable 消耗 #24 → rate-limit-proxy Phase 2：依真實 budget 主動排程（delay / 佇列 / block） #7 的一個 motivating use-case。
• (b) best-effort SessionStart advisory：Fable 5 session 啟動時，SessionStart hook 發一次性 nudge「coordinator 工作在 Fable 上很貴且 guard 看不見，考慮 /model 切 sonnet 做協調」。小、可做、但只提示無法強制。
• (c) 純 doctrine/telemetry：記進 doctrine（已在 ~/.claude/CLAUDE.md 有 fable×Workflow 相關），不寫 code。

Conflict Class

D_diagnose_first → 已 diagnose 完，結論是「非獨立可修項」。真正的實作若走 (a) 屬 #7 scope、走 (b) 是 SessionStart hook 的小 advisory。

Complexity

Simple —— 但只在選 (b) 時有 code（SessionStart 一條 advisory）。(a)/(c) 無 pacing-guard code。

Residue（結構性，不可繞過）

「強制」main-loop 離開 Fable 這件事，hook 結構上永遠辦不到——PreToolUse 沒有 main-loop 消耗的 surface。即使 #7 proxy 也只能觀測/警告、不能 block main-loop 自己的 turn。所以 #24 的完整解永遠只到「量得到 + 提示」，enforcement 是這條路的硬邊界。這正是建 issue 的價值：明確記錄「guard 有裝 ≠ 會擋 main-loop」。

推薦

(a) link #7 + (b) 小 advisory 二者可並行：#24 掛成 #7 的 use-case（結構正確的家），同時做一條 SessionStart best-effort nudge（立即、低成本、直接回應「怎麼沒擋下來」——至少 Fable session 一開始就被提醒）。要不要現在做 (b) 交給你（見對話）。

[kiki830621]

(b) best-effort advisory 已做（released v1.13.1，b48c8f2）

新增 SessionStart hook hooks/session-fable-nudge.py：resume/compact 時 tail-read 到 fable session → 印一句 nudge 進 session context（「guard 擋不到 main-loop coordinator 自己燒的 fable，考慮 /model 切 sonnet 做協調」）。

誠實覆蓋：✅ resume/compact（正是本 incident 樣貌，長 fable session 每次 compact 都提醒）；❌ fresh startup（空 transcript 測不到 model）；❌ mid-session /model 切 fable（無 switch hook）。fail-open、同受 _WORKFLOW_NUDGE/_OFF 開關。8 tests（套件 115 綠）。

disposition 收尾：

• (b) best-effort advisory → done（本版）
• (a) 核心「量 main-loop spend」→ rate-limit-proxy Phase 2：依真實 budget 主動排程（delay / 佇列 / block） #7（rate-limit-proxy）scope，唯一量得到的層
• Residue（結構性硬邊界）：enforcement（強制 main-loop 離開 fable）hook 永遠辦不到，即使 rate-limit-proxy Phase 2：依真實 budget 主動排程（delay / 佇列 / block） #7 proxy 也只能觀測/警告。

本 issue 建議保持 OPEN，掛成 #7 的 motivating use-case（核心解在那）；或你要 close 成「documented gap + best-effort done」也可。互補的 teammate-spawn 那半（#21 F5）已於 v1.13.0 released。