docs(logbook): 記錄 Telegram 批准執行真相鏈

docs/LOGBOOK.md

@@ -1,3 +1,33 @@
+## 2026-06-11｜P0 Telegram 批准後執行真相鏈止血
+
+**背景**：使用者指出每個 Telegram 告警批准後都只得到「已記錄觀察，未執行修復」，代表前一輪只補到告警送達與 recurrence 可見，尚未把 approval -> execution -> verifier -> KM / PlayBook 的執行真相鏈閉合。Production status-chain 抽查 `INC-20260611-BB1D9D` 確認舊流程為 `latest_action=OBSERVE`、`completion_status=completed_no_repair`、`repair_status=not_executed`；另一個具備 `kubectl rollout restart` 的事件雖有 execution record，但缺少 `auto_repair_executions` 與 verifier / KM 收斂證據。
+
+**完成內容：**
+- `OBSERVE`、`NO_ACTION`、`REPAIR_CANDIDATE_MISSING` 類 approval action 現在統一視為 no-action，不再標記 `execution_triggered=true`，也不再排程 executor。
+- Telegram no-action 卡片不再顯示批准 / 拒絕按鈕；若舊 no-action approval 被 callback，也只回覆「已記錄；此卡沒有可執行修復，等待補修復候選」，不再顯示「執行中」。
+- LLM fallback 失敗不再產生中風險 `OBSERVE` approval；改成低風險 `NO_ACTION - REPAIR_CANDIDATE_MISSING`，避免使用者批准一張其實沒有修復命令的卡片。
+- 人工批准且具備可執行修復 action 的路徑，現在會寫入 `auto_repair_executions`，`triggered_by=human_approved`，讓 Runs / truth-chain 能看到實際執行證據。
+- 修復執行成功後會寫入 KM 並執行 post-execution verifier；修復嘗試失敗時也會回寫 KM，避免只留下 Telegram 訊息而沒有閉環證據。
+
+**驗證與正式站證據：**
+- 本地：`DATABASE_URL='postgresql+asyncpg://test:test@localhost/test' REDIS_URL='redis://localhost:6379/15' python -m pytest apps/api/tests/test_telegram_webhook_execution_handoff.py apps/api/tests/test_telegram_message_templates.py apps/api/tests/test_approval_execution_auto_approved_finalize.py apps/api/tests/test_approval_execution_no_action.py apps/api/tests/test_awooop_truth_chain_service.py apps/api/tests/test_operator_outcome.py apps/api/tests/test_telegram_gateway_polling_handoff.py -q`：合計 `125 passed`。
+- 本地：`python -m py_compile` 覆蓋本輪修改的 approval / Telegram / webhook / execution 模組，通過。
+- 本地：`git diff --check`、`source-control-owner-response-guard.py`、`security-mirror-progress-guard.py` 通過。
+- Code commit：`32e4beca fix(api): connect approval execution truth chain`。
+- Deploy marker：`717b5870 chore(cd): deploy 32e4bec [skip ci]`。
+- Gitea code-review run `2658`：Success；CD run `2657` 已產生 deploy marker。
+- Production health：`/api/v1/health` 回傳 `healthy`、`environment=prod`、`mock_mode=false`；PostgreSQL、Redis、OpenClaw、SigNoz 皆為 up。
+- Production rollout：`awoooi-api` 與 `awoooi-worker` rollout status 通過，API 副本 `2/2`。
+- Production pod classifier readback：`OBSERVE` 與 `NO_ACTION - REPAIR_CANDIDATE_MISSING` 為 no-action / non-executable；`kubectl rollout restart deployment/api -n awoooi-prod` 為 executable repair action。
+- 舊事件 `INC-20260611-BB1D9D` 保持舊真相：`completed_no_repair`、`not_executed`、`latest_action=OBSERVE`。這是預期結果，本修復不回寫假成功，只阻止新的 no-action approval 再被誤導成「執行中」。
+
+**完成度與邊界：**
+- P0 Telegram 批准後執行真相鏈止血：`100%`。
+- Telegram 監控治理長期項：`88%`；已修告警送達、重複告警 recurrence、AI 分析中 recurrence、no-action approval 誤導執行、可執行修復紀錄與 verifier / KM 回寫。
+- 完整 AI 自動修復飛輪仍不得宣稱完成；下一步必須補 MCP evidence -> PlayBook trust -> 修復候選產生，讓中低風險事件真的能從「診斷 / 觀察」走到「有根據的修復命令」。
+- 本階段沒有 force push、沒有 destructive git、沒有讀取或輸出 Secret payload、沒有 SSH、沒有 active scan、沒有改 Alertmanager rule / receiver、沒有手動重啟 production service；部署由既有 Gitea CD 完成。
+- IwoooS 整體仍維持 `64%`；active runtime gate 仍為 `0`；owner response received / accepted 仍為 `0 / false`。
+
 ## 2026-06-11｜P0 Telegram 重複告警靜音第二波修復
 
 **背景**：第一波已修復 Alertmanager 缺少 `project_id` 導致 RLS fail-closed、告警被 degraded accepted no-retry 吃掉的主斷點。後續正式 logs 又確認另一條靜音路徑：同一指紋第一次告警進入背景 AI 分析後，第二次同指紋告警會被 `alertmanager_llm_inflight_suppressed` 擋下，只記錄 DB event，不送 Telegram，使用者仍會感覺「告警完全沒有出現」。

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

@@ -7,10 +7,10 @@
 | 項目 | 目前值 |
 |------|--------|
 | 工作視窗 | IwoooS / AWOOOI 資安治理 P0 |
-| 本次乾淨 worktree | `/private/tmp/awoooi-tg-alert-recurrence-p0-20260611` |
+| 本次乾淨 worktree | `/private/tmp/awoooi-approval-execution-p0-20260611` |
 | 本次分支 | detached HEAD on `gitea/main` |
-| 最新觀察到的 `gitea/main` | `7897e923 chore(cd): deploy 65a727a [skip ci]` |
-| 最新 P0 Telegram 告警鏈路基準 | code `65a727a2`、deploy marker `7897e923`、CD `2653`；Alertmanager 重複告警在 AI 分析中已節流送出 TG，production log `converged_alert_recurrence_sent`、`sent_count=2` |
+| 最新觀察到的 `gitea/main` | `717b5870 chore(cd): deploy 32e4bec [skip ci]` |
+| 最新 P0 Telegram 告警 / 批准執行真相鏈基準 | code `32e4beca`、deploy marker `717b5870`、code-review `2658`、CD `2657`；no-action approval 不再觸發 executor，可執行修復 approval 會寫入 `auto_repair_executions`、KM 與 verifier |
 | 最新 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` |
@@ -48,7 +48,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%`；治理長期項 `85%` | 否 | 已修復 Alertmanager tenant context、既有 approval 收斂告警 recurrence、AI 分析中重複告警 recurrence；但 Telegram long polling health 仍顯示 `polling_active=false`，互動面風險需後續處理，不調高 runtime gate |
+| Telegram 監控告警 / 批准執行真相鏈 | outbound 主鏈路 `100%`；批准後執行止血 `100%`；治理長期項 `88%` | 否 | 已修復 Alertmanager tenant context、既有 approval 收斂告警 recurrence、AI 分析中重複告警 recurrence、no-action approval 誤導執行、可執行修復 execution / KM / verifier 紀錄；但完整自動修復飛輪仍需補 MCP evidence -> PlayBook trust -> 修復候選產生，不調高 runtime gate |
 
 ## 2. P0 工作拆解與優先順序
 
@@ -67,7 +67,9 @@
 | P0-3 | AwoooP 同步封包 | 100% | 已送至 AwoooP 平行工作 thread `019e9154-7d5e-7b72-85be-c9d97e43ecc9`；後續仍需每次推版前重新 fetch / fast-forward | 本文件、thread send readback、mirror checklist readback |
 | P0-4 | production live sanity 節點 | 100% | desktop / mobile / 展開區塊 / overflow / action href 檢查已完成 | Playwright production sanity 通過 |
 | P0-5 | LOGBOOK 與完成度更新 | 100% | D2 comments-only、D2 AIOps sample、D2 Code Review 候選分類與 D2 AwoooP Runs fallback 皆已回填；可見 / bundle 變更皆已補 local / production desktop + mobile smoke | `docs/LOGBOOK.md` readback |
-| P0-6 | Telegram 監控告警靜音修復 | outbound 主鏈路 100%；治理長期項 85% | 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-6 | Telegram 監控告警靜音修復 | outbound 主鏈路 100%；治理長期項 88% | 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 | 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 |
 
 ## 3. S4.9 Owner Response Gate 規範