fix(aiops): suppress repeated llm alert loops

docs/LOGBOOK.md

@@ -6,6 +6,21 @@
 
 ---
 
+## 2026-05-01 | LLM 鬼循環治理 — in-flight lock + stable cache + no-retry 2xx
+
+Claude Code 成本評估指出真正瓶頸不是外部 AI 費用，而是同一告警 0 秒重入、20 秒週期反覆呼叫 LLM、以及 HTTP 500 讓 Alertmanager 立即重試。結論：先修飛輪，再談 Gemini/Groq/Claude 訂閱；健康狀態下外部 provider 只應作為 capped fallback。
+
+### 完成
+- Alertmanager 同指紋新告警在排入背景 LLM 前先拿 Redis in-flight lock，TTL 10 分鐘；同秒或短時間重複 delivery 不再各自 spawn LLM task。
+- Alertmanager grouping 失敗改 fail-open 並留 log，不再因聚合服務小故障回 500 造成 Alertmanager retry storm。
+- Alertmanager 內部處理例外改成已接收的降級 2xx 回應，避免外部 retry 把同一事件打成 LLM 風暴；安全拒絕如外網來源仍維持 403。
+- OpenClaw cache key 改成 `prompt_family + alertname/category/namespace/target/severity/fingerprint`；annotations、message、SignOz 即時數值變動不再讓同一告警每次 miss cache。
+- 補 LLM cache / Alertmanager in-flight lock 單元測試，鎖住重複告警不得打穿 cache 的行為。
+
+### 驗證
+- `python3 -m py_compile apps/api/src/api/v1/webhooks.py apps/api/src/services/openclaw.py` 通過。
+- `cd apps/api && pytest tests/test_alertmanager_rule_bypass.py tests/test_openclaw_cache_key.py tests/test_callback_dispatcher.py tests/test_telegram_button_consistency.py -q` → 60 passed。
+
 ## 2026-05-01 | HostBackupFailed rule-first e2e 補洞
 
 Live e2e 用 `HostBackupFailed` 打 Alertmanager 後發現 aged backup 告警會被分類成 `backup_failure`，未命中原本只允許 `host_resource` 的 rule-first gate，導致又進 OpenClaw LLM。

docs/adr/ADR-058-host-auto-repair-ssh-whitelist.md

@@ -182,6 +182,29 @@ If SSH MCP fails, the incident must not silently become a manual approval card;
 
 ---
 
+## Appendix C — LLM Ghost Loop Controls (2026-05-01)
+
+Alertmanager 重複 delivery、修復失敗後告警仍 firing、以及 provider timeout/500 會形成「告警 → LLM → 修復失敗 → 20 秒後再 LLM」的鬼循環。這不是 AI 訂閱費用問題，而是飛輪收斂問題。
+
+### 必須維持的控制
+
+| 控制 | 行為 |
+|------|------|
+| Alertmanager in-flight lock | 同一 fingerprint 排入背景 LLM 前必須取得 Redis `alertmanager:llm_inflight:{fingerprint}`，TTL 10 分鐘 |
+| Stable LLM cache key | 有 alert context 時，OpenClaw cache key 不得使用完整動態 prompt；必須使用 prompt family + stable alert dimensions |
+| No retry storm | Alertmanager webhook 已完成來源驗證後，內部處理錯誤應回 2xx degraded accepted，不回 500 觸發 Alertmanager 重試 |
+| Learning after blocked automation | executor 後成功/失敗必須寫 KM；executor 前 guard block 也應優先沉澱成 KM/AOL/timeline，避免下一次同告警重跑完整 LLM |
+| Paid provider policy | Gemini/Groq/Claude/OpenRouter 只能作為 rate-limited fallback 或高複雜度專家路徑；不得用付費 provider 掩蓋 dedupe/cache/retry 問題 |
+
+### 健康狀態判準
+
+- 同一 fingerprint 10 分鐘內最多一個背景 LLM analysis task。
+- 重複告警應命中 DB convergence、Redis in-flight lock、rule-first、Playbook/KM/RAG、或 LLM cache 其中一層。
+- 外部 provider 用量應接近「新問題數」而不是「告警 delivery 數」。
+- HTTP 500 比例不得由已接收告警的後處理錯誤造成；若有 500，需先確認是否在來源驗證/反序列化前失敗。
+
+---
+
 ## 首席架構師 Review 記錄 (2026-04-05)
 
 評分：**72/100 → 修正後 88/100**