# 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 內主要包含：

- continuity gate 規則與測試
- dispatch receipt binding 骨架與最小 receipt writer
- anti-blackhole / delivery watchdog 的前置設計與基礎腳本
- 相關 runbook / plan / state shape

### 目前重點

這個 repo 目前著重於把以下能力拆成可測試、可逐步落地的切片：

1. **continuity hard-gate**
   - approved plan 內 task 完成後，若沒有 next dispatch receipt，且狀態又不是 `waiting_user` / `blocked` / `pending_verification`，則不應允許正常收尾。

2. **dispatch receipt binding**
   - 不只知道 planner 推導出下一步，而是要真的留下可驗證的 dispatch receipt。

3. **anti-blackhole groundwork**
   - 為後續的 subagent completion-delivery watchdog 提供 receipt / state / failure mode 基礎。

### 說明

這是一個**聚焦匯出 repo**，不是整個原 workspace 的完整鏡像。目的是先把相關修補線獨立出來，方便：

- 追蹤修補進度
- 做 code review
- 補 README / runbook / 測試
- 後續再整合回主要流程

---

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

The repository currently includes:

- continuity gate rules and tests
- dispatch receipt binding skeletons and a minimal receipt writer
- groundwork for anti-blackhole / delivery-watchdog handling
- related runbooks, plans, and state-shape definitions

### Current Focus

This repo is currently structured to make the following capabilities testable and incrementally adoptable:

1. **Continuity hard-gate**
   - If a task inside an approved plan is marked complete, and there is no next dispatch receipt, and the closure state is not `waiting_user`, `blocked`, or `pending_verification`, the flow should not be allowed to close normally.

2. **Dispatch receipt binding**
   - It is not enough for the planner to derive a next action; that action must also produce verifiable dispatch evidence.

3. **Anti-blackhole groundwork**
   - The repo also lays groundwork for future subagent completion-delivery watchdog logic through receipt/state/failure-mode definitions.

### Note

This is a **focused export repository**, not a full mirror of the original workspace. The intent is to isolate the relevant hardening work so it can be:

- reviewed more easily
- iterated independently
- documented clearly
- integrated back into the main flow later