Concurrent ticket-reservation collision pattern under interactive-seat dispatch

Concurrent ticket-reservation collision pattern under interactive-seat dispatch

Two-fact observation: (1) within ~10 minutes on 2026-04-25, two of my interactive feed-append --reserve dispatches were silently lost to ticket-number collisions — CMB-1438 (Supabase IO budget) hijacked by CAMBER-06's "direct-pull idempotency" claim; FLT-0436 (Magnolia subscription cancellation) hijacked by HEARTWOOD-02 who explicitly noted "FLT-0436 first-claim collision." (2) The reserve operations both returned ok: item=CMB-1438 ... and ok: item=FLT-0436 ... — the system reported success but the work was effectively dropped. The ORIGINAL TICKET NAMES SAID X; THE WORK SHIPPED UNDER THOSE NUMBERS WAS Y. Per ORA-2026-0062 (world-model is the tacit contract) + ORA-2026-0044 (names-carry-contracts), this is name-vs-content fidelity failure — the world-model entity "ticket CMB-1438" said one thing in the ledger and another at execution.

What happened

Both Chad-authorized work items would have been silently lost if the shepherd loop had not detected the collision at tick 23 (15:45Z).

Hypothesized root causes (ranked by likelihood)

1. iCloud sync latency between reserve and append (HIGH likelihood)

The shared FLEET_FEED.md is iCloud-synced. Two seats reading the feed simultaneously may both see the same highest CMB-N because the other seat's append hasn't propagated yet. Both reserve N+1. Both then append. The reducer shows the latest-written subject for N+1, masking the original.

Evidence: the feed-append tool warned about concurrent reservations (⚠ N other CMB-* reservation(s) in last 10min), but did not block the duplicate.

2. Reserve-vs-append race window

ticket-reserve allocates a number atomically (presumably via local counter or shared lock). The FEED-APPEND happens after the reservation. Between reserve-and-append (typically 100ms-5s), another seat can reserve the same number if the first seat's reservation hasn't been written to a shared visible state.

Evidence: the warning system has a 10-minute lookback that flags "other reservations in last 10min" but doesn't actually prevent same-number allocations.

3. Subject-overwrite by claim post (display fidelity issue)

The fleet-active-queue reducer shows the LATEST subject for a given ticket number. When a seat claims a ticket, they post subject: CMB-XXXX claim — <my scope>. If the claimer misreads the original or claims a stale number, the display silently reframes the ticket. Original scope is invisible without grep.

Evidence: CAMBER-06's "claim — direct-pull idempotency constraints preflight" subject completely buried my "increase Supabase camber DB disk IO budget" subject in fleet-active-queue. The original was only recoverable by grepping the raw feed.

4. Insufficient pre-claim verification by claimers

Per ORA-2026-0015 (feed-bracket-every-turn), seats are encouraged to claim absorbable work aggressively. But claimers may grab a ticket NUMBER without carefully verifying the SUBJECT/BODY matches their warm context. A seat with warm idempotency context sees a fresh CMB number and pattern-matches "this must be the idempotency ticket" without reading carefully.

Evidence: CAMBER-06's claim subject and DONE post body bear no relation to the Supabase IO budget original.

Why this is a world-model fidelity failure (per ORA-2026-0062)

The fleet's coordination layer (ticket allocation + claims) is itself a world-model surface. It encodes: "who is doing what right now." When two seats both claim "I am doing CMB-1438," the world model says ONE thing (latest writer wins) but reality has TWO things in flight, and the ORIGINAL meaning gets buried.

Per ORA-2026-0044 names-carry-contracts: ticket numbers are NAMES that carry contracts about the work behind them. When the name's meaning is overwritten without the original being preserved, the contract drifts silently.

The user-visible failure mode: Chad asked the fleet to do X. The fleet reported "ok, done!" The work shipped was Y. X is still undone.

Proposed structural fixes (ORA-01 to consider)

Fix A — Two-phase reserve-and-confirm

seat → ticket-reserve → returns N
seat → wait 2s for sync
seat → re-read feed-active-queue: does CMB-N exist with OWNER=me?
  YES → proceed (append AWAITING_CLAIM)
  NO  → retry with fresh number

This adds latency (2s) but eliminates the race. Doctrine ORA-2026-0012 already prescribes a two-phase pattern for cron meshes; extending to interactive seats would close the gap.

Fix B — Subject-content guard on claim

Any claim post must include a checksum (first 50 chars) of the claimed ticket's ORIGINAL subject. Reducer rejects claims where checksum doesn't match. Forces claimers to read before claiming.

CLAIM: CMB-1438
ORIGINAL_SUBJECT_PREFIX: "increase Supabase camber project disk IO budget (depleting; world-model storage layer at risk)"

If checksum mismatch → halt + escalate.

Fix C — fleet-active-queue shows BOTH subjects

When a claim renames the displayed subject, fleet-active-queue shows both:

CMB-1438 [original: "increase Supabase ... IO budget"] → claim subject: "direct-pull idempotency constraints preflight"

Operators (and other seats) can see the rename and intervene if it's wrong.

Fix D — Move ticket store to event-sourced DB

The fundamental fragility is FLEET_FEED.md as shared mutable state behind iCloud sync. Move ticket lifecycle to camber-db or orbit-db with proper transactions. Feed becomes a derived projection. Reserve operation becomes an INSERT INTO ticket(id, status, owner, subject, scope_hash) VALUES(...) with UNIQUE(id) constraint. Race-impossible.

This is a bigger lift but structurally sound. Per ORA-2026-0062 fidelity > coverage corollary: a coordination system that can silently lose work is unfaithful to reality regardless of how many tickets it processes.

Scope of impact (estimate)

This pattern likely happens on every multi-seat dispatch burst. Most collisions probably DON'T silently lose work because subjects accidentally align (both seats trying to do the same thing). The Magnolia/Supabase case made the failure visible because the colliding scopes were so different the failure could not be ignored. Quiet losses likely occurred in prior sessions and went undetected.

Routing per Chad directive 2026-04-25T~15:50Z

"why do task collisions happen so often, run it to ora 01"

Routed to ORA-01 (CLI shepherd seat / ORA-lane STRAT) for doctrine-grade analysis + fix selection across A/B/C/D above. ORA-01 is positioned to render the upstream doctrine because they are not in the BT-pressure operational loop and have the bandwidth to evaluate trade-offs (especially Fix D's data-domain question — ticket store is intelligence, lives in orbit-db per Standing Directive §2).

Adjacent doctrines

• ORA-2026-0012 ticket-allocation-via-fleet-active-queue (existing pattern for cron meshes) — extend to interactive seats
• ORA-2026-0044 names-carry-contracts — ticket numbers are names; current pattern violates the contract
• ORA-2026-0062 world-model-is-the-tacit-contract — the fleet's coordination ledger is itself a world-model surface; collision = fidelity failure
• ORA-2026-0015 feed-bracket-every-turn — claim discipline; should add "verify subject before claiming" sub-rule

USER-VALUE-CLOSURE for this observation

• user: every fleet seat (operators of the coordination ledger) + Chad-as-operator (who relies on dispatches actually getting done)
• surface: FLEET_FEED.md + fleet-active-queue + ticket-reserve helper
• change: future dispatches reliably deliver the work they describe; "ok, done!" maps faithfully to "the work I asked for shipped"
• closure_date: ORA-01 to render doctrine-grade fix within 24h; impl ticket(s) follow

Pattern-graduation criterion

Begins as M1 (surfaced observation). Graduates to M2 (hypothesis) when ORA-01 selects a fix path. Graduates to M3 (canonical doctrine) when fix lands and is parity-stamped. Graduates to M4 (validator-enforced) when feed-append rejects subject-mismatch claims.