Skip to content

Sync Boatstack from Intelligence Flow Labs @ df798dfd69a0 - #92

Merged
operator-stack-publisher[bot] merged 1 commit into
mainfrom
sync/intelligence-flow-df798dfd69a0
Jul 24, 2026
Merged

Sync Boatstack from Intelligence Flow Labs @ df798dfd69a0#92
operator-stack-publisher[bot] merged 1 commit into
mainfrom
sync/intelligence-flow-df798dfd69a0

Conversation

@operator-stack-publisher

Copy link
Copy Markdown
Contributor

What this sync releases

Publishing a delivery slice no longer strands it — a published-open PR stays correctable in place

Multi-slice managed deliveries build sequentially, so publishing one slice's PR intentionally advances the delivery's BUILD pointer to the next slice. But that same pointer also decided which slices may still be corrected, and it advanced the instant gh pr create/edit returned — before the published slice's CI, review, or merge was ever observed. Once it moved, the just-published slice became unreachable: record-delivery-gate --slice <id> refused it as "not active", pr-context --slice <id> only relabelled the active slice instead of redirecting, and a corrective push landed as relation=unrelated. A slice whose PR was still open and simply needed its CI fixed had no bounded way back — a supervisory deadlock. The only sanctioned recovery, a corrective child delivery, is right for a merged or closed PR but wrong for one still open.

The fix separates which slice builds next (rightly advances) from which slices may still be corrected (must not be revoked before the postcondition is terminal). The addressable set is now {active slice} ∪ {published slices whose PR is not terminal}. Publication still advances the BUILD pointer, but a PUBLISHED slice remains re-gateable and re-publishable in place until its PR is terminal:

  • record-delivery-gate --slice <id> and pr-context --slice <id> now redirect the gate/ship lookup to the named active-or-published-open slice instead of rejecting it. Resolution is network-free — addressability is read from persisted delivery state, never a live gh call.
  • Re-publishing a published-open slice is an idempotent --action update of its still-open PR: it refreshes the recorded PR URL without advancing the BUILD pointer a second time. Only the first REVIEW_PASSED → PUBLISHED transition advances.
  • Each slice carries a pr_state marker. It is OPEN on first publication and is advanced to a terminal value (MERGED/CLOSED) only when the recovery/next resolver's existing gh pr view observation confirms it — a bounded, best-effort cache of an observed external fact. A terminal slice refuses in-place correction and routes to the corrective-child path, the bounded forward actuator. A published delivery still cannot be reset.
  • The per-slice changelog baseline now anchors to the slice actually being gated or shipped, not the BUILD pointer, so an in-place re-gate of an earlier published-open slice compares against its predecessor.

This is a standing instance of the recovery principle behind repair-state and the mutation boundary: a supervisor that removes an actuator must still expose a bounded actuator that reaches every valid next state — including reversing its own last move. A new nonblocking-supervisory-control conformance suite encodes that invariant as named-property tests so the failure class — advancing a durable supervisory pointer past an unobserved postcondition — cannot silently reappear, and the failure-move catalog records it as Premature supervisory pointer advance.

Projection provenance

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

@operator-stack-publisher
operator-stack-publisher Bot merged commit 7e66427 into main Jul 24, 2026
4 checks passed
@operator-stack-publisher
operator-stack-publisher Bot deleted the sync/intelligence-flow-df798dfd69a0 branch July 24, 2026 15:34
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

0 participants