docs: define auto-next obligation gate contract

docs/runbooks/auto-next-obligation-gate.md

@@ -0,0 +1,84 @@
+# 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.