docs(governance): record t24 remediation queue rollout

docs/LOGBOOK.md

@@ -1,3 +1,42 @@
+## 2026-05-14 | T24 非成功驗證補救工作佇列，讓舊 degraded 變成可追蹤工作項
+
+**背景**：T22/T23 已找出近 24h non-success verifier 的根因並修掉 executor / PromQL template 斷點，但 `/api/v1/ai/slo` 仍只把 historical degraded rows 顯示為 warning。Operator 仍無法直接判斷每筆舊 degraded 要 replay、reverify、建 Ticket，還是人工檢查。
+
+**修正**：
+- `verification_coverage` 新增 read-only `remediation_queue`，從 `recent_non_success` 轉成工作項，不直接重跑、不自動關單、不批准 write action。
+- 每筆工作項包含 `work_item_id / incident_id / auto_repair_id / alertname / playbook_id / failure_class / remediation_status / remediation_action / remediation_owner / remediation_reason`。
+- `unsupported_action_scheme` 會標成 `ready_for_replay -> replay_with_supported_executor -> auto_repair_executor`；`verifier_missing_promql` 會標成 `ready_for_reverify -> reverify_with_promql_template -> post_execution_verifier`。
+- `/governance` SLO tab 顯示「補救工作佇列」與每筆 action / owner / reason。
+- `/awooop/work-items` 新增 T24「非成功驗證補救工作佇列」工作項，直接讀 `/api/v1/ai/slo` 的 queue total / AI-ready / human counts。
+- 順手修掉 Work Items 的 telemetry 阻塞技術債：任一 production API 卡住時不再拖住整頁 `Promise.all`，每個 request 有 8s timeout，局部失敗回 `null`，其他可用 truth-chain 仍會更新。
+
+**本地驗證**：
+- `python3 -m py_compile apps/api/src/services/adr100_slo_status_service.py apps/api/tests/test_adr100_slo_status_service.py`：pass。
+- `DATABASE_URL=postgresql+asyncpg://test:test@localhost:5432/test pytest tests/test_adr100_slo_status_service.py tests/test_adr100_slo_metrics_service.py tests/test_governance_agent.py tests/test_ai_governance_endpoints.py -q`：53 passed。
+- `ruff check --select F,E9 src/services/adr100_slo_status_service.py tests/test_adr100_slo_status_service.py`：pass。
+- i18n JSON parse / `git diff --check`：pass。
+- `pnpm --filter @awoooi/web typecheck`：pass。
+- `pnpm --dir apps/web exec next lint --file src/app/[locale]/governance/tabs/slo-tab.tsx --file src/app/[locale]/awooop/work-items/page.tsx`：pass。
+- `NEXT_PUBLIC_API_URL=https://awoooi.wooo.work pnpm --filter @awoooi/web build`：pass。
+
+**推版與 production 驗證**：
+- `aa63ae5e feat(governance): surface verification remediation queue` 已推 Gitea main。
+- `44f7471b fix(awooop): keep work items telemetry from blocking` 已推 Gitea main。
+- Gitea Code Review run `2177` / `2179` success；CD run `2176` / `2178` tests / build-and-deploy / post-deploy-checks 全 success。
+- 最新 deploy marker：`cf173c49 chore(cd): deploy 44f7471 [skip ci]`。
+- Production image：API / Worker `192.168.0.110:5000/awoooi/api:44f7471b2143764efd949339aaca704b2e421e28`，Web `192.168.0.110:5000/awoooi/web:44f7471b2143764efd949339aaca704b2e421e28`。
+- K8s rollout：`awoooi-api` / `awoooi-worker` / `awoooi-web` in `awoooi-prod` 均 successfully rolled out。
+- `https://awoooi.wooo.work/api/v1/health`：200 healthy。
+- Production `/api/v1/ai/slo`：`remediation_queue.schema_version=adr100_remediation_queue_v1`，`total=8`，`ready_for_ai=8`，`needs_human=0`，`by_status=[ready_for_replay:7, ready_for_reverify:1]`。
+- Playwright production render check：
+  - `/zh-TW/governance` 顯示 `補救工作佇列`、`AI 可接手`、`用支援 executor 重跑`，console errors = 0。
+  - `/zh-TW/awooop/work-items` 顯示 `非成功驗證補救工作佇列`、`補救工作：8`、`AI 可接手：8`，console errors = 0。
+
+**目前整體進度**：
+- Alertmanager 低風險自動修復主線：約 97%。
+- 完整 AI 自動化管理產品化：約 89%。
+- T24 讓舊 degraded rows 不再只是 SLO warning，而是進入可視化工作佇列。下一段應實作安全 replay/reverify 執行入口：先支援 read-only reverify 與 low-risk replay dry-run，再決定哪些可自動 closure、哪些要建 Ticket / 轉人工。
+
 ## 2026-05-14 | T23 Auto-repair SSH diagnostic 改走 AwoooP MCP Gateway，補 verifier PromQL template
 
 **背景**：T22 已把近 24h non-success verifier 拆出根因，其中 `DockerContainerMemoryLimitPressure` 多數卡在 `PB-20260505-F4197B` 的 legacy `ssh {host} ...` 動作：AutoRepair executor 只接受 `scheme://host/payload`，因此直接失敗成 `unsupported_action_scheme`。另有 canary / host 類 verifier 缺 PromQL query template，導致 post-execution verification 只能 degraded。

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

@@ -2181,6 +2181,17 @@ Phase 6 完成後
 - 邊界：T23 修的是 executor / evidence collection 斷點，不代表所有 Docker memory pressure 告警都已完成「實際修復」。讀取診斷成功後仍要由後續 PlayBook/action semantics 判斷是否需要 restart、scale、rollback 或轉人工；`/api/v1/ai/slo` 24h window 仍會看到舊 historical degraded rows，需等新樣本覆蓋或窗口滑出。
 - 目前進度更新：Alertmanager 低風險自動修復主線約 97%；完整 AI 自動化管理產品化約 88%。下一段應把 historical degraded rows 轉成 replay / closure / ticket 工作鏈，並把 AwoooP Event Dossier 前端完整串 MCP Gateway、PlayBook、KM、Ansible/Sentry/SignOz evidence。
 
+**T24 非成功驗證補救工作佇列（2026-05-14 台北）**：
+- 觸發：T23 修掉 executor / PromQL template 後，historical degraded rows 仍只停在 `/api/v1/ai/slo` warning；Operator 仍無法直接看出每筆舊 degraded 要 replay、reverify、建 Ticket 或人工檢查。
+- 修正：`verification_coverage` 新增 read-only `remediation_queue`，每筆 queue item 帶 `work_item_id / incident_id / auto_repair_id / alertname / playbook_id / failure_class / remediation_status / remediation_action / remediation_owner / remediation_reason`；這是 dashboard triage metadata，不直接重跑、不自動關單、不批准 write action。
+- UI：`/governance` SLO tab 顯示「補救工作佇列」；`/awooop/work-items` 新增 T24「非成功驗證補救工作佇列」，直接顯示 queue total / AI-ready / human counts。
+- 技術債修補：`/awooop/work-items` telemetry fetch 增加 per-request timeout，避免某個治理 API 卡住時讓整頁停在初始 0。
+- 驗證：py_compile pass；`pytest tests/test_adr100_slo_status_service.py tests/test_adr100_slo_metrics_service.py tests/test_governance_agent.py tests/test_ai_governance_endpoints.py -q` 53 passed；ruff F/E9 pass；web typecheck / target lint / production build pass；i18n JSON parse / diff check pass。
+- Production deploy：`aa63ae5e feat(governance): surface verification remediation queue` + `44f7471b fix(awooop): keep work items telemetry from blocking` 已推 Gitea main；Code Review run `2177` / `2179` success；CD run `2176` / `2178` success；deploy marker `cf173c49 chore(cd): deploy 44f7471 [skip ci]`。
+- Production evidence：API / Worker / Web image 均為 `44f7471b2143764efd949339aaca704b2e421e28`；health 200；rollout success；`/api/v1/ai/slo` 回 `remediation_queue.total=8`、`ready_for_ai=8`、`needs_human=0`、`by_status=[ready_for_replay:7, ready_for_reverify:1]`；Playwright render check 確認 `/zh-TW/governance` 與 `/zh-TW/awooop/work-items` 新內容可見，console errors = 0。
+- 邊界：T24 只是把 historical degraded 轉成可見補救工作佇列，尚未真正執行 replay / reverify / closure / Ticket creation。下一段要做安全執行入口：先 read-only reverify 與 low-risk replay dry-run，再把結果接到 closure 或 Ticket。
+- 目前進度更新：Alertmanager 低風險自動修復主線約 97%；完整 AI 自動化管理產品化約 89%。
+
 ---
 
 ### 2026-04-20 晚 (台北) — C1-C4 全流程串接 — Playbook 鏈路保護（commit de2d34d）