40-gate suite (C1–C39 + SC1) proving the complete customer journey: discovery → checkout → Stripe payment → live GPS chain (C38) → order tracking (C24–C30) → order history (C31–C36) → notifications (C37) → SC1 cross-store commerce → final integrity (C39). Gate C22 produces the certified order_id for the Lifecycle Suite. C38 emits evidence_digest; SC1 emits store_commerce_digest — both required by C39.
order_id for Lifecycle Suite. C38 runs first in Domain H, emits evidence_digest. SC1 runs before C39, emits store_commerce_digest proving backend matrix + Rork runtime — C39 is blocked until both digests are present. Notifications are C37 / C37b / C37c.40 gates · 10 domains · Proves the full customer journey from discovery through tracking, history, and notifications
0
Passed
0
Failed
42
Pending
Domain A — Location & Home Discovery
0/4 passed
Domain B — Merchant Discovery
0/3 passed
Domain C — Items, Modifiers & Cart
0/3 passed
Domain D — Group Ordering
0/3 passed
Domain E — Fulfillment & Recipient
0/3 passed
Domain F — Replacement Preferences
0/1 passed
Domain G — Pricing, Discounts & Payment
0/6 passed
Domain H — Customer Order Tracking (C38 GPS first, then C24–C30)
0/8 passed
Domain I — Customer Order History
0/6 passed
Domain J — Notifications (C37, C37b, C37c)
0/3 passed
Cross-Store Commerce — SC1 (requires C38; produces store_commerce_digest for C39)
0/1 passed
Final Customer Integrity — C39 (requires C38 evidence_digest + SC1 store_commerce_digest)
0/1 passed
Certification chain: Discovery → Checkout → C22 Stripe Payment → Order Lifecycle Suite (returns milestone evidence) → Tracking C24–C30 → History C31–C36 → Final Integrity C37. Gate C22 produces the order_id consumed by Order Lifecycle Gate 6A.
C1–C39 + SC1. C38 (GPS chain) runs first in Domain H; SC1 (Cross-Store Commerce) runs before C39 and produces store_commerce_digest; C39 (Final Integrity) requires both C38 evidence_digest and SC1 store_commerce_digest. Notifications are C37/C37b/C37c. NOT_APPLICABLE allowed for Group Ordering, Gift, and Replacement only.
Core Checkout Certification — C1–C39
All gates must pass or be NOT_APPLICABLE. C39 requires C38 evidence_digest (non-null). NOT_APPLICABLE only valid for: Group Ordering (C11–C13, C23), Gift (C14), Replacement (C17), Loyalty (C21).
⚠ Gate C22 (Stripe Payment) must pass to certify.
Full Checkout Certification — C1–C39
Every gate must actively PASS — no NOT_APPLICABLE. Requires Group Ordering, Gift, Replacement, and Loyalty. C38 evidence_digest must be non-null.
🛰 Detected Device Location (read-only)
Click "Use Current Device Location" to detect GPS and reverse-geocode your area.
Administrative selector — not filtered by customer location
Administrative selector — may be out of range for negative C5 test
Target Customer Under Test — Rork account
Select the exact customer account currently logged into the Rork customer app. This customer will be authorized to retrieve the active certification run and submit runtime render evidence. This selector is administrative, like Target Merchant and Target Store. It is not affected by discovery location.
No Rork customer accounts found. Create one via the Rork phone-OTP signup flow first.
⚠ Select and apply the Rork customer currently logged into CustomerHome.
⚠ SIMULATED — coordinates for test customer, not detected from device. Apply Fixture to commit.
⚠ SIMULATED — negative sign required for western longitude (e.g. -76.1477 for Syracuse NY).
Disabled. C1 will use fixture coordinates as the discovery source (marked SIMULATED above). Enable to simulate a customer overriding their discovery location.
Configure the fixture above before running gates.
Select a merchant and store to enable gate execution.
Run ID
crun_1792436410717_tmuzi9
Test Customer
—
Select customer in fixture
Environment
⚠ not selected
Expires
—
Rork
Waiting for Rork
Latest Event
—
No fixture applied — configure and Apply Fixture first.
Expired Banner Cleanup (Part E)
Includes three-layer model, regression lifecycle, and customer_menu_ready semantics. No writes to discovery fields.
customer_discovery_enabled is the persistent admin-approval flag and is NEVER automatically mutated by readiness regression. Effective discoverability is always computed at request time: L1(Merchant.status=active) AND L2(discovery_enabled=true) AND runtime(menu_ready=true AND coords AND radius). If readiness regresses, the store hides immediately without rewriting this flag; when repaired it returns automatically.Proves the platform-wide normalized item-identity contract. item_id is the canonical internal identity; sku is an external/business identifier that may legitimately differ.
Identity contract v2 rules:
item_id ≠ sku → valid, never a conflictitem_id ≠ menu_item_id|id → ITEM_IDENTITY_CONFLICT (fail closed)item_id from skuskuKey invariant: pricing availability ≠ permission to place an alcohol order
Customers must see subtotal, delivery, service fee, tax, and tip before completing age/compliance acknowledgement. Only Place Order is blocked — not pricing itself. This diagnostic proves whether that invariant holds.
v4: Items resolved via Menu.sections[].items[] → item_id. No price submitted to API — server resolves authoritative customer price (base × markup) from catalog. Submitting Menu.price (base only) causes PRICE_MISMATCH on R; omitting it lets the server validate identity alone. R must pass (success=true, subtotal>0, pricing_token) before A1/A2 execute. Read-only — no production mutations.
Fixture R — Restaurant control
Must be a non-alcohol food store with an authoritative menu.
Fixture A — Alcohol store (under test)
Should be an alcohol/liquor store where pricing currently fails.
Select both stores above.
8 live negative probes — proves no fallback has crept back in
What this proves
Each probe fires a live request engineered to trigger the dangerous pre-Phase-1 fallback path. A passing result confirms the backend rejected the probe with the exact Phase-1 error code — not a silent substitution. Run this after every backend deploy that touches createOrder, getCheckoutPricing, getRorkMenu, or merchantMenuBrowse.
Click Run Regression Gate to execute all 8 probes.
No data is mutated. All probes fire rejected requests and verify the rejection code.
Read-only · Rork cart store_id → pricing request → Base44 resolved
Load evidence to evaluate chain. Requires an active suite run with C10 CLIENT_STATE and REQUEST_SENT phases submitted by Rork.
Rules enforced by Base44 backend functions. Static proofs from reading getRorkMenu, getCheckoutPricing, and createOrder — not runtime assertions.
If store_id is absent, the runtime menu resolver falls back to shared legacy menu and returns no store_id in response. Rork cannot derive store identity from the menu response — it must supply its own.
getRorkMenu L428: effective_store_id = selected_store_id || store_id || null
If store.merchant_id !== merchant_id in the request, getRorkMenu returns HTTP 403. Cross-merchant store access is blocked at the menu layer before any item is visible.
getRorkMenu L467–469: if (store && store.merchant_id !== merchant_id) return 403
Without store_id or selected_store_id, the resolver returns STORE_ID_REQUIRED mapped to unavailable_reason=MERCHANT_LINK_MISSING. Base44 does NOT silently infer a store from merchant_id alone when store_id is absent.
getCheckoutPricing L283: errorCode = STORE_ID_REQUIRED when no store_id, no merchant_id, no items merchant_id
Recovery only succeeds if merchant_id is present AND the merchant has stores. The recovery store must belong to the exact same merchant — a sibling store from a different merchant is never substituted.
getCheckoutPricing L114–155: fallbackStores = allStores.filter(s => s.merchant_id === candidateMid)
buildAuthoritativePriceMaps uses resolveStoreCommerceContext scoped to (merchant_id, store_id). Items are indexed by item_id/sku from that store's menu only — never from a sibling store, merchant-wide fallback, or name/position match.
resolveAuthoritativeItemPrice L110–113: resolveStoreCommerceContext(admin, { merchant_id, store_id })
The menu is resolved from the store_id + merchant_id pair. menu_id is an output of context resolution, not an input. Supplying menu_id without store_id does not route the request to the correct store.
resolveStoreCommerceContext: menu resolved after store context established; menu_id never read from request
If store_id is missing, createOrder auto-resolves by merchant_id. If store.merchant_id ≠ request merchant_id, the store is not used. Sibling stores from different merchants are never injected.
createOrder L928–935: resolvedStoreId = store_id || localStoreId; merchant_id rescue only from store.merchant_id match
createCheckoutQuote L606–616: if !resolvedStoreId && merchantId, it does a targeted Store.filter({ merchant_id }) and takes the primary store. This fallback is for first-quote cache miss only — it does not override an explicit store_id sent by Rork. The certified Rork path must never exercise this branch; if C10 sees REQUEST_SENT.store_id = null, that fails client certification immediately.
createCheckoutQuote L606–616: auto-resolve only when storeId is null
Before fix: Rork silently backfilled store_id from selectedStoreDetails / localStore / AsyncStorage — whichever store the customer last browsed — even when it did not originate the cart items. Base44 received a mismatched store_id, resolved a different runtime menu, and returned ITEM_IDENTITY_MISMATCH or STORE_NOT_FOUND. Rork showed "We couldn't calculate your order total."
After fix: resolvedStoreId is exclusively checkoutContextRef.current.cart_store_id. A cart with no store_id fails immediately with STORE_ID_REQUIRED_no_store_on_locked_cart. Item price fields are stripped from the wire payload.
Invariant: cart.storeId === REQUEST_SENT.store_id === BACKEND_RESULT.store_id
Scope: Read-only. No checkout APIs called, no data mutated, no production behavior changed. Evidence is fetched via an admin-authenticated server action (getCheckoutGateEvidence). Full runtime verification requires Rork to submit evidence from a live checkout attempt.
Two independent subtests. A certifies real device GPS and reverse-geocoding. B certifies deterministic fixture/override discovery for repeatable testing (C5 uses these simulated coords). Both must pass for C1 to be proven.
Apply a fixture first to enable Subtest B.
Proves: (DB) active greetings exist + global anonymous fallback present, (Resolver) named customer resolves greeting with zero unresolved tokens, (Resolver) anonymous falls back to global, (API) no raw template vars, (Rork) BLOCKED until Rork emits HomeGreetingRendered via recordCustomerHomeRenderEvidence with current run_id=crun_1792436410717_tmuzi9, source=base44, unresolved_tokens=0. run_id is mandatory — events from other runs are rejected.
⚠ Prior C3 result for run crun_1785284793934_ofqwdo
INVALIDATED_WRONG_ENTITY_CONTRACT — run was MERCHANT_CANONICAL; cannot prove which Store was rendered
AuditEvent 6a694e20af9dbba1d78a2df0 and snapshot snap_1785286130418_4m3z5u1e are preserved for historical audit only.
C5–C10 must be re-run on a new v2 run because they depend on the store selected through discovery.
contract_version: store_discovery_v2. Proves: DB (Stores with own coords), API (one result per Store, two eligible Stores under one Merchant = two results, no phantom stores), Rork runtime (HomeStoresRendered with store_ids ⊆ snapshot.store_ids, every Store maps to correct Merchant — HomeMerchantsRendered cannot satisfy v2 C3), UI (API confirmed).
4-layer proof: DB (categories + banners, no expired in active set, field=active), API (chip/banner response, no phantoms, no expired), Rork runtime (HomeCategoriesRendered + HomeBannersRendered events with run_id=crun_1792436410717_tmuzi9 — run_id is mandatory, contract-shape alone is NOT proof), UI (API confirmed).
Two-layer proof: Layer 1 (REFERENCE_ORACLE — DB haversine, informational only) + Layer 2 (PRODUCTION DISCOVERY — getHomeMerchants and getStoresForAddress, same path as Rork customer app).
C5 requires both layers. Oracle alone is insufficient. If store.latitude/longitude are null, C5 will remain NOT PROVEN until coordinates are repaired.
Negative test uses Syracuse NY (lat=43.0515 lng=-76.1477), ~65mi from Rochester-area stores. The in-range fixture coordinates must be within the store's service radius (Penfield: lat=43.1366 lng=-77.4907 ≈ 2.4mi).
4 layers: DB CONFIRMED (identity, image, rating, vertical, coords) · API CONFIRMED (all 8 render fields) · RORK STATE CONFIRMED (name + is_open agreement) · UI CONFIRMED (render event requires instrumentation). A card is NOT PROVEN unless the render event certifies: store_id, store_name, is_open, distance_miles, eta_minutes, delivery_fee, rating, vertical, frontend_build, rendered_at.
Independent 4-layer proof (does NOT use Gate 2 evidence): DB CONFIRMED (sections, items, stable item_ids, prices, migration_state) · API CONFIRMED (section/item count parity, markup-aware pricing audit) · RORK STATE CONFIRMED (same menu, resolver_source consistent with migration_state) · UI CONFIRMED (API layer confirmed). Authoritative stores serve store_specific menu. Shadow stores correctly serve shared_legacy until promoted — resolver_source=shared_legacy is expected and not a failure for shadow stores.
4-layer proof for 5 sampled items: DB CONFIRMED (item_id, name, price, availability, alcohol flags), API CONFIRMED (strict item_id match, markup-aware customer price, all items present, availability consistent), RORK STATE CONFIRMED (top-level items[], API-price parity), UI CONFIRMED (API layer confirmed). Cart baseline persisted only after all 5 items proven — consumed by C10, C18, C19, C20, C22, and C24.
4-layer proof: DB CONFIRMED (groups, required constraints, no dup option IDs, non-zero prices), API CONFIRMED (modifier_group_ids per item, stable IDs across two requests), RORK STATE CONFIRMED (modifier count matches API), UI CONFIRMED (API layer confirmed). Updates the cart baseline from C8 to include a sample modifier selection.
Requires a C8_PROVEN baseline. Proves server-authoritative pricing, PRICE_MISMATCH for tampered prices, qty mutations, signed tokens. E2E requires Rork client evidence injection.
Proves host creates group order, group order ID/token generated, share link opens correct store/cart, invitation cannot expose unrelated customer data, duplicate join is idempotent, expired invitation rejected, removed participant loses access.
NOT YET IMPLEMENTED
Gate scaffold — implementation pending
Proves participant items are attributed correctly, host sees aggregate cart, each participant sees permitted data, concurrent edits reconcile, participant cannot edit another's items, and final group cart freezes before payment.
NOT YET IMPLEMENTED
Gate scaffold — implementation pending
⚠ REQUIRES FORMALIZED ALLOCATION MATRIX before implementation. Host pays: delivery fee + host merchandise. Participants pay: their own merchandise + tax + service fee + tip. Gate must reconcile all obligations and verify sum equals group total exactly.
NOT YET IMPLEMENTED
Gate scaffold — implementation pending
Consumes the C8/C10-certified cart baseline (certified item_id, menu_id, store_id, price_cents). Mutates only the gift fields per test — so item identity checks pass before gift validation runs. Chain: C8 item → C9 modifiers → C10 certified cart → C14 gift mutation of that cart.
Proves payment method retrieval, foreign-customer isolation, delivery address geocoding and validation, service-radius recalculation on address change, and that address/payment state survives quote refresh.
Proves valid future slots are returned, past slots are excluded, minimum lead time is enforced, slot spacing is correct, store timezone is configured, and scheduled orders don't dispatch prematurely. Lead-time and interval assertions are driven by API-reported metadata, not hard-coded values.
Proves all 6 replacement choices, optional max price increase, preferred replacement item IDs, preferences saved per original line item (not globally), preference survives quote refresh / quantity mutation, storeReplacementContract reads the exact same persisted preference, tip invariance across all replacement paths, and negative tests for sibling-store / foreign-merchant items.
Proves subtotal, tax, service fee, delivery fee, and total all recalculate correctly on quantity changes. Validates exact cents and unique quote tokens per mutation.
Proves valid codes apply discount, invalid/expired codes are rejected, discount reduces total correctly, tip base is not incorrectly reduced, and quotes are consistent after promo application.
Proves 0%/15%/20%/25%/custom tip, percentage base calculation (pre-discount subtotal), promo interaction, loyalty interaction, quantity-change interaction, exact cents, driver receives 100%, and no spinner deadlock on custom tip input.
NOT YET IMPLEMENTED
Gate scaffold — implementation pending
When repaired, this gate must prove: balance retrieval, redemption threshold, reservation, quote discount, Stripe reconciliation, cancel-checkout releases reservation, failed payment does not earn/deduct, delivery commits points, refund reverses correctly, and idempotency.
Must use the real path: Checkout quote → Place Order → PaymentIntent → Payment Sheet → Stripe confirmation → webhook → Base44 reconciliation → paid merchant-visible order. Proves exact amount, signed quote token, idempotency, payment cancellation/failure, requires_action, webhook duplicate, order status, and merchant visibility only after success. OUTPUT: produces the certified order_id + full evidence envelope consumed by Order Lifecycle Gate 6A.
NOT YET IMPLEMENTED
Gate scaffold — implementation pending
Proves group allocation matrix with real Stripe intents: each participant obligation, host obligation, partial completion policy, timeout, participant failure, host fallback rule, no order release before required payments complete, and merchant sees one coherent paid order.
NOT YET IMPLEMENTED
Gate scaffold — implementation pending
Certifies updateDriverLocation → DB → getCustomerOrderTracking → OrderTrackingMap. Seven mandatory dimensions — physical GPS source, jitter-safe movement, ETA freshness, 60s stale handling, terminal shutdown, tracking_enabled zero-poll proof, cross-customer isolation. Emits evidence_digest required by Gate C39.
C39 dependency — evidence_digest
Gate C39 (Final Customer Integrity) must verify evidence_digest is non-null before certifying. Digest covers: source, timestamps, freshness_age_secs, movement_meters, gps_accuracy_meters, jitter_threshold_meters, movement_verdict, eta_changed, stale_verdict, shutdown_verdict, isolation_denied, tracking_enabled_in_payload, zero_polls_after_disable. No raw precise coordinates are included.
Proves: successful Stripe/webhook reconciliation navigates to the correct order_id; order belongs to the authenticated customer; store name and order number render correctly; item count matches the paid order; displayed order total matches the canonical paid total; tracking screen cannot open a foreign customer's order; unpaid/failed/abandoned orders do not appear as active paid orders; reopening the app restores the active order; stale checkout state cannot navigate to the wrong order. Evidence layers: Physical Order DB · Customer tracking API · Rork customer normalized state · Actual customer render event.
NOT YET IMPLEMENTED
Gate scaffold — implementation pending
Canonical state-to-copy matrix enforced: • pending_merchant_acceptance → 'Waiting for merchant confirmation' — Show estimated range, NEVER 'Arriving now' • merchant_accepted → 'Merchant confirmed your order' — Recalculate ETA • preparing → 'Your order is being prepared' • driver_searching → 'Finding a driver' — No false arrival claim • driver_assigned → 'Driver assigned' — Show current ETA • picked_up → 'Your order is on the way' • arrived_at_customer → 'Arriving now' (ONLY valid state for this copy) • delivered → 'Delivered' — Hide active ETA Timeline integrity: Placed → Merchant Accepted → Preparing → Driver Assigned → Picked Up → Delivered. Assertions: every step appears exactly once; never skips; never regresses; timestamps are ordered; server timestamps match customer-local timezone display. Proves: headline matches canonical status; ETA range valid; 'Arriving now' only in arrived_at_customer; countdown never negative; status/ETA do not regress; stale poll cannot overwrite newer state; merchant acceptance updates tracking promptly.
NOT YET IMPLEMENTED
Gate scaffold — implementation pending
Proves complete customer order representation on tracking screen: item names, item quantities, selected modifiers, modifier quantities, special instructions, replacement decisions, removed/refunded items, gift details (where applicable), scheduled delivery time (where applicable), merchant/store identity, delivery address, order total. Defect target: 'Only 1 item' summary must also prove detailed item/modifier lines are accessible and accurate.
NOT YET IMPLEMENTED
Gate scaffold — implementation pending
Reconciles every displayed amount against the signed checkout/order snapshot using exact cents (not formatted string comparisons): merchandise subtotal, promo discount, loyalty discount, delivery fee, service fee, tax, tip, adjustments/refunds, final paid total. Proves: displayed total equals Stripe amount; tip distinct from merchant earnings; post-order adjustment updates summary; partial refund appears correctly; promo/loyalty lines appear only when applicable; no duplicate or hidden fee; cancelled order shows refund status and amount. No charge may be silently omitted.
NOT YET IMPLEMENTED
Gate scaffold — implementation pending
Proves state-aware behavior: customer↔merchant chat before driver assignment; customer↔driver chat only after assignment; correct order thread; unread counts; notifications; closed/read-only behavior after terminal state per policy. SUPPORT/HELP: correct order context attached; does not expose unrelated order data; terminal orders remain support-accessible. ⚠ CALL STORE — NOT CERTIFIED: Phone masked calling is not yet integrated. 'Call Store' button must be hidden/disabled or explicitly labelled as unavailable until provider is wired. A visible button implying a proven capability is a defect.
NOT YET IMPLEMENTED
Gate scaffold — implementation pending
Tests every lifecycle boundary: before merchant acceptance, after acceptance, during preparation, after driver assignment, after pickup. For each state proves: button visibility matches policy; backend decides eligibility (not client); correct cancellation endpoint called; order state changes exactly once; merchant notified; dispatch task/driver offer withdrawn where applicable; driver notified when assigned; refund amount and policy correct; customer tracking changes to cancelled; duplicate cancellation is idempotent; cancellation cannot mutate a delivered order.
NOT YET IMPLEMENTED
Gate scaffold — implementation pending
Proves: polling/subscription reconnect; temporary offline state; request timeout; duplicated status events; out-of-order events; stale cached order; expired auth token; background/resume; app restart; second-device refresh; terminal state immutability; no indefinite 'waiting' state after payment or acceptance. Uses monotonically increasing lifecycle versions — client must reject a response that regresses from a newer state to an older one.
NOT YET IMPLEMENTED
Gate scaffold — implementation pending
Proves: active paid orders appear in Active Orders; pending payment does not appear as active paid; delivered orders move to history; cancelled orders move to history; fully refunded orders follow defined history policy; terminal order does not remain in active tracking; no duplicate cards; order classification uses canonical status helpers.
NOT YET IMPLEMENTED
Gate scaffold — implementation pending
For each history card verifies: merchant/store name; order date in customer-local timezone; final status; item summary; final charged or refunded amount; delivery/pickup type; thumbnail where expected; sort order newest-first; pagination/infinite scroll; empty state; refresh; store/customer isolation. Search & filter: merchant filter, date range filter, status filter (Delivered / Cancelled / Refunded), combined filters, pagination of filtered results.
NOT YET IMPLEMENTED
Gate scaffold — implementation pending
Opening a history order shows an immutable final snapshot: original items and modifiers; replacements; removed/refunded lines; final quantities; final financial summary; tip; delivery details; timestamps; cancellation/refund reason where applicable; merchant and driver details per policy; chat transcript availability per retention policy; receipt/payment reference. History must use order-time snapshots, NOT recalculate from current menu.
NOT YET IMPLEMENTED
Gate scaffold — implementation pending
Proves: reorder uses current store/menu availability (not cached); unavailable items identified; changed prices disclosed; deleted modifiers handled; current service radius rechecked; current hours rechecked; no stale signed quote reused; original order is not mutated; cross-store contamination cannot occur. Modifier migration: if a modifier previously selected (e.g. Blue Cheese) has since been removed by the merchant, reorder must detect the unavailable modifier, prompt the customer for a replacement, use current modifier IDs, and never reuse stale modifier IDs from the original order.
NOT YET IMPLEMENTED
Gate scaffold — implementation pending
Proves: payment receipt total equals Stripe charge; refund amount and status; partial refund lines; full refund lines; loyalty reversal/restoration; promo treatment; tip refund policy; downloadable or shareable receipt if supported. Cross-receipt reconciliation: Customer Receipt → Merchant Receipt → Physical Order → Stripe Charge must all agree. Isolation: merchant never sees customer markup; customer never sees merchant baseline; driver never sees platform revenue. No platform-internal earnings fields exposed to customer.
NOT YET IMPLEMENTED
Gate scaffold — implementation pending
Negative tests: foreign customer order; tampered order_id; wrong merchant/store; deleted customer session; stale cached history; terminal order mutation; history item linked to current menu instead of snapshot; duplicate history record; inconsistent canonical and legacy statuses.
NOT YET IMPLEMENTED
Gate scaffold — implementation pending
Verifies notification delivery for: merchant accepted, driver assigned, driver arriving soon, delivered, cancelled, refund issued, replacement request. Proves the full chain: DB event → notification queue → push payload → client receives → tap opens correct screen. Assertions: correct order_id in tap payload; correct screen navigated to; no notification for another customer's order; duplicate push events do not create duplicate notifications; cancelled order does not receive fulfillment notifications.
NOT YET IMPLEMENTED
Gate scaffold — implementation pending
Verifies: Gift SMS to recipient (correct phone, correct message, not sent to sender); order receipt email (correct total, correct items, no internal fields); driver update SMS; cancellation notification; refund notification. OTP reuse protections: OTP cannot be reused after success; expired OTP rejected; brute-force lockout enforced; OTP does not leak in response body.
NOT YET IMPLEMENTED
Gate scaffold — implementation pending
Negative tests: wrong customer receives a notification (foreign order_id); wrong order in notification payload; expired device token; duplicate pushes are deduplicated; background app receives notification correctly; foreground app receives in-app notification correctly; killed/force-closed app receives notification via system tray and tap resumes correct state; revoked push token is cleaned up and does not cause delivery failures for other tokens.
NOT YET IMPLEMENTED
Gate scaffold — implementation pending
SC1 is the sole owner of the all_store_commerce_v1 digest. The backend emits backend_store_commerce_v1 (matrix only). SC1 combines backend + Rork ordered sequence + flip evidence into the final digest. C39 requires source=GateSC1StoreCommerceContinuity, backend_matrix_passed=true, rork_runtime_passed=true, flip_status=confirmed_zero.
Rork Instrumentation Required
Rork must emit the following via authenticated Base44 action in this order:
StoreCommerceInstrumentationReady — once per run — fields: run_id, instrumentation_version="store_commerce_v1", menu_render_enabled=true, checkout_pricing_enabled=true, merchant_flip_detection_enabled=trueStoreMenuRendered — per store, per step — fields: run_id, sequence_step, store_id, menu_state, merchant_idStoreCheckoutPricingRendered — per store, per step — fields: run_id, sequence_step, store_id, cart_store_id, header_store_id, pricing_store_id, menu_unit_price_cents, quote_unit_price_cents, identity_check_executed=trueStoreCheckoutPricingFailed — per store, per step — emit instead of StoreCheckoutPricingRendered when pricing fails — fields: run_id, sequence_step, store_id, error_code (required), duration_ms. SC1 marks that step FAIL. Emitting both success + failure at the same step → run marked FAIL as unstable/recovered-after-failure.CheckoutMerchantFlipDetected — only when a flip occurs — fields: run_id, verdict, previous_header, next_header, cart_store_id. Do NOT emit if no flip.Missing StoreCommerceInstrumentationReady → BLOCKED. Missing run_id events → BLOCKED. Missing flip instrumentation → BLOCKED.
Multidimensional Profile Dimensions
• operational: ACTIVE | INACTIVE — inactive stores skip all commerce tests
• catalog: FULL_COMMERCE | EMPTY_CATALOG | SHADOW_NOT_READY — shadow with usable shared-legacy → FULL_COMMERCE
• delivery: READY | CONFIG_GAP — config gap notes the gap but does not skip menu/identity tests
• migration: AUTHORITATIVE | SHARED_LEGACY_FALLBACK | SHADOW_NOT_READY
C39 requires: schema_version=all_store_commerce_v1, source=GateSC1StoreCommerceContinuity, backend_matrix_passed=true, rork_runtime_passed=true, flip_status=confirmed_zero, manifest_coverage_percent=100, full_commerce_backend_coverage_percent=100, rork_full_commerce_coverage_percent=100
Confirms the full C1–C39 + SC1 certification chain. PREREQUISITES: (1) Gate C38 evidence_digest must be present and non-null. (2) Gate SC1 must emit an all_store_commerce_v1 digest with store_scope=ALL_STORES, store_manifest_digest non-null, coverage_percent=100, full_commerce_passed=full_commerce_required, unexecuted_store_count=0, failed_store_count=0, cross_store_isolation_passed=true, forward_sequence_passed=true, reverse_sequence_passed=true, merchant_flip_count=0, rork_runtime_passed=true. A missing digest or any false field blocks C39. Checks: no stale quotes, no abandoned PaymentIntents, no loyalty reservation leak, no duplicate order, no cross-store cart contamination (any store's menu/cache/cart appearing under another store), no gift-data leak, no group invitation leak, no replacement preference on wrong line, payment allocations reconcile, tracking and history gates agree on order state, all artifacts scoped to test_run_id. Requires lifecycle milestone evidence digest to verify the same controlled order was used end-to-end.
NOT YET IMPLEMENTED
Gate scaffold — implementation pending
Generated when all 42 gates pass or are marked NOT_APPLICABLE (for demonstrably disabled features). Currently: 0 passed· 42 pending.
Gate 6A in the Order Lifecycle Suite must validate the digest, IDs, menu version, payment status, and evidence freshness before accepting the handoff. A stale or unrelated order must be rejected.
{
"source": "CustomerCheckoutSuite",
"test_run_id": "crun_1792436410717_tmuzi9",
"order_id": "<certified_order_id>",
"merchant_id": "<merchant_id>",
"store_id": "<store_id>",
"customer_id": "<customer_id>",
"menu_id": "<menu_id>",
"menu_version": 0,
"quote_id": "<quote_id>",
"quote_token_hash": "<sha256_of_signed_quote_token>",
"payment_intent_id": "<pi_...>",
"payment_intent_amount_cents": 0,
"stripe_livemode": false,
"payment_status": "succeeded",
"webhook_event_id": "<evt_...>",
"webhook_processed_at": "<iso_datetime>",
"order_total_cents": 0,
"merchant_baseline_cents": 0,
"item_snapshot_hash": "<sha256_of_item_modifier_snapshot>",
"replacement_preferences": [],
"gift_metadata": null,
"group_metadata": null,
"certified_at": "<iso_datetime>",
"evidence_digest": "<sha256_of_full_envelope>"
}After the Order Lifecycle Suite completes delivery, it must return this milestone evidence envelope. C38 (GPS chain) runs first in Domain H; C24–C36 follow; C39 (Final Integrity) runs last and requires C38 evidence_digest. Any Domain H/I gate must reject stale or mismatched lifecycle evidence.
{
"test_run_id": "crun_1792436410717_tmuzi9",
"order_id": "<certified_order_id>",
"merchant_accepted_at": "<iso_datetime>",
"driver_assigned_at": "<iso_datetime>",
"picked_up_at": "<iso_datetime>",
"delivered_at": "<iso_datetime>",
"terminal_status": "delivered",
"lifecycle_evidence_digest": "<sha256_of_lifecycle_evidence>"
}Domain H (C38 first, then C24–C30):
Domain I → J → Final: