Proves the complete live chain: Customer Rork → Base44 checkout/payment → Merchant Rork → Dispatch → Driver Rork → Customer tracking → Delivery. Every executable gate runs a real production path — no simulated or mocked tests.
Test Run: run_1792436372608_523lrz
Runs all 15 executable gates in sequence · stops on first failure · preserves all evidence
Overall
0 / 23
AWAITING GATES
Blocking Gates
NoneAssertion counts across 0 executed gates — Client API asserts ≠ UI render proof · Rork UI column is 0 until render instrumentation is active
0
of 319 total
0/23 gates proven — select a test fixture to begin
Menu Connectivity
BLOCKEDCustomer ↔ Merchant
BLOCKEDMerchant ↔ Driver
BLOCKEDDriver ↔ Customer
BLOCKEDLive Order Lifecycle Pipeline
Run gates to light up the pipeline
Customer Cart
Quote
Stripe Paid
Merchant Received
Accepted
Preparing
Ready
Driver Offer
Driver Assigned
Pickup
En Route
Delivered
Domain A — Menu & Checkout Connectivity — Gates 1–4
Proves that Base44 and the fixture agree on all identity dimensions — merchant, store, menu, scope_key, and migration record — before any mutation is permitted.
Proves the merchant's store-owned menu travels correctly: Physical DB → getMerchantMenu API → getRorkMenu. Compares item counts, content hashes, and produces item-level diffs (missing IDs, price, availability, modifier mismatches).
Creates CONNECTIVITY_ITEM_<timestamp>, validates it propagates through physical DB → getMerchantMenu → getRorkMenu, confirms Store B is isolated, then removes it.
Race condition proof: customer adds available item → merchant disables item → customer submits stale cart → backend rejects it → no order or PaymentIntent created. Also cycles the item back to available and confirms all layers (DB, getRorkMenu, checkout) agree.
Domain B — Customer Order Creation & Payment — Gates 5
Creates a suite-owned order fixture: quote pricing → DB construction → field integrity → isolation. Stripe/webhook path NOT proven here — this is a controlled fixture, not a customer checkout proof. This order anchors all subsequent lifecycle gates.
Domain C — Merchant Order Intake & Handling — Gates 6A, 6B, 7–8
Proves the controlled order reaches the merchant via the real DB filter and backend API paths. Tests merchant isolation and foreign-store isolation. Prerequisite for Gate 6B (Merchant Order Rendering & Earnings).
Canonical merchant financial proof gate. Reconciles item names, quantities, modifier groups, selected modifiers, modifier quantities, notes/special instructions, merchant unit prices, modifier line totals, and merchandise subtotal across four layers: Physical Order Snapshot → Merchant Backend API → Merchant Rork State → UI (instrumentation stub). Hard-fails if customer-facing charges (markup, service fee, delivery fee, Stripe fee, taxes, platform revenue, loyalty discount, promo discount, or customer total) leak into any merchant-facing layer. The merchant merchandise subtotal established by this gate is immutable for reconciliation purposes. Subsequent gates (Out-of-Stock, Financial Adjustment, Cancellation, Final Integrity) must reconcile against this Subsequent gates must reconcile their resulting merchant financial state against the baseline established by Gate 6B rather than recalculating merchant earnings independently. This gate establishes the merchant financial baseline for Gates 7, 10, 11, and 22.
Calls the real acceptOrder backend function (same path as Rork merchant). Verifies DB state transition, field population, idempotency, and foreign merchant rejection.
Drives the order through merchant_accepted → preparing → ready_for_pickup via updateOrderStatus. Tests idempotency of duplicate taps and timestamp monotonicity.
Domain D — Merchant/Customer Communication & Adjustments — Gates 9–11
Calls the real orderChat function in both directions on the controlled order. Verifies physical DB presence, sender roles, conversation isolation, and foreign-order rejection. 📵 Phone communication: NOT TESTED.
Merchant marks an item unavailable on the controlled order. Proves the customer notification pathway, replacement preference persistence, and audit trail integrity.
Processes a financial adjustment (item removal/refund) on the controlled order. Verifies total delta, idempotency on duplicate key, and audit trail entry.
Domain E — Dispatch & Driver Connectivity — Gates 12–14
Triggers the real autoDispatchOnAccept path. Verifies order transitions to driver-searching state, DispatchTask records are created, and duplicate triggers are idempotent.
Calls driverAssignmentAPI to atomically assign a driver. Verifies DB state, timestamp population, idempotency, and foreign rejection. ⚠ No fixture driver — add a driver to the fixture for full proof.
Drives driver_assigned → arrived_at_store → picked_up. Reads back from physical DB and getOrderTracking (customer-facing) after each step.
Domain F — Driver/Customer Communication — Gates 15
Tests the driver conversation thread (separate from merchant chat). Verifies both directions, physical DB, conversation isolation, and foreign driver rejection. 📵 Phone: NOT TESTED.
Domain G — Delivery Completion — Gates 16
Drives picked_up → en_route → delivered via completeDelivery. Reads back from physical DB and getOrderTracking after each step. Verifies terminal immutability.
Domain H — Cancellation Branches — Gates 17–18
Cancels the controlled order as merchant. Verifies status transition, timestamp population, dispatch cleanup, foreign merchant rejection, and idempotent re-cancellation.
Customer cancels their order. Backend enforces policy by state — the client must not decide eligibility. Tests foreign customer rejection, policy enforcement at current boundary, and idempotent re-cancellation.
Domain I — Cross-Client State Synchronization — Gates 19
Compares Physical DB · Merchant Backend API · Customer Tracking · getOrderStatus — all must agree. Verifies timestamp monotonicity and terminal state immutability.
Domain J — Reliability & Security — Gates 20–22
Validates production resilience: double accept, double dispatch, double pickup, duplicate chat, stale CAS conflict detection. Every duplicate must either return the original result or a typed idempotent response — never duplicate records.
Uses real backend endpoints to prove every cross-entity, cross-role, and tampered-payload attack is rejected. Verifies no DB mutation occurs from rejected calls.
Proves the suite leaves the environment clean: no menu artifacts, no orphan dispatch tasks, no injected chat, Store B unchanged, controlled order terminal, migration records intact.