This page describes the universal customer-facing application that DomiDo ships to buyers, designers, admins, and the public. The target shape is one React Native plus Expo codebase rendered through React Native Web for the Web/PWA today, with iOS and Android compatibility preserved from the start so that the same screens can package for native targets when their phase gates open. The current required test target is Web desktop plus mobile-width browser smoke; native delivery is deferred but never excluded by web-only assumptions. The app package still contains migrated mock-derived evidence from an earlier Vite-era prototype, including React/DOM-oriented wrappers — these remain useful for Web desktop validation but are not the long-term runtime shape. The active direction is no longer to deepen those wrappers; validated flows are wired into Expo Router screens and typed React Native-compatible modules, domain by domain, while keeping the app compatible across Web/PWA, iOS, and Android.
The target runtime is React Native plus Expo, rendered through React Native Web for Web/PWA and packaged for iOS and Android. The current app root is an Expo package configured for iOS, Android, and Web/PWA output. Mock-derived React/DOM wrappers and static examples carried over from the earlier prototype remain in the tree as transitional evidence — they are useful for Web desktop validation today, but they are not the long-term runtime shape and they do not define what new production work looks like. Navigation is a shared route and screen model that maps to web paths and native navigation stacks; the modal and sheet system is shared too, covering auth, search, checkout, designer, account, and support interaction surfaces so that every domain reaches them through the same primitives. Production components are typed React Native components organized by domain and designed for both web and native layouts. Mock bundles under a mock subtree are temporary visual and workflow evidence, replaced domain by domain. Static data under a data subtree is temporary too, replaced by typed API snapshots as the API contract becomes implemented.
The target app uses React Native plus Expo with React Native Web for Web/PWA, plus iOS and Android compatibility, and the current package may keep mock-derived evidence as a short-term Web desktop delivery aid — but production product logic migrates into React Native and Expo modules rather than deepening DOM-only dependencies. Mock bundles are compatibility wrappers, not the target component architecture: new production work lands in typed React Native-compatible components outside the mock wrappers and is reachable from Expo Router screens. Feature phase state is loaded from a backend feature-phase configuration endpoint and consumed centrally — UI components never infer active features from route existence or mock visibility. Translation configuration is loaded from a backend translation-configuration endpoint and consumed through the shared API and runtime config layer; production components never hard-code supported content languages or call LLM translation providers directly.
Web-only APIs — direct DOM access, browser-specific layout assumptions, CSS-only interaction behavior — are isolated to transitional evidence or thin web adapters; production components prefer React Native primitives, shared design tokens, and platform adapters. Platform-sensitive behavior is accessed through adapters for navigation and linking, local storage, safe areas, media selection and upload, payment handoff, file download and export, browser-only APIs, and native-only APIs. The point of the adapter line is that a feature owner can write one component that works on Web/PWA today and that ports cleanly to iOS and Android when those targets open, without rewriting the screen.
Route-level modules align to product domains so feature work has a single home. Each module owns its domain end to end — typed components, navigation stack, and the API resources it calls — while cross-module concerns (auth, search, checkout, design tokens, platform adapters) sit in the Expo Router shell so a feature owner never reimplements them.
Every route-level module owns its domain end to end — typed components, navigation stack, and the API resources it calls. Cross-module concerns (auth, search, checkout, design tokens, platform adapters) sit in the Expo Router shell so a feature owner never reimplements them. The Public module covers Home, gallery, listing, designer profile, and the help, workshop, and legal entry points. The Create module covers the create wizard with its describe, projection, model, block-kit, and publish states. The Commerce module covers cart, checkout, saved carts, and SetupIntent pre-order confirmation. The Buyer dashboard covers pre-orders, future orders, notifications, and order and pre-order actions. The Designer module covers listings, the designer dashboard, Promo Studio, engagement surfaces, and payout readiness. The Account module covers profile, addresses, payment references, privacy, notifications, and security. The Admin beta operations module covers support, content and publication operations, beta analytics, and phase-gate visibility.
The boundary between server state and local state is explicit. Server state is represented as typed API snapshots matching the canonical API resources, and durable user workflow state — drafts, generation outputs, job progress and retry and cancel state, carts, saved carts, checkout state, pre-orders, designer payout readiness, statements, help comments, and support conversations — always comes from the API rather than being reconstructed in the client. Local state is allowed only for UI-only concerns: open panels, selected tabs, temporary prompt text, optimistic visual transitions, and modal state. The checkout flow holds a single typed checkout-state object and renders phase-specific behavior from the commitment type, the Stripe checkout mode, the feature phase gate, and validation messages — not from ad hoc booleans scattered across components. Designer dashboard state distinguishes attributed pre-orders and projected royalties (Phase A.5) from Phase B captured sales and payout-release state, so the same screen renders correctly across phases without copy-level guessing.
User-generated free text is displayed from API-provided localized fields, resolved against the request locale, the user's preferred content language, and backend fallback metadata. The app may send source-language hints during mutations, but source text, translated variants, translation status, and retry state are all server state. Nothing about translation lives in the client beyond the locale preference and the rendered output.
The migration is staged so visual coverage never regresses while typed components replace mock wrappers. The replacement order is: shell, route, modal, auth and search controls first; then public discovery and listing; then the create and generation workflow; then cart, checkout, and pre-orders; then the buyer dashboard; then the designer marketplace and Promo Studio; then help, workshop, and admin content. Each replacement preserves the required user journey on Web desktop before the corresponding mock wrapper is removed, and avoids decisions that would block Web/PWA, iOS, or Android reuse later. Production components use named types, accessible controls, shared design tokens, React Native-compatible layout primitives, and platform adapters where needed; a separate web-only UI framework is not introduced unless an explicit architecture decision approves it. The transitional mock-derived wrappers can be retired when the React Native and Expo app covers the Phase A Web/PWA journey and the Phase A.5 designer-readiness journey at equivalent or better Web desktop quality. The app workspace may remain separately versioned while it is embedded in the project, and its nested version-control metadata is not moved, deleted, or rewritten without explicit founder approval.
The current minimum app check is the app-package lint script, and when Expo web routes are wired, Web desktop export validation uses the Expo web export command or the equivalent package script. The required acceptance test target is Web desktop, so important route or screen changes require desktop browser validation. Web mobile, iOS, and Android are compatibility targets — they require architecture-safe code, shared primitives, and platform adapters, but they are not mandatory test targets until their phase gates open. Checkout and designer payout-readiness states require tests for inactive and future-phase behavior so a phase boundary cannot silently regress into a charge or a promised payout. The frontend never displays unsupported providers, fixed locale / currency / jurisdiction lists, fixed payout numbers, or direct-charge Phase A copy. Web desktop validation includes at least one non-default preferred content language, source-text fallback before translation completion, and owner / admin translation-status display wherever a surface exposes editable user-generated content. Accessibility covers keyboard navigation, modal focus, status announcements, form errors, screen-reader labels, touch targets, and disabled future-phase controls — the disabled controls are themselves accessible, not silently dropped.