feat: sync latest continuity hard-gate integration

README.md

@@ -15,34 +15,50 @@
 - 但沒有真的 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 evaluator**
+   - task 完成、next action 已知、但沒有 next dispatch receipt，且 closure 狀態又不是 `waiting_user` / `blocked` / `pending_verification` 時，會判定 `continuity_failure`。
 
-這個 repo 目前著重於把以下能力拆成可測試、可逐步落地的切片：
+2. **dispatch receipt binding groundwork**
+   - 已有 continuity receipt storage 定義
+   - 已有最小 dispatch receipt writer
+   - 已有 continuity gate / dispatch binding 對應測試
 
-1. **continuity hard-gate**
-   - approved plan 內 task 完成後，若沒有 next dispatch receipt，且狀態又不是 `waiting_user` / `blocked` / `pending_verification`，則不應允許正常收尾。
+3. **`derivedAction` 與 `nextDerivedAction` 一致納入 continuity 判定**
+   - 不再只有 `nextDerivedAction` 才受 gate 約束。
 
-2. **dispatch receipt binding**
-   - 不只知道 planner 推導出下一步，而是要真的留下可驗證的 dispatch receipt。
+4. **`dry_run_dispatch` 不得冒充真 receipt**
+   - planner 的 dry-run 結果不再被 handler fallback 當成真實 dispatch receipt。
 
-3. **anti-blackhole groundwork**
-   - 為後續的 subagent completion-delivery watchdog 提供 receipt / state / failure mode 基礎。
+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
 
-這是一個**聚焦匯出 repo**，不是整個原 workspace 的完整鏡像。目的是先把相關修補線獨立出來，方便：
+## 目前限制
 
-- 追蹤修補進度
-- 做 code review
-- 補 README / runbook / 測試
-- 後續再整合回主要流程
+這條線雖然已經接入現行 flow，但目前仍偏向 **prompt-level hard-gate integration**，而不是 engine-level abort。也就是說：
+
+- 已經不是只有規則文件
+- 已經不是只有獨立腳本測試
+- 但也還不是最底層 runtime/core 的絕對阻斷器
+
+## 下一步建議
+
+下一階段最合理的方向有兩條：
+
+1. **把 continuity hard-gate 再往更硬的 runtime enforcement 推進**
+2. **回頭補完 anti-blackhole / completion-delivery watchdog recovery 閉環**
 
 ---
 
@@ -61,31 +77,43 @@ The goal is to prevent this failure mode:
 - but the next task is never actually dispatched,
 - and the flow still closes out as if continuity were preserved.
 
-The repository currently includes:
+## Current State
 
-- 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
+The repo now includes and validates the following capabilities:
 
-### Current Focus
+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`.
 
-This repo is currently structured to make the following capabilities testable and incrementally adoptable:
+2. **Dispatch receipt binding groundwork**
+   - continuity receipt storage shape
+   - minimal dispatch receipt writer
+   - continuity gate / dispatch binding tests
 
-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.
+3. **`derivedAction` is treated as a real next-action source**
+   - The gate no longer depends only on `nextDerivedAction`.
 
-2. **Dispatch receipt binding**
-   - It is not enough for the planner to derive a next action; that action must also produce verifiable dispatch evidence.
+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.
 
-3. **Anti-blackhole groundwork**
-   - The repo also lays groundwork for future subagent completion-delivery watchdog logic through receipt/state/failure-mode definitions.
+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`
 
-### Note
+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
 
-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:
+## Current Limitation
 
-- reviewed more easily
-- iterated independently
-- documented clearly
-- integrated back into the main flow later
+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**