# 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**