From 3fcf61b7c9cdce02c4a3adc1df7b182c9bb6baf7 Mon Sep 17 00:00:00 2001 From: Your Name Date: Thu, 11 Jun 2026 15:54:26 +0800 Subject: [PATCH] =?UTF-8?q?docs(logbook):=20=E8=A8=98=E9=8C=84=20MCP=20Pla?= =?UTF-8?q?yBook=20=E4=BF=AE=E5=BE=A9=E5=80=99=E9=81=B8=20[skip=20ci]?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- docs/LOGBOOK.md | 31 +++++++++++++++++++ ...026-06-04-iwooos-security-governance-p0.md | 7 +++-- 2 files changed, 35 insertions(+), 3 deletions(-) diff --git a/docs/LOGBOOK.md b/docs/LOGBOOK.md index fb3ff3240..39841e51e 100644 --- a/docs/LOGBOOK.md +++ b/docs/LOGBOOK.md @@ -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 實發。 diff --git a/docs/workplans/2026-06-04-iwooos-security-governance-p0.md b/docs/workplans/2026-06-04-iwooos-security-governance-p0.md index 97f59f382..35de43710 100644 --- a/docs/workplans/2026-06-04-iwooos-security-governance-p0.md +++ b/docs/workplans/2026-06-04-iwooos-security-governance-p0.md @@ -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 規範