Sync Boatstack from Intelligence Flow Labs @ 2e2731b89000

[operator-stack-publisher]

What this sync releases

recovery-status no longer blocks on an unrelated, already-ignored stale delivery

recovery-status scans the shared delivery-state store before it selects the delivery a correction belongs to. That scan (allManagedDeliveryStates) failed closed on the first unreadable delivery and never consulted workflow.ignored_deliveries. So a single delivery abandoned by an earlier session — malformed on disk, and already explicitly ignored — turned every recovery into a repo-wide BLOCKED: Managed delivery state cannot be verified, even when the delivery actually being recovered was healthy and on the current branch. An operator hit exactly this in the field: recovery of a fine, unrelated pull request was stranded by a stale ignored delivery it had no relationship to, with no in-tool way forward.

This is the same failure class the next boundary already closed under the control law stale-delivery-cannot-block-unrelated-feature — but that law had been written as if it lived only at the ResolveNext boundary, so the twin read-only boundary, ResolveRecovery, never got the treatment. The store is one shared resource crossed by three boundaries: the two read-only resolvers (ResolveNext, ResolveRecovery), which must tolerate an unrelated corrupt delivery, and the mutation enumerator (ActiveManagedDeliveries), which must stay fail-closed so corrupt state can never be laundered into a write.

The law is now stated over the invariant rather than one call site, and ResolveRecovery enforces it. allManagedDeliveryStates partitions the store the way scanManagedDeliveries does for next: readable states come back as data, unreadable slugs come back as a separate list rather than aborting the scan. ResolveRecovery then applies the operator's ignored-deliveries filter to both lists before any invalidity becomes fatal, and blocks only on a delivery that is still both invalid and unignored — naming it and routing to the discard-delivery remedy. Recovery of an unrelated healthy delivery proceeds with an ignored corrupt delivery in the store; the mutation boundary is unchanged and still fails closed.

The regression suite pins the class shut at the recovery boundary with the twins of the existing next conformance tests — an ignored invalid delivery no longer blocks a healthy branch (positive/bypass), a still-unignored invalid delivery blocks while naming the offender and prescribing discard-delivery (negative/relation), and the read-only resolver leaves the offending state byte-for-byte untouched. A companion guide, docs/control-law-scoping.md, records the method that would have caught the original miss: state a control law over its invariant and failure class, enumerate every boundary that crosses the shared resource, and extend the existing law to cover them rather than minting a near-duplicate for the second one.

Concurrent first use no longer fails with "Text file busy" on Linux

When several tool calls hit an empty shared-runtime slot at the same time, one guard
hydrates the slot and the others wait. On Linux the kernel refuses to run a file while
another process still holds it open for writing. It reports this as "Text file busy". A
waiting guard could reach the run step in that brief window, fail to start the helper, and
deny the tool call by mistake. This showed up as a flaky Linux CI failure under contention.
macOS and Windows do not enforce this rule, so only Linux saw the denial.

The guard now retries the helper a bounded number of times when the start fails with this
exact condition, then hands off as before. The retry is short and self-clearing: the peer
closes the file the moment its write finishes, so the next attempt starts the helper. A
helper that genuinely cannot run still returns the same status after the retries, so no real
failure is hidden. The runtime binary is still written atomically, so the fix only closes
the read-side race.

Internal design note: hidden J_flow and the oracle-as-advisor pattern

This change adds an internal design note under the lab notes/ directory. The note names a
class of problem: a subproblem where the tool already owns a deterministic check but exposes
it only as a terminal accept-or-reject gate, so a coding agent re-discovers the answer by
trial and error. The note defines the class, a regret metric, and the "oracle-as-advisor"
pattern that turns a checker into a constructive guide.

There is no change to any shipped command, gate, runtime, or generated file. The notes/
directory is not part of the Boatstack distribution. This fragment records the addition to
keep the append-only release-note history complete.

Projection provenance

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