This page is the route-by-route, element-by-element record of how every visible surface of the DomiDo Web and Progressive Web App is backed: by a real backend contract, an allowed client-only behaviour, an external link, or an explicit phase gate. It walks each routed screen, lists the visible data and the actionable elements, names the read contract and the action contract behind them, and records whether the surface is covered by the canonical API, gated by a feature phase, intentionally local, or intentionally external. The discipline is strict because the app is the customer surface for the Phase A public interest beta: mock-only data is acceptable as design evidence, but it is never the implementation contract. The current routed app uses Expo Router and lazy-loads mock-derived bundles for each public route, so the mappings below describe implementation readiness rather than runtime behaviour already wired to the backend. The routes today carry mock bundles for the homepage, the gallery, the listing detail (with a buyer view and a designer-editor view selected by query parameter), the designer profile, the create wizard, the checkout, the buyer dashboard, the help and workshop hubs, and the Expo Router 404 component for +not-found. None of those bundles currently calls the backend — they use static arrays, component-local state, and a small amount of browser storage for search recents — and this page specifies what each one reads and calls once it is wired.
Each row uses one of four status labels. Covered means an API endpoint and schema in the canonical specification feeds or mutates the UI element. Gate required means the UI may remain visible only if it is disabled or read-only behind a feature phase gate or shell configuration. Client-only means no backend is needed because the state is visual, local, or browser-controlled. External means an external legal, social, or support target is provided by the shell or footer configuration.
The cross-app shell wraps every routed screen and is itself driven by configuration. The header navigation reads GET /app-shell and routes the user to the configured target — covered, with the requirement that navigation items are server-configured and phase-gated. The Journal navigation item is gate-required: no Journal route or dedicated content API exists, so the item is hidden until a configured target appears. The language and locale selector reads GET /app-shell, GET /config/translations, and GET /me, and writes through PATCH /me/preferences; it changes both the UI language and the preferred content language, and translated user-generated content is resolved through backend fallback rules rather than frontend language-model calls. Currency display reads GET /app-shell and GET /footer and writes through the same preferences endpoint where it is editable.
The global search modal reads GET /app-shell and GET /search and submits queries to the search endpoint; search scopes come from search configuration rather than hard-coded UI scopes, and the frontend uses the backend-supplied enabled-scope list rather than a baked-in array. Search recents follow the local-storage policy that search configuration defines and are otherwise browser-only. The voice search button reads GET /app-shell.search.voiceSearchAvailable and uses the browser speech API where it is available, gated by the shell.
The authentication modal exposes the OAuth buttons from GET /app-shell and calls POST /auth/oauth; sign out calls POST /auth/sign-out against the GET /me context, and the avatar menu uses the same /me payload to render route links and the sign-out action. The notification icon and count read from GET /app-shell and GET /account/notification-items and write through POST /account/notification-items/{notificationId}/read and POST /account/notification-items/read-all, with the shell-config notification summary as the header count source. The footer's columns, social links, and legal items come from GET /footer; newsletter signup posts to POST /newsletter-signups; and cookie controls read and write /legal/cookie-preferences.
Every routed screen runs inside the universal React Native and Expo app and stays compatible with Web and Progressive Web App, iOS, and Android. The Web desktop test target relies on the backend for source-language capture, asynchronous translation, translated-variant storage, fallback resolution, and translation status. The app-supported content languages come from GET /config/translations and embed inside the shell config; the frontend never hard-codes the language list beyond a safe local fallback, never calls a language-model translation provider directly, and always propagates the user's locale, the Accept-Language header, and any source-language hint through the API client.
Listing cards and the listing-detail title, story, and tags resolve through GET /gallery/listings, GET /listings/{listingId}, and GET /listings/{listingId}/related with a request language and the Accept-Language header; source text is created through draft publish or the designer listing editor, and responses expose localised display fields plus fallback or source status where they are needed. The create flow's prompt, brief, reference text, and publish copy read through draft endpoints and write through the draft create, update, save, and publish endpoints, each of which creates translation jobs; the source mutation succeeds before translation completes. The designer profile bio, inspirations, collections, and owner-edited copy read through GET /designers/{designerId} and GET /designer/profile and write through PATCH /designer/profile and PATCH /designer/listings/{listingId}; owner views may show translation status and retry state. Public reviews, questions, replies, and designer responses read through review and question endpoints and write through endpoints that accept an optional source-language hint, while eligibility and moderation still control write access. Designer messages, support conversations, reports, and dispute notes read through dashboard, action-queue, thread, and support endpoints and write through reply, report, claim, and support endpoints that create translation jobs for free-text bodies, with private translated variants inheriting the source's private visibility. Help comments and article feedback free text read through help-article and comment endpoints and write through comment, reply, feedback, and report endpoints with an optional source-language hint, while admin-authored help-article source remains publication content rather than user-generated translation pipeline. Promo Studio prompts and generated copy inputs read and write through Promo Studio project and job endpoints, which create translation jobs for persisted user prompts where they are shown later — covered under a Phase A.5 gate. AI text-assistance chips submit through POST /assist/text-jobs; text assistance is separate from the mandatory persistence translation, and accepting a suggestion still saves source text and triggers translation. Translation fallback and translation status render consistently for owner and admin surfaces, and the frontend never presents source-fallback content as a completed translation.
The guest hero and the primary calls-to-action read GET /app-shell and GET /config/feature-phases and route to /create or /gallery — covered. The returning-user resume strip reads GET /me/dashboard, GET /design-drafts/current, GET /me/interest-reservations, and the Phase A.5 GET /pre-orders, and lets the user resume a draft or open a reservation, pre-order, or the dashboard — covered. The credit chip and generation balance read GET /me/dashboard and GET /config/generation-costs; the top-up action stays hidden until a billing or top-up product exists, so this row is covered plus gate required. The featured gallery rail reads GET /gallery/listings and routes to listing pages with save and share where shown — covered. The featured designers rail reads GET /designers and writes follow state through /designers/{designerId}/follow — covered. The create modes read GET /config/create-style-presets and GET /config/feature-phases and route into the create stages — covered. The how-it-works content is shell-configured (covered) or static (also allowed).
The gallery hero, categories, filters, sort, and density controls all drive a GET /gallery/listings call with query parameters and are otherwise local UI state — covered, with filter and sort parameters explicit in the canonical API. The kit card grid and list read GET /gallery/listings and open the listing route — covered. Save uses the savedByViewer flag on the listing card and writes through POST /listings/{listingId}/save and DELETE /listings/{listingId}/save; share uses the listing share metadata and writes through POST /listings/{listingId}/share — covered. The featured-designer rail and the all-designers link read GET /designers and open the designer route, with follow if shown — covered. The empty-state suggestions read GET /gallery/listings and GET /search and offer query retry or filter reset — covered. The mobile filter sheet uses the same gallery list and reloads the query — covered.
The media viewer, the thumbnails, and the layer and play controls read GET /listings/{listingId} and are otherwise local controls — covered plus client-only. The title, owner and creator, indicative price, social proof, and facts come from the same endpoint, with a route into the creator or designer profile where active — covered. The interest call-to-action and the sticky call-to-action read GET /listings/{listingId} and write through POST /listings/{listingId}/interest; the Phase A.5 invitation flow uses the checkout endpoints instead. Phase A copy says non-binding interest, no card, no charge, no order or pre-order, and no fulfilment promise — Phase A demand is never called an order, pre-order, purchase, or commitment. Save, share, story, what-you-need, process, and specs all read from the listing endpoint and are otherwise local. Public questions read GET /listings/{listingId}/questions and write through POST /listings/{listingId}/questions; public reviews read GET /listings/{listingId}/reviews and accept reviews only from an eligible buyer context — covered. The designer profile card reads either GET /designers/{designerId} or the embedded listing-designer card and writes through the follow endpoint. Similar kits read GET /listings/{listingId}/related and open the listing route — covered.
The owner editor aggregate reads GET /designer/listings/{listingId}/editor and saves through PATCH /designer/listings/{listingId} — covered. Media replace and crop use the editor aggregate together with POST /media/uploads and PATCH /media/{mediaId}/crop, attaching media through the listing PATCH. Editable title, tags, story, specs, and visibility flow through the same listing PATCH together with publish-state PATCH and tag suggestions. Royalty controls are visible but gate-required in Phase A: PATCH /designer/listings/{listingId}/royalty operates only when the monetisation phase is active. Moderation rerun writes through POST /designer/listings/{listingId}/moderation-jobs; similarity and uniqueness read GET /designer/listings/{listingId}/similarity and dispatch required actions through the editor aggregate. Analytics and the right-column metrics read GET /designer/listings/{listingId}/analytics and write ad-boost changes through PATCH where it is enabled. The Promo Studio chip and modal use the Promo Studio configuration and project endpoints together with the scene, job, and asset endpoints. Review replies use the editor and dashboard review data plus the /designer/reviews/{reviewId}/reply methods. Messages, thread replies, and reports use the designer thread endpoints with reply, report, and claim writes. Duplicate listing reads from the source listing editor aggregate and writes through POST /designer/listings/{listingId}/duplicate — covered. Download STL and the artefact pack come from listing artefacts in the editor aggregate and write through POST /designer/listings/{listingId}/artifact-pack/download — covered. AI copy and reply assistance chips submit through POST /assist/text-jobs and are gate-controlled. The remixes and lineage preview reads the editor aggregate with its disabled-remix state and is gate-required until remix economics opens.
The public hero, avatar, banner, bio, and social links come from GET /designers/{designerId} — covered. Follow, notify, and share use the designer profile follow state through the follow and unfollow endpoint, with share either client-side or via the listing-share pattern. The stats strip and pinned kit catalogue come from the same designer endpoint; collections come from the designer endpoint and open a filtered profile or catalogue; reviews come from the embedded reviews on the designer profile, with reply only from the owner dashboard. Inspirations and in-conversation links come from the designer endpoint and open related designer or listing targets. Owner edit of profile, banner, bio, and social links reads GET /designer/profile and writes through PATCH /designer/profile plus the media-upload endpoints — covered.
The stage rail and the current draft read GET /design-drafts/current and GET /design-drafts/{draftId} and write through POST /design-drafts and PATCH /design-drafts/{draftId} — covered. The draft list for dashboard builds reads GET /design-drafts and lets the user open, resume, or discard a draft by its endpoint — covered. Style presets and prompt examples come from GET /config/create-style-presets, applied through the draft PATCH. Reference upload uses the media upload endpoint and attaches through /design-drafts/{draftId}/reference-media. The projection face slots, history, and autofill use the draft projection payload with put-face, generate, autofill, and restore-history endpoints. Model generation and the tryout selector use the draft model tryouts and GET /jobs/{jobId} with model job, select, feedback, and job retry and cancel endpoints; the job response exposes polling progress, safe errors, retry and cancel eligibility, and artefacts. Block-kit generation, the bill of materials, and the assembly view use the draft block-kit endpoints and GET /jobs/{jobId} with the block-kit job endpoint and retry and cancel controls; job progress includes voxelisation and blockification stages before the bill of materials or assembly outputs are loaded. The publish title, description, tags, visibility, ownership, and safety acknowledgements use the draft publish-settings PATCH plus save and publish, and Phase A publish requires owner or licence acknowledgement and does not require royalty or payment setup. The AI publish-copy helper uses the current draft context and writes through POST /assist/text-jobs. The generation credit and cost display reads GET /config/generation-costs and GET /me/dashboard; the top-up button stays hidden until a billing or top-up product exists.
The checkout route's visibility itself is gate-required: GET /config/feature-phases and GET /app-shell decide whether the route appears, and Phase A does not expose active payment checkout for interest reservations. The bag, items, and totals read GET /cart and GET /checkout and write through the add, update, remove, and save-cart endpoints — covered for Phase A.5 and Phase B only. Delivery address and method read from checkout delivery, the account addresses, and the jurisdiction configuration, and write through PATCH /checkout/delivery and the account address endpoints. Payment reference and card verification read from checkout payment and payment references and write through PATCH /checkout/payment and POST /checkout/setup-intent — covered for Phase A.5 invitation conversion only. Adding a saved card outside checkout writes through POST /account/payment-references/setup-intent — covered and Phase A-gated. The promo code uses PATCH /checkout/promo-code against the checkout review or payment view. The review and no-capture acknowledgement use POST /checkout/review and POST /checkout/confirm. The confirmation page renders the checkout commitment response with share, client navigation, or dashboard links, and displays pre-order language only in Phase A.5 and omits receipt or invoice unless Phase B.
The overview tiles and resume cards read GET /me/dashboard and open the target routes — covered. Interest reservations read GET /me/interest-reservations and GET /interest-reservations/{reservationId} and cancel through DELETE /interest-reservations/{reservationId} — covered and active in Phase A. Phase A.5 pre-orders read GET /pre-orders and GET /pre-orders/{preOrderId} and cancel through POST /pre-orders/{preOrderId}/cancel — covered and Phase A.5-gated. Future orders read GET /orders and GET /orders/{orderId} with the order action endpoints — covered but Phase B-gated. The order sheet's tracking, returns, disputes, and report actions use the order detail plus the specific action endpoints, all Phase B-gated. Builds in progress read GET /design-drafts and resume through the draft route, with update and delete through the draft endpoints. Saved kits use GET /me/dashboard saved listings and write through the save and delete-save endpoints. Following designers uses GET /me/dashboard following-designers and writes through the follow and unfollow endpoint. Addresses use the account address endpoints with create, update, and delete. Payment references use the payment-reference endpoints with delete and SetupIntent for a new card; this is Phase A-gated unless required for an active Phase A.5 or B flow. Profile, security, two-factor authentication, and sessions use the account profile and security endpoints with patch, password, two-factor authentication, and session-revoke. Notifications, privacy, data export, and delete use the account notification, privacy, and lifecycle endpoints with patch, export, and lifecycle requests.
The overview tiles, charts, activity, and action queue read GET /designer/dashboard and GET /designer/action-queue and open the action targets — covered. The kits list and the row actions read GET /designer/listings and use edit, share, duplicate, artefact download, archive, and unlist endpoints — covered. The sales list and detail read GET /designer/sales and GET /designer/sales/{saleId} with a dispute endpoint where it is shown. Earnings and payout readiness use the payout-account, payout, reserves, events, and statements endpoints with connect, schedule, request, retry, and export actions — covered, with actual payout release Phase B-gated. The reviews queue reads embedded queue data on the designer dashboard and uses the review reply endpoints. Messages and the inbox read GET /designer/action-queue plus the thread and message endpoints and use reply, report, and claim action endpoints. Designer settings use the account endpoints together with the payout-account endpoints and accept patches across profile, security, notifications, and payout.
The help hub's topics, tree, featured items, and popular items read GET /help/topics and GET /help/articles and open the topic and article routes. Topic filters, sort, and search use GET /help/articles with query parameters or fall through to /search and reload the article list. The article body, table of contents, related items, and backlinks come from GET /help/articles/{slug} and offer section navigation. Article comments and replies use the help comments endpoints with create, reply, like, and report. The was-this-helpful vote comes from the article detail and writes through POST /help/articles/{slug}/feedback — covered. Bookmark uses POST /help/articles/{slug}/bookmark and DELETE /help/articles/{slug}/bookmark — covered. The support-ticket call-to-action uses help configuration or article context and writes through POST /support/conversations. Admin help editing and publishing use the admin help endpoints for create, update, publish, and artefact.
The product analytics wrapper reads GET /config/product-events and writes through POST /analytics/events; the app uses backend event names, versions, and consent classes rather than ad-hoc event strings — covered. Beta feedback affordances on routed pages may take optional context from the current route or resource and post through POST /beta/feedback; the feedback carries route, screen, resource references, source language, severity or rating, and release version — covered.
The user-facing support list, detail, and reply read GET /support/conversations and GET /support/conversations/{conversationId} and write through POST /support/conversations, PATCH /support/conversations/{conversationId}, and POST /support/conversations/{conversationId}/messages; user reads exclude internal notes and staff routing state. The founder beta dashboard reads GET /admin/beta and exports through GET /admin/beta/export; it includes funnel, interest-reservation, Phase A.5 pre-order, designer and listing-owner, support, feedback, reliability, and product-learning metrics. The founder demand review reads GET /admin/interest-reservations and writes invitations through POST /interest-reservations/{reservationId}/invite-preorder in Phase A.5; the invite action is gated by buyer fresh-consent flow, listing-owner terms, moderation and intellectual-property checks, regulatory and product gates, and pricing gates. The founder support queue reads GET /admin/support/conversations and the detail endpoint, with PATCH and message endpoints; staff actions are audited and the first-response state is visible. The founder incidents and alerts read GET /admin/reliability/incidents and GET /admin/alert-rules; the UI shows owner, severity, state, impact, and first action or runbook summary, and alert changes go through the admin and operations workflow.
The static 404 fallback may optionally pull chrome from GET /app-shell and otherwise routes back to home or gallery — covered, no dedicated backend required.
The canonical API includes every endpoint and schema the routed surfaces above call. The buyer-side endpoints include the dashboard aggregate at GET /me/dashboard for the home resume cards, dashboard overview, saved kits, following designers, and credit summary; the builds-in-progress draft list at GET /design-drafts; the designer discovery rail at GET /designers; the related-or-similar kits at GET /listings/{listingId}/related; the public listing reviews at GET /listings/{listingId}/reviews together with buyer review creation where eligible; and the account-level card setup outside checkout at POST /account/payment-references/setup-intent. The designer-side endpoints include the owner designer profile read and edit at GET and PATCH /designer/profile, the listing duplicate at POST /designer/listings/{listingId}/duplicate, and the artefact-pack download at POST /designer/listings/{listingId}/artifact-pack/download. The cross-surface AI text assistance runs through POST /assist/text-jobs. The multilingual user-generated-content surface is owned by the backend through GET /config/translations, together with the localised-text and localised-field-map types and the text-translation job type. Product analytics ingestion runs through GET /config/product-events and POST /analytics/events. The help feedback and bookmark endpoints live at /help/articles/{slug}/feedback and /help/articles/{slug}/bookmark. The user-facing support list, detail, and reply, plus the admin support queue, live at the /support/conversations* and /admin/support/conversations* paths. Structured beta feedback posts to POST /beta/feedback. The founder beta dashboard, export, and operational incident and alert views live at /admin/beta, /admin/beta/export, /admin/reliability/incidents, and /admin/alert-rules. Phase A interest reservations live at POST /listings/{listingId}/interest, GET /me/interest-reservations, GET /interest-reservations/{reservationId}, and DELETE /interest-reservations/{reservationId}. The founder demand review and Phase A.5 conversion invitation live at GET /admin/interest-reservations and POST /interest-reservations/{reservationId}/invite-preorder.
The frontend obeys a small set of cross-cutting rules that the audit relies on. Search scopes come from the backend-supplied enabled-scope list rather than a hard-coded array. The Journal navigation item stays hidden or disabled until the app-shell navigation returns a real target. The paid credit top-up controls stay hidden until a billing or top-up product exists. Non-binding interest-reservation wording is used in Phase A listing and dashboard surfaces — Phase A demand is never called an order, pre-order, purchase, or commitment — and no-capture pre-order wording appears only in Phase A.5 invitation, checkout, and dashboard surfaces. Phase B order fulfilment, shipments, returns, receipts, invoices, build companion, and payout release are visible only behind feature gates. The user's locale, the Accept-Language header, and any source-language hints travel through the API client; the app never calls language-model translation providers directly. Translation fallback and translation status render consistently for owner and admin surfaces, and the frontend never claims that source fallback is a completed translation. Analytics and beta feedback from routed pages are wired through the API client with event-dictionary validation. The routed mock pages are wired to backend loaders and actions before beta, because the static mock arrays are design evidence rather than runtime contract. Any UI implication that DomiDo owns or authors user-created designs is removed or gated, replaced by user and listing-owner attribution and the limited platform licence copy.
The traceability set holds the following invariants. Every routed UI surface has an entry on this page. Every visible data element has a named read contract or an allowed client-only or static classification. Every actionable element has a named mutation, external-link, client-only, or phase-gate classification. Every API contract named on this page exists in the canonical specification. Every future-phase action that remains visible is controlled by a feature phase gate. Every free-text UI field that can be shown to other users has either a localised-text or localised-field-map read contract or an explicit exclusion. Every user-triggered mutation with retry, payment, job, upload, publish, analytics-ingestion, beta-feedback, support, or admin side effects has an idempotency and error contract and never relies on opaque generic JSON. A frontend implementer can build API clients from this document without guessing backend ownership, public-or-private auth state, rate-limit behaviour, or safe retry behaviour.