54 Commits

Author	SHA1	Message	Date
Your Name	cfb866d055	feat(governance): add agent market automation surfaces	2026-06-04 21:50:55 +08:00
Your Name	9b01f1fa46	fix(api): serialize startup bootstrap ddl	2026-05-24 17:10:26 +08:00
Your Name	db4fa420ea	fix(api): tolerate legacy incident outcomes	2026-05-19 12:07:54 +08:00
Your Name	795085170a	feat(awooop): persist inbound source envelopes	2026-05-13 21:29:04 +08:00
Your Name	24b15f4ad2	feat(awooop): harden outbound truth chain mirror	2026-05-12 23:21:45 +08:00
Your Name	ff30c61c4c	fix(rls): 收斂 API DB access context	2026-05-12 19:55:13 +08:00
Your Name	7ed8c95409	fix(mcp): persist blocked gateway audit rows	2026-05-06 16:21:43 +08:00
Your Name	8629ac709b	feat(awooop): Phase 1-8 完整實作 — AwoooP Agent Platform 六平面架構 ... ## Phase 1-3: Control Plane + Contract System - awooop_phase1_control_plane_2026-05-04.sql: 12 張核心表 + RLS - awooop_phase1_batch1_rls_2026-05-04.sql: 全部 FORCE RLS + GRANT - packages/awooop-contracts/: 六合約 JSON Schema + golden fixtures - src/models/awooop_contracts.py: Pydantic v2 contract models（extra=forbid） - src/repositories/contract_repository.py: contract lifecycle（draft→published→active） - src/services/contract_service.py: HMAC publish sig + Redis multi-sig activate - src/services/schema_validator.py: LLM output validator（retry×3, E-SCHEMA-001） ## Phase 2: Tenant Isolation - awooop_phase2_budget_ledger_2026-05-04.sql: budget_ledger + RLS - src/services/budget_service.py: Token Budget Hard Kill 三層防線 - src/core/context.py: PROJECT_ID ContextVar（31 background loop 自動繼承） - src/db/base.py + models.py: project_id 欄位 + RLS set_config 注入 - src/hermes/nl_gateway.py: project_id Redis key 前綴（Phase A 雙寫） - src/services/anomaly_counter.py: per-project 改造（Phase A fallback） ## Phase 4: Platform Shell in Shadow Mode - awooop_phase4_run_state_2026-05-04.sql: run_state + step_journal + idempotency - src/services/run_state_machine.py: 8-state FSM + SKIP LOCKED + stale reaper - src/services/platform_runtime.py: UUID v7 + W3C trace_id + shadow_execute - src/services/audit_sink.py: PII/secret redaction 9 patterns - src/api/v1/platform/runs.py: POST/GET /v1/platform/runs（Router→Service 架構） - src/workers/platform_worker.py: SKIP LOCKED worker + heartbeat + reaper loop - src/main.py: platform router + lifespan worker start/stop ## Phase 5: MCP Gateway 五閘門 - awooop_phase5_mcp_gateway_2026-05-04.sql: 4 表 + RLS - src/plugins/mcp/gateway.py: McpGateway（Gate 1~5, E-MCP-GATE-001~009） - src/plugins/mcp/redaction_middleware.py: 雙層 redaction + 16K 截斷 - src/plugins/mcp/registry.py: __provider name mangling（ADR-116） - src/plugins/mcp/credential_resolver.py: k8s secret ref 解析 - tests/test_mcp_credential_isolation.py: 10 個迴歸測試（secret leak 防再現） ## Phase 6-8: EwoooC + Channel Hub + Approval Token - awooop_phase6_ewoooc_onboarding_2026-05-04.sql: ewoooc tenant + 4 read-only MCP tools - awooop_phase7_channel_hub_2026-05-04.sql: conversation_event + outbound_message - src/services/provider_proxy.py: ProviderProxy + PlatformEnvelope（ADR-115） - src/services/channel_hub.py: Telegram inbound mirror + Progressive Feedback（30s） - src/services/awooop_approval_token.py: HS256 + jti NX replay 防護 + suggest mode Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>	2026-05-04 19:31:53 +08:00
Your Name	13e51802fe	feat(awooop): Phase 0 全 ADR + Phase 1 control plane schema（含 critic 四項修正） ... ## Phase 0（文件層，全部 Accepted） - ADR-106/107：AwoooP 平台架構 + 儲存策略 - ADR-111~118：Bootstrap → RLS 七項核心 ADR - ADR-119~124：SAGA → Singleton Decomposition 六項 ADR - ADR-UI-01~04：Operator Console 四個 UI ADR ## Phase 1（DB schema + migration） - awooop_phase1_control_plane_2026-05-04.sql：7 張新表 + trigger + RLS - Step 1：三角色（platform_admin/migration BYPASSRLS，awooop_app 受 RLS） - Step 13：GRANT awooop_app 最小權限（7 條） - Step 14：RLS fail-closed，移除 __platform__ 後門 - awooop_phase1_batch1_rls_2026-05-04.sql：高流量四表三步式 ADD COLUMN - awooop_phase1_batch1_backfill.py：SKIP LOCKED 分批回填腳本 - awooop_models.py：7 個 SQLAlchemy 2.x models ## Critic 修正（4 Critical + 3 Major） - C-1：ADD CONSTRAINT IF NOT EXISTS → DO 塊 + pg_constraint 查詢 - C-2：__mapper_args__ 字串 list → primary_key=True on mapped_column - C-3：__platform__ RLS 後門 → 全移除，改用 BYPASSRLS role - C-4：awooop_app role 從未建立 → Step 1 + 7 條 GRANT - M-1：active_pointer_guard SECURITY DEFINER（FORCE RLS 跨租戶保護） - M-2：pg_partman create_parent 加冪等防護 - M-3：immutability trigger 新增身份欄位保護（project_id/family/contract_id） ## Task 1.2 修補 - agent_loader.py：硬編碼 Mac 路徑 → AGENTS_DIR 環境變數 - Dockerfile：補 COPY .claude/agents/ Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>	2026-05-04 13:37:11 +08:00
Your Name	e45b055e0e	feat(governance): AI 治理事件處理鏈四軌交付（C/D/B/A） ... 【十二人專家團隊全景掃描 + 並行四軌實施】 統帥質疑「有讓 12-agent 一起協作嗎」後，依照團隊規則完成全鏈路交付： onboarder + critic + db-expert + debugger + frontend-designer 並行掃描， 找到 6 大 Gap，再由 fullstack-engineer × 4、refactor-specialist 協作落地。 【Track C — trust_drift 雙寫整併】 兩條獨立寫 event_type=trust_drift 路徑互不呼叫，下游 consumer 拿到雙份資料 無法判定 source-of-truth。整併保留 governance_agent.check_trust_drift（功能 更全：auto-deprecate + Telegram + PG），TrustDriftDetector 降為純統計 lib， W-6 watchdog 改呼叫 governance_agent。新增 TestSinglePgWritePerDriftScenario 驗證同一 drift 場景只觸發一次 PG 寫入。 變更： - apps/api/src/services/trust_drift_detector.py（lib only，不再寫 PG） - apps/api/tests/test_trust_drift_watchdog.py（W-6 改 mock governance_agent） 【Track D — governance_remediation_dispatch 派遣表】 ai_governance_events 是不可變 Event Sourcing，不能塞執行狀態。新建派遣表 作為投影層：1 event → 0..N dispatches，狀態可變、可重試、可審計。 - PgEnum 5 種 event_type + 7 階段狀態機（pending → dispatched → executing → succeeded/failed/cancelled/skipped） - 失敗重試 INSERT 新 row（不改舊 row 的 status，保留審計痕跡） - Partial unique index ux_grd_one_active_per_event 強制「同事件唯一活躍」 - 4 個複合 index 支援 worker poll、去重查詢、觀測面板 - FK 對應 ai_governance_events / playbooks / incidents / approval_records 全部 SET NULL（avoid cascade lock，但 governance_event 用 RESTRICT） 變更： - apps/api/src/db/models.py（GovernanceRemediationDispatch ORM class） - apps/api/migrations/governance_remediation_dispatch_2026-05-03.sql - apps/api/src/repositories/governance_remediation_dispatch_repo.py （6 個 async 函式 + 3 個自訂例外：DispatchAlreadyActive / InvalidStatusTransition / DispatchNotFound） - apps/api/src/models/governance_dispatch.py（DecisionContextV1 等 4 schema） - apps/api/tests/test_governance_remediation_dispatch.py（29 tests） 【Track B — /governance 頁面】 後端 PR1 三個 endpoint + 前端 PR2-5 完整三 Tab。 PR1 後端： - GET /api/v1/ai/governance/events（events_tab，含 event_type/severity/ 狀態/時間範圍篩選 + 分頁） - GET /api/v1/ai/governance/queue（queue_tab，含 graceful fallback： dispatch 表不存在時回 table_pending=True 不拋 500） - GET /api/v1/ai/governance/summary（slo_tab 30d 違反時序圖） - severity 映射規則寫死（critic 建議未來移 settings） PR2-5 前端： - /governance 路由 + AppLayout + Compliance Badge 橫幅 + PageTabs - SLO Tab：3 KPI 卡片（Syne 28px + StatusOrb + 7d sparkline）+ 30d 違反 stacked BarChart - Events Tab：篩選列 + 表格 + inline 展開行（JSON / 修復建議 / 派遣記錄） - Queue Tab：HITL 待辦卡片 + 信任度進度條 + 批准/拒絕按鈕（本 PR console.log） - Sidebar 加入「AI 治理」入口（ShieldCheck icon） - i18n 雙語完整（governance namespace + nav.governance） - 7 個新元件：slo-kpi-card / slo-violation-chart / events-table / events-filter-bar / event-detail-drawer / queue-item-card / queue-history-tabs 變更： - apps/api/src/api/v1/ai_governance.py（router） - apps/api/src/services/governance_query_service.py - apps/api/src/models/governance.py（Pydantic V2 schemas） - apps/api/tests/test_ai_governance_endpoints.py（21 tests） - apps/web/src/app/[locale]/governance/（page + 3 tabs） - apps/web/src/components/governance/（7 元件） - apps/web/messages/{zh-TW,en}.json（governance namespace） - apps/web/src/components/layout/sidebar.tsx（+1 行） - apps/api/src/main.py（router include） 【Track A — GovernanceDispatcher 決策融合】 把治理事件接到 remediation 執行器，走北極星方向決策融合（LLM × Playbook trust × MCP），符合「禁寫死規則」鐵律。 - 設計鐵律：DecisionFusionAdapter 是新增 wrapper，**不修改任何 Tier 3 檔** （decision_manager / learning_service / trust_engine），只 consume 既有 API - 三維融合公式：confidence = 0.4×llm + 0.3×playbook_trust + 0.3×mcp_consistency （權重加 TODO 標明未來由 AI 自學調整） - 三分支決策路徑： confidence ≥ 0.85 → auto_dispatch（status=dispatched） 0.65 ≤ confidence < 0.85 → pending_approval（HITL） confidence < 0.65 → skip + log - decision_context JSONB 完整記錄三維輸入快照（給未來 fine-tune 用） - poll 30s 掃 unresolved 事件，仿 governance loop 模式 - 重複事件擋去重（呼叫 get_active_for_event） 變更： - apps/api/src/services/governance_dispatcher.py - apps/api/src/services/decision_fusion_adapter.py - apps/api/tests/test_governance_dispatcher.py（14 tests） - apps/api/src/main.py（lifespan task 接 run_governance_dispatcher_loop） 【驗證】 1836 個 unit test 全過（29 skipped 為既有 PG integration env 問題） 【調度教訓 — 已記入 memory】 - vuln-verifier 應在 fullstack-engineer **之前**跑（避免並行讀到已修代碼誤判） - critic 雙輪審查不可省（第二輪抓到 NaN sentinel + Prom rule 連鎖） - 北極星「禁寫死規則」搭配 decision-fusion 確實實施 【未動 Tier 3 — 已驗證】 git diff 確認本 commit 完全沒改 decision_manager.py / learning_service.py / trust_engine.py，只新增 wrapper service consume 既有 API。 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-03 12:42:40 +08:00
Your Name	7e4d995e4b	feat(aiops): add mcp agent loop foundation	2026-05-01 13:21:19 +08:00
Your Name	f154ac022e	feat(playbook): version generated playbooks	2026-04-30 23:59:39 +08:00
Your Name	c5b1810172	fix(cd-blocker): 補 knowledge_entries 防禦性 ALTER（解 CD #1115-1117 全 failure） ... 🚨 真根因：CD pipeline 從昨天 push fb0c72db 起，4 個 commit (1114-1117) 全 failure prod pod 28 小時沒更新 → 統帥 17:33/17:35 看到的 Telegram 告警仍是「llm_failed」 不是 ai_router 沒推翻 A2，是**部署根本沒上 prod**。 ## CD 失敗證據（gitea actions API） ``` #1117 7b471e7a failure Gemini sanitize #1116 3668d49f failure W2 三件 + KMWriter critic #1115 fb0c72db failure 推翻 A2 DIAGNOSE Ollama primary #1114 8d24f151 failure PR-R1 4 Major 修 #1113 681b5ac9 success PR-R1 規則→Playbook 遷移 ← 最後一次成功 ``` ## 失敗 Stack Trace（job 1267 logs） ``` sqlalchemy.exc.ProgrammingError: column "related_approval_id" of relation "knowledge_entries" does not exist SQL: INSERT INTO knowledge_entries (..., related_approval_id, path_type, ...) test: tests/integration/test_b5_core_flows.py::test_knowledge_entry_view_count ``` ## 根因 commit c22e5f33 (KMWriter) 加 ORM 欄位 `related_approval_id` + `path_type`： - `models.py` ORM Mapped 欄位 ✅ - `knowledge.py` Pydantic schema ✅ - `migrations/p1_1_km_idempotent_path_type.sql` 加 path_type ✅ - **但 `db/base.py:init_db()` 沒對應 ALTER**❌ CI integration test 用 prod schema 建 PG → 既有表沒有新欄位 → INSERT 失敗。 我之前只補了 `timeline_events.incident_id` 的 ALTER，漏了 `knowledge_entries`。 ## 修法 `db/base.py:init_db()` 補 3 條防禦性 SQL（同 timeline_events 模式）： ```sql ALTER TABLE knowledge_entries ADD COLUMN IF NOT EXISTS related_approval_id VARCHAR(64), ADD COLUMN IF NOT EXISTS path_type VARCHAR(50); CREATE UNIQUE INDEX IF NOT EXISTS uix_knowledge_incident_path ON knowledge_entries(related_incident_id, path_type) WHERE related_incident_id IS NOT NULL AND path_type IS NOT NULL; CREATE INDEX IF NOT EXISTS ix_knowledge_related_approval ON knowledge_entries(related_approval_id) WHERE related_approval_id IS NOT NULL; ``` ## 驗證 - 1635 unit tests 全綠 - 預期 CD #1118 (本 commit) 解 4 個失敗 commit 的部署 backlog - 部署完成後 prod ai_router fb0c72db 推翻 A2 才會真的生效 Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-04-29 20:44:23 +08:00
Your Name	3668d49f2f	feat(flywheel): W2 三件 + KMWriter critic 修法（1635 tests 全綠） ... W2 (onboarder 4 週飛輪 80→90 路徑第二週) + critic PR review 5 個 critical/major 全部修完，default flag=false 安全無爆炸風險。 ## W2 三件 PR ### PR-R2 — AOL → catalog confidence EWMA 回灌（修飛輪斷鏈 C2） - 新檔 `apps/api/src/jobs/aol_to_catalog_writeback_job.py` - 邏輯：每小時掃 AOL 計算 EWMA confidence (alpha=0.3) 回灌 alert_rule_catalog - 失敗閾值 N=5 連續低成功率 → review_status='draft' - Hermes _fetch_noisy_rules SQL 加 OR review_status='draft' - ENABLE_AOL_WRITEBACK_JOB=false (default) - 8 個測試（mock path 修正：lazy import → patch src.db.base.get_db_context） ### PR-V1 — self_healing_validator 串接 (修飛輪斷鏈 C6) - 新檔 `apps/api/src/services/self_healing_validator.py`（純函數 assess_self_healing） - post_execution_verifier.py step 5 串接（feature flag gate） - evidence_snapshot.py 加 self_healing_score / self_healing_detail 欄位 - db/models.py + base.py ALTER IF NOT EXISTS - score < 0.5 → 觸發 rollback 提案 Telegram alert（不自動執行） - ENABLE_SELF_HEALING_VALIDATOR=false (default) - 7 個測試 ### PR-L1 — KM ↔ Playbook 雙向回路 (修飛輪斷鏈 C3+C4) - learning_service.py 三條新邏輯： 1. _write_playbook_evolution_km：promote/demote 寫 KM 演化條目 2. _check_and_mark_playbook_review：N=5 累積觸發 review_required 3. _demote_alert_rule_catalog_confidence：DEPRECATED → confidence×=0.5 - PlaybookRecord 加 review_required 欄位（schema migration via base.py） - ENABLE_KM_PLAYBOOK_FEEDBACK_LOOP=false (default) - KM_PLAYBOOK_REVIEW_THRESHOLD=5 可調 - 6 個測試 ## KMWriter Critic 5 個 Critical/Major 修復（之前 critic PR review 發現） 之前 push commit c5753e1c 已修，本 commit 補回 stash 中的對應檔案： - C1 km_writer.py:194 backfill 自打臉（已修：同步 await + DLQ） - C2 km_writer.py:391 KM_WRITE_AWAIT=false 路徑收緊 - M1 decision_manager.py:2178/2203 移除 _fire_and_forget - M2 incident_service.py:1099 自製 path 加 retry+DLQ - M3 km_writer.py:166 冪等聲明對齊（UPSERT + partial unique index） ## 驗證 - 1635 unit tests 全綠（+27 from 1608） - 與 fb0c72db (推翻 A2 Ollama primary) 共存無衝突 - 所有新 Job/Service default flag=false（不爆炸） ## 期望影響 飛輪斷鏈 C2 + C3 + C4 + C6 全修 飛輪自主化評分：65 → 85 預估（W2 完成後） 啟用順序（待 prod fb0c72db 驗證 OLLAMA primary 跑得起來後）： 1. ENABLE_AOL_WRITEBACK_JOB=true 2. ENABLE_KM_PLAYBOOK_FEEDBACK_LOOP=true 3. ENABLE_SELF_HEALING_VALIDATOR=true Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-04-29 19:44:04 +08:00
Your Name	681b5ac949	feat(flywheel): W1 PR-R1 規則→Playbook 遷移 + PR-K1 timeline 防禦 ALTER ... W1 第二波：onboarder 飛輪 80→90 路徑剩餘兩件 PR。 ## PR-R1 — 25 條 yaml 規則 → DRAFT Playbook 遷移 斷鏈背景（onboarder C2）：alert_rules.yaml 25 條規則 68% 寫死 RESTART， 沒有對應 Playbook → RAG 永遠 generic_fallback → 規則命中率沒回饋給 catalog。 修法： - 新建 services/rule_to_playbook_migrator.py - 自動從 alert_rules.yaml 解析每條 rule - 產生 PlaybookRecord（status=DRAFT, ai_confidence=0.3, source=YAML_RULE） - 誠實標示信心 0.3（非假 1.0，違反 feedback_confidence_truthfulness） - INSERT ON CONFLICT 冪等（name LIKE 'AutoMigrated: %' 去重，不擾動 seed） - 新建 scripts/migrate_rules_to_playbooks.py（CLI: --dry-run/--commit/--disable-flag） - ENABLE_RULE_MIGRATION_DRAFT=true（rollback flag） - 23 測試覆蓋（parse / build_dict / idempotent / dry_run / action_type / severity_map / feature_flag / wildcard_filter / partial_existing 等） ## PR-K1 — timeline_events 防禦性 ALTER（db-expert finding） 任務原前提錯誤：onboarder 報告的 C7 斷鏈（incident_id 欄位）在 2026-04-24 P1.6 已修復 ORM。但生產環境若在 P1.6 前已建表，create_all 跳過 已存在的表 → ORM 寫入 SELECT 仍可能找不到 column。 修法： - db/base.py:init_db() 補防禦性 ALTER: ALTER TABLE timeline_events ADD COLUMN IF NOT EXISTS incident_id VARCHAR(64); CREATE INDEX IF NOT EXISTS ix_timeline_incident_id ON timeline_events(incident_id); - IF NOT EXISTS 為 no-op 安全（已有 column 不做事） - stage 欄位是任務描述的幻覺（codebase 0 writer），不新增 未做： - alembic migration（專案不用 alembic，遵循既有 init_db ALTER pattern） - onboarder C7 在 ORM 層已修，本 commit 確保 prod schema 對齊 ## 驗證 - 1608 unit tests 全綠（+23 from 1585） - PR-R1 23 個測試獨立通過 ## 期望影響 - 飛輪 RAG 終於有 25 條 DRAFT Playbook 可查 → +5 分 - prod schema 對齊保險 → 防 ORM SELECT 失敗 Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-04-29 10:49:25 +08:00
Your Name	c5753e1c57	fix(critic-review): KMWriter 名實統一 + Alertmanager 修抑制 + drift checker AST 化 ... critic PR review 揭示已 push commits 的 7 個 blocker，本 commit 全部修復。 ## C1 + C2 + M1 + M2 + M3 — KMWriter 真正統一契約（critic 最嚴重 5 條） ### C1 km_writer.py:194 — backfill 自打臉修 - 裸 asyncio.create_task(_backfill_path_a_approval) → await _backfill_path_a_approval_safe() - 同步 await + 獨立 DLQ km:backfill:dlq + try/except 不阻塞主寫入 - 新增 km_backfill_reconciler_job.py（每 5 分鐘掃 DLQ）+ ENABLE_KM_BACKFILL_RECONCILER flag - 防 Path B 比 Path A 先完成 → related_approval_id 永遠 NULL 的 race ### C2 km_writer.py:391 — KM_WRITE_AWAIT=false 路徑收緊 - 從 ensure_future（fire-and-forget 比舊版同步寫更糟） - 改 await writer.write(retry=1, timeout=2.0)（仍 await 但只試一次、超時短） - docstring 明確標註「緊急回滾用，不保證可靠性」 ### M1 decision_manager.py:2178/2203 — 移除 _fire_and_forget 旁路 - 兩處 _fire_and_forget(executor.write_execution_result_to_km(...)) - 改 await asyncio.shield(...) + BaseException 保護（防上層 cancel 中斷） - KM_WRITE_AWAIT=true 在這條路徑終於真正 await ### M2 incident_service.py:1099 — 自製 path 加 retry+DLQ - 原本 if settings.KM_WRITE_AWAIT: await asyncio.wait_for else create_task - 改 3 次指數退避 retry + DLQ 保護（呼叫 km_writer 私有 helper） ### M3 km_writer.py:166 — 冪等聲明對齊實作 - knowledge_repository.create() 加 UPSERT 路徑（pg_insert ON CONFLICT DO UPDATE） - KnowledgeEntryCreate / KnowledgeEntryRecord 加 path_type 欄位 - migration: ADD COLUMN path_type + partial unique index uix_knowledge_incident_path ## M4 alertmanager.yml — equal: [] 收緊（critic 防爆炸抑制） - OllamaInstanceDown / KMConverterDown 抑制加 equal: ['cluster'] 約束 - 防多 cluster 場景下任一 Ollama down 誤抑全 AI/SLO 告警 ## M5 Alertmanager 版本驗證（已確認 v0.31.1，遠超 v0.22+） ## M6 governance_agent.py — health score 區分 skipped vs ok vs violated - check_slo_compliance 加 _meta {violated_count, skipped_count, ok_count, all_skipped, status} - run_self_check: SLO 全 skipped 時獨立發 governance_slo_data_gap 告警 （不污染 self_failure 計數，因為 no_data 是 emitter 未實作不是治理機制故障） ## M7 scripts/check_config_drift.py — 改 AST 解析 - regex 改 ast.parse 找 Settings ClassDef AnnAssign Field(default=...) - 避免多行 list / default_factory= / 含跳行字串的 false negative - 4 欄位（AI_FALLBACK_ORDER / ARGOCD_URL / PROMETHEUS_URL / OLLAMA_URL）全對齊 ## 新增測試 - test_km_writer_backfill_reconciler.py: 7 cases（C1 reconciler + safe helper） - test_km_writer_idempotent.py: 5 cases（M3 path_type 注入 + UPSERT 分支） ## 驗證 - 1585 unit tests 全綠（+13 從 1572） - amtool check-config SUCCESS（8 inhibit_rules / 2 receivers） - drift checker AST-based 4 欄位全對齊 - Alertmanager v0.31.1 確認支援新語法 ## 期望影響 - KMWriter 名實統一：飛輪閉環 KM 寫入路徑 100% 可靠 - M4 抑制爆炸風險解除 - 治理層不再對 SLO no_data 靜默 - drift checker false negative 風險解除 Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-04-29 10:44:39 +08:00
Your Name	c22e5f334e	feat(km): P1-1 KMWriter 統一契約 + 5 caller 切換 + M4 反查鏈補齊 ... 12-Agent 全景診斷揪出 KM 寫入鏈路 5 條入口無統一契約，fire-and-forget 在 Pod recycle 時會丟失條目。本次抽 KMWriter 強制 7 條契約。 ## 7 條契約強制 1. 同步底線：強制 await asyncio.wait_for(timeout) 2. 重試：3 次指數退避 1s/2s/4s（OperationalError / 網路類例外） 3. 失敗回收：3 次後寫 Redis DLQ km:dlq + log 4. 觀測：structlog event + 預留 metric hook（P1-3 補 emitter） 5. 冪等：incident_id + path_type 為 unique key 6. 禁止吞例外：except 必須 log + raise/DLQ 7. M4 反查鏈：payload 含 approval_id 時自動填 related_approval_id 並回填 Path A ## Caller 切換（5 條入口統一介面） - incident_service.py:1086 Path A（KB extractor + km_conversion） - approval_execution.py:771 Path B-人工 - decision_manager.py:2178 Path B-自動成功（消除跨類私有方法調用 M1） - decision_manager.py:2200 Path B-自動失敗（修 B2 早期吞例外） - playbook_service.py:210 PlaybookKM（兩份 T0 報告都漏的第三條） ## M4 反查鏈補齊 - knowledge.py + models.py: 補 related_approval_id ORM 欄位 - 對齊 phase26_incident_km_integration.sql:20 schema（partial index 已存在） - approval↔KM 雙向反查鏈完整（dual-path 縫合線） ## Feature Flag (rollback 保險) - KM_WRITE_AWAIT=true (default): await + timeout + DLQ 強制 - KM_WRITE_AWAIT=false: fire-and-forget（舊行為） ## 測試 - apps/api/tests/test_km_writer.py: 18 測試全綠 覆蓋 success / timeout / retry / DLQ / 冪等 / KMWriteError / on_failure=raise / 反查鏈回填 - 1552 unit tests 全綠（無回歸） ## 驗收 飛輪閉環核心 — KM 寫入不再靜默丟失，AI 學習鏈不斷裂。 Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-04-29 10:44:39 +08:00
Your Name	025a493f06	feat(p3.2+adr-100): Model Version Tracker + SLO 自治 + KB rot cleaner ... Wave 8 P3.2 模型版本追蹤 + ADR-100 SLO 自我治理 + 配套： P3.2 — Model Version Tracking: - model_version_probe.py (268 行) — 探測 Ollama / OpenRouter 等 provider 的 model version - model_version_tracker.py (101 行) — 對齊 PG provider_version_history 表 - migrations/p3_2_provider_version_history.sql + rollback — 25 行 schema - db/models.py +32 行 — ProviderVersionHistory ORM ADR-100 — AI 自主化 SLO: - docs/adr/ADR-100-ai-autonomous-slo.md (167 行) — 飛輪 SLO 設計與閾值 - ops/monitoring/slo-rules.yml (254 行) — Prometheus SLO recording rules + alerts - ops/monitoring/tests/test_slo_rules.yaml (242 行) — promtool unit tests 整合修改: - main.py +72 行 — Lifespan 啟動 model_version_probe + KB rot cleaner schedule - gitea_webhook.py +45 行 — webhook 接收 model 版本變化通知 - ci_auto_repair.py / evidence_snapshot.py / pre_decision_investigator.py — 配合接線 新測試: - test_kb_rot_cleaner_schedule.py (120 行) — 9 tests pass - test_slo_rules.yaml — promtool 驗收 Tests: 9 passed (test_kb_rot_cleaner_schedule) Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> Co-Authored-By: Multiple Engineers (P3.2 + ADR-100) <noreply@anthropic.com>	2026-04-27 14:54:19 +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	e96055eef9	fix(p0.4): Playbook 學習鏈三道修復 — partial index + race防護 + 手動路徑接線 ... ADR-092 P0.4 Playbook EWMA 學習閉環的 DB / Repository / Service 三層修補。 DB 層 (db-expert-fix by Engineer-B): - ApprovalRecord.matched_playbook_id 移除 index=True，改 __table_args__ partial index (WHERE matched_playbook_id IS NOT NULL) — 多數列 NULL，full index 浪費空間 - adr092_p1_learning_chain_rollback.sql: 純 ROLLBACK SQL（DBA 手動執行） Repository 層: - playbook_repository.py: SELECT FOR UPDATE 防 lost update 避免並發 EWMA 更新覆蓋彼此 Service 層 (P0.4 修復): - proposal_service.py: 手動審核路徑補 _try_playbook_match_id 呼叫 decision_manager auto_execute 路徑已有此邏輯（行 2035）， 此處補手動路徑缺口，使 matched_playbook_id 可寫入 DB → EWMA 才能演化 測試: - test_playbook_repository_race_condition.py: 3 cases SELECT FOR UPDATE 防 race 正確阻擋並發 EWMA 更新（pass） Note: migration SQL 待 DBA 手動執行（feedback_dev_prod_separation.md）， 不執行 alembic upgrade（statu 文件禁忌條款）。 Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-04-26 20:19:46 +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） ... 【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
OG T	9d6aa7ea45	feat(trust): ADR-088 Trust Score 持久化 — L4 自動放行核心 ... TrustScoreManager 從記憶體升級為 PostgreSQL 持久化， Pod 重啟後信任分數不再歸零，AI 能真正累積到 L4 自動放行門檻。 變更: - migrations/adr088_trust_score_persistence.sql: trust_records 表 - db/models.py: TrustRecordDB ORM model - repositories/interfaces.py: ITrustRepository Protocol - repositories/trust_repository.py: PG upsert ON CONFLICT DO UPDATE - services/trust_engine.py: bulk_load() 啟動 warm-up - services/learning_service.py: _persist_trust() + 2 call sites - main.py: 啟動時 load_all() → bulk_load() 流程: 批准 5 次 → score=5 寫入 DB → Pod 重啟 → warm-up 讀回 → evaluate_adjusted_risk MEDIUM→LOW → 自動執行 2026-04-17 ogt + Claude Sonnet 4.6（亞太）: ADR-088 Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>	2026-04-17 16:14:44 +08:00
OG T	f9ba200638	fix(db): Phase 6 migration 三條 CREATE INDEX 拆開各自 execute ... asyncpg 不支援 prepared statement 內多條 SQL 指令， 原本一個 text("""...""") 包含三條 CREATE INDEX 導致 CrashLoopBackOff。 拆成三個獨立 conn.execute() 呼叫。 2026-04-15 ogt + Claude Sonnet 4.6（亞太） Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>	2026-04-15 19:37:58 +08:00
OG T	fab65e7d7a	fix(alerts): PENDING 收斂無 TTL → 老記錄永久封鎖 Telegram 告警 ... 根因：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	4e2e6652e3	fix(db): 移除 IncidentEvidence.incident_id 的重複 index 定義 ... 根本原因：incident_id 同時設定 index=True（mapped_column） 與 __table_args__ 中的 Index("ix_incident_evidence_incident_id")， 導致 table.create 生成重複的 CREATE INDEX， 觸發 "already exists" 被靜默捕捉，整個 CREATE TABLE transaction 回滾。 直接效果：Pod 啟動時 incident_evidence 表永遠不會被建立， 導致後續 ALTER TABLE 失敗 → CrashLoopBackOff。 修法：移除 mapped_column 中的 index=True， 索引由 __table_args__ 統一管理。 注意：已在 PostgreSQL 直接建立 incident_evidence 表解除 CrashLoop。 Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>	2026-04-15 16:13:18 +08:00
OG T	14a02263ae	feat(Phase 4): 主動巡檢 + 趨勢預測 + 8D 感官升級 全部完成 ... ## Phase 4 完整交付（ADR-084） ### 新增服務 - trend_predictor.py: numpy 線性回歸，4h 閾值突破預警，R² 信心評分 - proactive_inspector.py: 每 5 分鐘主動巡檢協調器 - DynamicBaselineService（3σ 偏離） - LogAnomalyDetector（新 Drain3 pattern） - TrendPredictor（斜率外推 4h 預測） - Shadow Mode + 30 分鐘去重 + Holt-Winters 背景重訓 ### 8D 感官升級（EvidenceSnapshot Phase 4 增強） - PreDecisionInvestigator._collect_phase4_anomalies(): 決策前讀取 ProactiveInspector 最近巡檢快取 + LogAnomalyDetector 新 pattern - EvidenceSnapshot.anomaly_context: 新欄位，Phase 4 動態異常上下文 - DiagnosticianAgent._build_prompt(): prompt 包含 anomaly_context， LLM RCA 可參考動態基線偏差與趨勢預警 ### 資料庫遷移 - incident_evidence: ADD COLUMN anomaly_context JSONB（冪等） ### main.py - 啟動 run_proactive_inspector_loop() asyncio task 2026-04-15 ogt + Claude Sonnet 4.6（亞太）: Phase 4 全部完成 Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>	2026-04-15 15:47:05 +08:00
OG T	952c10955b	fix(db): 多 replica 並行啟動競爭 — 每 table 獨立 tx + DROP INDEX IF EXISTS ... 根因：單一大 transaction 內兩個 pod 同時建同一個 table， 其中一個 CREATE INDEX 失敗 → 整個 transaction ROLLBACK → table 也消失 → 下次重啟同樣情況 → 無限 CrashLoop。 修法三層： 1. 每個 table 用獨立 transaction 建立（失敗不影響其他） 2. 建 table 前先 DROP INDEX IF EXISTS 清殘留孤兒 index 3. 捕捉 "already exists" 讓並行 pod 優雅跳過（不 crash） Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>	2026-04-15 15:38:43 +08:00
OG T	bf45b80bd2	feat(Phase 3.5 + Phase 4): AI 學習成果持久化到 PostgreSQL — 修正「AI 失憶」架構缺陷 ... ADR-085: AI 學習成果不可存在 Cache 架構鐵律確立： - PostgreSQL = System of Record（AI 的永久記憶） - Redis = Warm Cache（加速讀取，TTL 到期從 PG 復原） 核心變更： 1. models.py: 新增 PlaybookRecord / DynamicBaselineRecord / LogClusterRecord ORM 2. base.py: ALTER TABLE playbooks 補加 trust_score / requires_approval_level 等欄位 3. playbook_repository.py: 完整雙寫實作（PG upsert + Redis cache） 4. dynamic_baseline_service.py: Holt-Winters 訓練結果寫入 PG，Redis 只作 24h warm cache 5. log_anomaly_detector.py: Drain3 cluster template 寫入 PG（UPSERT on cluster_id） 6. main.py: 啟動時執行 backfill_redis_to_pg()（Redis → PG 冪等補救） 修正的問題： - Playbook 7天 Redis TTL 到期 → AI 失去所有修復知識 - trust_score EWMA 隨 Redis TTL 歸零 → AI 重新回到初始信任度 0.3 - Holt-Winters 基線 24h TTL → AI 每天重新學習「正常」的定義 - Drain3 cluster 沒有持久化 → AI 把已知 log pattern 反覆當新 pattern Phase 4 新服務（requirements.txt 已加入 statsmodels + drain3 + numpy） Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>	2026-04-15 15:34:04 +08:00
OG T	0f2ec7987c	fix(db): 改用 inspect 跳過現有 table，根治 CrashLoopBackOff ... checkfirst=True 只跳過 CREATE TABLE，SQLAlchemy 2.0 仍對 __table_args__ Index 物件發出獨立 CREATE INDEX → duplicate error。 改法：先 inspect 取得現有 tables，只對不存在的 table 呼叫 table.create()，index 永遠只隨新 table 建立，不再 duplicate。 Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>	2026-04-15 15:18:25 +08:00
OG T	a142e6e937	fix(db): create_all checkfirst=True 修復 CrashLoopBackOff ... rolling update 時 create_all 嘗試重建既有 index 導致 "ix_incident_evidence_incident_id already exists" 啟動失敗。 checkfirst=True 讓 SQLAlchemy 跳過已存在的 table/index， init_db() 從此冪等，不再造成 CrashLoopBackOff。 Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>	2026-04-15 15:00:49 +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	d4b8b1588b	feat(flywheel): Phase 2-2/2-4 — classify_alert_early + alertname/notification_type/alert_category 寫入 ... ADR-073 Phase 2-2: 早期分診，在 LLM 分析前決定 alert_category + notification_type - webhooks.py: 新增 classify_alert_early() — 6 條規則覆蓋 config_drift/info/backup/infra/k8s/db/general - webhooks.py: alertmanager_webhook 呼叫 classify_alert_early() 並傳入兩個 create_incident_for_approval() 呼叫點 - incident_service.py: create_incident_for_approval() 新增 notification_type/alert_category 參數，寫入 Incident model - incident_repository.py: _incident_to_record_data() 新增 alertname/notification_type/alert_category 序列化 - db/models.py: IncidentRecord ORM 新增 alertname/notification_type/alert_category 三個 mapped_column 防止 HostBackupFailed 等告警被誤路由到 K8s executor (ADR-073 Phase 2-4 同步完成) Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>	2026-04-12 14:33:11 +08:00
OG T	9846a6cc93	feat(incident): Phase 27 frequency_snapshot DB 持久化 — incidents 表新增 JSONB 欄位 ... frequency_stats 原僅存 Redis(TTL 35天)，Pod 重啟或超期即失 - incidents.frequency_snapshot JSONB：建立 incident 時寫入快照，永久保存 - incident_repository: _record_to_incident 還原 IncidentFrequencyStats - _incident_to_record_data 序列化 frequency_stats 快照到 DB - Migration: phase27_incident_frequency_snapshot.sql 已執行完成 Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>	2026-04-10 01:05:41 +08:00
OG T	896bef94ee	fix(web): pending-approvals-card 加防重複點擊 + loading 狀態 ... linter 自動強化: actioningId state 防止同一張卡重複操作 - disabled + opacity 0.6 + cursor not-allowed - loading 時按鈕顯示 '...' - finally() 確保 actioningId 清除 Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>	2026-04-09 18:38:08 +08:00
OG T	1483218bab	feat(approval): 批准/拒絕後立即回應 Telegram + 持久化 message_id 到 DB ... 問題：按下 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	6f475000f6	fix(db): alert_operation_log.event_type String→PgEnum (create_type=False) ... 修正 DatatypeMismatchError: DB 欄位為 native enum alert_event_type， SQLAlchemy model 誤用 String(50)，導致 alert_operation_log 寫入失敗。 使用 PgEnum(create_type=False) 讓 SQLAlchemy 映射已存在的 DB enum， 不重建型別。18 個 event_type 值與 M-003 migration 一致。 Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>	2026-04-08 22:42:36 +08:00
OG T	88696dba9b	feat(sprint5.1): Data Safety Guardrails 全鏈路整合 (L1-L5) ... Layer 0 - K8s RBAC: - k8s/rbac/api-velero-reader.yaml: awoooi-executor SA Velero backup reader Layer 1 - DB Migration (已在 188 執行): - M-002: approval_records 新增 approval_level/votes/required_votes - M-003: alert_event_type ENUM 新增 8 個值 Layer 2 - IaC: - ops/config/service-registry.yaml: 全服務 Stateful 分級清單 (BLOCK/CRITICAL_HITL/STANDARD_HITL/AUTO) Layer 3 - Python Services: - service_registry.py: 讀取 YAML，提供 is_blocked/requires_multisig/get_required_votes - velero_client.py: kubectl 查詢 Velero 備份年齡，失敗 fallback 999h - preflight_service.py: Pre-flight 安全檢查 (Q2/Q4 決策) Layer 1-M001 - Playbook model: - playbook.py: 新增 requires_approval_level/stateful_targets/requires_pre_backup Layer 4 - 業務邏輯: - alert_operation_log_repository.py: 新增 8 個 event_type (Guardrail/Pre-flight/MultiSig/備份) - auto_repair_service.py: 注入 Service Registry Guardrail 檢查 (BLOCK → 直接拒絕) - webhooks.py: ALERT_RECEIVED 溯源記錄 + auto_repair flag Q9 + Langfuse trace_id Q10 - db/models.py: ApprovalRecord 同步 approval_level/votes/required_votes 欄位 - docker-health-monitor.sh: 純感知層改造（移除所有 docker restart 邏輯） Layer 5 - Telegram 通知: - telegram_gateway.py: T1-T6 六個新通知方法 (Guardrail/Pre-flight/Backup/MultiSig/ChangeApplied) 參考: ADR-062 Data Safety Guardrails, ADR-063 Service Registry IaC Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>	2026-04-08 16:24:09 +08:00
OG T	f20121ad41	feat(audit): Phase 11 告警操作完整溯源 — alert_operation_log + 歷史回填 ... 統帥指令「所有告警訊息通通寫入資料庫，並記錄相關操作」 變更: - phase11_alert_operation_log.sql: 新表 (Event Sourcing，不可變) - phase11b_backfill_alert_operation_log.sql: 歷史回填 654 筆 - 14 筆 ALERT_RECEIVED (incidents) - 265 筆 TELEGRAM_SENT (approval_records) - 265 筆 USER_ACTION (approval_records) - 110 筆 EXECUTION_COMPLETED (audit_logs) - db/models.py: AlertOperationLog SQLAlchemy model - repositories/alert_operation_log_repository.py: append/list_by_incident/get_stats - webhooks.py: _try_auto_repair_background 寫入 AUTO_REPAIR_TRIGGERED + EXECUTION_COMPLETED + TELEGRAM_RESULT_SENT - webhooks.py: _push_to_telegram_background 寫入 TELEGRAM_SENT - telegram.py: handle_callback 寫入 USER_ACTION (approve/reject) 已執行 migration: awoooi_prod@192.168.0.188 ✅ Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>	2026-04-08 11:22:03 +08:00
OG T	eee6f06215	feat(auto-repair): 所有操作強制寫入 DB — auto_repair_executions 表 ... 統帥指令: 所有自動修復操作（成功/失敗）必須持久化 變更: - migrations/phase10_auto_repair_executions.sql: 新增表 + 4 個索引 - db/models.py: 新增 AutoRepairExecution SQLAlchemy model - repositories/audit_log_repository.py: 新增 AutoRepairExecutionRepository (create/list_by_incident/get_stats) - auto_repair_service.py: execute_auto_repair 成功/失敗分支都寫入 DB - 新增 similarity_score 參數傳遞 - AutoRepairDecision 新增 similarity_score 欄位 - webhooks.py: 傳入 similarity_score 到 execute_auto_repair 已執行 migration: awoooi_prod@192.168.0.188:5432 ✅ Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>	2026-04-08 11:16:37 +08:00
OG T	658337ec18	fix(phase26): 打通 Incident→DB→KM 完整鏈路 + namespace 修正 ... 問題根因: 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	3455044457	feat(phase25): Nemotron 主動防禦三方向 P0+P1+P2 完整實作 ... P0 - DIAGNOSE Privacy-First Routing: - ai_router.py: _local_fallback_chain [NEMOTRON→OLLAMA→REJECT] - DIAGNOSE 意圖 override 改為 NEMOTRON (原 OLLAMA) - DIAGNOSE fallback 使用 local-only 鏈，不觸碰雲端 - 全部失敗時 REJECT + Telegram 通知 - config.py: NEMOTRON_DIAGNOSE_TIMEOUT_SECONDS=30, OLLAMA_DIAGNOSE_TIMEOUT_SECONDS=60 - nemotron.py: 根據 context[task_type] 選擇 timeout P1 - Knowledge Auto-Harvesting: - models/knowledge.py: EntryType.AUTO_RUNBOOK + ANTI_PATTERN + symptoms_hash - EntryStatus.PUBLISHED (ANTI_PATTERN 直接發布，無需審核) - models/playbook.py: SymptomPattern.compute_hash() (16字元確定性 hash) - services/runbook_generator.py: NemotronRunbookGenerator (v1.1) - generate_runbook() → AUTO_RUNBOOK (DRAFT) + Telegram 審核 card - generate_anti_pattern() → ANTI_PATTERN (PUBLISHED) + Telegram 通知 - 使用 nvidia.chat() (正確介面)，Nemotron 超時時 Minimal fallback - knowledge_service.py: check_anti_pattern(symptoms_hash, days=7) - db/models.py: symptoms_hash VARCHAR(16) + ix_knowledge_symptoms_hash - repositories/knowledge_repository.py: create() 支援 symptoms_hash + status - auto_repair_service.py: anti_pattern_gate 在 decide() + runbook hook 在 execute() - migrations/phase8_symptoms_hash.sql: ALTER TABLE + partial index + PUBLISHED constraint P2 - Config Drift Detection: - models/drift.py: DriftItem/DriftReport/DriftLevel/DriftIntent/DriftStatus - services/drift_detector.py: GitStateReader + K8sStateReader + DriftDetector - services/drift_analyzer.py: 白名單過濾 + DriftLevel 分級 - services/drift_interpreter.py: NemotronDriftInterpreter（意圖分析，不生成修復指令） - services/drift_remediator.py: rollback(kubectl apply) + adopt(git push gitea) - api/v1/drift.py: POST /scan, GET /reports, POST /rollback, POST /adopt - migrations/phase9_drift_reports.sql: drift_reports 表 - k8s/drift-cronjob.yaml: 每小時自動掃描 CronJob Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>	2026-04-04 12:35:05 +08:00
OG T	db1aed81d9	fix(db): C1 時區統一遷移 — utc_now → taipei_now (全 5 table) ... 🔴 首席架構師審查 C1: 全系統禁止 UTC，必須台北時區 +8 - utc_now() → taipei_now() (調用 src.utils.timezone.now_taipei) - 影響: ApprovalRecord, TimelineEvent, AuditLog, IncidentRecord, KnowledgeEntryRecord - 13 處 default/onupdate 全部替換 - 移除 datetime.UTC import Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>	2026-04-02 09:13:36 +08:00
OG T	628387de8c	fix: risklevel migration 自動化 + Telegram Whitelist 注入 ... 1. init_db() 啟動時自動確保 risklevel enum 包含 'high' 值 (Phase 23 新增，避免舊 DB 缺值導致 InvalidTextRepresentation) 2. CD Pipeline 新增 OPENCLAW_TG_USER_WHITELIST 自動注入 (之前為 CHANGE_ME，已更新為實際 user ID 5619078117) Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>	2026-04-02 09:13:13 +08:00
OG T	48a0bc66f7	fix(api): KB 首席架構師審查修復 (I1 tags filter + I2 type annotation) ... - I1: Repository list_entries 實作 tags JSONB @> 篩選 (之前聲明未實作) - I2: ORM tags 型別從 list[dict[str, Any]] 修正為 list[str] 首席架構師審查: 87/100 C1 時區(UTC→Taipei) 為既有系統性問題，另開 task 統一遷移 Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>	2026-04-02 09:04:41 +08:00
OG T	d8be78b135	feat(api): Knowledge Base Phase 1 後端四層架構 ... - models/knowledge.py: Pydantic Schema (EntryType/Source/Status/CRUD) - db/models.py: KnowledgeEntryRecord ORM (PostgreSQL) - repositories/interfaces.py: IKnowledgeRepository Protocol - repositories/knowledge_repository.py: PostgreSQL CRUD 實作 - services/knowledge_service.py: 業務邏輯 (get_db_context 內部管理 session) - api/v1/knowledge.py: REST Router (get_knowledge_service，無直接 DB 存取) - main.py: 掛載 Knowledge Base Router - k8s/jobs/migrate-knowledge-entries.yaml: DB Migration Job API 端點: GET/POST / | GET/PATCH/DELETE /{id} | POST /{id}/approve GET /search | GET /categories Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>	2026-04-02 00:55:56 +08:00
OG T	30153496d1	fix(api): 修復全部 lint 錯誤 (ruff --fix) ... - Import sorting (I001) - Unused imports (F401) - f-string without placeholders (F541) - Loop variable unused (B007) - zip() strict parameter (B905) - Exception chaining (B904) - collections.abc imports (UP035) Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>	2026-03-26 16:06:20 +08:00
OG T	9bff46a1b0	feat: integrate Sentry + fix CI/CD issues ... Sentry Integration (補強 SignOz): - Add @sentry/nextjs for frontend error tracking + session replay - Add sentry-sdk[fastapi] for backend error tracking - Create sentry.client/server/edge.config.ts - Integrate with next.config.js + instrumentation.ts - Add Sentry exception capture in FastAPI error handler - Create deployment scripts for Self-Hosted @ 192.168.0.110 CI/CD Fixes: - Fix F821 Undefined name 'Field' in incidents.py - Add NEXT_PUBLIC_API_URL env var to CI build step - Add build-arg to Docker build verification E2E Test Improvements: - Fix strict mode violations in dashboard-acceptance tests - Add timeout increase for Phase 4 demo tests - Make tests more resilient to UI variations Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>	2026-03-24 15:19:52 +08:00
OG T	8159d22db9	refactor: ClawBot → OpenClaw 全域更名 ... - 刪除舊版 clawbot.py (已有新版 openclaw.py) - 更新 models/ai.py 類型定義 (ClawBotAnalysisRequest/Response) - 更新 api/v1/ai.py import 與註解 - 更新 Discord username - 更新所有註解與文檔 依據: feedback_openclaw_naming.md (統帥 2026-03-20 正式命名決議) Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>	2026-03-24 12:57:36 +08:00