feat: sync watchdog recovery slice

README.md

@@ -8,112 +8,72 @@
 - **dispatch receipt binding**
 - **anti-blackhole / completion-delivery watchdog groundwork**
 
-目標是避免這種情況再次發生：
+目標是避免兩類問題持續發生：
 
-- 任務已完成
-- 下一步其實已經明確
-- 但沒有真的 dispatch 下一個 task
-- 最後流程卻還是收尾，造成 **auto-next break / continuity failure**
+1. **continuity failure / auto-next break**
+2. **subagent anti-blackhole / fake timeout**
 
 ## 目前已完成
 
-目前這個 repo 已經包含並驗證以下能力：
+### A. Continuity hard-gate
+- continuity evaluator
+- dispatch receipt binding groundwork
+- `derivedAction` continuity binding
+- `dry_run_dispatch` 不得冒充真 receipt
+- fake receipt authority 最小收緊
+- hook integration 已接入
 
-1. **continuity evaluator**
-   - task 完成、next action 已知、但沒有 next dispatch receipt，且 closure 狀態又不是 `waiting_user` / `blocked` / `pending_verification` 時，會判定 `continuity_failure`。
-
-2. **dispatch receipt binding groundwork**
-   - 已有 continuity receipt storage 定義
-   - 已有最小 dispatch receipt writer
-   - 已有 continuity gate / dispatch binding 對應測試
-
-3. **`derivedAction` 與 `nextDerivedAction` 一致納入 continuity 判定**
-   - 不再只有 `nextDerivedAction` 才受 gate 約束。
-
-4. **`dry_run_dispatch` 不得冒充真 receipt**
-   - planner 的 dry-run 結果不再被 handler fallback 當成真實 dispatch receipt。
-
-5. **fake receipt authority 已補強**
-   - continuity gate 不再接受任意 non-null `dispatchReceipt`
-   - 現在至少要求最小 receipt 欄位：
-     - `planId`
-     - `currentTask`
-     - `nextDerivedAction`
-     - `dispatchedAt`
-
-6. **hook integration 已接入**
-   - continuity gate 已接進 `hooks/force-recall/handler.ts`
-   - 目前會透過 `[APPROVED_PLAN_CONTINUITY_GATE]` block 注入現行 flow
+### B. Anti-blackhole watchdog recovery
+- watchdog status recompute
+- 最小 recovery decision 閉環：
+  - `fetch_history`
+  - `respawn`
+  - `blocked`
+- owner-visible reporting payload
+- scenario matrix tests
 
 ## 目前限制
-
-這條線雖然已經接入現行 flow，但目前仍偏向 **prompt-level hard-gate integration**，而不是 engine-level abort。也就是說：
-
-- 已經不是只有規則文件
-- 已經不是只有獨立腳本測試
-- 但也還不是最底層 runtime/core 的絕對阻斷器
+- continuity 仍偏 prompt-level hard-gate integration
+- watchdog recovery 目前驗收的是 decision / reporting / test slice，不是 live integration
 
 ## 下一步建議
-
-下一階段最合理的方向有兩條：
-
-1. **把 continuity hard-gate 再往更硬的 runtime enforcement 推進**
-2. **回頭補完 anti-blackhole / completion-delivery watchdog recovery 閉環**
+1. continuity runtime enforcement hardening
+2. watchdog live recovery integration
+3. escalation / receipt contract hardening
 
 ---
 
 ## English Description
 
-This repository is a focused export from a larger OpenClaw workspace. It captures a workflow hardening workstream around:
+This repository is a focused export from a larger OpenClaw workspace covering:
 
 - **approved plan continuity hard-gate**
-- **dispatch receipt binding**
-- **anti-blackhole / completion-delivery watchdog groundwork**
-
-The goal is to prevent this failure mode:
-
-- a task is completed,
-- the next step is already known,
-- but the next task is never actually dispatched,
-- and the flow still closes out as if continuity were preserved.
+- **anti-blackhole / completion-delivery watchdog recovery**
 
 ## Current State
 
-The repo now includes and validates the following capabilities:
+### A. Continuity hard-gate
+- continuity evaluator
+- dispatch receipt binding groundwork
+- `derivedAction` continuity binding
+- `dry_run_dispatch` no longer accepted as a real receipt
+- fake receipt authority tightened
+- hook integration present
 
-1. **Continuity evaluator**
-   - When a task is complete, the next action is known, and there is no next dispatch receipt, and the closure state is not `waiting_user`, `blocked`, or `pending_verification`, the flow is classified as `continuity_failure`.
+### B. Anti-blackhole watchdog recovery
+- watchdog status recompute
+- minimal recovery-decision loop:
+  - `fetch_history`
+  - `respawn`
+  - `blocked`
+- owner-visible reporting payload
+- scenario matrix tests
 
-2. **Dispatch receipt binding groundwork**
-   - continuity receipt storage shape
-   - minimal dispatch receipt writer
-   - continuity gate / dispatch binding tests
-
-3. **`derivedAction` is treated as a real next-action source**
-   - The gate no longer depends only on `nextDerivedAction`.
-
-4. **`dry_run_dispatch` is no longer accepted as a real receipt**
-   - Planner dry-run output is no longer promoted into a real dispatch receipt by handler fallback logic.
-
-5. **Fake receipt authority has been tightened**
-   - The continuity gate no longer accepts any arbitrary non-null `dispatchReceipt`
-   - It now requires at least these minimum fields:
-     - `planId`
-     - `currentTask`
-     - `nextDerivedAction`
-     - `dispatchedAt`
-
-6. **Hook integration is now present**
-   - The continuity gate is integrated into `hooks/force-recall/handler.ts`
-   - It currently enters the live flow through the `[APPROVED_PLAN_CONTINUITY_GATE]` injected block
-
-## Current Limitation
-
-This workstream is now beyond pure documentation and beyond isolated script-level testing, but it still behaves more like a **prompt-level hard-gate integration** than a true engine-level abort mechanism.
+## Current Limitations
+- continuity remains prompt-level rather than engine-level
+- watchdog recovery is validated as a decision/reporting/test slice, not live execution integration
 
 ## Suggested Next Steps
-
-Two reasonable follow-up directions remain:
-
-1. **push continuity hard-gate further toward stronger runtime enforcement**
-2. **return to anti-blackhole / completion-delivery watchdog recovery closure**
+1. continuity runtime enforcement hardening
+2. watchdog live recovery integration
+3. escalation / receipt contract hardening