From b32c21472df44154cc73b12e148495c8a351d348 Mon Sep 17 00:00:00 2001 From: Your Name Date: Thu, 11 Jun 2026 16:09:11 +0800 Subject: [PATCH] =?UTF-8?q?docs(logbook):=20=E8=A8=98=E9=8C=84=E4=BF=AE?= =?UTF-8?q?=E5=BE=A9=E5=80=99=E9=81=B8=E9=98=BB=E6=93=8B=E5=8E=9F=E5=9B=A0?= =?UTF-8?q?=20[skip=20ci]?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- docs/LOGBOOK.md | 29 +++++++++++++++++++ ...026-06-04-iwooos-security-governance-p0.md | 8 ++--- 2 files changed, 33 insertions(+), 4 deletions(-) diff --git a/docs/LOGBOOK.md b/docs/LOGBOOK.md index ec8e020b..c47927c9 100644 --- a/docs/LOGBOOK.md +++ b/docs/LOGBOOK.md @@ -32,6 +32,35 @@ - owner response request sent / received / accepted 仍為 `0 / 0 / 0`；不得把 handoff queue 視為已收件或已批准。 - 未送 owner request、未標記 received / accepted、未收 raw response、未收 secret 明文、未建立 GitHub repo、未 sync refs、未切 GitHub primary、未 SSH、未 active scan、未改主機、未重啟服務。 +## 2026-06-11｜P0 MCP evidence / PlayBook 修復候選 D1 + +**背景**：D0 上線後，production 只讀盤點確認新流程已開始在真實告警上寫入 `repair_candidate_status=blocked`，但阻擋原因多為 `playbook_command_not_safely_routable`。進一步檢查 production PlayBook 發現常見命中包含 `PB-20260420-789AC7` 通用兜底重啟模板與 `PB-20260505-F4197B` SSH 診斷命令。這些都不能硬轉成修復，否則會回到「看似自動化、實際是假修復」。 + +**本輪完成**： + +- `RepairCandidateService` 新增通用兜底 PlayBook gate：`alert_names=["*"]` 或名稱含通用兜底者，不得產生 repair approval candidate。 +- SSH / shell 診斷命令若未通過安全路由，會優先標示為觀察 / 診斷型，不再只丟內部安全路由錯誤。 +- blocker metadata 新增 `repair_candidate_blocker_summary`，把 `mcp_evidence_missing`、`playbook_generic_fallback_not_repair`、`playbook_observe_only`、`playbook_command_not_safely_routable` 等轉成繁中可讀原因。 +- webhook fallback 的 `NO_ACTION - REPAIR_CANDIDATE_MISSING` action 會使用繁中 blocker summary，讓 Telegram / AwoooP 看得懂「為什麼不能自動修」。 + +**驗證與正式站證據**： + +- 本地：`test_repair_candidate_service.py` + `test_matched_playbook_id_e2e.py`：`12 passed`。 +- 本地：Telegram / approval / shadow / rule-engine / auto-execute 回歸測試：`143 passed`。 +- 本地：`py_compile`、`git diff --check`、`source-control-owner-response-guard.py`、`security-mirror-progress-guard.py`、credential pattern 掃描通過。 +- Code commit：`47d677ac fix(api): 說明修復候選阻擋原因`。 +- Deploy marker：`16282062 chore(cd): deploy 47d677a [skip ci]`。 +- Gitea：code-review `#2676` success；CD `#2675` 產生 deploy marker。 +- Production health：`healthy / prod / mock_mode=false`；`awoooi-api` rollout successfully rolled out。 +- Production pod blocker smoke：通用兜底 PlayBook 回傳 `candidate_found=False`、blockers=`playbook_generic_fallback_not_repair` + `playbook_command_not_safely_routable`，summary=`只命中通用兜底 PlayBook，禁止當成修復命令；PlayBook 命令未通過安全路由`。 + +**完成度與邊界**： + +- P0-9 MCP evidence / PlayBook 修復候選產生：D1 `60%`。 +- Telegram 監控治理長期項：`92% -> 93%`。 +- 目前真實瓶頸已轉為 PlayBook coverage / 專屬修復候選不足：不是 UI 問題，也不是 Telegram 按鈕問題。 +- active runtime gate 仍 `0`；不 SSH、不 active scan、不讀 secret payload、不重啟主機、不直接執行修復、不把通用兜底或診斷命令當成可批准修復。 + ## 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 當終點，必須嘗試用真相鏈證據產生可批准的修復候選。 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 35de4371..bb5b519b 100644 --- a/docs/workplans/2026-06-04-iwooos-security-governance-p0.md +++ b/docs/workplans/2026-06-04-iwooos-security-governance-p0.md @@ -9,10 +9,10 @@ | 工作視窗 | IwoooS / AWOOOI 資安治理 P0 | | 本次乾淨 worktree | `/private/tmp/awoooi-manual-repair-p0-20260611` | | 本次分支 | detached HEAD on `gitea/main` | -| 最新觀察到的 `gitea/main` | `df2fde51 chore(cd): deploy 2d00fa1 [skip ci]` | +| 最新觀察到的 `gitea/main` | `16282062 chore(cd): deploy 47d677a [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 | +| 最新 P0 MCP evidence / PlayBook 修復候選基準 | code `cc614023`、D1 blocker clarity `47d677ac`、deploy marker `16282062`；正式部署 tree 經 production pod smoke 確認可由 MCP evidence + approved PlayBook trust 產生 medium approval candidate、綁定預配置 approval id、不外露 preallocated metadata，且通用兜底 PlayBook 不會被誤當修復命令 | | 最新 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` | @@ -50,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%`；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 | +| Telegram 監控告警 / 批准執行真相鏈 | outbound 主鏈路 `100%`；批准後執行止血 `100%`；no-action 人工處置包 D0 `100%`；MCP / PlayBook 修復候選 D1 `60%`；治理長期項 `93%` | 是，僅限候選產生與可追蹤性 | 已修復 Alertmanager tenant context、既有 approval 收斂告警 recurrence、AI 分析中重複告警 recurrence、no-action approval 誤導執行、可執行修復 execution / KM / verifier 紀錄、no-action 人工處置包、MCP evidence / PlayBook trust 候選產生，以及通用兜底 / 診斷型 PlayBook 阻擋理由；但完整自動修復飛輪仍需用真實告警驗證 approval -> execution -> verifier -> KM 全鏈，不調高 runtime gate | ## 2. P0 工作拆解與優先順序 @@ -72,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 修復候選產生 | 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 | +| P0-9 | MCP evidence -> PlayBook 修復候選產生 | D1 `60%` | 已補 webhook fallback 先建立 incident，再收 MCP evidence、查 approved PlayBook、檢查 trust / command safety、產生 medium approval candidate 與 verifier plan；D1 追加通用兜底 PlayBook / 診斷型命令不可誤當修復、阻擋理由繁中化；下一步要補專屬 PlayBook coverage 並用真實告警跑完 approval -> execution -> verifier -> KM / PlayBook 回寫 | 目標 pytest `12 passed + 143 passed`、py_compile、guard、production health、API rollout、新 pod production candidate / blocker smoke；status-chain 後續仍必須看到 tool call、PlayBook id、risk gate、repair candidate、verifier plan | ## 3. S4.9 Owner Response Gate 規範