Approved Plan Continuity Hard Gate

中文說明

這個 repo 是從較大的 OpenClaw workspace 中抽出的焦點工作流成果，主題是：

• approved plan continuity hard-gate
• dispatch receipt binding
• anti-blackhole / completion-delivery watchdog groundwork

目標是避免這種情況再次發生：

• 任務已完成
• 下一步其實已經明確
• 但沒有真的 dispatch 下一個 task
• 最後流程卻還是收尾，造成 auto-next break / continuity failure

目前已完成

目前這個 repo 已經包含並驗證以下能力：

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

目前限制

這條線雖然已經接入現行 flow，但目前仍偏向 prompt-level hard-gate integration，而不是 engine-level abort。也就是說：

• 已經不是只有規則文件
• 已經不是只有獨立腳本測試
• 但也還不是最底層 runtime/core 的絕對阻斷器

下一步建議

下一階段最合理的方向有兩條：

1. 把 continuity hard-gate 再往更硬的 runtime enforcement 推進
2. 回頭補完 anti-blackhole / completion-delivery watchdog recovery 閉環

---

English Description

This repository is a focused export from a larger OpenClaw workspace. It captures a workflow hardening workstream around:

• 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.

Current State

The repo now includes and validates the following capabilities:

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.

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.

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