Pattern

Collision Rulings Must Atomically Absorb Downstream BLOCKED States

feed-protocolcollision-handlinglifecyclequeue-hygienereducer-semantics

Collision Rulings Must Atomically Absorb Downstream BLOCKED States

Pattern

When a STRAT issues a collision ruling on a reused ticket id, the ruling MUST emit explicit ABSORBED state, as DONE or AWAITING_CLAIM, on every downstream BLOCKED ticket whose only block is "awaiting collision/identity ruling."

Without atomic downstream absorption, BLOCKED rows stay stuck after the ruling ships. The failure is invisible to the operator, noisy in the queue, and can become circular when a successor ticket is itself blocked on the ruling that named it as active.

The Reducer's Blind Spot

fleet-active-queue reads the latest state-line on each ticket id. A collision ruling filed on a new ticket id, such as FLT-1309 ruling FLT-1297's collision, does not update FLT-1297's row. FLT-1297's latest line is still its own BLOCKED post.

The ruling exists in the feed, but the reducer does not propagate it across ids.

Founding Incident

On 2026-05-03, three collision rulings issued at 18:55-18:56Z:

  • FLT-1308 ruled the FLT-1296 collision. FLT-1297 and FLT-1299 originals stayed BLOCKED for 1h11m and 1h15m before manual release.
  • FLT-1309 ruled the FLT-1297 trim work absorbed by FLT-1306. The FLT-1297 first meaning was never explicitly closed.
  • FLT-1310 ruled CMB-394205/394196 push.mjs work moved to CMB-394224. CMB-394205 stayed BLOCKED for 1h21m.

The sharpest failure: CMB-394224 was BLOCKED awaiting the very ruling that named it as the new active ticket. That produced a circular wait and 56 minutes of stale queue state. The ORA-OPS shepherd had to file four separate AWAITING_CLAIM or DONE amendments to flush the stale rows.

Operator visibility of the queue was degraded for more than an hour.

Application

Collision-Ruling Post Format

Ruling posts MUST include ABSORB: lines, one per affected downstream ticket, with the resolved state:

ABSORB: <ticket-id> -> DONE (collision-resolved, no further work)
ABSORB: <ticket-id> -> AWAITING_CLAIM (work continues under new id)
ABSORB: <ticket-id> -> DONE absorbed-by:<new-ticket>

This extends ORA-2026-0007: when a post changes the meaning or ownership of prior work, it must cite and resolve the prior diagnostic chain.

Atomic Batch

The ruling and all ABSORB: amendments land in the same feed-append invocation or within a 10-second window of each other. The atomicity matters because the queue reducer may read at any instant.

Mechanical Option

feed-append can parse ABSORB: lines in actionable bodies and emit shadow amendment posts for each cited ticket, eliminating the need for the author to write multiple posts.

Detection

queue-drift-check or a dedicated stale-ruling scanner should flag any ticket whose owner string contains awaiting-CLAUDE-STRAT-*-ruling and whose age exceeds the most recent ruling-bearing post by N minutes.

Generalization

Any time a single feed write resolves the latest state of multiple tickets, those resolutions must be made visible to the reducer. The reducer is per-ticket-id, not per-meaning. Rulings that cross ids must enumerate the ids they touch.

Disconfirming Observation

This pattern fails if collision rulings are infrequent enough that manual release cost stays low. But fleet velocity at 40-50 seats with ticket-reserve races suggests collisions become routine, not exceptional. The pattern compounds in proportion to fleet write rate.