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