wooo/awoooi
1
1
Fork 0
Code Issues 2 Pull Requests 1 Actions 3 Packages Projects Releases Wiki Activity

docs(logbook): 記錄 MCP PlayBook 修復候選 [skip ci]

Browse Source
This commit is contained in:
Your Name
2026-06-11 15:54:26 +08:00
parent df2fde51ad
commit 3fcf61b7c9
2 changed files with 35 additions and 3 deletions
Download Patch File Download Diff File Expand all files Collapse all files

31
docs/LOGBOOK.md
View File

@@ -1,3 +1,34 @@
## 2026-06-11｜P0 MCP evidence / PlayBook 修復候選 D0
**背景**：使用者指出 Telegram 告警「批准後仍沒有自動化」，且 `NO_ACTION - REPAIR_CANDIDATE_MISSING` 只把問題推給人工，沒有真正把告警接到 MCP evidence、PlayBook trust、修復候選、approval gate、execution / verifier / KM 鏈路。本階段先補最前面的候選生成斷點：LLM fallback 後不能直接把 no-action 當終點，必須嘗試用真相鏈證據產生可批准的修復候選。
**本輪完成**：
- 新增 `apps/api/src/services/repair_candidate_service.py`：候選產生必須同時通過 MCP evidence、approved PlayBook、trust score、command safety gate；不得用預設重啟硬湊成功。
- `webhooks.py` 的 LLM fallback 改為先預配置 approval id、建立 incident，再收 evidence / PlayBook candidate，最後用同一個 id 建立 approval，讓 Telegram / AwoooP / timeline 指向同一條真相鏈。
- 若有候選，approval action 改成實際 PlayBook command，risk 至少為 `medium`，等待人工批准後才進 execution chain；若無候選，仍保留 no-action 人工處置包並寫明 blockers。
- `approval_db.py` 支援 `preallocated_approval_id`，建立 record 時綁定 id，但不把該內部欄位外露到 `extra_metadata`。
**驗證與正式站證據**：
- 本地：`test_repair_candidate_service.py` + `test_matched_playbook_id_e2e.py`：`11 passed`。
- 本地：Telegram / approval / shadow / rule-engine / auto-execute 回歸測試：`143 passed`。
- 本地：`python3.11 -m py_compile apps/api/src/services/repair_candidate_service.py apps/api/src/services/approval_db.py apps/api/src/api/v1/webhooks.py` 通過。
- 本地：`git diff --check`、`source-control-owner-response-guard.py`、`security-mirror-progress-guard.py`、credential pattern 掃描通過。
- Code commit：`cc614023 fix(api): 產生 MCP PlayBook 修復候選`。
- Deploy marker：`df2fde51 chore(cd): deploy 2d00fa1 [skip ci]`；該 tree 包含 `cc614023`。
- Gitea：`2d00fa1` code-review `#2674` success；CD `#2673` 產生 deploy marker。
- Production health：`https://awoooi.wooo.work/api/v1/health` 回傳 `healthy / prod / mock_mode=false`。
- Production rollout：`awoooi-api` deployment successfully rolled out；新 ReplicaSet `awoooi-api-7845454b9-*` 兩個 pod ready。
- Production pod smoke：新 pod 內 import deployed service，確認 `candidate_found=True`、action=`kubectl rollout restart deployment/awoooi-api -n awoooi-prod`、risk=`medium`、status=`candidate_ready_for_approval`、`sensors_succeeded=2`、approval id binding 成立、`preallocated_approval_id` 未外露到 metadata。
**完成度與邊界**：
- P0-9 MCP evidence / PlayBook 修復候選產生：D0 `55%`。
- Telegram 監控治理長期項：`90% -> 92%`。
- 這不是完整全自動修復完成；仍需下一段用真實告警驗證 approval -> execution -> verifier -> KM / PlayBook trust 回寫全鏈。
- active runtime gate 仍 `0`；S4.9 owner response gate 仍 `0%`；不 SSH、不 active scan、不讀 secret payload、不重啟主機、不直接執行修復、不把 UI / Telegram 可見當 runtime 授權。
## 2026-06-11｜P2-402F AI Agent host / K3s / stateful 版本只讀盤點
**背景**：P2-402E 已建立 Gitea PR 草案 lane，但 host OS、K3s、PostgreSQL、Redis、MinIO、Harbor、Gitea 與監控 / DevOps stateful 服務仍缺少統一版本盤點與 maintenance window 批准包。本階段先建立 committed read-only inventory，讓 OpenClaw / Hermes / NemoTron 可以整理版本與維護證據，但不得執行 SSH、kubectl、升級、重啟或 Telegram 實發。

7
docs/workplans/2026-06-04-iwooos-security-governance-p0.md
View File

@@ -9,9 +9,10 @@
| 工作視窗 | IwoooS / AWOOOI 資安治理 P0 |
| 本次乾淨 worktree | `/private/tmp/awoooi-manual-repair-p0-20260611` |
| 本次分支 | detached HEAD on `gitea/main` |
| 最新觀察到的 `gitea/main` | `9181cc0e chore(cd): deploy 4da7f2c [skip ci]` |
| 最新觀察到的 `gitea/main` | `df2fde51 chore(cd): deploy 2d00fa1 [skip ci]` |
| 最新 P0 Telegram 告警 / 批准執行真相鏈基準 | code `32e4beca`、deploy marker `717b5870`、code-review `2658`、CD `2657`；no-action approval 不再觸發 executor，可執行修復 approval 會寫入 `auto_repair_executions`、KM 與 verifier |
| 最新 P0 Telegram no-action 人工處置包基準 | code `cd928852`、deploy marker `9181cc0e`、code-review `2666`；正式部署 tree 已包含 no-action 人工處置包、`處置包 / 重診 / 歷史 / 靜默 / 真相鏈 / Runs` 鍵盤、production pod render / keyboard smoke |
| 最新 P0 MCP evidence / PlayBook 修復候選基準 | code `cc614023`、deploy marker `df2fde51`；正式部署 tree 經 production pod smoke 確認可由 MCP evidence + approved PlayBook trust 產生 medium approval candidate、綁定預配置 approval id，且不外露 preallocated metadata |
| 最新 P2-D0 繁中文案基準 | code `cd2275a2`、deploy marker `1920bd08`、code-review `2565`、CD `2564` |
| 最新 P2-D1 本地掃描基準 | `VISIBLE_LITERAL_TARGET_SCAN_OK files=221`；全站 TS / TSX 中文 literal 盤點 `35` 檔 / `752` 行；註解語氣 backlog `32` 筆 |
| 最新 P2-D1 正式部署基準 | code `f9bf8a28`、deploy marker `879b0a36`、CD `2578`、code-review `2579` |
@@ -49,7 +50,7 @@
| Frontend design system / visual grammar | 維持 `60%` | 否 | 本輪只推進 IwoooS 頁面資訊架構與圖表排序，不宣稱全站設計系統完成 |
| P2 全站繁中治理 D0+D1+D2 註解語氣 / AIOps sample / Code Review 候選分類 / AwoooP Runs fallback | `53%` | 只限高風險可見 literal、盤點、註解語氣、AIOps 範例資料命名、Code Review route i18n 與 AwoooP Runs fallback readability | D0 已清 messages 高風險殘留；D1 已掃 `apps/web/src` 字串 literal 並修正高風險可見 / bundle 文案；D2 已清 `apps/web/src` 內部稱謂註解、AIOps sample/mock 命名、Code Review 可見文案搬進 `codeReview` namespace，並清理 Runs / Callback / Source Flow fallback 可見殘留。全站 hardcoded TSX 可見 literal 仍需後續分批搬遷 |
| AI Agent automation inventory UX / readability | 本地 `100%`；正式站 `100%` | 否 | 治理頁已把 P1-002 後資料重排為決策指揮摘要、決策支援六因子覆蓋率與 Gitea / Runner 缺口矩陣；這是可讀性與決策支援 slice，不調高 backlog `78%`、IwoooS `64%`、S4.9 gate 或 active runtime gate |
| Telegram 監控告警 / 批准執行真相鏈 | outbound 主鏈路 `100%`；批准後執行止血 `100%`；no-action 人工處置包 D0 `100%`；治理長期項 `90%` | 是，僅限 no-action 可接手性 | 已修復 Alertmanager tenant context、既有 approval 收斂告警 recurrence、AI 分析中重複告警 recurrence、no-action approval 誤導執行、可執行修復 execution / KM / verifier 紀錄，並補上 no-action 人工處置包與操作入口；但完整自動修復飛輪仍需補 MCP evidence -> PlayBook trust -> 修復候選產生，不調高 runtime gate |
| Telegram 監控告警 / 批准執行真相鏈 | outbound 主鏈路 `100%`；批准後執行止血 `100%`；no-action 人工處置包 D0 `100%`；MCP / PlayBook 修復候選 D0 `55%`；治理長期項 `92%` | 是，僅限候選產生與可追蹤性 | 已修復 Alertmanager tenant context、既有 approval 收斂告警 recurrence、AI 分析中重複告警 recurrence、no-action approval 誤導執行、可執行修復 execution / KM / verifier 紀錄、no-action 人工處置包與 MCP evidence / PlayBook trust 候選產生；但完整自動修復飛輪仍需用真實告警驗證 approval -> execution -> verifier -> KM 全鏈，不調高 runtime gate |
## 2. P0 工作拆解與優先順序
@@ -71,7 +72,7 @@
| P0-6 | Telegram 監控告警靜音修復 | outbound 主鏈路 100%；靜音 / recurrence slice 88%；整體治理見總表 90% | Alertmanager 缺 project context、既有 approval 收斂告警靜音、AI 分析中重複告警靜音皆已修復並正式 smoke；下一步處理 `polling_active=false` 與非 Alertmanager route project context warning | API health、Telegram health、API pod Alertmanager smoke、production logs `converged_alert_recurrence_sent` |
| P0-7 | Telegram 批准後執行真相鏈止血 | 100% | no-action approval 不再顯示批准 / 執行中；可執行修復 approval 會寫入 `auto_repair_executions`、KM 與 verifier；下一步補 MCP evidence / PlayBook trust 產生真正修復候選 | 目標 pytest `125 passed`、py_compile、guard、production health、API / worker rollout、production pod classifier readback |
| P0-8 | Telegram no-action 人工處置包與操作入口 | 100% | no-action 卡片已新增人工處置包、證據補齊清單、AwoooP 修復候選建立步驟、verifier / KM / PlayBook 回寫提醒，並改成 `處置包`、`重診`、`歷史`、`靜默`、`真相鏈`、`Runs` 鍵盤；舊訊息不 retroactive 改寫 | 目標 pytest `64 passed + 44 passed`、py_compile、guard、production health、API / worker rollout、production pod render / keyboard smoke |
| P0-9 | MCP evidence -> PlayBook 修復候選產生 | 0% | 針對目前只會產生 `OBSERVE` / `REPAIR_CANDIDATE_MISSING` 的告警，補 evidence collection、PlayBook trust、risk gate 與修復候選產生；不得用預設重啟硬湊成功 | status-chain 必須看到 MCP evidence、tool call、PlayBook id、risk gate、repair candidate、verifier plan |
| P0-9 | MCP evidence -> PlayBook 修復候選產生 | D0 `55%` | 已補 webhook fallback 先建立 incident，再收 MCP evidence、查 approved PlayBook、檢查 trust / command safety、產生 medium approval candidate 與 verifier plan；下一步要用真實告警跑完 approval -> execution -> verifier -> KM / PlayBook 回寫 | 目標 pytest `11 passed + 143 passed`、py_compile、guard、production health、API rollout、新 pod production candidate smoke；status-chain 後續仍必須看到 tool call、PlayBook id、risk gate、repair candidate、verifier plan |
## 3. S4.9 Owner Response Gate 規範