Skip to main content

Merge sequencing: land the PAL classifier foundation first, then #950 consumes it

Status: ACCEPTED (Bhargav, 2026-07-09). Sequences the #950/#951 merge per ADR-0012/0013.

ADR-0013 reshapes #950 (its normalize classification dissolves into the PAL classifier). Merging #950 as-is and refactoring after would land tested money-path code and then gut it. Instead we invert the dependency: the canonical classifier is the foundation both refactors consume, so it lands first.

The three-step sequence​

  1. PR-1 — PAL foundation (NEW, small, additive, merges first).

    • PAL core exchanges/core/orderStatus/: getCanonicalStatus, orderToSizeVector, SizeVector, CanonicalStatus (moved from domain/orderStatus/).
    • finalizeCanonicalOrder(order) in exchanges/core, called at the tail of every adapter mapper; stamps CanonicalOrder.canonicalStatus.
    • CanonicalOrder.canonicalStatus (in-memory PAL field) + CanonicalOrder.sizeVoided; Order.sizeVoided DB column (additive, nullable). No orders.status literal migration here — that stays with #950.
    • A read-time serializer field (/orders + WS) exposing the derived canonical status additively alongside the existing status. This gives PR-1 standalone value + proves the classifier on live dev1 data — it is NOT dead scaffolding.
    • Low risk: adds a field + a pure function; breaks no existing reader.

  2. PR-950 (Pran) — rebase onto PR-1 and CONSUME.

    • Delete orderState/normalize.ts classification; router reads canonicalOrder.canonicalStatus.
    • Applier STOREs it as the Order.status literal; order_status_literals cutover migration lands HERE (with the writers that produce the new literals).
    • states.ts keeps vocabulary + evaluators + mapLegacyStatus migration mapping (no longer a derivation site).

  3. PR-951 (ours, reshaped) — rebase after #950.

    • Settlement axis: deriveOrderOutcome → releaseMarketCredit dedupe + admin.ts §3.9 fix + drop 'push'.
    • FE cleanup: delete betStatusBucket / useMyBets 3-bucket / betDisplay re-derivations / betTools inline — consume the served canonical status.
    • Docs consolidation into one record reconciled with order-state-machine-v2.md.

Why not A (merge #950, refactor after) or B (combine)​

  • A churns tested money-path code (normalize lands then is gutted) and forces reconciling two orders.status migrations post-hoc.
  • B tangles two people's ownership into one branch/review.
  • C lands the shared dependency first (additive, low-risk), making #950 a clean consumer.

Hinges on (coordination, not code)​

  • #950's merge is HELD until PR-1 lands and Pran rebases onto it.
  • Pran is bought into the ADR-0013 reshape (his normalize classification dissolves).
  • Draft alignment message to Pran precedes any merge.