# HAS mobile backend mapping This inventory is based on the current local `vegetarian-production-20260807` source. Paths below are relative to that source root. Named functions and actions were checked in source. Existing implementation indicates reusable internal logic. Availability on the new mobile `/v1` API must be checked against the published OpenAPI contract. Production feature flags and payment-provider configuration need runtime validation before mobile rollout. All approved screen references point to the supplied checkout and profile PDF inventory. Proposed mobile endpoint paths are intentionally left for the versioned contract. ## Capability mapping ### Phone OTP and session **Status — existing-internal** Reuse handleUserAuth actions start-checkout-phone, verify-checkout-phone, request-login-otp, verify-login-otp and register-passwordless. Define mobile challenge/session DTOs, repeat-request behavior and secure session lifecycle. Legacy identify-phone and otp-login return 410. Mobile /v1 contract is pending. Related screens — CO-02, CO-03 Evidence - `server/src/user-auth.js` - `src/landing/LoginPage.tsx` ### Customer profile and contact verification **Status — partial** Existing update-profile, request-contact-step-up and email/phone verification actions protect contact changes. Reuse this behavior. No birthday, nationality or gender implementation was found in the inspected customer/server source. Define optionality and storage for these fields. Checkout email capture remains a design question. Related screens — CO-04, CO-05, CO-06, PR-10 Evidence - `server/src/user-auth.js` - `src/user/UserProfileApp.tsx` ### Plans, package lengths and meal combinations **Status — existing-internal** The web catalog requests packages, sharing-packages, delivery-options and delivery-settings. Order creation handles balanced, vegetarian and sharing services. Return a versioned mobile catalog of valid combinations and server-calculated prices, preserving trial eligibility. Related screens — CO-07, CO-08, PR-08 Evidence - `src/landing/CheckoutFlowPage.tsx` - `src/landing/checkoutCatalogRequests.ts` - `server/src/functions/checkout-order.js` - `server/src/functions/trial-pricing.js` ### Daily menu and food details **Status — existing-internal** Reuse getOrderMenu, buildOrderMenuEntries and resolveOrderMenuFood for purchased order menus. Public browsing must use the public catalog behavior. Define food DTOs for image, nutrition, ingredients/allergens only where source data exists. Filters in PR-01 are unopened in the PDF. Related screens — CO-07, CO-10, PR-01, PR-02, PR-03 Evidence - `src/landing/MenuPage.tsx` - `server/src/user-self-service.js` - `src/lib/menuHelpers.ts` ### Dietary exclusions and preferences **Status — existing-internal** Existing get-order-preference-options and update-order-preferences actions and menu substitution logic provide a base. Preserve allowed options, eligibility and schedule cutoff. Confirm semantics of the app allergy wording and supported combinations. Related screens — CO-09, PR-06, PR-08 Evidence - `server/src/user-auth.js` - `server/src/user-self-service.js` - `src/user/UserProfileApp.tsx` ### Snack add-on **Status — existing-internal** Reuse buildSnackAddon, getOrderSnackSnapshot and order upgrade eligibility. Expose price units, inclusion count, snack menu and availability flags in the mobile contract. Related screens — CO-10, PR-06, PR-09, PR-12 Evidence - `server/src/functions/snack-addons.js` - `server/src/user-self-service.js` - `server/src/functions/order-upgrades.js` ### Address book, map and per-day address schedule **Status — existing-internal** Reuse createCustomerDeliveryAddressHandlers, normalizeOrderDeliveryAddressSchedule, requireCheckoutAddressDetails, getCheckoutAddress, previewOrderDeliveryRouting and updateOrderDeliveryAddress. Preserve expectedVersion conflict checks and routing preview. Supply iOS place search/location configuration and missing day-assignment UI. Current normalizeOrderDeliveryAddressSchedule specifically requires Monday, Wednesday and Friday assignments. Verify the app delivery-day model before generalizing this behavior. Related screens — CO-11, CO-14, PR-06 Evidence - `server/src/functions/customer-delivery-addresses.js` - `server/src/functions/checkout-address-details.js` - `server/src/user-self-service.js` - `src/lib/checkoutAddressContract.ts` ### Coverage, districts and delivery slots **Status — existing-internal** deliveryOptions returns provider catalogVersion and coverage/slot hierarchy. Preserve active-provider authority and version validation in the app contract. Resolve duplicate placeholder slot labels in the PDF using real IDs. Related screens — CO-11, CO-13, CO-14, PR-05 Evidence - `server/src/functions/delivery-options.js` - `server/src/functions/delivery-routing.js` - `src/lib/deliveryRouting.ts` ### Delivery instruction options **Status — partial** Existing address and routing data provide context. Map the four app instruction choices to persisted instructions with defined address/order scope and compatible selections. Exact structured option IDs in the PDF need an agreed contract. Related screens — CO-13, CO-18, PR-06 Evidence - `server/src/functions/checkout-address-details.js` - `server/src/functions/customer-delivery-addresses.js` - `src/user/UserProfileApp.tsx` ### Start dates and delivery calendar **Status — existing-internal** Define mobile available-date responses from authoritative scheduling rules, Dubai business time, active provider, holidays and cutoff. Verify the design two-day lead text against runtime rules. Expose next delivery and calendar for the selected order. Related screens — CO-16, PR-05 Evidence - `src/landing/CheckoutFlowPage.tsx` - `server/src/functions/checkout-order.js` - `server/src/user-self-service.js` ### Portion sizes and nutrition **Status — partial** Existing order and upgrade code handles portion_size including normalizePortionSize. Expose allowed sizes and incremental prices. The identical sample macros for Regular and Large require verified catalog nutrition. Related screens — CO-15, PR-06, PR-09 Evidence - `src/landing/CheckoutFlowPage.tsx` - `server/src/user-self-service.js` - `server/src/functions/order-upgrades.js` ### Reusable bag acknowledgement **Status — new-contract-needed** Website delivery content exists. A persistent customer acknowledgement matching CO-12 was not found in the inspected server/customer source. Decide whether the acknowledgement is local guidance or stored consent and implement its agreed behavior. Related screens — CO-12 Evidence - `src/landing/components/DeliverySection.tsx` ### Paid cutlery option **Status — new-contract-needed** No cutlery field or priced cutlery implementation was found in the inspected server/customer source. Define amount and charging unit, order snapshot, fulfillment visibility and refund treatment before adding it to the server quote. Related screens — CO-12 Evidence - `src/landing/CheckoutFlowPage.tsx` ### Order draft, pricing, VAT and confirmation **Status — existing-internal** Reuse verified-profile order creation, assertCheckoutOrderIntegrity and calculateCheckoutVat. The mobile facade needs server-priced versioned quote and idempotent submit behavior with owned order status. App-only fields must join the authoritative order snapshot. Related screens — CO-07, CO-08, CO-10, CO-12, CO-15, CO-17, CO-19 Evidence - `server/src/functions/checkout-order.js` - `server/src/functions/checkout-order-integrity.js` - `server/src/functions/checkout-vat.js` - `server/src/functions/order-confirmation.js` - `src/landing/checkoutDraft.ts` ### Card, Apple Pay and Google Pay **Status — partial** Provider selection and createPaymenntCheckoutSession, getAuthoritativePaymenntPaymentState and paymenntWebhook already exist. Supply mobile session/return/status contract and validate provider-specific iOS Apple Pay or hosted flow. Google Pay visibility must follow actual platform/provider capability. Existing Tabby website flow has no approved app frame. Related screens — CO-17, CO-19, PR-12 Evidence - `server/src/functions/card-checkout.js` - `server/src/functions/card-provider-selection.js` - `server/src/functions/stripe-checkout.js` - `server/src/functions/tabby-checkout.js` ### Auto-renew enrollment and cancellation **Status — existing-internal** Existing assertAutoRenewCheckoutConsent, enrollAutoRenewalAfterInitialPayment, cancelAutoRenewal, scheduling and provider enrollment logic should be reused. Expose eligibility, recurring quote, consent version and cancellation. Production enablement remains configuration-dependent and needs runtime validation. Related screens — CO-17, PR-05 Evidence - `server/src/functions/auto-renewals.js` - `server/src/functions/auto-renewal-worker.js` - `server/src/functions/card-checkout.js` - `server/src/user-auth.js` ### Wallet balance, split payment and transactions **Status — existing-internal** wallet overview and order-status customer actions plus walletOverview, quoteCheckoutWallet, reserveCheckoutWallet, captureWalletReservation and releaseWalletReservation exist. assertWalletCheckoutScope currently rejects auto-renew, renewal-origin and upgrade orders. CO-17 must reflect allowed combinations. Define a customer-scoped transaction DTO for PR-11 rather than exposing CRM ledger tools. Related screens — CO-17, PR-04, PR-11 Evidence - `server/src/functions/wallet.js` - `server/src/wallet-service.js` - `server/src/wallet-checkout.js` - `src/lib/walletService.ts` ### Wallet reward campaigns **Status — existing-internal** customerWalletRewardCampaigns and walletRewardProgress expose earned credit/progress. Full campaign progress and reward-detail UI is outside the supplied approved designs. Confirm app scope before exposing these DTOs. Related screens — Scope/design pending Evidence - `server/src/wallet-rewards.js` - `server/src/wallet-rewards-worker.js` - `server/src/functions/wallet.js` ### Referral and invitation rewards **Status — unknown** No referral or invite implementation was found in inspected customer/server code. Existing wallet rewards do not establish a referral contract. Confirm whether referral is in app scope and define attribution, eligibility and reward rules before implementation. Related screens — Scope/design pending Evidence - `server/src/wallet-rewards.js` ### Freeze and resume subscription **Status — existing-internal** getOrderFreezeOptionsV2, freezeOrderSubscriptionV2 and mutate-order-freeze-v2 already exist. Expose options and mutation contract with owned order, eligibility, remaining allowance, preview dates and expected concurrency behavior. Adapt PR-07 range selection to these rules. Related screens — PR-06, PR-07 Evidence - `server/src/user-self-service.js` - `server/src/user-auth.js` ### Plan upgrades and upgrade payment **Status — existing-internal** Reuse listOrderUpgradeOptions, quoteOrderUpgrade, completePaidOrderUpgrade and cancelOrderUpgrade with eligibility and financial snapshots. Expose quote expiry and server-confirmed payment status. The quoted amount in PR-12 must be authoritative. Related screens — PR-08, PR-09, PR-12 Evidence - `server/src/functions/order-upgrades.js` - `server/src/functions/order-upgrade-card-checkout.js` - `server/src/functions/order-upgrade-lifecycle.js` - `server/src/user-auth.js` ### Orders, deliveries and manual extension **Status — existing-internal** get-user-data returns owned customer data and order projection, sanitizeOrder and cancelPendingOrder provide existing behavior. Build focused mobile list/detail responses. Manual package extension has server tooling but customer-facing availability and app flow require separate scope confirmation. Related screens — PR-04, PR-05, PR-06 Evidence - `server/src/user-auth.js` - `server/src/user-self-service.js` - `src/user/UserProfileApp.tsx` - `server/src/functions/package-extensions.js` ### Support, contact and chat **Status — partial** Website contact and chat components exist. Define what the repeated headset action opens in iOS and expose appropriate public contact settings. Full support/contact conversation UI is absent from the PDFs. Related screens — CO-02, CO-03, PR-04 Evidence - `src/chat/ChatWidget.tsx` - `src/lib/publicContactSettings.ts` - `src/lib/contactFormApi.ts` - `src/landing/ContactPage.tsx` ### Terms and communication preferences **Status — partial** Use current approved terms and existing email-consent logic. Provide terms version/link for checkout and consent storage where required. App screens for legal content and communication preferences are absent. Related screens — CO-17 Evidence - `src/landing/TermsPage.tsx` - `src/landing/termsContent.ts` - `src/landing/CookiePolicyPage.tsx` - `src/landing/EmailPreferencesPage.tsx` - `server/src/functions/email-consent.js` ### Home, plan discovery, reviews, FAQ and articles **Status — design-pending** Website surfaces exist and the user confirmed app Home is still pending. Inventory these content sources for later approved Home design. Public articles, UGC and delivery-information pages need explicit app scope decisions. Related screens — CO-19 Evidence - `src/App.tsx` - `src/landing/LandingApp.tsx` - `src/landing/components/HomePageSections.tsx` - `src/landing/components/FAQSection.tsx` - `src/landing/components/HomeReviewsSection.tsx` - `server/src/functions/blog-public.js` ### Account deletion **Status — new-contract-needed** PR-10 explicitly includes Delete account. No customer account-deletion implementation was found in the inspected customer/server code. Define authenticated deletion request, active-order treatment, retained accounting records and completion status before adding the mobile endpoint. Related screens — PR-10 Evidence - `src/user/UserProfileApp.tsx` - `server/src/user-auth.js` ### Purchase and refund transaction history **Status — partial** Existing orders, provider payments and wallet ledger are distinct data sources. PR-11 shows card-branded purchase/refund history. Build an owned customer transaction projection including refund state, currency and available card brand/last four digits. Confirm which provider metadata is retained and omit unavailable fields. Related screens — PR-11 Evidence - `server/src/user-auth.js` - `server/src/functions/card-checkout.js` - `server/src/wallet-service.js` ## Customer website surfaces without complete approved app screens | Website surface | App coverage decision | | --- | --- | | Home, plan discovery and pricing comparison | Home PDF pending, type-of-plan entry before CO-07 remains open | | FAQ, reviews, delivery coverage and bag information | Reuse content where approved Home or support designs call for it | | Public blog and article details | App scope and design pending | | UGC listing and contact form | No complete app screen supplied | | Full support/chat flow | Headset entry points exist, destination design pending | | Email verification and secure contact-change challenge | Web behavior exists, mobile challenge states need design | | Email marketing preferences and legal documents | Terms link exists in checkout, full screens pending | | Tabby payment and alternate payment-result states | Website payment paths exist, app inclusion and failure/pending/cancel flows pending | | Auto-renew cancellation and wallet reward details | Backend behavior exists, full management flows pending | | Manual extension, cancellation and historical order details | Some profile entry points exist, complete flow coverage needs review | The website CRM, kitchen, finance and mailbox are operational surfaces. This mapping concerns the customer app and uses their services only through appropriate server-owned business logic. ## Contract conflict to resolve CO-17 contains both an auto-renew switch and wallet switch. Current `assertWalletCheckoutScope` rejects wallet use for auto-renew, renewal-origin and upgrade orders. The mobile quote must return eligible payment choices and a reason for unavailable combinations. Altering this policy would require corresponding accounting and renewal changes. ## Newly required or unverified data Birthday, nationality, gender, paid cutlery, bag acknowledgement and referral attribution need explicit schema/behavior decisions. The approved visual design remains the source for layout. These backend decisions determine actual data and valid actions. ## Address schedule constraint The inspected address schedule implementation currently accepts Monday, Wednesday and Friday. CO-14 offers assignment to delivery days. The mobile contract must reflect the actual delivery calendar and explicitly address any broader assignment requirement.