wooo/awoooi
1
1
Fork 0
Code Issues 2 Pull Requests 1 Actions 7 Packages Projects Releases Wiki Activity
1,685 Commits 195 Branches 2 Tags
7f4088bcd0d99600b830c1ccdbdecdabed376ad3
Commit Graph

105 Commits

Author SHA1 Message Date
Your Name
7f4088bcd0 fix(aiops-p0): 六大病根 P0 全面修復（ADR-092 B4） 
【P0.1】knowledge_extractor_service.py:210 — AttributeError 修復
- Signal.description 欄位不存在（100% 失敗，KM 每天+5 根因）
- 改用 alert_name + annotations.summary 拼接文字

【P0.2+P0.3】Gate 9+11 唯讀指令鬆綁
- blast_radius_calculator: kubectl get/top/describe/logs/version → score=1（非 50）
- operation_parser: 增加 INVESTIGATE 類型識別（唯讀 kubectl 不回 None）
- executor.py: OperationType 新增 INVESTIGATE enum
- approval_execution.py: INVESTIGATE 路徑直接呼叫 execute_kubectl_command

【P0.4】MCP SSH/K8s Provider 修復
- decision_manager: params= → parameters=（符合 MCPToolProvider.execute 簽名）
- decision_manager: MCPToolResult .get() → .success/.output（dataclass 用法）
- decision_manager + ssh_provider: 補入 hosts 120/121（原 default 缺失）
- auto_approve: phase2_agent_debate source bypass confidence 閾值

【P0.5】告警規則語義矛盾修復
- alert_rules.yaml: 8 條 kubectl 查詢規則 RESTART_DEPLOYMENT → NO_ACTION
  (CrashLoopBackOff/PostgreSQL 連線/慢查詢/MinIO 磁碟/K3s 節點/告警鏈路/SSL/CoreDNS 等)
- incident_service.py: cAdvisor/CoreDNS 從 general 拆出獨立分類

【P0.6】proactive_inspector 動態基線 PromQL 全修
- 5 個 MONITORED_METRICS PromQL 全部修正（cadvisor label/datname/blackbox）
- db_connection_pool: datname="awoooi" → "awoooi_prod"
- http_error_rate: 無效 http_requests_total → blackbox probe_success
- cpu/memory: namespace label → name=~"k8s_api_awoooi-api.*"

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
 2026-04-24 15:32:23 +08:00
Your Name
45dbe07188 fix(flywheel): 自動化飛輪六大能力修復（ADR-092 B3）
Some checks failed
run-migration / migrate (push) Failing after 22s
Details
Deploy Alert Rules / Deploy Prometheus Alert Rules (push) Successful in 53s
Details
Type Sync Check / check-type-sync (push) Successful in 2m54s
Details
CD Pipeline / build-and-deploy (push) Has been cancelled
Details
Ansible Lint / lint (push) Has been cancelled
Details 
【根因鏈修復】
MCP Provider bugs → PreDecisionInvestigator 失敗 → Agent Debate 無上下文
→ LLM 逾時 → description="待分析" → ADR-091 鐵閘攔截 → tg_sent 未設
→ W-2 Watchdog 誤報「靜默故障」

【六大修復】
1. MCP Provider 三蟲修復
   - ssh_provider: asyncssh.run() → conn.run()
   - prometheus_provider: KeyError 'query' → .get() 容錯
   - k8s_provider: 空 pod_name → 早返回錯誤字典

2. Agent Debate / 決策品質
   - decision_manager: 逾時降級文字改為明確描述（繞過 ADR-091 鐵閘）
   - intent_classifier: LLM 逾時降級至關鍵字分類（非 None）

3. Watchdog 誤報修復（ADR-092 B3）
   - W-2: tg_sent Redis TTL → telegram_message_id IS NULL（DB 真值）
   - W-5 新增: suggested_action IN 空/待分析/NO_ACTION + tg_id IS NULL
   - approval_timeout_resolver: 60min → 15min，batch 50 → 200

4. Config Drift 自動化
   - drift_adopt_service: auto_adopt_if_safe() 六條件安全閘
   - drift.py: 背景任務先嘗試自動採納再發人工 Telegram 卡片

5. Playbook 飛輪穩定
   - playbook_seed_service: 修復幂等性（deprecated 不視為缺失）
   - playbook_evolver: 只載 DRAFT+APPROVED（非全部 294 筆）

6. 可觀測性
   - alert_rule_engine: auto_rule 結構化日誌 + Redis 計數器（pipeline）
   - auto_approve: reject 原因 Redis 計數器
   - heartbeat_report_service: 新增「⚙️ 自動化統計（今日）」區塊

【待人工執行】
psql $DATABASE_URL -f apps/api/migrations/cleanup_duplicate_deprecated_playbooks.sql

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
 2026-04-24 10:55:50 +08:00
OG T
cf50a5ce25 fix(solver+execution): Checkpoint-1 假成功修復 + Checkpoint-2 K8s 環境感知
All checks were successful
CD Pipeline / build-and-deploy (push) Successful in 10m55s
Details 
## Checkpoint-1: 假成功根治
- approval_execution.py: execute_approved_action 改返回 bool
  (原返回 None，呼叫端無法判斷 K8s 是否接受指令)
- decision_manager.py auto-execute 路徑: 用 _exec_success 取代硬編 success=True
  修復: K8s 拒絕指令時正確發 ❌ 而非 ✅ 自動修復完成

## Checkpoint-2: K8s 環境感知 (Inventory Pre-flight)
- solver_agent.py: 新增 _fetch_k8s_inventory() — 生成 kubectl 指令前先拉
  kubectl get deployments,statefulsets -n awoooi-prod，將真實名稱清單
  注入 Solver prompt，LLM 必須從清單選擇，防止幻覺（awooiii-api 三個 i）
- 超時 5s 或失敗 → 返回 ""，prompt 顯示警示但不中斷主流程

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
 2026-04-17 23:08:23 +08:00
OG T
cbb719b4a1 fix(decision_manager): ADR-091 hotfix — 修復 d5dbfc9 喪屍閘門邏輯漏洞
All checks were successful
CD Pipeline / build-and-deploy (push) Successful in 11m9s
Details 
d5dbfc9 引入的閘門條件 `not action.strip()` 在 action="待分析" 時
判斷為 False（非空字串），導致閘門失效，喪屍卡片仍然突圍廣播。

根本原因：c759b4e P1 修復讓 suggested_action fallback 為 "待分析"
而非 ""，使原本的 empty-string 檢查形同虛設。

修復：改用集合判斷 `_action_text in {"", "待分析", "NO_ACTION", "待分析 - 系統自動保護"}`，
涵蓋所有已知失敗狀態 token，完全封堵喪屍卡片廣播路徑。

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
 2026-04-17 22:44:53 +08:00
OG T
af2adb5b96 fix(telegram): ADR-091 禁止 Agent Debate 分析失敗時廣播「待分析」喪屍卡片
All checks were successful
CD Pipeline / build-and-deploy (push) Successful in 10m51s
Details 
問題根因:
  GET /incidents 觸發 Phase 2 Agent Debate → LLM 全失敗
  → description="待分析" + action="" → 每隔幾分鐘廣播新 Telegram 卡片
  → 告警疲勞（SRE 最致命的殺手）

架構缺陷 (anti-pattern):
  GET 請求（讀取操作）產生對外廣播副作用 → 違反 RESTful 原則

修復 (_push_decision_to_telegram):
  在 DB 更新完成後、Telegram 推送前加入閘門：
  description="待分析" AND action="" → 靜默退出，絕不廣播

ADR-091 鐵律:
  只有 Alertmanager Webhook POST（真實新告警）可觸發 Telegram 廣播
  Agent Debate 失敗分析 → 靜默 DB 更新，不污染頻道

2026-04-17 ogt + Claude Sonnet 4.6

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
 2026-04-17 22:26:35 +08:00
OG T
c759b4eeab fix(webhook+decision): ADR-089 async webhook + 超時髒資料修復
All checks were successful
CD Pipeline / build-and-deploy (push) Successful in 10m16s
Details 
P0 — Webhook async (ADR-089):
- Alertmanager 收到告警立即回 202，不再同步等 90s LLM
- 新增 _process_new_alert_background()：LLM 分析/Approval/Incident/Telegram 全進背景
- 根治 Alertmanager Fallback 風暴（超時 → 重送 → 指數退避風暴）

P1 — 超時髒資料 (decision_manager):
- _package_to_proposal_data: blocked_reason 禁止進 desc_parts（禁進卡片）
- _push_decision_to_telegram: suggested_action fallback 改「待分析」，禁止 description 流入

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
 2026-04-17 16:29:24 +08:00
OG T
1ae9e9f389 fix(code-review): P0-1 action fallback 語意修正 + P1-2 reason enum + P2-2 secops 清洗
All checks were successful
CD Pipeline / build-and-deploy (push) Successful in 10m7s
Details 
Code Review 發現 (2026-04-17 首席架構師審查):

P0-1 auto_approve.py 條件 1d 語意修正:
- 原：用 `action` 變數（已 fallback = action or kubectl_command）做 kubectl 判斷
  → action="" + kubectl_command="kubectl get pods" → action="kubectl get pods" → 1d 通過
  → _kubectl_cmd 與 action 同值（重複判斷同一來源），掩蓋 action 本身是自然語言的情況
- 修：改用 proposal_data.get("action", "") 原始值（_raw_action）
  → 直接檢查 action 欄位本身，邏輯語意明確

P1-2 auto_approve.py NO_EXECUTABLE_ACTION 新增:
- 新增 AutoApproveReason.NO_EXECUTABLE_ACTION enum 值
- 條件 1d 改用此 reason（原 NO_PLAYBOOK 語意為「無匹配 Playbook」，不適用此場景）
- 避免污染 KM 飛輪學習資料的根因分類（ADR-068）

P2-2 decision_manager.py secops 分支:
- threat_behavior 改用 _parse_debate_summary → 取 diagnosis 欄位
- 與 BUG-A/BUG-C 修復一致，不再傾倒完整 debate_summary 前 150 字

ADR-082: Phase 2 多 Agent 協作
2026-04-17 ogt + Claude Sonnet 4.6（亞太）: Code Review 後修正

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
 2026-04-17 15:23:35 +08:00
OG T
f421e652d3 fix(telegram): BUG-C TYPE-3 排版清洗 + 批准/拒絕永遠置頂（ADR-075 UI 第三波修復）
Some checks failed
CD Pipeline / build-and-deploy (push) Has been cancelled
Details 
Checkpoint 1 — decision_manager.py TYPE-3 root_cause 清洗:
- 舊: root_cause=_smt(reasoning, 500) → debate_summary 全文（診斷/方案/審查/質疑）全部傾倒到 AI 診斷欄
- 新: _parse_debate_summary 只取 diagnosis 欄位 + _smt 截斷 300 字
- 移除 _requires_human 變數（已無用途）

Checkpoint 2 — telegram_gateway.py _build_inline_keyboard 按鈕順序重構:
- 舊: K8s 類別按鈕置頂，批准/拒絕受 requires_human_approval 控制 → 死卡
- 新: [✅ 批准][❌ 拒絕] 永遠第一行，K8s/DB/Host 操作按鈕置後
- 移除 requires_human_approval 參數（邏輯已簡化為無條件置頂）

修改範圍: decision_manager.py else 路由段 + _build_inline_keyboard + send_approval_card 簽名，
telegram_gateway.py 模板/訊息格式零改動。

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
 2026-04-17 14:42:29 +08:00
OG T
418d73540b fix(telegram): BUG-A TYPE-1 + BUG-B TYPE-4D 資料前處理（ADR-075 UI 第二波修復）
All checks were successful
CD Pipeline / build-and-deploy (push) Successful in 10m25s
Details 
BUG-A (TYPE-1 純資訊通知):
- 舊: message=reasoning[:200] → debate_summary 全文傾倒（診斷/方案/審查/質疑一起出現）
- 新: _parse_debate_summary(reasoning) 只取 diagnosis 欄位 + _smt 截斷 200 字

BUG-B (TYPE-4D Config Drift):
- 舊: diff_summary=description[:500] → LLM 輸出的 JSON 原文直接顯示在 <pre> 區塊
- 新: JSON Catcher — json.loads(description) 成功則格式化「📝建議操作/📖說明/⏪回滾方案」
       失敗 (JSONDecodeError/TypeError/AttributeError) → 平滑降級為純文字截斷

僅修改 decision_manager.py 路由準備段，telegram_gateway.py 模板層零改動。

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
 2026-04-17 14:14:10 +08:00
OG T
6baa2e91da fix(telegram): 修復死卡按鈕 + 重複渲染 + 智能截斷三連修
All checks were successful
CD Pipeline / build-and-deploy (push) Successful in 10m26s
Details 
問題 1 — 批准/拒絕按鈕消失（死卡）
根因：_build_inline_keyboard 有 alert_category 動態按鈕時走 category 路徑，
      approve/reject 行被跳過 → requires_human_approval 卡片無審核扳機
修復：新增 requires_human_approval 參數；True 時強制在動態按鈕後插入批准/拒絕行
影響：decision_manager 傳入 proposal_data.requires_human_review

問題 2 — TYPE-8M 三欄重複渲染
根因：diagnosis/system_impact/probable_cause 全用 reasoning[:100] → 同一段字
修復：新增 _parse_debate_summary()，拆分 debate_summary 的「診斷/方案/安全審查/質疑」
      各欄位填入不同語意的組件

問題 3 — 幽靈截斷「質疑：無（通」
根因：粗暴 [:N] 在括號/中文字中間切斷
修復：新增 _smart_truncate()，在句子邊界（。！？；，）截斷，補 …[截斷] 標記

驗證：verify_telegram_ui.py 全部通過（括號平衡 ✅、欄位不重複 ✅、按鈕存在 ✅）

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
 2026-04-17 13:57:42 +08:00
OG T
0ab92c20d6 fix(telegram): root_cause 截斷上限 300→500 — 修復「質疑：無（通」幽靈重現
All checks were successful
CD Pipeline / build-and-deploy (push) Successful in 10m31s
Details 
根因：debate_summary 結構為「診斷（≤220字）；方案；安全審查；質疑」
      診斷假設長時總長超過 300 chars → root_cause 截斷在「通」字
修復：300 → 500（Telegram 單卡 4096 限制，安全）

2026-04-17 ogt + Claude Sonnet 4.6

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
 2026-04-17 13:28:16 +08:00
OG T
b7c2b691bb fix(p2-backlog): 修復 suggested_action「待分析」— action 空時 fallback 到 description
Some checks failed
CD Pipeline / build-and-deploy (push) Failing after 1m26s
Details 
根因：_push_decision_to_telegram() 的 suggested_action 只有兩條路：
- action 有值 → 顯示 action[:120]
- action 空   → 顯示「待分析」

但 _package_to_proposal_data() 已從 hypothesis 組出 description
（含「根因：...（信心 X%）；方案：...」），此時 action="" 卻還是顯示「待分析」
導致 SRE 在 Telegram 卡片看不到 AI 的診斷結論。

修復：action 空時，優先用 description[:120] 作為 suggested_action
（description 已包含根因摘要，比「待分析」有意義）
fallback chain: action → description → "待分析"

2026-04-17 ogt + Claude Sonnet 4.6

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
 2026-04-17 11:48:49 +08:00
OG T
0388e50d0e fix(p1-backlog): 修復「待分析」死結與 Telegram 訊息截斷
All checks were successful
CD Pipeline / build-and-deploy (push) Successful in 30m25s
Details 
問題 1：REQUEST_REVISION → 待分析
  根因：safe_candidates=[] → selected=None → recommended_action=None
        → decision_manager action="" → TG 卡顯示「待分析」（資訊流斷裂）
  修復 coordinator_agent.py：
    無安全候選時回退至 Solver 原始最優方案
    標記「[Reviewer 未核准，僅供參考] {action}」
    SRE 永遠能看到 AI 建議，資訊流絕不中斷

問題 2：debate_summary 在 (blast_radius... 中間截斷顯示 (bl
  根因：root_cause=reasoning[:150] — 150 字元對中文 debate_summary 過短
  修復 decision_manager.py：
    root_cause 截斷 150 → 300
    suggested_action 截斷 80 → 120

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
 2026-04-17 11:12:02 +08:00
OG T
0c15fa5988 refactor(decision): 狀態機重構 — YAML NO_ACTION 閘門上移至決策路由中樞
Some checks failed
CD Pipeline / build-and-deploy (push) Has been cancelled
Details 
架構師指令（2026-04-17）：通知層禁止查詢業務邏輯。
撤銷 c05bcdb 的 inline YAML 查詢（義大利麵補丁），
將 NO_ACTION / INVALID_TARGET 判斷移至正確位置。

重構方向：
① 移除 _push_decision_to_telegram() 的 inline YAML 查詢
  → 通知層只做 blocked_reason → NotificationType 轉譯（Single Responsibility）

② 新增 decide() 第 4c 步：YAML NO_ACTION 路由閘門
  位置：_dual_engine_analyze() 返回後、auto_approve.evaluate() 之前
  邏輯：
    - NO_ACTION → blocked_reason="YAML: NO_ACTION" + is_informational_only=True
      → 短路跳過 auto_approve + Blast Radius → TYPE-1（或 critical → TYPE-4）
    - INVALID_TARGET → blocked_reason="INVALID_TARGET-..." → 短路 → TYPE-4
    - 閘門查詢失敗 → 靜默降級，繼續正常流程

Checkpoint 覆蓋：
  CP1 上移 YAML 評估層 ✅
  CP2 短路跳過 auto_approve ✅
  CP3 通知層純粹轉譯 ✅

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
 2026-04-17 10:20:01 +08:00
OG T
c05bcdbbd4 fix(decision): inline YAML NO_ACTION 補查 — 修復 Phase 2 路徑盲點
Some checks failed
CD Pipeline / build-and-deploy (push) Failing after 4m0s
Details 
根因：Phase 2 (agent debate → auto_approve 拒絕 → 直接推 TG) 不經過
      auto_execute() 的 YAML check，Coordinator 不設 blocked_reason。
      PostgreSQL disk / host resource 等 NO_ACTION 規則告警在 Phase 2
      路徑仍顯示「ACTION REQUIRED」卡片（TYPE-3），而非 TYPE-1 資訊卡。

修復：_push_decision_to_telegram() 在 blocked_reason 為空時，補做一次
      alertname inline YAML 查詢，任何路徑（Phase 2 / Expert / Webhook）
      都能正確偵測 NO_ACTION → TYPE-1 / critical NO_ACTION → TYPE-4。

生產驗證觸發：INC-20260416-C365D0 PostgreSQL disk alert 顯示 ACTION REQUIRED
             而非 TYPE-1，確認全景 Code Review 遺漏此執行路徑。

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
 2026-04-17 10:15:28 +08:00
OG T
83ab5e32d7 fix(happy-path): Happy Path 全境加固 — INVALID_TARGET + critical NO_ACTION + 空指令攔截
Some checks failed
CD Pipeline / build-and-deploy (push) Has been cancelled
Details 
問題 1 (P0) — deployment/unknown 無效重啟：
- alert_rule_engine: 追蹤 _invalid_target flag，回傳 blocked_reason="INVALID_TARGET-..."
- decision_manager: auto_execute 路徑偵測 INVALID_TARGET → 提早返回 + TYPE-4 人工確認
- auto_approve: 新增條件 1c — action 為空字串直接拒絕，防止誤報「即將執行」

問題 2 (P1) — critical+NO_ACTION 靜默：
- decision_manager: blocked_reason 感知層重構
  ① INVALID_TARGET → TYPE-4
  ② NO_ACTION + critical → TYPE-4（升級，SRE 不可錯過）
  ③ NO_ACTION + 非 critical → TYPE-1（維持純資訊卡）

問題 3 (P1) — 規則匹配信心黑洞：
- auto_approve 條件 1c 確保空 action 不通過 auto-approve
  即便 is_rule_based=True 也無法在無指令時自動執行

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
 2026-04-16 22:57:50 +08:00
OG T
92b39ab840 fix(no-action-notify): YAML NO_ACTION 告警改為 TYPE-1 資訊通知（移除無意義審核按鈕）
Some checks failed
CD Pipeline / build-and-deploy (push) Has been cancelled
Details 
根因：
- host_resource/postgresql_disk_monitoring YAML 規則設 NO_ACTION
- 但 classify_notification() 不知道 NO_ACTION
- confidence=0.2（感應器無資料）→ 判為 TYPE-4（信心不足需人工審核）
- SRE 看到「審核批准/拒絕」按鈕，卻沒有任何自動修復動作可執行 → 毫無意義

修復：
- _push_decision_to_telegram 偵測 blocked_reason 含 "NO_ACTION"
- 強制 _notif_type = TYPE-1（純資訊通知，無審核按鈕）
- SRE 看到資訊卡「主機 CPU/負載/磁碟告警 (觀察即可)」而非假的審核請求

2026-04-16 ogt + Claude Sonnet 4.6 (台北時區)

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
 2026-04-16 22:37:15 +08:00
OG T
54d6818b8d fix(sensors+rules+dedup): 全景三根因修復 — asyncssh缺失/YAML規則空洞/重複卡片
Some checks failed
CD Pipeline / build-and-deploy (push) Has been cancelled
Details 
Fix 1: asyncssh 未安裝 → sensors_succeeded 永遠=0
  - apps/api/pyproject.toml 加入 asyncssh>=2.14.0
  - 根因：ssh_provider.py 的 import asyncssh 在 try/except 外，ImportError 直接噴出
  - 效果：15 個 SSH tool 全部恢復可用

Fix 2: YAML 規則空洞 → HostHighLoadAverage/PostgreSQLDiskGrowthRate 落 generic_fallback → restart
  - 合併 host_cpu_high 為 host_resource_alert，覆蓋 25+ 個主機層 alertname
  - 新增 postgresql_disk_monitoring 規則，覆蓋磁碟增長/exporter/vacuum 類告警
  - 所有主機層/磁碟監控告警 → NO_ACTION，禁止 kubectl restart

Fix 3: 同一 incident 被多 pod 同時處理 → 送出 3 張重複 Telegram 卡
  - decision_manager.get_or_create_decision(): ANALYZING 狀態加入早返回
  - 根因：ANALYZING 不在 (READY/EXECUTING/COMPLETED) 條件 → pod-B/C 各自建新 token

2026-04-16 ogt + Claude Sonnet 4.6 (台北時區)
 2026-04-16 22:23:49 +08:00
OG T
513232e90b fix(decision_manager): Agent 分析結果覆寫 Webhook 垃圾 action
All checks were successful
CD Pipeline / build-and-deploy (push) Successful in 28m30s
Details 
根因 (INC-20260416-C365D0 事故完整根因分析):
- Webhook inline LLM 建立 ApprovalRecord.action = "kubectl rollout restart awoooi-prod"
- Agent 分析正確（postgres disk → NO_ACTION）但只發新 Telegram 卡，未覆寫 DB
- 用戶批准 Agent 卡 → 系統查 incident_id → 找到 Webhook 舊 ApprovalRecord
  → 執行垃圾 action（rollout restart 一個磁碟告警！）

修復:
- approval_db.py: 新增 update_action_by_incident_id()（按 incident_id 更新 PENDING 記錄）
- decision_manager.py: Agent 確認 action 後立即覆寫 ApprovalRecord
  若 action="" (NO_ACTION): 存 "NO_ACTION - {description}" 讓用戶知道 Agent 建議觀察
  用戶批准時執行的是 Agent 的正確建議，而非 Webhook 的通用 action

2026-04-16 ogt + Claude Sonnet 4.6（亞太）

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
 2026-04-16 20:07:15 +08:00
OG T
8b2a3df64b fix(telegram): 修復 Telegram 卡片 description 顯示 debug garbage
Some checks failed
CD Pipeline / build-and-deploy (push) Failing after 3m12s
Details 
問題：description = debate_summary[:500]，用戶看到的是內部審計文字
修復：從 diagnosis.top_hypothesis + action_plan.top_candidate 組出人類可讀摘要
格式：「根因：[描述]（信心 X%）；方案：[動作]」

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
 2026-04-16 18:42:13 +08:00
OG T
27ba97e586 fix(ollama): 清除所有硬寫 188:11434 fallback — 全部改指向 111 GPU
All checks were successful
CD Pipeline / build-and-deploy (push) Successful in 15m59s
Details 
- decision_manager.py: 兩處 getattr fallback 188 → 111
- routes/agent.py: OLLAMA_BASE_URL 188 → 111
- knowledge_extractor_service.py: _OLLAMA_BASE 188 → 111

config.py 預設早已是 111，此次清掉 code 層殘留的 188 硬寫值。

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
 2026-04-16 03:01:31 +08:00
OG T
5a3a649f8a fix(decision): TYPE-1 告警重複洗版兩個根因修復
Some checks failed
CD Pipeline / build-and-deploy (push) Has been cancelled
Details 
根因 1: TYPE-1 bypass 在 existing_token 檢查之前執行
→ 每次 get_or_create_decision() 不管 token 是否存在，都直接推 TG
→ 修復: existing_token 檢查提前到 TYPE-1 bypass 之前（統一入口）

根因 2: TYPE-1 token TTL 僅 3600s
→ 1h 後 token 過期，下次掃描重新建立並再推 TG
→ 修復: TYPE-1 token TTL 提升至 86400s (24h)

影響: HostBackupFailed 等 TYPE-1 告警每個 incident 只推 1 次（24h 內）

2026-04-16 ogt + Claude Sonnet 4.6

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
 2026-04-16 02:49:31 +08:00
OG T
62bcc50770 fix(tg+km): 補齊 Telegram 操作紀錄揭露與 KM 分類修復 (ADR-076)
Some checks failed
CD Pipeline / build-and-deploy (push) Has been cancelled
Details 
Telegram 訊息新增欄位：
- alert_category 分類標籤（🏷️ 主機/K8s/資料庫/服務等）
- playbook_name 顯示匹配到的 Playbook 名稱
- 頻率統計從 count_24h>1 降至 >=1（初次告警也顯示）
- TelegramMessage 新增 alert_category/playbook_name 欄位
- decision_manager → send_approval_card 穿透 playbook_name

KM 修復：
- EntryType.PLAYBOOK → EntryType.AUTO_RUNBOOK（前者不存在，會 AttributeError）
- category "auto_generated" → "ai_system"（前端 i18n 有對應翻譯）
- runbook_generator 同步修正 category
- KM 建立後推 Telegram 通知（best-effort）

DB decision_chain 補欄位：
- 新增 playbook_id / playbook_name / alert_category

2026-04-16 ogt + Claude Sonnet 4.6

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
 2026-04-16 02:46:17 +08:00
OG T
0760315059 fix(decision-manager): 修正 CAST 語法 + 關閉 shadow_mode
Some checks failed
CD Pipeline / build-and-deploy (push) Has been cancelled
Details 
decision_chain_persist_failed 根因:
  asyncpg 不支援 :dc::json 語法 (:: 與具名參數 : 衝突)
  改為 CAST(:dc AS jsonb) — asyncpg 標準寫法

configmap:
  AIOPS_P4_SHADOW_MODE: true → false
  真實主動監控啟用 (proactive_inspector 輸出供 PreDecisionInvestigator 讀取)

2026-04-16 Claude Sonnet 4.6 Asia/Taipei

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
 2026-04-16 01:24:48 +08:00
OG T
457018c0f9 fix(decision-manager): AI 分析結果寫入 incidents.decision_chain (DB 長期保存)
Some checks failed
CD Pipeline / build-and-deploy (push) Has been cancelled
Details 
修復 Gap: decision token 只有 Redis TTL 12min，AI 診斷歷史永久丟失
  - 新增 _persist_decision_to_db() method
  - get_or_create_decision() 完成後 fire-and-forget 寫入 PG
  - 寫入: ts / confidence / risk_level / provider / source / diagnosis[:200]
  - try/except 吞錯不影響主流程，warning log 追蹤

DB/Cache 分層:
  PG (長期): incidents.decision_chain (歷史) + outcomes + KM entries
  Redis (短期): decision token dedup + working memory + playbook cache

2026-04-16 Claude Sonnet 4.6 Asia/Taipei

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
 2026-04-16 01:08:30 +08:00
OG T
ecfb7148bf fix(prod): 接通 YAML 規則引擎與自動執行路徑 — 架構核心斷點
Some checks are pending
CD Pipeline / build-and-deploy (push) Has started running
Details 
架構斷點根因：
  YAML 規則引擎（alert_rules.yaml）是人工審閱的權威動作來源，
  但自動執行路徑只讀 proposal_data["kubectl_command"]（LLM 生成），
  兩者完全脫節 → HostHighCpuLoad 得到 kubectl restart，DockerContainerUnhealthy
  的 SSH 指令被 LLM 的 kubectl 覆蓋。

修復策略：
  在 auto_execute 入口，先查 YAML match_rule：
  1. YAML → NO_ACTION（如 HostHighCpuLoad）→ 立即返回，不執行任何操作
  2. YAML → 非 kubectl 指令（如 ssh docker restart）→ 覆蓋 LLM action，
     後續 infrastructure SSH 路由才能生效

影響：
  - HostHighCpuLoad / NodeCPUUsageHigh → 停止自動執行，降級人工審核
  - DockerContainerUnhealthy → SSH docker restart（若 labels 有 host/container）

2026-04-15 ogt + Claude Sonnet 4.6（亞太）: 生產緊急修復第三批

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
 2026-04-15 21:50:25 +08:00
OG T
3696fb5938 fix(prod): 修復 host_resource 誤發 K8s kubectl + 自動執行重複風暴
Some checks failed
CD Pipeline / build-and-deploy (push) Has been cancelled
Details 
1. decision_manager: host_resource 告警（HostHighCpuLoad 等）
   不得執行 kubectl 操作 → 降級人工審核
   根因：原本只擋 infrastructure，host_resource 漏進 K8s 路徑
   → 導致 kubectl rollout restart deployment/HostHighCpuLoad 被真實執行

2. decision_manager: auto_execute 路徑補入 Redis cooldown
   同一 target 5 分鐘內最多自動執行 2 次，防止 awoooi-worker 3x 風暴
   根因：decision_manager 自動執行路徑完全無冷卻保護

2026-04-15 ogt + Claude Sonnet 4.6（亞太）: 生產緊急修復第二批

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
 2026-04-15 21:45:46 +08:00
OG T
67f437043a fix(prod): 修復四個生產致命 bug — outcome 寫入 / OpenClaw / Telegram 通知 / LLM 規則顯示
Some checks failed
CD Pipeline / build-and-deploy (push) Has been cancelled
Details 
1. decision_manager: 移除 UPDATE incidents 中的 verification_result 欄位
   （incidents 表無此欄位 → 所有 outcome 寫入失敗 outcome_write_failed）

2. failure_watcher: get_openclaw_service → get_openclaw
   （函數名錯誤 → OpenClaw 分析全部 ImportError 崩潰）

3. failure_watcher: tg.send_message → tg.send_notification
   （TelegramGateway 無 send_message 方法 → 修復通知無法送出）

4. decision_manager: expert_analyze 補齊 initial_diagnosis / diagnosis_description key
   （openclaw.py 讀這兩個 key，但 expert_analyze 只有 matched_rule / description
    → LLM 永遠看到 Matched Rule=unknown，無法正確分析）

2026-04-15 ogt + Claude Sonnet 4.6（亞太）: 生產緊急修復

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
 2026-04-15 21:41:31 +08:00
OG T
65838708ce fix(format): 剩餘 send_notification raw text 改為 ADR-075 TYPE-X 格式
All checks were successful
CD Pipeline / build-and-deploy (push) Successful in 18m11s
Details 
- decision_manager.py: 自動修復通知改為 TYPE-2 ├─/└─ 樹狀格式
- gitea_webhook_service.py: Code Review 通知改為 TYPE-1 格式，移除 ═══ border

至此所有 3 個外部 send_notification 呼叫者均符合 ADR-075 格式規範：
  1. ai_router.py — TYPE-1 AI Provider 不可用（已於 3ce5025 修復）
  2. decision_manager.py — TYPE-2 自動修復完成/失敗（本 commit）
  3. gitea_webhook_service.py — TYPE-1 Code Review（本 commit）

2026-04-15 ogt + Claude Sonnet 4.6（亞太）: Phase 6 format enforcement

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
 2026-04-15 20:05:49 +08:00
OG T
fab65e7d7a fix(alerts): PENDING 收斂無 TTL → 老記錄永久封鎖 Telegram 告警
Some checks are pending
CD Pipeline / build-and-deploy (push) Has started running
Details 
根因：find_by_fingerprint 的 PENDING 匹配條件無時間上限，
2026-04-12 建立的 3 筆 PENDING approval records（hit=77/30/17）
持續吃掉所有同指紋告警，造成 2+ 小時 Telegram 靜音。

修正（approval_db.py）：
  - PENDING_TTL_HOURS = 24：PENDING 記錄逾 24h 不再收斂新告警
  - 原本：OR(status=PENDING, created_at>=30min前)
  - 修正：OR(PENDING AND created_at>=24h前, created_at>=30min前)

緊急修復：kubectl exec 直接將 7 筆過期 PENDING 記錄設為 expired，
即時恢復 Telegram 告警流（不等部署）。

Phase 6 AI 自我治理閉環（ADR-087）：
  - feat(db): 新增 ai_governance_events 表 + 3 個 index（base.py + models.py）
  - feat(svc): ai_slo_calculator.py — 7d 滾動 SLO（success/override/false_neg）
  - feat(svc): trust_drift_detector.py — Playbook 信任度極端偏態偵測
  - feat(job): kb_rot_cleaner.py — K8s API/Prom metric/老舊 incident_case 腐爛清理
  - feat(svc): decision_manager.py — 自我降級守衛（SLO 違反 → 提高門檻/保守模式）

2026-04-15 ogt + Claude Sonnet 4.6（亞太）

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
 2026-04-15 18:56:26 +08:00
OG T
655d1a568a feat(Phase 5): Declarative 修復抽象化 + Blast Radius 分控 全部完成
Some checks failed
CD Pipeline / build-and-deploy (push) Has been cancelled
Details 
## Phase 5 交付（ADR-086）

### 新增服務（4 個）
- blast_radius_calculator.py: 爆炸半徑計算器（0-100 純函數）
  - 18 種 kubectl 動作基礎分 + 命名空間倍率 + 特殊 flag 修正
  - HARD_RULES 永擋：delete ns/pv/pvc/clusterrole + rm -rf + DROP TABLE
  - 分級：≤10 auto / 11-50 human / 51-99 dual / 100 blocked
- declarative_remediation.py: DeclarativeSpec 不可變規格（frozen dataclass）
  - evaluate() 封裝 Blast Radius + dry-run + rollback_plan + constraints
  - rollback_plan 從 kubectl 動作類型自動推導（不呼叫 LLM）
- gitops_pr_service.py: Gitea Issue 高風險修復審核（tier=dual）
  - 含 Blast Radius + 目標狀態 + 回滾計畫 + 雙人審核流程
  - AIOPS_P5_GITOPS_PR flag 守衛
- rollback_manager.py: 驗證失敗自動回滾
  - 先驗 rollout history ≥ 2 revision，防止無版本可回滾
  - kubectl rollout undo + 120s 收斂等待

### decision_manager.py 接線（AIOPS_P5_BLAST_RADIUS_CHECK）
- _auto_execute() 在安全守衛後、ApprovalRequest 前插入分級守衛
- blocked → 永擋 + 人工審核通知
- dual → 非同步 GitOps Issue + 升級人工審核
- human → 升級人工審核（不自動執行）
- auto（≤10）→ 原有自動執行流程
- 失敗降級：計算異常 → 保守升人工

### learning_service.py
- record_declarative_outcome(): 記錄 DeclarativeSpec 執行結果
  anomaly_key=declarative:{incident_id}，含 blast_radius_score/tier/rollback

2026-04-15 ogt + Claude Sonnet 4.6（亞太）: Phase 5 全部完成

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
 2026-04-15 16:06:54 +08:00
OG T
7da64eaad2 feat(Phase 3): 學習閉環重建 — 三根因修復 + 2x EWMA + Evolver Agent
Some checks failed
CD Pipeline / build-and-deploy (push) Failing after 19m7s
Details
Type Sync Check / check-type-sync (push) Failing after 1m18s
Details 
ADR-083 Phase 3 學習閉環重建：

**三根因修復**
- approval_execution.py: fire-and-forget create_task → await asyncio.wait_for(timeout=30) × 2
  （成功路徑 L265 + 失敗路徑 L353，超時記錄 learning_trigger_timeout metric，主流程不 crash）
- models/approval.py: ApprovalRequestBase 新增 matched_playbook_id 欄位
- decision_manager.py: _auto_execute 建立 ApprovalRequest 時填充 matched_playbook_id
- learning_service.py: 雙路徑查找 _matched_pb_id（matched_playbook_id + metadata fallback）

**2x EWMA 負向強化**
- models/playbook.py: 新增 trust_score: float = 0.3（EWMA 動態信任度欄位）
- repositories/playbook_repository.py: update_stats 加 EWMA
  成功: trust = 0.9 × old + 0.1 × 1.0
  失敗: trust = 0.8 × old + 0.2 × 0.0（衰減速度 2x）
  trust < 0.1 → log warning，等 Evolver 封存

**Evolver Agent（新建）**
- services/playbook_evolver.py: 三功能全靜態規則
  1. 低信任封存: trust < 0.1 → DEPRECATED
  2. 休眠封存: 30d 未使用 AND trust < 0.5 → DEPRECATED
  3. 相似合併: 症狀 Jaccard > 0.9 → 保留高 trust，封存低 trust
  AIOPS_P3_EVOLVER_ENABLED=False 預設關閉

**文件**
- ADR-083 學習閉環重建
- MASTER §8 Phase 3 完工記錄

AIOPS_P3_ENABLED=False（預設），骨架就位等統帥批准開啟

Co-Authored-By: Claude Sonnet 4.6（亞太）<noreply@anthropic.com>
 2026-04-15 14:01:37 +08:00
OG T
5ddba6d6e0 feat(adr-082): Phase 2 多 Agent 協作 — 5 角色辯證系統骨架上線 
新增 5 個 Agent + Orchestrator + DecisionManager 接線：
- protocol.py: DiagnosisReport / ActionPlan / ReviewVerdict / CriticReport / DecisionPackage 型別系統
- DiagnosticianAgent: RCA 根因分析，confidence < 0.4 → ABSTAIN
- SolverAgent: 修復方案軍師，blast_radius 評分 + 降級 rule-based mock
- ReviewerAgent: 安全審查，HARD_RULES 靜態 pattern + blast_radius 閾值 (>50 revision, >80 reject)
- CriticAgent: 刻意唱反調，強制 3 問批判性思維，critical challenge → REJECT
- CoordinatorAgent: 純規則聚合，6 級決策閘，REQUEST_REVISION → 強制人工
- AgentOrchestrator: 30s 全局超時，Reviewer ‖ Critic 並行，DB Immutable Event Sourcing + Redis Streams
- DecisionManager: AIOPS_P2_ENABLED gate + _package_to_proposal_data 橋接既有 proposal_data 格式
- AgentSession DB table + 4 個複合 index
- ADR-082 決策記錄

Gate 2 修復（7 項）:
- CRITICAL: DELETE FROM regex lookahead 位置錯誤（移至 FROM 後）
- CRITICAL: REQUEST_REVISION 可抵達 auto-execute 路徑（改回 requires_human_approval=True）
- IMPORTANT: _extract_json flat regex 不支援巢狀 JSON（改 find/rfind 邊界提取）
- IMPORTANT: all_degraded 遺漏 verdict.degraded（補全 4 個 Agent）
- IMPORTANT: Solver ABSTAIN guard 放行降級假設（改為無論 hypotheses 有無均跳過）
- IMPORTANT: dataclasses.asdict() Enum 未序列化導致 DB 寫入靜默失敗（加 json.dumps default handler）
- IMPORTANT: P2 gate 直讀屬性繞過父 Phase 守衛（改用 is_phase_enabled(2)）

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
 2026-04-15 13:48:55 +08:00
OG T
f1cbf6db7d feat(adr-081): Phase 1 感官縱深 — 8D 情報蒐集 + 執行後驗證 
成品：
- IncidentEvidence DB model（8D 感官 + pre/post 執行狀態）
- EvidenceSnapshot dataclass（build_summary → LLM 上下文）
- SanitizationService（Prompt Injection 0-tolerance，12 pattern）
- MCPToolRegistry（動態工具登記，suggest_tools 不寫死告警類型）
- PreDecisionInvestigator（8D 並行感官，P99 < 8s，Redis 30s 快取）
- PostExecutionVerifier（warmup 10s → 後狀態評估 success/degraded/failed）
- decision_manager + approval_execution 接線（feature flag 守衛）

Gate 1 修復：D4/D5/D7/D8 補 sanitize_dict_values；移除裸 "error" failure
signal 防 error_rate key 誤判；evidence_snapshot rowcount 零行警告。

測試：130 passed（+111 新增）

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
 2026-04-15 13:08:38 +08:00
OG T
6c7f648b60 fix: 3 個飛輪沉默未打通節點 — 統帥截圖盤出
All checks were successful
CD Pipeline / build-and-deploy (push) Successful in 18m56s
Details 
統帥截圖證據 (Telegram MEDIUM 告警仍走人工審核):
INC-20260411-A03B2E / A2BB29 顯示「[規則匹配]」+ action=unknown-service

節點 1: AutoApprovePolicy 擋下規則匹配 (飛輪主因)
  - ADR-073 規則匹配 confidence=0.0 (防偽造)
  - AutoApprovePolicy.min_confidence=0.50 → 擋下
  - 結果: MEDIUM 規則匹配永遠人工審核，飛輪不轉
  修復: auto_approve.py 加 _is_rule_based 判斷
        (is_rule_based / source=expert_system / rule_id / matched_rule)
        → bypass min_confidence 檢查
        → 驗證: should_auto_approve=True ✅

節點 2: _is_bad_target 漏 unknown-service magic string
  - _resolve_target_from_k8s fallback 產 unknown-service / unknown-pod
  - GAP-A4 Phase 1/2 只擋 'unknown' 而非前綴
  修復: alert_rule_engine.py 加 unknown-/none-/null-/undefined- 前綴黑名單
        → 驗證: 4 個 magic 全 bad ✅

節點 3: stale_ready_tokens_resend 無時效過濾
  - 截圖是 2026-04-11 (4 天前) 告警
  - 舊 labels 過期，重 process 也產不出新 target
  - 壓爆 Ollama + 污染 Telegram 卡片
  修復: decision_manager.py 跳過 > 3 天的 stale incident
        → skip + log stale_ready_token_skipped_too_old

回歸: 113/113

Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
 2026-04-15 10:56:48 +08:00
OG T
ca862c5575 fix(GAP-A4 Phase 2): LLM 路徑 target 救援 — 解開 12 次飛輪攔截
Some checks failed
CD Pipeline / build-and-deploy (push) Has been cancelled
Details 
統帥全景報告診斷（2026-04-14 20:00）：
2h 內 12 次 auto_execute_blocked_unresolved_placeholder
全是 LLM 直接產出 `kubectl ... deployment HostHighCpuLoad`
GAP-A4 Phase 1 只修了 alert_rule_engine._extract_vars
但 LLM 在 decision_manager 路徑沒做同樣檢查 → 12 次擋下 → 0 KM 0 飛輪

修復 (decision_manager._auto_execute placeholder 替換後):
1. 從 action regex 提取 deployment 名（kubectl ... deployment XXX）
2. 套用 alert_rule_engine._is_bad_target() 驗證
3. 若是垃圾（==alertname/unknown/IP）→ 從 incident.signals[0].labels
   重推 (用 _extract_vars 同一套 multi-layer 邏輯)
4. 若有合法 target → action.replace(llm_target, good_target)
5. 若 labels 也救不了 → log target_rescue_failed → safety guard 處理

效果：
- KubePodCrashLooping (有 deployment label) → LLM 即使填錯也救回
- HostHighCpuLoad (純主機，無 K8s label) → 仍進 safety guard，
  但 log 變 target_rescue_failed 而非 unresolved_placeholder
- 12 次飛輪攔截可望大幅減少

回歸：66/66 (GAP-A4 + kubectl validation) 全過

Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
 2026-04-14 20:06:05 +08:00
OG T
8b7e9cbfb8 fix(BLOCKER): LLM 連續失敗 — 4 個違反設計處全部修復
All checks were successful
CD Pipeline / build-and-deploy (push) Successful in 14m21s
Details 
統帥盤點發現飛輪沉默真因：4 個違反既定架構設計的 bug 同時撞車。

P0a — Ollama timeout 違反 GAP-B4 設計
  config.py:OPENCLAW_TIMEOUT 從 120s 改 30s
  原 120s 違反 ADR-052 GAP-B4 (LLM 25s hard timeout) 設計
  致 Ollama 過載時 thread 飢餓 120s 才降級

P0b — AI Router silent skip 觀測性修復
  ai_router.py: not_registered/circuit_open/rate_limit/privacy_skip
  全部累積到 errors 陣列，log all_providers_failed 時可知為何 skip
  原本 errors=["ollama: Timeout"] 但 tried=4 個，無法診斷

P1a — send_text 方法不存在 bug
  ai_router.py:1005 tg.send_text() → tg.send_notification(parse_mode=HTML)
  TelegramGateway 只有 send_notification 沒 send_text
  致 fallback 失敗通知本身失敗（雙重靜默）

P1b — resend_stale_ready_tokens 並發爆炸
  decision_manager.py: 加 asyncio.Semaphore(5) + 200ms throttle
  原本 fire_and_forget N 個 task 同時跑，N=108 時 Ollama embedding
  全部 timeout，包括我打的 live-fire 也被擠爆
  改：max 5 並發 + 每完成喘 200ms

CD 流程審查 (Blocker 1): 完全符合 ADR-039 設計，10-15 min 是預期
不需修，是設計就需要這時間。

Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
 2026-04-14 19:37:03 +08:00
OG T
dd0a778e1f feat(GAP-B4): LLM 超時降級扶梯 — 精確化內層 timeout
All checks were successful
CD Pipeline / build-and-deploy (push) Successful in 14m19s
Details 
_dual_engine_analyze 強化（2026-04-14 Claude Sonnet 4.6）:
- OpenClaw LLM 呼叫獨立 25s hard timeout（留 5s 給後續處理）
- 超時時明確 llm_timeout_fallback 日誌，立即降級 Expert System
- NemoClaw second opinion 加 3s timeout（advisory 不拖累主流程）
- 保留外層 decide() 30s wait_for 作為 defence-in-depth

為何要做：
- 外層 30s 會把 LLM 卡死整段吃光，thread pool 可能飢餓
- 內層 25s 更早降級 → Expert System 仍能在 SLA 內回應
- LLM timeout 與其他異常用不同日誌標記，便於 SLO-2 監控

Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
 2026-04-14 15:51:23 +08:00
OG T
c0ba1000f3 Revert "fix(auto-repair): 中低風險+無kubectl_command → TYPE-1 純資訊，不顯示審核按鈕" 
This reverts commit abf1ffa91e7327a36af93be2742d53dac1933f0d.
 2026-04-14 13:33:24 +08:00
OG T
2df4945880 fix(auto-repair): 中低風險+無kubectl_command → TYPE-1 純資訊，不顯示審核按鈕 
問題: HostHighCpuLoad 等主機層告警 affected_services=[] → OpenClaw 生成
kubectl unknown → safety guard 攔截 → 退回 READY + TYPE-3 帶按鈕卡片
用戶一直看到帶按鈕的中/低風險告警，按鈕無法修復任何東西

修復三處:
1. openclaw.py: _call_openclaw_analyze() 回傳 suggested_action 欄位
   + target_resource 預設改為 "" (避免 "unknown" 進入 safety guard)
2. decision_manager.py: classify_notification() 傳入
   suggested_action / risk_level / has_kubectl_command
3. telegram_gateway.py: classify_notification() 新規則 —
   無 kubectl_command + risk=low/medium + action=investigate/no_action
   → TYPE-1 (純資訊，無按鈕)

搭配 clawbot-v5 f4b84d7 (OpenClaw prompt CRITICAL RULES) 一起生效

2026-04-14 Claude Sonnet 4.6 Asia/Taipei

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
 2026-04-14 13:33:24 +08:00
OG T
9c8dde0951 fix(telegram): 修復 Incident 無 title 欄位導致所有 Telegram 推送失敗
Some checks failed
CD Pipeline / build-and-deploy (push) Failing after 2m3s
Details 
根因: _push_decision_to_telegram() 有兩處引用 incident.title，
但 Incident model 從來沒有此欄位，導致所有告警卡片推送都
拋 AttributeError，事件在 telegram_decision_push_failed 靜默失敗。

修法:
- line 188: message 改用 signal annotation summary/description/alert_name
- line 249: TYPE-1 title 改用 alertname label / signal.alert_name

影響: 自從 decision_manager 加入這兩行以來，所有 Telegram 通知都沒發出
（包含 TYPE-1 資訊通知和 TYPE-3 審批卡）

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
 2026-04-12 21:02:55 +08:00
OG T
a5f17cea79 fix(notification): TYPE-1 backup/info 告警不再發審批卡
Some checks failed
CD Pipeline / build-and-deploy (push) Has been cancelled
Details 
classify_notification() 不知道 alert_category，對 backup 告警
（confidence=0, auto_executed=False）返回 TYPE-3，覆蓋掉
classify_alert_early() 已設好的 notification_type=TYPE-1。

修法：在路由分支前，讓 incident.notification_type 明確值
（TYPE-1 / TYPE-4D / TYPE-8M）覆蓋 classify_notification()。

影響：backup/info/watchdog 告警只發 send_info_notification()，
不再噴帶按鈕的審批卡到 Telegram。

2026-04-12 ogt (ADR-075 bugfix)

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
 2026-04-12 19:49:31 +08:00
OG T
bc2665ef6b feat(adr075): Step-5 decision_manager TYPE-5S/TYPE-6B 路由分支
Some checks failed
CD Pipeline / build-and-deploy (push) Has been cancelled
Details 
- 新增 secops elif：alert_category=secops → send_secops_card()
  (resource, threat_behavior 從 incident.signals labels 提取)
- 新增 business elif：alert_category=business → send_business_alert()
  (metric_name/current_value/threshold 從 Prometheus labels 提取)
- TYPE-7E escalation_monitor 標記 out-of-scope (ADR-075 範疇外)
- 兩分支均加 2026-04-12 ogt (ADR-075 Step-5) 變更標記

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
 2026-04-12 19:12:35 +08:00
OG T
1cb654cf59 fix(adr-075): CR P0/P1 修補 — TYPE_8M enum + 死碼清理 + docstring 更新
Some checks failed
CD Pipeline / build-and-deploy (push) Has been cancelled
Details 
P0-2: NotificationType 新增 TYPE_8M = "TYPE-8M"
      classify_notification 早期回傳 TYPE-8M
      decision_manager 改用 NotificationType.TYPE_8M enum 比較（移除字串字面量）
P1-1: 移除 _CATEGORY_BUTTONS 中不可達的 alertchain_health/flywheel_health 條目
P1-4: test_classify_alert_early.py docstring 更新為 13 條規則/10 分類

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
 2026-04-12 18:44:12 +08:00
OG T
561c1d806b feat(adr-075): Phase 2 — TYPE-8M 飛輪/告警鏈路健康通知格式與路由
Some checks failed
CD Pipeline / build-and-deploy (push) Failing after 4m0s
Details 
新增 send_meta_alert() — ⚙️ META SYSTEM 卡片（觸發診斷/查看面板/靜默）
decision_manager 新增 TYPE-8M elif 分支（在 TYPE-4D 後）
_alert_category 提取提前至 if 鏈前，三個分支共用

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
 2026-04-12 18:39:04 +08:00
OG T
2cef2098d3 feat(adr-075): 修復 Telegram 動態按鈕 4 個斷點 + 新增 7 種告警分類
Some checks failed
CD Pipeline / build-and-deploy (push) Has been cancelled
Details 
斷點 A: decision_manager 提取 alert_category/notification_type 傳入 send_approval_card
斷點 B: send_approval_card 新增參數並傳遞至 _build_inline_keyboard
斷點 C: 互動型通知 (TYPE-3/4/4D/8M) 禁止發 SRE 群組，防 nonce 洩漏
斷點 D: _CATEGORY_BUTTONS k8s_workload → kubernetes + 新增 6 類按鈕組

classify_alert_early 新增: alertchain_health, flywheel_health, storage,
devops_tool, external_site, ssl_cert, host_resource (從 infrastructure 分離)
Test: 52 classify + 664 total passed

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
 2026-04-12 18:35:56 +08:00
OG T
c09521a1c6 fix(cr): Code Review P0/P1 全修補 — 積木化+SSH路由+安全守衛順序
Some checks failed
CD Pipeline / build-and-deploy (push) Failing after 2m30s
Details 
P0-1: classify_alert_early 移至 incident_service (Service層)，webhooks.py import 修正
P0-2: _ssh_execute() 改用 self._ssh，移除冗餘 SSHProvider() 實例化
P1-1: infrastructure SSH routing 移至 kubectl safety guard 之前，docker指令不再被攔截
P1-2: alert_rule_engine 新增 get_risk_for_alertname() public API
P1-3: classify_notification() docstring 修正 ORM→Pydantic

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
 2026-04-12 14:51:12 +08:00
OG T
dbc77c5e62 feat(flywheel): Phase 3 — decision_manager Tier 3 七大修復 (首席架構師授權)
Some checks failed
CD Pipeline / build-and-deploy (push) Has been cancelled
Details 
ADR-073 Phase 3 全部完成:

3-1: TYPE-1 triage guard
- get_or_create_decision() 入口: notification_type=TYPE-1 直接 bypass LLM 分析
- classify_notification() 優先讀 incident.notification_type (早期分診結果)
- ConfigurationDrift/KubeConfigDrift 補入 TYPE-4D 匹配清單

3-2: infrastructure → SSH MCP routing
- _auto_execute() 中 alert_category=infrastructure + 非 kubectl action → _ssh_execute()
- _ssh_execute(): docker_restart / service_restart tool 路由
- 取 instance label 對應 SSH_MCP_ALLOWED_HOSTS 白名單主機

3-3: send_info_notification() TYPE-1 已存在，classify_notification 修復確保正確呼叫

3-4: Dynamic button builder 已存在 _build_inline_keyboard + _CATEGORY_BUTTONS

3-5: action | parse fix
- _auto_execute() 開頭: action 含 | 時取第一段 (LLM 有時輸出 "kubectl X | kubectl get")

3-6: risk_level YAML priority override LLM
- dual_engine_analyze() LLM 結果返回後，用 alert_rules.yaml 對應 rule.risk 覆蓋

3-7: send_drift_card() TYPE-4D 已存在，classify_notification 修復確保正確觸發

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
 2026-04-12 14:39:19 +08:00
OG T
184b37a8b1 refactor(decision_manager): I2 DI 化 MCP Providers + fix config list type bug 
- DecisionManager.__init__ 注入 SSHProvider/K8sProvider，移除函數內 import+實例化
- config.get_tg_user_whitelist() 支援 list 輸入（monkeypatch/直接傳入），修復 AttributeError
- LOGBOOK 更新（test fix 6e0ee8b）

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
 2026-04-12 13:04:46 +08:00
OG T
8be87b0f32 fix(review): 首席架構師 Code Review — c439277 Tier 3 紅區修補
Some checks failed
CD Pipeline / build-and-deploy (push) Failing after 8m39s
Details 
Critical:
- C1: decision_manager _collect_mcp_context container 變數 Python ternary 優先度 bug 修正
  原: `A or B or C[0] if list else ""` (ternary 控制全式)
  修: `A or B or (C[0] if list else "")` (明確括號)
- C2: 所有 MCP 呼叫加 asyncio.wait_for timeout=5s，防止阻塞決策主路徑
  同時加 unknown host warning log (C4)
- C3+M1: _DESTRUCTIVE_PATTERNS 補全移至模組頂層常量
  新增: delete pods(複數)/kubectl drain/kubectl cordon/kubectl rollout undo/
        docker rm/docker stop/docker kill/rm -rf/"replicas": 0(JSON patch)

Important:
- I1: webhooks.py IP 排除改用 is_internal_ip() 支援全 RFC-1918 (10.x/172.16-31.x/192.168.x)
- I4: 新增 test_destructive_patterns.py — 25 測試全過
  涵蓋: 常量存在、攔截、誤攔迴歸、critical 永遠攔截

🔴 Tier 3 紅區 — 首席架構師 Code Review 通過後 push

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
 2026-04-11 22:05:52 +08:00