lukasandClaude Sonnet 5
d291312139
CONTEXT.md described Order Item cancellability and Order completion in ways the code didn't actually implement (cancellability only covered the first Preparation Step; completion required pickup, not any terminal state). Corrected the glossary to match intended behavior, added Guest Access Token and Charge as formal terms, and recorded the single-Charge-per-Order design as an ADR. Also closes a real race in cancelOrderItem: a Machine could claim a queued Step between the cancellability check and the delete, letting an already-cooking item get cancelled and refunded. The delete now atomically re-checks status = 'queued'. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
863 B
Single Charge per Order, refunded incrementally per cancelled Item
An Order is charged once, in full, at placement time — before any Order Item exists — rather than opening a separate charge per Order Item. When an Order Item is later cancelled, its share of the total is refunded against that same Charge, so one Charge can be partially refunded multiple times over an Order's life, once per cancelled Item. We chose one Charge per Order because it means a single payment authorization per customer checkout, keeping the payment-provider integration and the customer-facing checkout flow simple; the alternative — a Charge per Order Item — would let items be refunded fully independently of one another, but would mean authorizing the customer's card multiple times per Order and tracking a payment-provider transaction per Item instead of per Order.