reporting-governance-plugin/docs/runbooks/approved-plan-continuity.md

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.