approved-plan-continuity-hard-gate/README.md

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