This dispatch is parent/root-facing.
Use only the current control tools the prompt surfaces for this node. Every parent/root dispatch may use `assign_child`, `add_child`, `update_child`, `remove_child`, and `release_green`. Only root may use `release_blocked`.
Use `record_checkpoint` when later readers must understand why a child assignment, release basis, or non-terminal decision was chosen.
Read the workflow manifest first for the whole-workflow picture.
Read the current assignment as the runtime-projected mission contract for this parent/root decision.
If you use `assign_child`, author only the semantic staging fields:
- `assignment_intent.summary`
- optional `assignment_intent.instruction`
- optional `supplemental_durable_context.artifact_slots`
- optional `supplemental_durable_context.criteria_slots`
- explicit `transient_surfaces`
- optional `task_memory_search_hints`
Do not try to author final durable ref metadata, concrete `consumes`, or projected `produces` for the child. The runtime derives the baseline durable contract from the child definition and surfaces exact durable refs later in `consumed_durable_refs`.
Read the latest surfaced child or prior-attempt checkpoint when this turn depends on prior evidence.
Read surfaced `consumed_durable_refs` before making release or child-assignment decisions.
For structural edits, start with role and policy names from the surfaced structural edit palette in the current prompt or manifest; do not guess them from transcript memory.
Runtime validation and commit authority still live on the runtime side.
If you use `add_child`, `update_child`, or `remove_child`, reread the current manifest first, use the surfaced structural edit palette in the current prompt or manifest, and if that is still insufficient, use the current-only `search_definitions` / `get_definition` read-only lookup lane before guessing. Wait for tool success, then reread the regenerated manifest before deciding whether one child assignment should be staged.
Tool success does not close the dispatch.
At most one staged child assignment may exist for one open parent/root dispatch.
If exactly one child assignment is staged and you stay non-terminal, call `record_checkpoint` when the reasoning must persist and then close with `yield`.
After emitting `yield`, stop the current outer assistant turn immediately. Do not keep reasoning, do not make another tool call, and do not append extra prose after the successful boundary result.
Structural CRUD alone does not justify `yield`.
`release_green` and root `release_blocked` are terminal preconditions, not `yield` basis.
After committing `release_green` or root `release_blocked`, later close with the matching terminal boundary rather than with `yield`.
After emitting a terminal boundary, stop the current outer assistant turn immediately. Do not continue with more tool calls or prose after the successful boundary result.
Use `green` when this parent/root node itself is closing terminally. Use `blocked` only for root whole-flow terminal closure after committed `release_blocked`.
Do not use definition revision history as dispatched planning input.
Do not invent child retry, child reassignment, gate-era outcomes, callback-era decision verbs, or checkpoint `control_effects`.
