docs(ops): make readiness summary first reboot check [skip ci]

docs/LOGBOOK.md

@@ -44910,6 +44910,7 @@ production browser smoke:
 - 新增 post-reboot 機器可讀摘要腳本，串接既有只讀 `post-start-quick-check.sh`、188 host hygiene checklist、Wazuh no-false-green repo gates。
 - 腳本不新增 runtime 修復能力，不會 restart / reload / repair / import / delete / patch / write remote state。
 - 輸出固定 key/value，讓 operator / AI agent 每次重啟後先判斷 `SERVICE_GREEN`、`PRODUCT_DATA_GREEN`、`BACKUP_CORE_GREEN`、`DR_ESCROW_BLOCKED`、`HOST_188_HYGIENE_BLOCKED`、`WAZUH_MANAGER_REGISTRY_ACCEPTED`、`RUNTIME_ACTION_AUTHORIZED` 與 `NEXT_REQUIRED_GATES`。
+- `docs/runbooks/REBOOT-POST-START-QUICK-CHECK.md` 升至 v1.7，將此 summary 設為第一入口，舊 `post-start-quick-check.sh` 保留為展開細節與手動 fallback。
 
 **只讀驗證結果**：
 - `POST_START_RESULT=FULL_STACK_GREEN_DR_ESCROW_BLOCKED`

docs/runbooks/REBOOT-POST-START-QUICK-CHECK.md

@@ -1,6 +1,6 @@
 # 主機重啟後一頁式總檢查
 
-> Version: v1.6
+> Version: v1.7
 > Last updated: 2026-06-26 Asia/Taipei
 > Scope: 110 / 120 / 121 / 188 post-reboot service recovery. 112 Kali / Wazuh / active scan 不屬於本流程。
 
@@ -10,7 +10,7 @@
 
 每次 110 / 120 / 121 / 188 任一台主機開機、關機、重啟、斷電恢復、VMware console fsck、Docker / K3s 大量重排後，都先跑本頁，再決定是否宣稱恢復。
 
-最新基準：2026-06-26 06:26-06:28 read-only refresh。Cold-start `PASS=89 WARN=0 BLOCKED=0`；MOMO `V10.690`、latest import job `57 completed`、`DB_DAILY_FRESHNESS 1|2026-06-24`；StockPlatform `/api/v1/system/freshness` 為 `status=ok`、`latest_trading_date=2026-06-25`、blockers `[]`；backup-status 110 `13/13 fresh failed=0`、188 `2/2 fresh failed=0`、`core_blockers=0`、`offsite_fresh=1`、`rclone_gdrive_fresh=1`、`last_backup_all=2026-06-26 02:31:02`。DR 仍因 `escrow_missing=5` 不可宣稱 complete。06:26 full wrapper 的 `iwooos` / `vibework` 單次 route `000` 已由獨立 curl 與 route-only wrapper 確認為 transient；v1.6 起 public route gate 會 retry，只有連續失敗才算 `BLOCKED`。
+最新基準：2026-06-26 07:47 machine-readable summary。`scripts/reboot-recovery/post-reboot-readiness-summary.sh --no-color` 回傳 `SERVICE_GREEN=1`、`PRODUCT_DATA_GREEN=1`、`BACKUP_CORE_GREEN=1`、`DR_ESCROW_BLOCKED=1`、`ESCROW_MISSING_COUNT=5`、`HOST_188_HYGIENE_BLOCKED=1`、`WAZUH_MANAGER_REGISTRY_ACCEPTED=0`、`RUNTIME_ACTION_AUTHORIZED=0`、`OVERALL_DECLARATION=FULL_STACK_GREEN_DR_ESCROW_BLOCKED`。Cold-start `PASS=89 WARN=0 BLOCKED=0`；MOMO `V10.701`、latest import job `57 completed`、`DB_DAILY_FRESHNESS 1|2026-06-24`；StockPlatform `/api/v1/system/freshness` 為 `status=ok`、`latest_trading_date=2026-06-25`、blockers `[]`；backup-status 110 `13/13 fresh failed=0`、188 `2/2 fresh failed=0`、`core_blockers=0`、`offsite_fresh=1`、`rclone_gdrive_fresh=1`、`last_backup_all=2026-06-26 02:31:02`。DR 仍因 `escrow_missing=5` 不可宣稱 complete。188 host hygiene 與 Wazuh manager registry 仍是 service green 之外的獨立 blocker。
 
 本頁只回答四件事：
 
@@ -43,13 +43,30 @@
 
 ## 3. 10 分鐘只讀總檢查順序
 
-優先使用 repo-side wrapper：
+優先使用 machine-readable summary：
+
+```bash
+scripts/reboot-recovery/post-reboot-readiness-summary.sh --no-color
+```
+
+此 summary 只做 read-only 檢查，會委派一頁式總檢查、188 host hygiene checklist 與 Wazuh repo-side no-false-green gates，並將 delegated logs 保留在 `/tmp/awoooi-post-reboot-readiness-*`。第一眼先看這些欄位：
+
+- `SERVICE_GREEN=1`：服務面可宣稱恢復。
+- `PRODUCT_DATA_GREEN=1`：MOMO / StockPlatform 主要資料 freshness 可宣稱恢復。
+- `BACKUP_CORE_GREEN=1`：備份核心可宣稱恢復。
+- `DR_ESCROW_BLOCKED=1` / `ESCROW_MISSING_COUNT>0`：不可宣稱 DR complete。
+- `HOST_188_HYGIENE_BLOCKED=1`：188 host hygiene 需維護窗口，不等於產品服務掛掉。
+- `WAZUH_MANAGER_REGISTRY_ACCEPTED=0`：不可宣稱 Wazuh 全主機納管恢復。
+- `RUNTIME_ACTION_AUTHORIZED=0`：本流程沒有授權 runtime 寫操作。
+- `OVERALL_DECLARATION`：本輪可使用的最高宣告。
+
+需要展開細節時，再使用 repo-side wrapper：
 
 ```bash
 scripts/reboot-recovery/post-start-quick-check.sh --no-color
 ```
 
-此 wrapper 只做 read-only 檢查，並委派既有 cold-start / MOMO preflight / backup-status；不 restart、不 reload、不 import、不改 K8s、不讀 token 內容。wrapper 會把 warning 分成 `SERVICE`、`BOUNDARY`、`EVIDENCE` 三類，避免把 `escrow_missing>0` 誤判成服務降級。若 wrapper 因某個 SSH 權限或路徑失敗，再依下列分段命令手動補證據。
+此 wrapper 只做 read-only 檢查，並委派既有 cold-start / MOMO preflight / backup-status；不 restart、不 reload、不 import、不改 K8s、不讀 token 內容。wrapper 會把 warning 分成 `SERVICE`、`BOUNDARY`、`EVIDENCE` 三類，避免把 `escrow_missing>0` 誤判成服務降級。若 summary 或 wrapper 因某個 SSH 權限或路徑失敗，再依下列分段命令手動補證據。
 
 Public route gate 自 v1.6 起會使用 `ROUTE_RETRY_ATTEMPTS`（預設 `3`）與 `ROUTE_RETRY_DELAY_SECONDS`（預設 `2`）重試。單次 `000` / timeout 若 retry 後恢復，應列為 evidence warning 或 transient route evidence，不可直接當成網站仍壞；只有連續失敗才是 service blocker。