fix(ollama): cooldown noisy failed endpoints

docs/LOGBOOK.md

@@ -1,3 +1,81 @@
+## 2026-05-25｜T173 GCP upstream 紅燈驗證與 Ollama endpoint cooldown 降噪
+
+**背景**：
+
+- T172 已恢復 production `GCP-A -> GCP-B -> 111 -> Gemini` 順序，且 111 fallback 已正常承接。
+- production `/api/v1/health` 仍 degraded，原因是 110 proxy 對 GCP-A/GCP-B upstream 回 502 / connection refused。
+- nginx error log 顯示大量 `POST /api/embeddings` 反覆打 `11435/11436`，在 GCP-A/B 已知 offline 時造成不必要的 latency 與 log 噪音。
+
+**live 驗證結論**：
+
+- 本機與 110 直打：
+  - `34.143.170.20:11434` -> connection refused。
+  - `34.21.145.224:11434` -> connection refused。
+- SSH：
+  - GCP-A `34.143.170.20:22` -> connection refused。
+  - GCP-B `34.21.145.224:22` -> port open，但現有 `owen_taipei` / `oleetsai` / 常見 user + 本機 key 均 publickey denied。
+- GCP 控制面：
+  - `owen.hy.tsai@gmail.com` 與 `owen.tsai@gmail.com` 均缺 `compute.instances.list` / `compute.firewalls.list` / `getIamPolicy` 權限。
+- 判讀：目前無法從本 session 直接修 GCP VM / firewall / OS service；需要具 Compute/IAM 權限者恢復 GCP-A/B，或提供可用 SSH key。
+
+**本次修補**：
+
+- 新增 `ollama_endpoint_circuit_breaker.py`：
+  - 短 TTL in-process cooldown，預設 60 秒。
+  - 不改 ADR-110 policy order；只在高頻 embedding/RAG 路徑暫時略過剛失敗的 endpoint。
+  - 若所有 endpoint 都被 cooldown，回到完整順序，避免永遠不探測恢復。
+- 偵測到 main 上曾短暫把 `OLLAMA_URL` / `OLLAMA_SECONDARY_URL` 都切到 `11437`；這會讓 `ollama_gcp_a` label 實際指向 111，造成 Operator 誤判。
+- 本輪改回 manifest：`11435 -> GCP-A`、`11436 -> GCP-B`、`11437 -> 111`，讓 policy / label / frontend 事實保持一致。
+- 接入高頻路徑：
+  - `embedding_service.py`
+  - `knowledge_rag_service.py`
+  - `playbook_rag.py`
+- 成功時會清除 cooldown；network/timeout/5xx 失敗才短暫標記，不因 4xx 或資料錯誤誤封 endpoint。
+- 前端/health/failover status 不套用 cooldown，仍會顯示 GCP-A/B 真實紅燈，不消音、不假裝 healthy。
+
+**local verification**：
+
+```text
+py_compile:
+  ollama_endpoint_circuit_breaker.py
+  embedding_service.py
+  knowledge_rag_service.py
+  playbook_rag.py
+  test_ollama_endpoint_circuit_breaker.py
+  -> ok
+ruff F/E9 targeted -> passed
+pytest:
+  test_ollama_endpoint_circuit_breaker.py
+  test_ollama_endpoint_resolver.py
+  test_playbook_service.py
+  -> 23 passed
+git diff --check -> ok
+```
+
+**注意 / 下一步**：
+
+- 這不是修復 GCP-A/B；它是 runtime 降噪與 latency 保護。
+- GCP-A/B 的真正修復仍需：
+  - GCP Compute IAM：`compute.instances.get/list`、`compute.firewalls.list/update`、必要時 serial console / reset 權限。
+  - 或可用 SSH key，能進 GCP-B 檢查 `systemctl status ollama`、`ss -tlnp`、`ufw/iptables`、`OLLAMA_HOST`。
+- 權限恢復後，優先修 GCP-B，因為 SSH port 已開；GCP-A 則先查 VM 狀態 / firewall / SSH service。
+
+**目前整體進度**：
+
+- AwoooP 告警可觀測鏈：約 99.2%。
+- 低風險自動修復閉環：約 95.5%。
+- 前端 AI 自動化管理介面同步：約 96.4%。
+- Telegram detail/history 可解釋性：約 95.5%。
+- Callback evidence / DB 回放性：約 95.6%。
+- MCP / 自建 MCP 使用可視性：約 88%。
+- Sentry / SigNoz source correlation 可視性：約 88%。
+- Ansible / PlayBook 決策可視性：約 84.8%。
+- KM owner-review / completion 可治理鏈：約 84%。
+- AI Provider lane 健康度：約 84%（111 fallback 正常；GCP-A/B 仍待 Compute/SSH 權限修復；高頻路徑已降噪）。
+- 完整 AI 自動化管理產品化：約 93.9%。
+
+---
+
 ## 2026-05-25｜T172 Ollama Provider lane 恢復 111 fallback 接線
 
 **背景**：