85 lines
3.2 KiB
Markdown
85 lines
3.2 KiB
Markdown
# 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.
|