docs(logbook): record approval timeline deploy [skip ci]

docs/LOGBOOK.md

@@ -1,3 +1,43 @@
+## 2026-05-07 | AwoooP 人工審批決策寫入 Run Timeline
+
+**背景**：AwoooP Run Detail / Action Panel 已把 `waiting_approval` 導到審批頁，審批頁也會在決策後回到 Run Timeline；但後端 `decide_approval()` 只轉 Run state 與寫 audit，Timeline 本身沒有「人工核准 / 人工拒絕」節點。這會讓操作者回到 Run Detail 後，只看到狀態變了，卻看不到是誰在人工閘門做了哪個決策。
+
+**本次修補**：
+- `platform_operator_service.decide_approval()` 在 approve / reject 後寫入 `awooop_run_step_journal`。
+- Step tool name 使用：
+  - `operator_console.approve`
+  - `operator_console.reject`
+- Run Detail timeline 看到 `operator_console.*` step 時，轉成「人工審批：核准 / 拒絕」語義節點。
+- Step summary 保留 `approver`、`decision`、`reason`，並壓縮到 DB 欄位安全長度。
+- 同步更新 `awooop_run_state.step_count`，讓 evidence count 與 timeline 數量一致。
+- `write_audit()` 補 `run_id`，讓 audit log 可以回掛 Run。
+- 前端 Run Detail timeline 對 `kind="approval"` 使用審批圖示。
+- 修正 Run Detail 既有隱性問題：後端 import `or_ as sa_or`，但查詢使用 `sa_or_()`；本輪改為一致的 `sa_or()`，避免 detail API 在有資料時觸發 `NameError`。
+
+**驗證**：
+- `py_compile apps/api/src/services/platform_operator_service.py` → passed。
+- `ruff check apps/api/src/services/platform_operator_service.py` → All checks passed。
+- `pytest apps/api/tests/test_awooop_operator_auth.py apps/api/tests/test_platform_router_order.py -q` → 7 passed。
+- `pnpm --filter @awoooi/web lint -- --file 'src/app/[locale]/awooop/runs/[run_id]/page.tsx'` → No ESLint warnings or errors。
+- `pnpm --filter @awoooi/web typecheck` → success。
+- `NEXT_PUBLIC_API_URL='https://awoooi.wooo.work' pnpm --filter @awoooi/web build` → success，`/[locale]/awooop/runs/[run_id]` route 存在。
+- touched files internal IP scan → no match。
+- Gitea Code Review `#1862` success，CD `#1861` success。
+- CD deploy marker：`83f4ab0d chore(cd): deploy 2df36b1 [skip ci]`。
+- K8s live image：
+  - `awoooi-api` → `192.168.0.110:5000/awoooi/api:2df36b11e2f961d0d05e79518126b96b55d4d338`。
+  - `awoooi-web` → `192.168.0.110:5000/awoooi/web:2df36b11e2f961d0d05e79518126b96b55d4d338`。
+  - `awoooi-worker` → `192.168.0.110:5000/awoooi/api:2df36b11e2f961d0d05e79518126b96b55d4d338`。
+- Production smoke：
+  - `/api/v1/health` → 200。
+  - `/zh-TW/awooop/runs/{run_id}` → 200。
+  - `/en/awooop/runs/{run_id}` → 200。
+  - `/api/v1/platform/runs/list?per_page=3` → 200，`total=0`（目前 production 無可展示 Run，非路由錯誤）。
+- Production API/Web log 短窗口未看到 `platform_operator`、`run_detail`、`approval_decision_step`、`NameError`、`sa_or`、Traceback、`MISSING_MESSAGE` 或 `IntlError`。
+- CD 尾段 188 ops 腳本同步再次驗證：`docker-health-monitor.sh 已同步`、`pg-backup.sh 已同步`、`權限設定完成`，未再出現 `scp: unrecognized option: n`。
+
+判讀：AwoooP 的人工審批已回到 Run Timeline 主線。下一步要做的是讓 Telegram 原告警卡的「已批准 / 已拒絕 / 執行中 / 已結束」狀態與 AwoooP Run state 使用同一個狀態摘要，避免群組和 Console 仍出現語義落差。
+
 ## 2026-05-07 | CD 188 ops 腳本同步修復，移除 scp 不支援參數
 
 **背景**：手動檢查 Gitea CD log 時發現 `Sync Ops Scripts to 188` 步驟雖然被標成非致命，但實際上 `scp` 收到 `ssh` 專用的 `-n` 參數後會報 `scp: unrecognized option: n`，導致 `docker-health-monitor.sh` 與 `pg-backup.sh` 無法同步到 188。這會讓 188 ops 腳本版本漂移，後續監控與備份治理難以信任。