docs(logbook): 記錄修復候選人工草案包 [skip ci]

docs/LOGBOOK.md

@@ -111,6 +111,40 @@
 - 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 修復候選 D2
+
+**背景**：使用者指出 Telegram 告警批准後仍常落在「AI 選擇不執行修復，需人工判斷」或 `NO_ACTION - REPAIR_CANDIDATE_MISSING`，但沒有產出明確操作選項、PlayBook 草案欄位或下一步。D1 已避免把通用兜底 / 診斷命令誤包成修復，本階段把「缺安全修復候選」轉成可接手的人工草案包，避免人工 review 只剩一句話。
+
+**本輪完成**：
+
+- `RepairCandidateService` 在 blocked result 產生 `repair_candidate_draft_package_v1`，並標示 `playbook_draft_required=true`。
+- draft package 會依阻擋原因給出 lane / next step，例如建立服務專屬修復 PlayBook、把診斷命令升級成修復 PlayBook、重新收集 MCP evidence、或改走安全 MCP / Ansible 路由。
+- webhook fallback 的 approval description、dry-run check、root cause 與 Telegram metadata 會帶入 `repair_candidate_blocker_summary`、`repair_candidate_next_step`、`repair_candidate_required_fields`。
+- Telegram 人工處置包新增三個可見欄位：阻擋原因、下一步、PlayBook 草案必填欄位；必填欄位包含 `alertname`、`target_selector`、`mcp_evidence_refs`、`repair_command`、`rollback_command`、`verifier_plan`、`owner_review`。
+- 本波只補「缺候選時如何接手」，不把 no-action approval 誤改成已執行修復，也不直接發 Telegram、改 Bot token、改 webhook、啟動 live probe 或執行 runtime。
+
+**驗證與正式站證據**：
+
+- 本地：`python3.11 -m py_compile apps/api/src/services/repair_candidate_service.py apps/api/src/api/v1/webhooks.py apps/api/src/services/telegram_gateway.py` 通過。
+- 本地：`test_repair_candidate_service.py` + `test_telegram_ai_automation_block.py`：`11 passed`。
+- 本地：Telegram / approval / truth-chain / no-action 回歸：`132 passed`。
+- 本地：`ruff check --select F,E9`、`git diff --check`、`source-control-owner-response-guard.py`、`security-mirror-progress-guard.py`、credential pattern 掃描通過。
+- 本地 non-sending Telegram render smoke：人工處置包含 `阻擋`、`下一步`、`PlayBook 草案欄位`、`repair_command`，且不含「已批准 / 執行中」誤導語。
+- Code commit：`febe9ecf fix(api): 補修復候選人工草案包`。
+- Deploy marker：`70441251 chore(cd): deploy febe9ec [skip ci]`。
+- Gitea：code-review `#2682` success；CD `#2681` 產生 deploy marker。
+- Production health：`https://awoooi.wooo.work/api/v1/health` 回 `healthy / prod / mock_mode=false`。
+- Production rollout：`awoooi-api`、`awoooi-web`、`awoooi-worker`、`awoooi-auto-repair-canary` 均使用 image tag `febe9ecfcda97f1936bee9a6b2e668ceeee711c3`；API ready `2/2`。
+- Production pod helper render smoke：`_format_manual_handoff_package_lines()` 回傳 `blocker=True`、`next_step=True`、`draft_fields=True`、`manual_status=True`，文字包含阻擋原因、下一步、PlayBook 草案欄位與 Runs / 真相鏈 / 補證據步驟。
+
+**完成度與邊界**：
+
+- P0-9 MCP evidence / PlayBook 修復候選產生：D2 `68%`。
+- Telegram 監控治理長期項：`93% -> 94%`。
+- 目前仍不能宣稱 AI 全自動修復已完整打通：D2 讓「缺候選」變成可接手草案包，但還沒有用真實告警完成 approval -> execution -> verifier -> KM / PlayBook trust live-fire。
+- 下一步必須補專屬 PlayBook coverage、AwoooP draft work item 入口、MCP evidence / tool call / result 前端可視化，並用真實中低風險告警驗證修復命令、rollback、verifier 與 KM 回寫。
+- active runtime gate 仍 `0`；不 SSH、不 active scan、不讀 secret payload、不重啟主機、不直接執行修復、不把 UI / Telegram 可見當 runtime 授權。
+
 ## 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 診斷命令。這些都不能硬轉成修復，否則會回到「看似自動化、實際是假修復」。

docs/superpowers/specs/2026-04-15-MASTER-ai-autonomous-flywheel-v2.md

@@ -3804,3 +3804,20 @@ Trigger commit `f5cd37b7` 與 deploy marker `0ba92357` 已把 governance UI 的
 - `security-mirror-progress-guard.py` 固定檢查 rollout risk 卡片、邊界鍵值與 i18n 鏡像，避免後續誤刪或改成操作入口。
 
 **裁決：** 此段只完成 rollout risk 可見性與防誤讀，不代表 ArgoCD sync、kubectl、主機重啟、修復、部署、runtime execution、S4.9 owner response gate 或 security acceptance 已授權。後續若要查明 Degraded / OutOfSync，只能先做只讀證據盤點，任何 GitOps 寫入或主機操作都需另行人工批准。
+
+### 2026-06-11 晚間 (台北) — P0-9 修復候選人工草案包正式上線
+
+**觸發**：統帥指出 Telegram 告警批准後仍常落在「AI 選擇不執行修復，需人工判斷」或 `NO_ACTION - REPAIR_CANDIDATE_MISSING`，但沒有產出人工可操作的選項、PlayBook 草案欄位或下一步。這代表 D0 / D1 只止住 fake execution 與 fake repair candidate，還沒有把 blocked path 變成可接手的 workflow。
+
+**已推進：**
+- P0-9 D2：`RepairCandidateService` 的 blocked result 新增 `repair_candidate_draft_package_v1`、`playbook_draft_required`、lane、next step、required fields 與 blocked operations。
+- P0-9 D2：webhook fallback 將 blocker summary、next step 與 required fields 帶進 approval description、dry-run check、root cause 與 Telegram metadata。
+- P0-9 D2：Telegram 人工處置包顯示阻擋原因、下一步與 PlayBook 草案欄位，必填包含 `alertname`、`target_selector`、`mcp_evidence_refs`、`repair_command`、`rollback_command`、`verifier_plan`、`owner_review`。
+- 驗證：本地 API 目標 / 回歸測試 `132 passed`，py_compile、ruff F/E9、guard、diff check、credential scan 通過；Gitea code-review `#2682` success；CD `#2681` 產生 deploy marker `70441251 chore(cd): deploy febe9ec [skip ci]`。
+- 正式站：`awoooi-api`、`awoooi-web`、`awoooi-worker`、`awoooi-auto-repair-canary` 均部署 image `febe9ecfcda97f1936bee9a6b2e668ceeee711c3`；production health `healthy / prod / mock_mode=false`；production pod helper render smoke 確認人工處置包含 `阻擋`、`下一步`、`PlayBook 草案欄位` 與 Runs / 真相鏈 / 補證據步驟。
+
+**完成度：**
+- P0-9 MCP evidence / PlayBook 修復候選：D2 `68%`。
+- Telegram 監控治理長期項：`94%`。
+
+**裁決：** D2 只把「缺安全修復候選」從空泛人工 review 升級成可接手的草案包，不代表 AI 全自動修復已打通。下一步仍必須補服務專屬 PlayBook coverage、AwoooP draft work item 入口、MCP evidence / tool call / result 前端可視化，並以真實中低風險告警完成 approval -> execution -> verifier -> KM / PlayBook trust live-fire。active runtime gate 仍 `0`；不 SSH、不 active scan、不讀 secret payload、不重啟主機、不直接執行修復、不把 Telegram / UI 可見當 runtime 授權。

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` | `16282062 chore(cd): deploy 47d677a [skip ci]` |
+| 最新觀察到的 `gitea/main` | `70441251 chore(cd): deploy febe9ec [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`、D1 blocker clarity `47d677ac`、deploy marker `16282062`；正式部署 tree 經 production pod smoke 確認可由 MCP evidence + approved PlayBook trust 產生 medium approval candidate、綁定預配置 approval id、不外露 preallocated metadata，且通用兜底 PlayBook 不會被誤當修復命令 |
+| 最新 P0 MCP evidence / PlayBook 修復候選基準 | code `cc614023`、D1 blocker clarity `47d677ac`、D2 manual draft package `febe9ecf`、deploy marker `70441251`；正式部署 tree 經 production pod smoke 確認可由 MCP evidence + approved PlayBook trust 產生 medium approval candidate、綁定預配置 approval id、不外露 preallocated metadata，且通用兜底 / 診斷型 PlayBook 不會被誤當修復命令；若缺安全修復候選，Telegram 人工處置包會顯示阻擋原因、下一步與 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 修復候選 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 |
+| Telegram 監控告警 / 批准執行真相鏈 | outbound 主鏈路 `100%`；批准後執行止血 `100%`；no-action 人工處置包 D0 `100%`；MCP / PlayBook 修復候選 D2 `68%`；治理長期項 `94%` | 是，僅限候選產生、阻擋原因與人工草案包可追蹤性 | 已修復 Alertmanager tenant context、既有 approval 收斂告警 recurrence、AI 分析中重複告警 recurrence、no-action approval 誤導執行、可執行修復 execution / KM / verifier 紀錄、no-action 人工處置包、MCP evidence / PlayBook trust 候選產生、通用兜底 / 診斷型 PlayBook 阻擋理由，以及缺候選時的 PlayBook 草案欄位 / 下一步提示；但完整自動修復飛輪仍需用真實告警驗證 approval -> execution -> verifier -> KM / PlayBook trust 全鏈，不調高 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 修復候選產生 | 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 |
+| P0-9 | MCP evidence -> PlayBook 修復候選產生 | D2 `68%` | 已補 webhook fallback 先建立 incident，再收 MCP evidence、查 approved PlayBook、檢查 trust / command safety、產生 medium approval candidate 與 verifier plan；D1 追加通用兜底 PlayBook / 診斷型命令不可誤當修復、阻擋理由繁中化；D2 在缺候選時產生 `repair_candidate_draft_package_v1`、`playbook_draft_required`、下一步與必填欄位，並讓 Telegram 人工處置包顯示阻擋原因 / 下一步 / PlayBook 草案欄位；下一步要補專屬 PlayBook coverage、AwoooP draft work item 入口，並用真實告警跑完 approval -> execution -> verifier -> KM / PlayBook 回寫 | 目標 pytest `132 passed`、py_compile、ruff F/E9、guard、production health、API / Web / Worker / canary rollout、production pod helper render smoke；status-chain 後續仍必須看到 tool call、PlayBook id、risk gate、repair candidate、verifier plan |
 
 ## 3. S4.9 Owner Response Gate 規範