Sync Boatstack from Intelligence Flow Labs @ 719220d52b8a

[operator-stack-publisher]

What this sync releases

Change-safety net — the delivery model can grow without breaking what ships today

The delivery machine is now described in one authoritative registry, and two safety nets keep that
description honest as new features land:

• Coverage conformance. A test parses the CLI's real delivery dispatch and asserts every delivery
  verb it handles is classified — either mirrored by a registry transition or on an explicit
  non-delivery allowlist. A new delivery verb that forgets to declare itself in the registry now fails
  the build instead of silently drifting out of the model the driver navigates.

• Schema-migration hook. Managed delivery state is routed through a versioned migration step before
  it is loaded. At the current schema version this is a byte-for-byte pass-through, so today's behavior
  is unchanged; when the schema next changes, old state has a defined, tested upgrade path, and state
  written by a newer Boatstack fails closed with "update Boatstack" rather than as generic corruption.

Both are covered by control-law conformance suites, so the guarantees are enforced, not aspirational.
Together they mean the delivery-flow surface can gain moves and fields without stranding an in-flight
delivery or letting a new verb escape the model.

boatstack flow next --execute — run only the moves that are provably safe

flow next already prescribes the exact next command toward a published delivery. It now takes an
opt-in --execute flag that lets the driver run that move for you — but only when the move is proven
safe: its arguments follow entirely from state, and there is nothing to fabricate. At the first move
that owes human input — a gate's status and evidence, a reviewer's identity, the human-confirmed PR
preview fingerprint — the driver prescribes-and-stops and hands you the exact command to run.

Execute is off by default; it happens only when you pass --execute, and BOATSTACK_FLOW_DRIVE=0
refuses execution even then. Today every forward delivery move owes human input, so the driver
correctly prescribes-and-stops at the very first step — the shipped auto-drive allowlist is
deliberately empty of forward moves. This release is the mechanism and its guardrails: a move runs only
if it is BOTH on the allowlist AND has an explicitly registered executor, so nothing runs by accident,
and the driver never invents evidence, a gate status, a fingerprint, or an identity.

The driver re-reads ground truth after each executed step, so it never acts on an assumed position, and
a step budget bounds the loop as a backstop against any cycle in the model.

boatstack flow next — the exact command, not just the next state

flow next now prints the exact command to run for the lowest-cost next move toward a published
delivery, not just the name of the next state. The command is resolved through the delivery registry —
the same single declaration the conformance and liveness checks hold faithful — so the verb it emits is
always a real command the binary accepts, and always the legal next transition the oracle chose.

Arguments that follow from state (the feature, the addressable slice, the gate, the preview path) are
filled in for you. Arguments that must come from a human or CI — the gate status, the evidence ledger,
the human-confirmed preview fingerprint, the reviewer identity — are listed explicitly as required and
are never fabricated: they appear as <REQUIRED> placeholders in the printed command, and the --json
form carries them in a separate requires_human_input field alongside an auto_derivable flag. When
the flow position cannot be placed, flow next prescribes nothing rather than guessing a command.

This turns the delivery flow from something the operator has to reassemble each step into a single
readable instruction: the next command is derivable from the recorded state, so the tool states it.

boatstack flow tasks — the ordered sub-actions inside a building slice

While a delivery slice is building, the next move was only ever named "build" — an opaque instruction
that left the operator to reconstruct the order of the work by hand. flow tasks now reads the
compiled plan's task graph, scopes it to the active slice, and prints the slice's sub-actions in
dependency order with the one to start pointed at. The same first sub-action is surfaced as a hint on
flow next whenever the slice is building, so "build" is no longer a dead end.

The ordering is a topological sort of the slice's own depends_on edges: a dependency on an earlier
slice's task is treated as already done, and a dependency outside the slice never pulls a foreign task
into the list. The reader adds no state and tracks no completion — it orders and points; the operator
decides when a sub-action is done. When there is no compiled task graph or the flow position cannot be
placed, it resolves to nothing with a reason rather than inventing a sub-action.

Coding work is still never a modeled transition — this is a read-only pointer over the plan, not a new
part of the delivery state machine.

Projection provenance

Generated from operatorstack/intelligence-flow@719220d52b8ac1237c9169099b53a024dc583cc6.
Review provenance, tests, and examples before merging.