From ade596d2ceb52b3397f715f5755b65afbd3d123f Mon Sep 17 00:00:00 2001 From: Your Name Date: Thu, 18 Jun 2026 11:57:35 +0800 Subject: [PATCH] =?UTF-8?q?docs(logbook):=20=E8=A8=98=E9=8C=84=20no-action?= =?UTF-8?q?=20=E8=99=95=E7=BD=AE=E5=8C=85=E9=83=A8=E7=BD=B2=20[skip=20ci]?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- docs/LOGBOOK.md | 35 +++++++++++++++++++++++++++++++++++ 1 file changed, 35 insertions(+) diff --git a/docs/LOGBOOK.md b/docs/LOGBOOK.md index d24b73da..58b49008 100644 --- a/docs/LOGBOOK.md +++ b/docs/LOGBOOK.md @@ -1,3 +1,38 @@ +## 2026-06-18｜Telegram no-action 批准轉人工處置包與資產沉澱契約 + +**背景**：使用者指出 Telegram 告警批准後仍常顯示「AI 選擇不執行修復，需人工判斷」，而且沒有真正進入可操作的 AI 自動化閉環；KM、PlayBook、腳本、排程與自動化機制也沒有在告警、頁面與工作項目形成可查證沉澱。程式碼盤點後確認舊契約會把 `NO_ACTION - REPAIR_CANDIDATE_MISSING` 類批准回成 `ApprovedWithoutExecution`，並刻意不排 executor，導致 operator 體感是「批准後無事發生」。 + +**完成內容**： +- `apps/api/src/api/v1/telegram.py` 新增 `ApprovedForManualHandoff` 回應契約：當批准的 action 是 `NO_ACTION` / `REPAIR_CANDIDATE_MISSING` 時，仍禁止排 executor，但 API 回應必須帶出 `manual_handoff_required`、`manual_handoff_scheduled`、`manual_handoff_kind=repair_candidate_draft`、`next_action`、`work_item_id`、`work_item_href`、`repair_candidate_blocker`、`required_fields`、`required_writebacks` 與 `automation_asset_requirements`。 +- `apps/api/src/services/telegram_gateway.py` 的批准後卡片文案改為「已轉人工處置包；請按處置包或重診補修復候選，這不是執行中」，避免再把 no-action 類批准誤解成執行中或完成。 +- Telegram 人工處置包新增資產沉澱要求：KM、PlayBook、腳本 / Ansible、排程 / 監控規則、Verifier 結果；並要求 Runs、Work Items、Knowledge Base 顯示資產 ID、owner、狀態與下一步。 +- `apps/api/src/services/repair_candidate_service.py` 的 `repair_candidate_draft_package_v1` 新增 `automation_asset_requirements` 與 `required_writebacks`，讓 AwoooP Work Item / API / Telegram 共用同一份沉澱契約，而不是只有文字提醒。 +- 修復候選草案必填欄位從 PlayBook 基礎欄位擴充為：`script_or_ansible_ref`、`schedule_or_monitoring_rule_ref`、`km_update_plan`、`automation_asset_record`，並把 `automation_asset_record` / `dashboard_visibility_refs` 納入 coverage gap 模板欄位。 + +**本地驗證**： +- `DATABASE_URL=postgresql+asyncpg://ci:ci@localhost/ci PYTHONFAULTHANDLER=1 /Users/ogt/.pyenv/shims/pytest tests/test_telegram_webhook_execution_handoff.py tests/test_telegram_message_templates.py tests/test_telegram_ai_automation_block.py tests/test_repair_candidate_service.py -q -p no:cacheprovider`：`71 passed`。 +- `python3 -m py_compile apps/api/src/api/v1/telegram.py apps/api/src/services/telegram_gateway.py apps/api/src/services/repair_candidate_service.py` 通過。 +- `git diff --check` 通過。 +- `python3 scripts/security/source-control-owner-response-guard.py --root .`：`SOURCE_CONTROL_OWNER_RESPONSE_GUARD_OK`。 +- `python3 scripts/security/security-mirror-progress-guard.py --root .`：`SECURITY_MIRROR_PROGRESS_GUARD_OK`。 +- 舊死結字串掃描：`ApprovedWithoutExecution`、`此卡沒有可執行修復`、`等待補修復候選` 在 `apps/api/src` / `apps/api/tests` 命中 `0`。 + +**正式部署與 readback**： +- Code commit：`c1c20656 fix(api): 將無修復批准轉入處置包`。 +- Deploy marker：`3c6b9865 chore(cd): deploy c1c2065 [skip ci]`。 +- Gitea Actions：code-review `3108` 成功；CD `3107` 已產生 deploy marker，Actions list 顯示 `c1c20656` 已進 success 清單。 +- Production API：`GET https://awoooi.wooo.work/api/v1/health` 回 `healthy / prod / mock_mode=false`；PostgreSQL、Redis、Ollama GCP-A、OpenClaw、SigNoz 皆為 `up`。 +- Production Telegram health：`GET https://awoooi.wooo.work/api/v1/telegram/health` 回 `status=configured`、`mode=long_polling`、`polling_active=true`、`bot_token_set=true`、`chat_id_set=true`、`sre_group_chat_id_set=true`、whitelist `10`。 +- Production AwoooP smoke：`/zh-TW/awooop?_v=3c6b9865-ai-handoff-prod-desktop` 桌機 `1440x1000` 與 `/zh-TW/awooop?_v=3c6b9865-ai-handoff-prod-mobile` 手機 `390x844` 皆可見 `AwoooP`、`操作決策圖譜`、`告警 / 來源`、`證據鏈`、`學習回寫`、`來源到 Run`；console error `0`、HTTP failed `0`、頁面水平溢位 `0`、敏感工作視窗片語命中 `0`。 +- 截圖：`/tmp/awoooi-awooop-ai-handoff-prod-desktop-3c6b9865.png`、`/tmp/awoooi-awooop-ai-handoff-prod-mobile-3c6b9865.png`。 + +**仍待處理**： +- 手機 AwoooP 深層舊區塊仍有少量長 span 元素局部 overflow，頁面層沒有水平捲動，但仍屬於 D2 文字牆 / 舊區塊元件化問題。 +- 本輪沒有偽造正式 Telegram callback，不亂打 production nonce；no-action 批准契約以單元測試、部署 marker、Telegram health 與頁面 smoke 作為本段證據。 +- 下一段必須把 Work Items / Knowledge Base / Runs 的資產沉澱顯示整併，讓 KM、PlayBook、腳本、排程、Verifier 的 asset record 在頁面上可查，否則仍會落入「做了但使用者看不到」。 + +**邊界**：本輪沒有把 `NO_ACTION` 偷改成直接執行命令，沒有打開 runtime gate，沒有讀 secret，沒有發送測試 Telegram，沒有呼叫 Bot API 發正式訊息，沒有 SSH / kubectl / host write / active scan。此修正只把「無安全修復候選」從批准死結改成可追蹤處置包與資產沉澱契約；真正自動修復仍必須經修復候選、owner review、approval gate、executor、verifier 與 KM / PlayBook writeback。 + ## 2026-06-18｜重啟 Plan B 機讀 baseline 與 readiness audit guard 補強 **背景**：前一段已把 Plan B 寫進 `FULL-STACK-COLD-START-SOP.md`，但如果只有 Markdown，未來仍可能在重構或同步時漂移。這輪把 Plan B 升成機讀 baseline 與 readiness audit 必檢項，讓「有沒有 Plan B」可以被工具檢查。