Admit exactly one initiator for an operation and reject identity reuse with other contents.
Snapshot catalog products and persist the queued order, the append-only finalization fact, all items, and any confirmed checkout attempt atomically.
An attempt present in checkout makes the order commercial; its absence
keeps the order non-commercial. Returns null without inserting anything
when a selected product is unavailable. Everything written here commits
together or not at all, so a finalized order can never exist without its
finalization fact or its item snapshots.
Reconstruct the current local calendar day's commercial sales.
Returns the exact gross total together with one row per product that sold, grouped by the stable product identity captured at finalization rather than by any display value, so a catalog rename cannot split one product's quantity into two counters. The returned rows are ordered largest quantity first. Both parts come from one read of the same commercial item snapshots, so the total and the breakdown always agree.
Read the confirmed checkout attempt of one commercial order.
The returned facts include the database time the attempt was recorded, so the checkout identity, outcome, provider reference, and time stay associated and durable for as long as the order exists.
Read the append-only finalization fact of one order.
Returns null for an unknown identity rather than a record, so a caller
can tell "no such order" from "finalized without captured metadata". The
record keeps the values the order entered service with even after
current-state columns such as its queue number or note change.
Read an already finalized order so a completed duplicate can be replayed safely.
Price one selection from the current catalog before any checkout call.
Returns the gross integer minor-unit total, or null when any selected
product is unavailable. The application prices before it charges so a
missing product can never produce a charge.
Read the active kitchen queue oldest-queued-first.
The result is ordered by the authoritative queue-entry time rather than by the optional queue number, which is neither unique nor mandatory. Each entry carries its immutable item snapshots, so a later catalog change cannot alter what the queue presents.
Read delivered orders newest first with immutable snapshots and recorded history.
Read the immutable item snapshots for one finalized order.
Read metadata changes in their committed order.
Read one order's fulfillment history oldest transition first.
Append-only: a correction adds a record rather than replacing earlier ones, so this returns every state change the order ever underwent.
Read every still-unresolved checkout attempt, oldest first.
Reading is how the uncertainty stays visible: the list survives a reload and a process restart because it is reconstructed from durable rows rather than from page state. It reports attempts only, never a payment verdict, and deliberately exposes no way to resolve one — reconciliation semantics do not exist yet, so nothing here may imply that an operator can settle them here.
Price one selection into its per-line neutral breakdown before any checkout call.
Returns one PricedOrderLine per selected product in the selection's
own order, or null when any selected product is unavailable — the same
availability rule as OrderRepository.grossTotalMinor, read from the
same catalog, so the breakdown and the gross total always describe the same
priced selection. A provider adapter needs the per-line VAT that a bare
total cannot carry; the application resolves it here from neutral catalog
facts and never from a provider field.
Record a checkout attempt whose provider result was never confirmed.
This is the durable half of "do not silently fail an unknown outcome": the attempt is kept as its own fact rather than discarded, because the application cannot claim it failed and therefore must not let it vanish.
It creates no order, no items, and no queue entry, which is what keeps an
indeterminate attempt out of confirmed sales and out of the kitchen. The
unique application-owned operationId means a repeat of the same operation
cannot add a second row, so there is no durable path from one unknown
attempt to a second charge.
Apply one declared fulfillment transition and append its history fact.
The state change is conditional on the order still holding transition.from: the update
and the history insert commit in one transaction, so an order that has already moved —
because of a racing request, a repeated tap, or any other caller — is reported as
notInExpectedState with nothing written. Two concurrent requests for the same
transition therefore cannot both succeed, and history can never record a transition the
committed state does not reflect.
Atomically update active-order metadata and append old/new facts for changed fields.
Persistence boundary for atomic order finalization and finalized reads.