feat: export continuity hard-gate and watchdog workstream

docs/runbooks/approved-plan-continuity.md

@@ -0,0 +1,56 @@
+# Approved Plan Continuity
+
+## Continuity receipt core fields
+
+### `planId`
+- The identifier of the approved plan that the continuity receipt belongs to.
+- Use this field to associate the receipt with one specific approved plan.
+
+### `currentTask`
+- The task from the approved plan that is currently being executed or has just completed.
+- Use this field to record which plan task the receipt is about.
+
+### `nextDerivedAction`
+- The next concrete action derived from the current task that should be dispatched to continue the workflow.
+- Use this field to record the intended follow-up action for continuity.
+
+### `dispatchedAt`
+- The timestamp indicating when the next derived action was actually dispatched.
+- Use this field to record when the continuity handoff occurred.
+
+## Continuity receipt linkage fields
+
+### `dispatchRunId`
+- The unique identifier for the dispatch run that produced or recorded the next-step continuity handoff.
+- Use this field to link the receipt to one concrete dispatch execution, not just a planned action.
+- This field is for receipt linkage and traceability only; it does not by itself define continuity-gate pass/fail behavior.
+
+### `childSessionKey`
+- The session linkage key for the child session or spawned execution context that receives the dispatched next action.
+- Use this field to connect the continuity receipt to the specific downstream session that should carry the workflow forward.
+- This field records linkage identity only; it does not by itself imply hook integration or dispatch binding logic.
+
+### `replyClosureState`
+- The closure state recorded at the point the current reply is being closed.
+- Use this field to state whether the reply closed under a dispatch-linked continuation path or some separately defined terminal closure state.
+- This field is defined here as a receipt field only; legal closure states and gate enforcement are defined in later tasks.
+
+
+## Legal terminal states
+
+These are the only legal non-dispatch terminal states for an approved-plan continuity closure. If a reply closes without a real next-dispatch receipt, `replyClosureState` must be one of the states below.
+
+### `waiting_user`
+- Use this state only when the approved-plan workflow cannot continue until the user provides a decision, approval, missing information, or some other explicit user response.
+- This state means the workflow is intentionally paused on user input, not silently stopped.
+- Do not use this state when the next step could already be dispatched without further user involvement.
+
+### `blocked`
+- Use this state only when the approved-plan workflow cannot proceed because of an external blocker, dependency, permission issue, outage, or other constraint that is not resolved by the current executor.
+- This state means progress is prevented by a real blocking condition, not by omission of the next dispatch.
+- Do not use this state to explain away a missing continuity handoff when execution could still continue.
+
+### `pending_verification`
+- Use this state only when the implementation or execution step is done enough that the workflow should stop specifically for verification, validation, review, or confirmation of results.
+- This state means the next meaningful action is to verify what was already produced, rather than to dispatch another implementation step immediately.
+- Do not use this state for incomplete work that still has an undispatched next action.