# Auto-Next Obligation Gate

## Purpose

This runbook defines the approved-plan continuity rule that a workflow may not stop at a completed-task boundary when the next task in the same approved plan is already known and continuation is still allowed.

## When auto-next is obligatory

Auto-next is obligatory when all of the following are true:

- the current workflow is inside the same approved plan
- the current task is complete
- the next task is known
- the system is attempting a task-boundary stop instead of continuing execution
- reply closure state is not `waiting_user`
- reply closure state is not `blocked`
- reply closure state is not `pending_verification`
- `highRiskStop` is not active

In this state, the system must auto-dispatch the next task and record a real dispatch receipt. A dry-run planner result or stated intent to continue is not enough.

## Legal non-auto-next closures

The following are legal non-auto-next closures even when a next task exists:

- `waiting_user`
- `blocked`
- `pending_verification`

These states are the only normal closure states that can stop without auto-next dispatch.

## Allowed non-closure exception

The following explicit exception may bypass auto-next obligation without using the normal legal terminal closure states:

- `highRiskStop`

`highRiskStop` means the workflow is intentionally stopping at an explicit high-risk stop point and therefore does not have to auto-dispatch the next task yet.

## Forbidden behavior

The following behavior is forbidden:

- completed task
- next task known
- same approved plan
- normal closeout or handoff language
- no real dispatch receipt for the next task
- no legal closure state
- no `highRiskStop`

A completed task in the same approved plan must not end with “I can continue with the next task” style closeout unless the next task has actually been dispatched.

## Canonical failure condition

If all of the following are true:

- task is complete
- next task is known
- next task belongs to the same approved plan
- the system is stopping at a task boundary
- no valid dispatch receipt exists
- closure is not `waiting_user`, `blocked`, or `pending_verification`
- `highRiskStop` is false

Then the continuity gate must fail and treat the stop as an auto-next obligation violation.

## Canonical failure table

| Task complete | Next task known | Same approved plan | Boundary stop | Receipt | Closure / exception | Expected |
| --- | --- | --- | --- | --- | --- | --- |
| yes | yes | yes | yes | no | completed closure | FAIL |
| yes | yes | yes | yes | valid receipt | completed closure | PASS |
| yes | yes | yes | yes | no | `waiting_user` | PASS |
| yes | yes | yes | yes | no | `blocked` | PASS |
| yes | yes | yes | yes | no | `pending_verification` | PASS |
| yes | yes | yes | yes | no | `highRiskStop` | PASS |

## Notes for implementation

- The obligation applies only when the next task is known within the same approved plan.
- A generic next action is not enough unless it proves the same approved plan task transition.
- A real dispatch receipt remains the source of truth for whether auto-next actually happened.
- This rule is intentionally minimal so it can later move into the continuity plugin without changing the behavior contract.