openclaw/reporting-governance-plugin
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs: define legal approved-plan terminal states

Browse Source
This commit is contained in:
Eve
2026-04-24 11:49:30 +08:00
parent 15ef9ac425
commit 113f1cdb39
1 changed files with 19 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

19
docs/runbooks/approved-plan-continuity.md
View File

@@ -35,3 +35,22 @@
- Use this field to state whether the reply closed under a dispatch-linked continuation path or some separately defined terminal closure state. - 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. - 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.