feat(agent99): add durable completion callback

docs/workplans/2026-07-10-agent99-enterprise-ai-automation-master-plan.md

@@ -1,6 +1,6 @@
 # Agent99 全域 AI 自動化主計畫
 
-> 建立時間：2026-07-10 15:05 CST；最近更新：2026-07-11 20:14 CST
+> 建立時間：2026-07-10 15:05 CST；最近更新：2026-07-11 20:34 CST
 > 狀態：P0 執行中，尚未達成全域 AI 自動化
 > 機器可讀總帳：`docs/operations/agent99-enterprise-ai-automation-work-items.snapshot.json`
 > 歷史需求來源：`docs/workplans/2026-07-02-commander-inserted-requirements-priority-ledger.md`
@@ -97,13 +97,13 @@
 
 ## 5. 更新後的唯一執行順序
 
-2026-07-11 20:14 live audit 重新校正後，機器可讀執行順序固定為：`AG99-P0-001 → P0-006 → P0-003 → P0-004 → P0-005 → P0-007 → P0-008 → P0-009 → P0-013 → P0-012 → P0-014 → P0-010 → P0-011`。先關閉 Agent99 假綠與看不見的執行結果，再擴充 ingress、evidence/candidate、verifier 與各 domain 自動化。下表的數字是穩定 work-item ID，不再被誤當目前執行順位；`next_execution_order` 才是 runtime projection 的唯一順位來源，且必須包含每個未完成 P0 恰好一次。
+2026-07-11 20:34 runtime 驗證後，機器可讀執行順序固定為：`AG99-P0-006 → P0-003 → P0-004 → P0-005 → P0-007 → P0-008 → P0-009 → P0-013 → P0-012 → P0-014 → P0-010 → P0-011`。`P0-001` 的假綠與看不見結果已由 99 runtime receipt 關閉，現在先完成 canonical callback，再擴充 ingress、evidence/candidate、verifier 與各 domain 自動化。下表的數字是穩定 work-item ID，不再被誤當目前執行順位；`next_execution_order` 才是 runtime projection 的唯一順位來源，且必須包含每個未完成 P0 恰好一次。
 
 ### Wave 0：先修正 AI 決策真相
 
 | 順序 | ID | 工作 | 狀態 | 驗收 |
 | --- | --- | --- | --- | --- |
-| 1 | AG99-P0-001 | 修正 `exitCode=0 => resolved`、evidence parse 假綠，對齊 99 runtime script 與 source SHA | **重新開啟；current P0** | Production 99 outcome self-test 通過；required evidence 必須 fresh 且可解析；Recover 必須有 sent 或明確 suppressed receipt；runtime manifest matched、drift `0` |
+| 1 | AG99-P0-001 | 修正 `exitCode=0 => resolved`、evidence parse 假綠，對齊 99 runtime script 與 source SHA | **完成；99 runtime `06509e071`** | required evidence `7/7` fresh+parsed+content healthy；Recover 7/7 phase verified；TG `sent=1`、`visualSent=1`；runtime manifest 14/14 matched |
 | 2 | AG99-P0-002 | 修正 alert taxonomy、wrong-domain routing、bridge-before-grouping、actionable Telegram card 漏接與重複事件 | **完成；99 runtime `34e32f6e`、14/14 matched** | Alertmanager、AI card、ACTION REQUIRED、CI/CD failure 共用 dispatcher；`suggestedMode`/kind 優先；5 分鐘先 group；同 fingerprint 只建立一個 active incident；保留 acceptance receipt |
 | 3 | AG99-P0-003 | 強化 ingress：relay token 必填、Telegram chat+sender allowlist、idempotency/single consumer | 待辦 | 未認證 LAN request 拒絕；producer `auto_repair`/policy 被保留；所有 request 可追 trace |
 | 4 | AG99-P0-004 | 新增 EvidenceCollect / RepairCandidate / MCP lane | 待辦 | 缺 evidence 的事件會建立可查 candidate，不再錯送 Perf/AwoooRepair；`INC-*` 可從收件追到 candidate |
@@ -113,7 +113,7 @@
 | 順序 | ID | 工作 | 狀態 | 驗收 |
 | --- | --- | --- | --- | --- |
 | 5 | AG99-P0-005 | 模式專屬 verifier、真 rollback、cooldown/circuit-breaker | 待辦 | Recover/Perf/LoadShed/Harbor/AWOOOI/backup/provider 各有 post-condition；失敗不寫成功 cooldown |
-| 6 | AG99-P0-006 | Agent99 → AWOOOI/AwoooP/IWOOOS completion callback | **進行中；先關閉 Recover 可見生命週期 receipt** | incident/Run/Work Item/Verifier/recurrence 同一 trace 收斂；Telegram 可讀回報只從結果物件產生 |
+| 6 | AG99-P0-006 | Agent99 → AWOOOI/AwoooP/IWOOOS completion callback | **進行中；current P0** | incident/Run/Work Item/Verifier/recurrence 同一 trace 收斂；Telegram 可讀回報只從結果物件產生 |
 | 7 | AG99-P0-007 | 全主機 10 分鐘 reboot state machine | **進行中；本輪 breach 後已 late recovery，L1/L2 runtime 已整合，L0/600 秒重測待完成** | L0 off-LAN detection/OOB power、L1 Agent99/VMware、L2 110 full-SOP 必須以同一 incident 閉環；首可用/全綠時間與 blocker/ETA 可查 |
 | 8 | AG99-P0-008 | 99 VMware/VMX/autostart/lock 與 Windows Update no-auto-reboot | **本次 boot runtime green；controlled apply/rollback/verifier 完成，待下次 reboot 驗證 startup 時序** | 110/188/112/120/121 VMX、autostart task、guest running 與 no-auto-reboot verifier green；111 由實體 Mac readback 驗證 |
 
@@ -200,6 +200,13 @@
 - 同一 preflight 對最新 SRE/Telegram inbox safe summary 顯示 `RuntimeException`，卻仍因檔案時間新而回傳綠燈。這是明確 false-green regression，不可用更多 dashboard 掩蓋。
 - current P0 因此重新定位為 `AG99-P0-001`，第二順位是 `AG99-P0-006`：先把 required evidence 改成 fresh + parseable、Recover 成功事件形成繁中生命週期卡與 phase timeline、dedupe 也留下 receipt；驗證後才回到 secure ingress、candidate、verifier 與 reboot/各 domain 主線。
 
+### 2026-07-11 20:34 P0-001 runtime closure 與 P0-006 source
+
+- Agent99 原子部署 receipt `agent99-deploy-20260711-202021.json` 回報 source revision `06509e071c8b7c538feb112e4e4774ee22abf7d1`、14/14 runtime files matched，rollback 是 `backup-20260711-202021`。
+- 新版 live preflight 在 20:20:51 回報 9/9 tasks、relay=1、queue=0，required evidence `fresh=7/7`、`usable=7/7`、parse/content failure 都是 0；不再用檔案時間掩蓋 inbox JSON 解析失敗。
+- Production-principal Recover `agent99-recovery-20260711-202159-3404b5b3` 完成 5/5 VM、5/5 host、5/5 public 與 7/7 recovery phases；42.9 秒、coordinator verified、service-recovery only。TG receipt 是 `sent=1`、`visualSent=1`，實際 1200×760 圖卡顯示七階段時間軸。後續同狀態 run 以 `dedupe_window` suppressed 並保留 receipt。
+- `P0-006` source 已新增 token-authenticated callback、idempotent channel event、AWOOOI operation receipts、AwoooP completed shadow run、durable DB readback，以及 99 pending/processed retry queue；payload 禁止 secret、raw log 與完整 evidence path。Focused tests 39 passed、ruff green。此段尚未經 Gitea CD 與 production replay，所以維持 in progress。
+
 ## 7. 工作項強制欄位與治理
 
 每個工作項必須先有：`id`、priority/order/status、scope、owner lane、dependencies、acceptance 與 next action。任何工作項升到 `candidate_ready`、`in_progress` 或 `executing` 前，還必須補齊 problem、trigger、evidence sources、AI role、action mode、controlled actions、prohibited actions、rollback、mode-specific verifier、callback、evidence refs 與 last update；缺一不可執行。
@@ -215,4 +222,4 @@
 
 ## 8. 立即下一步
 
-目前唯一 P0 是 `AG99-P0-001`。立即動作是把 parse-aware preflight、Recover 生命週期卡、phase timeline 與 dedupe receipt 原子部署到 99，再由 production principal 跑一次 Recover；只有 runtime manifest matched、preflight parse-clean、Telegram sent 或 dedupe-suppressed receipt 明確存在才前進。後續固定依序：`P0-006 → P0-003 → P0-004 → P0-005 → P0-007 → P0-008 → P0-009 → P0-013 → P0-012 → P0-014 → P0-010 → P0-011`。main push 只在唯一 writer slot 進行；沒有 slot 時保留 local commit，不讓推送協調打斷 runtime 主線。
+目前唯一 P0 是 `AG99-P0-006`。立即動作是提交 callback source，依單一 writer 協調取得 main push slot，讓 API 先經 Gitea CD 上線；再部署 99 callback client，重播一個受控 SRE alert，要求同一 callback/run/trace 在 AWOOOI operation log、AwoooP Run、IWOOOS owner plane、Agent99 local receipt 與 Telegram 都可讀回。後續固定依序：`P0-003 → P0-004 → P0-005 → P0-007 → P0-008 → P0-009 → P0-013 → P0-012 → P0-014 → P0-010 → P0-011`。main push 只在唯一 writer slot 進行；沒有 slot 時保留 local commit，不讓推送協調打斷 runtime 主線。