wooo/awoooi
1
1
Fork 0
Code Issues 2 Pull Requests 1 Actions 5 Packages Projects Releases Wiki Activity
4,108 Commits 195 Branches 2 Tags
44ea892e4fb3e5847eaef30c8e9564d0acdafcea
Commit Graph

26 Commits

Author SHA1 Message Date
Your Name
cc6140230d fix(api): 產生 MCP PlayBook 修復候選
Some checks failed
CD Pipeline / build-and-deploy (push) Has been cancelled
Details
CD Pipeline / post-deploy-checks (push) Has been cancelled
Details
CD Pipeline / tests (push) Has been cancelled
Details
Code Review / ai-code-review (push) Has been cancelled
Details
2026-06-11 15:42:11 +08:00
Your Name
32e4beca06 fix(api): connect approval execution truth chain
All checks were successful
CD Pipeline / tests (push) Successful in 1m27s
Details
Code Review / ai-code-review (push) Successful in 14s
Details
CD Pipeline / build-and-deploy (push) Successful in 4m24s
Details
CD Pipeline / post-deploy-checks (push) Successful in 1m29s
Details
2026-06-11 13:03:54 +08:00
Your Name
1ae8f809af fix(api): record approval gate timeline events
Some checks failed
CD Pipeline / tests (push) Successful in 1m25s
Details
Code Review / ai-code-review (push) Successful in 15s
Details
CD Pipeline / build-and-deploy (push) Successful in 4m12s
Details
CD Pipeline / post-deploy-checks (push) Failing after 11s
Details
2026-06-04 15:27:37 +08:00
Your Name
3d8b395032 fix(alerts): 補齊處置結果與人工通知契約
Some checks failed
CD Pipeline / tests (push) Failing after 45s
Details
CD Pipeline / build-and-deploy (push) Has been skipped
Details
CD Pipeline / post-deploy-checks (push) Has been skipped
Details
Code Review / ai-code-review (push) Successful in 12s
Details
2026-05-31 15:46:07 +08:00
Your Name
e2ab879636 fix(alerts): correct telegram execution truth
Some checks failed
CD Pipeline / tests (push) Failing after 52s
Details
CD Pipeline / build-and-deploy (push) Has been skipped
Details
CD Pipeline / post-deploy-checks (push) Has been skipped
Details
Code Review / ai-code-review (push) Successful in 11s
Details
2026-05-31 13:58:39 +08:00
Your Name
cd17a67774 fix(alerts): surface legacy hitl backlog
Some checks failed
CD Pipeline / tests (push) Successful in 1m21s
Details
Code Review / ai-code-review (push) Successful in 13s
Details
Type Sync Check / check-type-sync (push) Failing after 40s
Details
CD Pipeline / build-and-deploy (push) Successful in 5m22s
Details
CD Pipeline / post-deploy-checks (push) Successful in 2m19s
Details
2026-05-31 13:16:22 +08:00
Your Name
4a57c2d04f feat(flywheel): expose incident processing timeline
All checks were successful
CD Pipeline / build-and-deploy (push) Successful in 10m56s
Details
2026-04-29 23:38:30 +08:00
Your Name
cc547736ab feat(wave6-8): P2.1 fusion + P2.2 governance + P2.4 consensus + Wave 7/8 BLOCKER 修復 
承接 Wave 6/7/8 多 engineer 在 agent 限額前完成的代碼，補 commit 解 production
HEAD 隱性 import error（decision_fusion 已被 decision_manager 引用但檔案 untracked）。

新增（後端核心）:
- decision_fusion.py (562 行) — P2.1 方法 III（OpenClaw + Hermes + Elephant 三 LLM 融合）
- aiops_timeline.py + aiops_timeline_service.py — critic B4 修復
  /api/v1/aiops/timeline endpoint，DB 存取抽到 service 層遵守 leWOOOgo 積木化
- migrations/p2_decision_fusion_columns.sql + rollback — approval_records fusion 欄位

修改（後端整合）:
- decision_manager.py — fusion 三斷鏈修補（critic B1+B2+B3）：
  · B1: 寫 _evidence_snapshot_ref 到 token.proposal_data
  · B2: fusion 前計算 complexity_score 並寫 token
  · B3: fusion composite 寫 token.proposal_data["decision_fusion"]
- auto_approve.py — fusion + consensus 認識（critic B3+B5）：
  · composite > 0.7 → auto_execute_eligible bypass min_confidence
  · source=consensus_engine + score>=0.6 → 規則可信路徑
- consensus_engine.py — db-fix _save_consensus 重用 agent_sessions
- governance_agent.py — db-fix _alert PG 寫入 ai_governance_events
- approval_db.py — fusion 3 欄位 + 2 partial index + CheckConstraint
- db/models.py — schema 對齊 migration
- core/config.py — vuln #1 修復：OLLAMA_URL/_FALLBACK_URL field_validator
  拒絕公網 IP + 外部域名，僅允許私網/loopback/K8s SVC 白名單
- core/feature_flags.py — P2 fusion + consensus flags
- main.py — governance_agent lifespan 啟動
- failover_alerter.py — Wave8-X2: in-memory dedup fallback（Redis 拒絕後不 fail-open）
- ollama_*.py — metrics 整合 + recovery 改善
- auto_repair_service.py — verifier 接線

新增（測試 2438 行）:
- test_decision_fusion.py / test_governance_agent.py / test_consensus_integration.py
- test_p2_db_fixes.py / test_wave8_fusion_fixes.py
- test_config_url_validation.py（vuln #1 12 tests）
- test_failover_alerter.py +Wave8-X2 in-memory dedup 補測

驗收: 116 tests pass (decision_fusion + wave8_fusion + config_url + consensus +
                      governance + p2_db_fixes + failover_alerter)

Conflict resolution:
- 3 檔（config.py + auto_approve.py + decision_manager.py）git stash pop 衝突
  保留 stashed (engineer 最終版)，補回 ValueError 「公網 IP」字樣對齊 test

Note: 此 commit 解 production HEAD 隱性 import error
仍未修: vuln #4 prompt injection / debugger B14 quota fail-closed
       / B25-B26 drain_pending_tasks / B8 governance fail alert

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Co-Authored-By: Multiple Engineers (Wave 6/7/8) <noreply@anthropic.com>
 2026-04-27 08:11:40 +08:00
Your Name
6d5fd3c124 feat(ws2): ADR-093 路由統一 — BIGINT + NotificationMatrix + feature flag 
## 修復

### T2.1 BigInteger overflow 修復
- `db/models.py`: telegram_chat_id Integer → BigInteger
  （原 int32 無法容納群組 ID -1003711974679）

### T2.2 移除 CAST workaround
- `approval_db.py:739`: 移除 CAST(:telegram_chat_id AS BIGINT)
  ORM 已正確使用 BigInteger，workaround 可退役

### T2.3 Redis key 一致性修復
- `heartbeat_report_service.py:575`: telegram:polling_leader → telegram:polling:leader
  （telegram_gateway.py 使用冒號分隔，heartbeat 用底線是 bug）

## 新增

### T2.4 notification_matrix.py
- `services/notification_matrix.py`: ADR-093 路由矩陣
  - Destination(DM/GROUP/BOTH) + RoutingRule dataclass
  - NOTIFICATION_ROUTING dict（TYPE-1 ~ TYPE-8M 完整映射）
  - resolve_chat_ids(type, dm, group, *, tg_group_cutover=False) 灰階切流 API

### T2.5 telegram_gateway.py feature flag 保護
- line 43: 加 notification_matrix import
- line 1827-1834: TG_GROUP_CUTOVER=False 時維持舊行為
  TG_GROUP_CUTOVER=True 時解除 _interactive_types 黑名單，由矩陣控制

### T2.6 Migration SQL
- `migrations/adr093_notification_routing.sql`:
  - CREATE TABLE approval_records (telegram_chat_id BIGINT)
  - CREATE ROLE awoooi_migrator (IF NOT EXISTS)
  - 含舊環境 ALTER COLUMN int→bigint 保護

## 測試同步
- `tests/integration/setup_test_schema.sql`: telegram_chat_id BIGINT

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
 2026-04-25 02:10:06 +08:00
Your Name
04ff22563e fix(aiops-p1): Playbook 學習閉環 5斷點全修 + DB Migration（ADR-092 B4）
Some checks failed
run-migration / migrate (push) Failing after 14s
Details
CD Pipeline / build-and-deploy (push) Failing after 2m7s
Details 
【P0.4 補丁】pre_decision_investigator Prometheus query 欄位缺失
- _build_tool_params() 補 "query" 欄位（prometheus_query tool 必要參數）
- 新增 _build_prometheus_query() — 依告警類型生成 PromQL（CPU/Memory/Crash/Disk/HTTP/Pod/fallback）
- 修復後 D3_METRICS 感官維度實際取得資料（原本 100% 回 missing_query_parameter）

【P1 Playbook 學習閉環 B1-B5 全修】
- B2 db/models.py: ApprovalRecord 新增 matched_playbook_id 欄位 + ix_approval_matched_playbook index
- B2 db/models.py: TimelineEvent 新增 incident_id 欄位（MCP 稽核用）+ index
- B3 approval_db.py: record→ApprovalRequest 補回 incident_id + matched_playbook_id
- B4 approval_repository.py: 同 B3（兩個轉換函式必須同步）
- B5 approval_db.py: approval_request_to_record_data 補 matched_playbook_id → DB 才能存值

【P1.5 KM 寫入】approval_execution.py: fire-and-forget → await wait_for(30s)
- 根因：asyncio.create_task 在 Pod recycle 時被殺，KM 寫入靜默遺失
- 修復：await asyncio.wait_for(..., timeout=30.0) + TimeoutError log

【Migration 文件】adr092_p1_learning_chain_fix.sql
- ALTER TABLE approval_records ADD COLUMN matched_playbook_id VARCHAR(36)
- ALTER TABLE timeline_events ADD COLUMN incident_id VARCHAR(64)
- 執行：psql $DATABASE_URL -f apps/api/migrations/adr092_p1_learning_chain_fix.sql

【附帶 Agent 改動】
- decision_manager: Phase 2 YAML NO_ACTION 優先門（主機層/外部服務跳過 Agent Debate）
- alert_rules.yaml: Sentry/ClickHouse + HostDiskUsageHigh/Critical 新規則
- solver_agent: action_title 語意合成兜底（取代靜默丟棄）

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
 2026-04-24 15:41:35 +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
Your Name
156a52f807 fix(aiops): ADR-092 三修 — Playbook enum崩潰 + Telegram永久靜默 + 採納失敗 + AI自健診
All checks were successful
CD Pipeline / build-and-deploy (push) Successful in 13m33s
Details 
B1 playbook_service.py: evolver setattr傳str而非PlaybookStatus enum
  → _pg_upsert playbook.status.value炸（163次/48h），修：update_with_validation強制enum轉型

B2 approval_db.py + webhooks.py: find_by_fingerprint PENDING誤收斂
  → PENDING≠Telegram已發；修：成功push後mark tg_sent:{fingerprint} Redis(24h TTL)
  → find_by_fingerprint debounce窗外PENDING必須Redis確認才收斂

drift_adopt_service.py: telegram_gateway呼叫adopt_drift(report_id)但方法不存在
  → 新增adopt_drift()包裝：從DB載入DriftReport後委派adopt()，修復採納失敗

B3 ai_slo_watchdog_job.py + main.py: AI無法感知自身故障（MASTER §1.1盲區）
  → 新增每15分鐘自健診：W-1 SLO違反 W-2 TG靜默偵測 W-3 飛輪成功率
  → 任一異常→TYPE-8M send_meta_alert；Redis去重1h

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
 2026-04-20 20:00:06 +08:00
OG T
6ad73b4834 fix(flywheel): 三修 L5/L6 斷鏈 — RBAC 擴權 + 失敗原因入庫 + verifier 失敗時也跑
All checks were successful
CD Pipeline / build-and-deploy (push) Successful in 11m6s
Details 
2026-04-18 晚（台北時區） — ogt + Claude Opus 4.7 (1M)

全景飛輪診斷暴露 3 個真斷鏈:
  - L5 執行 30d: EXECUTION_FAILED 216 / EXECUTION_SUCCESS 2 (失敗率 99%)
  - L6 驗證 7d: verification_result 全 NULL (988 筆 evidence 都沒驗)
  - 所有 rejection_reason / error_message 欄位全空(無法診斷)

根因: awoooi-executor ServiceAccount RBAC 不足,executor.py 每次
kubectl get nodes/HPA 都 Forbidden,連 evidence 都抓不到,後面 repair
全炸,verifier 因為 execution 沒 success 永遠不 trigger,evidence
驗證結果永遠 NULL。修一個 RBAC 解 3 個節點。

## P0.1 RBAC 擴權 (k8s/awoooi-prod/07-rbac.yaml)

新增 cluster-scope 讀權(僅 list/get/watch,零寫入):
  - nodes + nodes/status (evidence gathering 必需)
  - horizontalpodautoscalers (HPA 狀態)
  - metrics.k8s.io: nodes + pods (resource metrics)
  - statefulsets + daemonsets (完整 workload 視圖)

已 kubectl apply + 煙霧測試: kubectl get nodes 可跑。

## P0.2 失敗時必寫 rejection_reason (approval_db.py)

update_execution_status() 新增 error_message 參數,失敗時寫入
rejection_reason (截 2000 字) → 之後診斷有依據。

approval_execution.py 呼叫端同步更新,result.error 一路傳進 DB。

## P0.3 Verifier 失敗時也跑 (approval_execution.py)

原邏輯: verifier 只在 result.success=True 時呼叫 → 99% 失敗下
永遠不跑。

新邏輯: 失敗 path 也 create_task 跑 verifier,action_taken 後綴
加 ":FAILED" 標記。verifier 抓 post_state 寫
verification_result='failed' 回 incident_evidence。

L7 learning 從此有失敗樣本可學,playbook trust 負向 2x 衰減才
真正生效。

預期效果:
  - EXECUTION_FAILED 率 30d 內應從 99% 降到 <30%
  - incident_evidence.verification_result NULL 率應從 100% 降到 <10%
  - approval_records.rejection_reason 補齊率從 0% 到 100%

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
 2026-04-18 20:12:57 +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
f31b4e31ba fix(approval): create_approval_with_fingerprint 補注 48h expires_at 預設值
Some checks failed
CD Pipeline / build-and-deploy (push) Has been cancelled
Details 
根因（盤點後確認）：
  所有 webhook 建立 approval 的路徑（webhooks.py:908/1426/1566）均未傳
  expires_at，DB 欄位為 NULL。get_pending_approvals() 的自動過期邏輯
  WHERE expires_at < now 對 NULL 永遠為 False → 殭屍 PENDING 永不清理。

修正策略：
  在 create_approval_with_fingerprint()（告警 approval 唯一共用入口）
  注入預設 48h TTL，一次覆蓋全部 3 個 webhook 呼叫點。
  手動 API 建立（approvals.py）自行傳 expires_at，不受影響。

與 2026-04-15 24h PENDING_TTL_HOURS 補丁協同工作：
  - 24h: find_by_fingerprint 不再收斂過期 PENDING → 新告警重新觸發通知
  - 48h: get_pending_approvals auto-expire → UI 殭屍記錄自動清除

2026-04-15 ogt + Claude Sonnet 4.6（亞太）：完整盤點後補完

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
 2026-04-15 19:08:17 +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
36754a8a84 fix: Bug A 診斷 + Bug B 真修 — LLM 120s/130s 硬編 → OPENCLAW_TIMEOUT
Some checks failed
CD Pipeline / build-and-deploy (push) Has been cancelled
Details 
殘留兩個深層 bug 處理:

Bug A (approval.incident_id 仍 NULL) — 加診斷
  - update_incident_id 加 rowcount 檢查
  - 若 UPDATE 0 rows affected → warning log (id 型別 mismatch 或 session 不同步)
  - 手動 UPDATE 測試通過 → DB/permissions 正常，問題在應用層
  - 等 CD 部署後 live-fire 觀察 log 診斷真因

Bug B (LLM 仍 2m6s >> 30s) — 真修
  openclaw.py 兩處硬編 timeout:
  - line 146 httpx client default: 120.0s → settings.OPENCLAW_TIMEOUT (30s)
  - line 348 /analyze/incident POST: 130.0s → settings.OPENCLAW_TIMEOUT (30s)
  GAP-B4 commit dd0a778 只修了 ai_providers/ollama.py
  但 openclaw.py 自己的 httpx client 和 endpoint call 沒改
  這就是為什麼 Live-fire #2-#7 都卡 120s+ 的真因

回歸測試: 125/125 (dispatcher + a4 + classify + grouping)

Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
 2026-04-14 20:38:00 +08:00
OG T
9b9ff5bec6 fix(critical): approval_records.incident_id 欄位未寫入 — Telegram 卡片找不到 INC 編號
All checks were successful
CD Pipeline / build-and-deploy (push) Successful in 15m15s
Details 
🚨 統帥實測發現（live-fire #2, #3 反復找不到卡片）:
DB 查詢證據:
  SELECT id, incident_id, telegram_message_id FROM approval_records
  → incident_id=NULL, telegram_message_id=NULL (所有新 approval)

但 incidents 表確實有對應的 INC-20260414-3318E8 / 5C90CC。

根因:
approval_db.approval_request_to_record_data() dict 定義完全沒有 incident_id
欄位。ApprovalRequestCreate schema line 165 明明有 incident_id: str | None，
但轉 record 時被丟掉 → DB 永遠 NULL → Telegram 卡片顯示 INC 號空白。

影響:
- 用戶 Telegram 上根本認不出是哪個 incident 的審核卡
- 人工審核閉環名存實亡（即使批准也無法連回 incident）
- update_telegram_message_id 路徑也無法 fallback 補回（查 NULL 找不到）

修復 (最小侵入):
在 dict 補 "incident_id": request.incident_id

影響範圍零破壞:
- 舊 approval 繼續 NULL (不動)
- 新 approval 此後會正確寫入
- DB schema 本來就有此欄位 (line 280 Mapped[str|None])

Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>
 2026-04-14 19:21:11 +08:00
OG T
e2c6ca598e fix(approval_db): update_telegram_message 用 raw SQL + CAST BIGINT 避免 int32 overflow
Some checks failed
CD Pipeline / build-and-deploy (push) Has been cancelled
Details 
telegram_chat_id 為 BIGINT (5619078117 > 2^31-1)，SQLAlchemy ORM 會推斷為 $N::INTEGER
改用 raw SQL + CAST(:telegram_chat_id AS BIGINT) 繞過型別推斷

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
 2026-04-10 00:53:50 +08:00
OG T
ebccb88278 fix(approval_db): 修復 incident_id 篩選查空 DB 欄位而非 JSON 導致執行斷路
Some checks failed
CD Pipeline / build-and-deploy (push) Has been cancelled
Details 
get_all_approvals(incident_id=...) 原本在應用層過濾
a.metadata.get("incident_id")，但 ApprovalRecord.incident_id
是直接欄位，不在 extra_metadata JSON，導致永遠返回空列表，
Telegram 批准後出現 telegram_approval_not_found_by_incident，
審批從未實際執行。改為 .where(ApprovalRecord.incident_id == incident_id)
DB 層直接篩選，同時效能更佳。

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
 2026-04-09 19:05:48 +08:00
OG T
1483218bab feat(approval): 批准/拒絕後立即回應 Telegram + 持久化 message_id 到 DB
All checks were successful
CD Pipeline / build-and-deploy (push) Successful in 13m9s
Details 
問題：按下 TG 批准/拒絕按鈕後完全沒有任何回應，使用者不知道是否成功。
      Telegram message_id 只存 Redis 24h TTL，過期後無法追蹤。

修正：
- approval_records 加 telegram_message_id / telegram_chat_id 欄位（已 ALTER TABLE）
- approval_db.update_telegram_message() — 持久化 message_id 到 DB
- decision_manager: 發送告警卡片後同時寫 Redis + DB
- telegram_gateway._notify_approval_result() — 批准/拒絕後：
    1. editMessageReplyMarkup 移除批准/拒絕按鈕，保留資訊按鈕
    2. sendMessage reply_to 在原訊息下回覆狀態行
    3. fallback: send_notification 發新訊息
- _handle_group_command: chat_id 改為 _chat_id 消除 IDE lint

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
 2026-04-09 18:19:31 +08:00
OG T
658337ec18 fix(phase26): 打通 Incident→DB→KM 完整鏈路 + namespace 修正
Some checks failed
CD Pipeline / build-and-deploy (push) Failing after 1m29s
Details
Type Sync Check / check-type-sync (push) Failing after 52s
Details 
問題根因:
1. create_incident_for_approval 只存 Redis，不存 PostgreSQL
   → TTL 7天後消失，Playbook 萃取永遠找不到 Incident
2. ApprovalRecord 無 incident_id 欄位
   → _trigger_playbook_extraction 靠 regex 掃中文文字找 INC-，永遠失敗
3. operation_parser namespace fallback 是 "default"
   → 所有 deployment 在 awoooi-prod，203 次執行全失敗

修復:
- Incident 同時寫入 Redis + PostgreSQL (save_to_episodic_memory)
- ApprovalRecord 加入 incident_id 欄位 (model + ORM + migration)
- alertmanager_webhook 建立 Approval 後回寫 incident_id
- _trigger_playbook_extraction 直接用 approval.incident_id
- operation_parser DEFAULT_NAMESPACE = "awoooi-prod"

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
 2026-04-06 11:46:05 +08:00
OG T
f6a28d235c feat(api): Phase 16 R3.4 ApprovalDBService DI 重構 
變更:
- ApprovalDBService 新增 __init__(repository) 建構子
- get_approval() 支援 Repository 注入
- get_pending_approvals() 支援 Repository 注入
- get_approval_service(use_repository=True) 啟用 DI

絞殺者模式:
- use_repository=False (預設): 內嵌 DB 操作
- use_repository=True: 使用 ApprovalDBRepository

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
 2026-03-25 21:26:23 +08:00
OG T
6f049877fc fix(lint): ruff auto-fix + lewooogo-core src 加入 git 
- Python: ruff --fix 修復 280 個 lint 錯誤
- lewooogo-core: src/ 目錄未追蹤，導致 CI eslint 失敗

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
 2026-03-23 23:51:37 +08:00
OG T
7478dc0254 feat(phase6-9): Complete modular architecture and Agent Teams 
Phase 6.4 - Modular Architecture:
- Add lewooogo-brain adapters for LLM providers
- Add lewooogo-data dual memory (Redis + PostgreSQL)
- Implement consensus engine for multi-agent decisions
- Add incident memory service for historical context

Phase 9 - Agent Teams (Claude Agent SDK):
- Add base agent class with Claude Sonnet 4 integration
- Implement action planner, blast radius, and security agents
- Add agent API endpoints and proposal workflow
- Integrate ADR-009 OpenClaw Agent Teams architecture

DevOps & CI/CD:
- Add GitHub Actions CI/CD workflows (ci.yaml, cd.yaml)
- Add pre-commit hooks and secrets baseline
- Add docker-compose for local development
- Update Kubernetes network policies

Frontend Improvements:
- Add auto-healing error boundary component
- Update i18n messages for agent features
- Enhance dual-state incident card with execution feedback

Documentation:
- Add 7 ADRs covering MCP, design system, architecture decisions
- Update ARCHITECTURE_MEMORY.md with modular design
- Add GLOBAL_RULES.md and SOUL.md for project identity

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
 2026-03-23 18:40:36 +08:00
OG T
196d269b92 feat: add all application source code 
- apps/api: FastAPI backend with Dockerfile
- apps/web: Next.js frontend with Dockerfile
- apps/sensor: Signal collection agent
- packages: shared packages

Co-Authored-By: Claude <noreply@anthropic.com>
 2026-03-22 18:57:44 +08:00