CSD events

Every ledger write carries a composite unique index on (source_system, idempotency_key), and every reverse-side movement additionally claims a (anchor_key, leg) pair under its own partial unique index. A replay re-runs the classifier with the current ruleset and attempts the same inserts; the duplicates are rejected by the database, not by an application-level check-then-act.

Replay is refused for any topic whose migration_state is not i3_owns or legacy_retired, because a replay would post into a ledger a sibling still owns. The refusal is a 409 with the state in the body. Today that is all nine topics.

Bulk replay above 10 events writes an approval row naming the approver before anything runs. Today's 4 replays produced 0 new ledger rows and 0 new granted claims, which is acceptance test AC-08.12: replaying the last 24 hours must change nothing.

i3 keeps serving from its own state. A return_cases row in authorised or in_transit simply stops advancing and appears on the aging board, which is the correct behaviour: the parcels are still physically moving whether or not CSD is reachable.

No backfill is possible. CSD has no outbox. Its inventory client is fire-and-forget by design: fireInvWebhook catches every failure, writes it to a module-scoped invWebhookLastResult object, logs it and returns null. That object does not survive a process restart, so an event lost during an i3 outage is lost with no record on either side.

This page states that rather than promising otherwise. reverse_bridge_state.sibling_outbox_supported is false and backfill_window_days is 0. The v2 mockup's banner said "queued cases will backfill on resume", which is a promise the sibling cannot keep.

CSD builds two keys today and both are case-grained: Neither carries a line_id and neither carries a sequence. Three consequences, all live today:

1. A case covering three SKUs reserves one, because the caller passes skus[0] with quantity: 1.
2. A case that enters approval, is cancelled, and re-enters fires the identical key, so the second hold is deduped away and the stock is never re-held.
3. The location is hardcoded to 'HQ_319' regardless of where the stock actually is.

i3's receiver rejects those shapes with a 400 naming the missing fields, which is what the six blocked rows in the stream are. The correct key is csd:res:<case_id>:<line_id>:<place|release>:<seq>.

CSD already fixed this shape once, for money. Before 14 July 2026 the exchange path credited only the first selected item, so a return of earrings at AED 275 plus a necklace at AED 420 credited 275 and the customer was overcharged by 420. The fix routed refund and exchange through one helper, src/lib/return-credit.ts, whose docstring states the principle: "rule-based, not order-specific: works for any number of returned items and any bundle depth".

The identical shape is unfixed on the stock side. The reservation caller still takes skus[0]. i3 refuses to accept a single-SKU shape for a multi-SKU case at all, so the bug cannot be reproduced against the ledger even if it is reintroduced against the money.