120 lines
4.4 KiB
Markdown
120 lines
4.4 KiB
Markdown
# 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**
|