This page is the catalogue of conditions that every feature must satisfy before it ships. The conditions originated as Given–When–Then statements and they remain ready to be turned into test cases and review checks, but here they are folded into the topic sections so a reviewer can read each surface as a single explanation rather than as a list of disconnected scenarios. The criteria reject the things the product has explicitly chosen against: unsupported payment options, unphased pre-order or no-charge checkout semantics, fixed AI costs, fixed moderation or ad costs, fixed locale, currency, and jurisdiction lists, fixed payout numbers, fixed post-checkout wait claims, guaranteed fulfilment before Phase B, real payout release before Phase B delivery eligibility, and specific Workshop or Help article facts. Where a behaviour is conditioned on a delivery phase, the phase is named explicitly so that an off-by-one phase assumption — Phase A behaviour expected of Phase A.5, or Phase B behaviour expected of Phase A.5 — is immediately visible.
Every feature that appears in the app must identify its delivery state in its API, copy, actions, and acceptance criteria — Phase A active, Phase A conditional, Phase A.5 active, Phase B active, Phase C expansion, native-deferred, or blocked or read-only. When Phase A open beta is active, the app supports discovery, create and publish, user-owned public listings, non-binding interest reservations, reservation cancellation, dashboard visibility, analytics, support, moderation and reporting, and legal and trust copy — and it does so without collecting a card, creating a Stripe object, creating a pre-order, creating a charged order or invoice, creating a shipment or ship-date promise, or releasing a payout. When Phase A.5 is active before real fulfilment, selected interest reservations can be invited into fresh-consent Stripe SetupIntent no-capture pre-orders, and the designer-acquisition surfaces become available: public designer profiles, listing management, Promo Studio, marketplace discovery, reviews, Q&A, and messages, Stripe Connect and KYC, payout settings, projected royalties, reserve and dispute modelling, statement previews, and payout readiness all open ahead of Phase B order capture. When Phase B is not active, every fulfilment, shipment, receipt, invoice, return, replacement, build-companion, PaymentIntent capture, or payout-release surface is disabled, read-only, waitlisted, or represented as a future-phase preview rather than as live behaviour. Web desktop is the mandatory Phase A beta validation target; Web mobile, iOS, and Android are compatibility or future-gate targets and do not block Phase A acceptance.
When the app shell renders, the header shows language choices returned by backend configuration and does not hard-code mock language labels as product truth, and the footer makes configured locale, currency, social, legal, Manage cookies, newsletter, sitemap, and data-request controls reachable. The authentication modal offers OAuth options that are exactly Google, Apple, and Facebook — nothing else — and a successful OAuth flow associates the user profile, drafts, saved listings, interest reservations, Phase A.5 pre-orders, Phase B orders, designer dashboard pointers, and authorised admin-content capability with the signed-in account.
Configuration endpoints carry the product knobs that mock copy must not pretend to know. A jurisdiction-configuration request returns supported and unsupported state, the coming-soon message, VAT behaviour, delivery availability, and Stripe supported-card copy. An AI-generation-cost configuration request returns projection, model, block-kit, Promo Studio photo, and Promo Studio video generation costs as configurable values rather than hard-coded constants. A payout-configuration request returns the minimum payout, payout request fee, below-minimum payout fee, eligibility delay, and labels as configurable values. A create-style-preset configuration request returns label, palette, descriptor, seed prompt, swatches, thumbnail or reference media, enabled state, display order, and config version for each preset. A Promo Studio configuration request returns environment presets, style presets, lens choices, duration and aspect choices, credit and cost labels, top-up availability, and custom environment upload availability — again as configurable values. A feature-phase configuration request returns delivery phase gates identifying active, conditional, preview, deferred, and blocked capabilities so the frontend does not infer operational readiness from mock visibility. A translation-configuration request returns supported content languages, default language, fallback order, translation availability, glossary version, and async translation policy from backend configuration rather than from the mock.
When a user saves translatable free-form text, the source text, source language, field and resource context, author role, visibility, and translation status are stored immediately, and translation jobs are queued asynchronously for every configured supported language except the source language. When a requested-language translation is complete, API read responses return the translated display string for that locale; when it is pending or failed, the response falls back to the configured fallback language or source text without breaking the UI. Structured or sensitive fields — names, emails, phone, address, payment or security data, file names, identifiers, VAT or tax fields, OAuth profile data, credentials — never trigger an LLM translation job. When source text changes after translations exist, the previous translations are marked stale and new translation jobs are queued. When a translation provider fails, the source mutation remains successful, a safe translation failure state is stored, retry can be attempted, and no raw provider prompt or secret appears in API responses or logs. When private, support, or message content is translated, authorisation and moderation rules remain identical for translated and source variants, and translated private content is not exposed through public search.
The model and source upload contract is precise. When the format is GLB, GLTF, OBJ, or STL and the size is at or below 100 megabytes, the upload can be accepted. Any unsupported format is rejected with a format validation message, and an upload above 100 megabytes shows a size validation error and is never attached to the draft. When the user opens the create wizard and a saved draft or generation state exists, the wizard offers or resumes that draft before starting a blank draft, and the new create flow exposes Describe, Projections, 3D model, Block kit, and Save-and-publish stages.
The Describe stage persists title and brief, reference text, uploaded media, crop state, category, selected tags, and suggested tags on the draft. When a style preset is applied in Describe, the prompt is updated with the preset descriptor or seed prompt, the reference image is set, and the preset reference is stored without hard-coding the preset list. The Projections stage opens with front, back, right, left, top, and bottom face slots and marks only front as compulsory — attempting to proceed without a front projection blocks progression to model generation or publish, while optional missing faces do not block valid drafts. When a projection face is generated, the draft stores source asset, generated preview, active face, history entry, status, optionality, and zoom state, and when the user restores a projection history entry, the active face returns to that historical generated asset and remains in the history list.
When any projection, model, or block-kit generation job starts, the API returns 202 with a Job containing type, status, progress, current step, configured cost metadata, retry and cancel eligibility, and polling guidance. In the 3D model stage, configured generation options are available and each completed tryout has status, preview, stats, output size label, and a GLB or GLTF-compatible output reference; when the user submits model quality feedback, the rating, issue categories, optional comment, usability decision, and tryout reference are stored. The Block kit stage shows the configured generation cost before generation, and when generation completes the BOM groups, SKU count, part count, estimated cost, estimated build time, assembly steps, and search and filter metadata are available; job progress includes user-safe stages for model validation, voxelisation, blockification, BOM and cost calculation, assembly and export generation, and artifact persistence. When a generation job fails, is cancelled, or is retried, the previous successful projection, model, or block-kit state remains available, safe error and retry state is returned, and stale job results cannot overwrite newer draft state.
When the publish settings open, the visibility options are private, unlisted, and public. The allowed royalty range is 0–25 and zero royalty supports community-gift copy where shown. Remix controls in Phase A are disabled and the user is notified that remixes are disabled in Phase A. Saving a draft keeps it resumable without publishing, and publishing a valid draft creates a listing with media, designer, price, visibility, disabled-remix state, tags, kit summary, and assembly summary.
When the home or gallery rail renders, listing cards can show image, title, designer, price, saved state, tags and badges, and live listing metadata. Search from the header returns results carrying configured scope metadata, scope counts, result type, title, snippet or summary, thumbnail, avatar or swatch metadata, target reference, and the listing, designer, or help-specific metadata sufficient for the search modal. When no active search query exists, local recent searches can be shown and cleared without backend persistence. When a listing detail opens, it shows product media, title, designer identity, price, save and share actions, kit and assembly details, and an add-to-cart action where the phase supports it. When a product-detail variant is served, the response identifies its source surface so variant-specific copy is not merged into another surface by accident. When a signed-in user saves or unsaves a listing, the card and detail view update saved state consistently.
In Phase A, a signed-in user expressing interest in a public listing creates or refreshes an interest reservation with listing, owner, source, acknowledgement version, indicative price or price-unavailable snapshot, jurisdiction intent, status, and dashboard visibility. The Phase A interest sheet states that the action is non-binding, collects no card, creates no Stripe object, creates no pre-order or order, raises no invoice or receipt, promises no shipment, and can be cancelled where state permits. Repeating the interest action for the same listing returns or refreshes the existing active reservation. Cancelling an active interest reservation transitions it to cancelled, keeps it auditable, removes it from active demand counters, and never creates a payment, order, or fulfilment record.
When Phase A.5 or Phase B checkout is active and a listing is added to cart, cart state includes item, quantity, thumbnail, title, designer or listing owner, kit summary, line total, and order summary totals. Phase A never starts checkout from an interest reservation, while Phase A.5 and Phase B checkout exposes Bag, Delivery, Payment, Review, and Confirmation surfaces. When delivery is edited, saved address, manual address, jurisdiction, delivery method, collection point where required, and delivery price are validated, and an unsupported jurisdiction blocks payment with coming-soon copy and prevents Stripe progression. In Phase A interest flow, unsupported jurisdiction is stored only as non-convertible or coming-soon demand where allowed. In Phase A.5 payment, saved Stripe card references and Stripe-handled new-card verification are available through SetupIntent without capture for invited eligible reservations only; in Phase B, Stripe-handled payment capture may be available. Payment copy contains only the card types Stripe supports in the selected jurisdiction.
When checkout reaches Review in Phase A.5, it shows jurisdiction-dependent VAT, delivery, subtotal, expected charge total, Stripe card verification readiness, explicit no-capture acknowledgement, source interest reservation, and no promised ship date or post-checkout wait-time metric. Confirming a Phase A.5 checkout creates a no-capture pre-order from an invited eligible interest reservation and Stripe SetupIntent verification, and the confirmation shows pre-order reference, no-capture status, cancellation path, dashboard link, and gate versions — no receipt, invoice, shipment, capture, payout, or order fulfilment readiness is created. Confirming a Phase B checkout after the active gates pass creates a charged order from Stripe payment completion, and the confirmation may show order reference, receipt, invoice, fulfilment readiness, and a link to order details. When a buyer saves a bag for later, a saved cart or checkout draft is created with item summary, selected checkout step, jurisdiction, VAT and delivery context, resume action, discard action, and stale validation if the cart changes before resume. Every checkout delivery, payment, promo, review, or confirmation submission uses the typed schema for that step and returns validation messages tied to fields rather than accepting an opaque free-form payload.
The buyer dashboard responds to phase. In Phase A, current interest reservations show status, item summary, listing owner, non-binding state, cancellation availability, and Phase A.5 conversion-invite state; in Phase A.5, no-capture pre-orders additionally show card verification state, no-capture state, cancellation availability, and Phase B conversion readiness; in Phase B, current and past orders additionally show payment, delivery, fulfilment readiness, and order-detail entry. The detail sheets follow the same staging. A Phase A interest reservation detail shows listing, listing owner, indicative price or price-unavailable state, non-binding acknowledgement, cancellation state, attribution, and conversion-invite timeline without SetupIntent verification, receipt, invoice, shipment, promised ship date, or captured charge. A Phase A.5 pre-order detail shows expected totals, SetupIntent verification, no-capture acknowledgement, cancellation state, attribution, gate versions, and timeline without receipt, invoice, shipment, promised ship date, captured charge, or payout release. A Phase B order detail makes payment, charge, jurisdictional VAT, refund, receipt, invoice, delivery, fulfilment readiness, and timeline information available.
Fulfilment behaviour follows the same gates. When Phase B fulfilment gates are active and an order is ready after payment capture, it can enter fulfilment; when required blocks are absent from storage, the order status informs the user to wait for block availability; when Phase A or A.5 production readiness prevents fulfilment, the interest reservation, pre-order, or future-phase order preview shows no promised ship date and records that email notification may be sent when a later pre-order or Phase B fulfilment path is ready. Payment retry runs through Stripe and records the attempt without exposing raw card data. Address change, delivery preference, return, replacement, dispute, or support-contact submissions record the order action with status and user-facing result. When a return is assessed, damage, wear signs, change of mind, and diminished value can each produce a return fee or deduction with a user-facing explanation. When a user is blacklisted or restricted for anti-abuse or customer-extremism reasons, the restriction is recorded, audited, and challengeable through support or dispute processing.
When the buyer dashboard shows order update notifications, unread and read state, severity, linked order or action target, mark-read, and mark-all-read behaviour are available without changing the underlying order state. Order tracking detail renders shipments, parcels, parcel-item grouping, safe tracking display, tracking stops, ETA deltas, and user-facing tracking messages from order data rather than from fixed mock values. When a buyer submits a payment retry, delivery preference, return, replacement, report-issue, dispute, or order message action, the request is typed, eligibility and validation are enforced, attachments are referenced safely, and the response updates order status and timeline idempotently. When Phase B is active and an order has assembly steps, the build companion opens from QR or active-order entry with step payloads, progress, stuck-help, and support escalation; progress saves and resumes after the tab closes; and the finished build can store finished-build photos, profile and designer feedback permission, and a separate build-experience rating.
When the designer listing editor opens, title, description, category, tags, media, BOM and assembly, visibility, status, royalty, disabled-remix state, price, and publish and update controls are available. Royalty values below 0 or above 25 are rejected, and listed price recalculates for valid values. Royalty values display their VAT-inclusion according to the money data, and ad boost respects configured bounds with spend representable in payout or statement context. When the designer dashboard opens in Phase A.5, attributed pre-orders, projected royalties, payout readiness, Stripe Connect and KYC state, statement previews, messages, disabled-remix items, and action queue are available; when Phase B has captured eligible orders, captured sales, payout due, fees, statement archive, and export are available. The listing editor aggregate returns owner edit state, unsaved and versioned save state, editable versus platform-owned sections, moderation flags, similarity matches, analytics, buyer preview, and action context, and when moderation rerun is requested, configured cost and eligibility apply rather than a fixed credit value.
Payout settings in Phase A.5 expose Stripe Connect state, KYC state, configurable payout options, payout request fee, below-minimum payout rule, VAT number, UTR, tax region, and readiness or blocking labels before real fulfilment. A payout-on-request submitted before Phase B captured delivery-eligible funds exist is blocked with a readiness reason; once Phase B eligibility exists, the configured fee applies, defaulting to 2% when no other configuration is in place. A below-minimum payout request follows the same gate, again with a 2% default fee. A Phase A.5 attributed pre-order creates a projected royalty event with no money-movement eligibility; a Phase B captured order's earliest payout eligibility is no earlier than 30 days after delivery. Any Phase A remix split proposal or action that exists in legacy or mock state is non-actionable and explains that remixes are disabled in Phase A.
Promo Studio acceptance covers a long surface. When a listing owner opens the designer listing Hero section, the Promo Studio launch control is available, and a non-owner or public user attempting to start Promo Studio is rejected by authorisation. Promo Studio opens with Stage, Photos, Video, and Library steps, step counts, credit and cost summary from configuration, listing name, close-and-Escape behaviour, and back, next, and done controls. The Stage persists environment, optional custom HDRI or reference environment, lens, horizon and sun state, object placement, scale, rotation, yaw, camera rig state, source model, footprint metadata, and reset state. Photo generation records scene snapshot, prompt, style, cost config version, progress, result asset IDs, and failure and retry state; a generated photo result can be kept and starred, animated as a video source, downloaded, and added to listing gallery where authorised. Opening Promo Studio Video without generated photos explains that a generated photo is required first and blocks video generation; otherwise, video generation records source photo, motion prompt, duration, aspect ratio, cost config version, progress, result asset IDs, and failure and retry state. The Library exposes All, Photos, Video, and Starred filters, counts, empty states, per-asset actions, and download-all where authorised — a download-all request includes only authorised selected or filtered private assets and returns an authorised download reference. When a Promo Studio asset is added to listing gallery, public listing media updates and the asset's gallery-publication state transitions from private-and-generated to listed-and-published.
Designer earnings reflect phase. In Phase A.5, projected, pending-readiness, and blocked-release balances are shown with configuration-derived explanations; in Phase B, available, pending, in-transit, and reserved balances are shown. When a sale is disputed, sale status, dispute reason and state, reserve impact, handling status, and royalty and statement impact are viewable by the owning designer and authorised roles. Phase A.5 payout history may show payout-readiness previews without money movement; Phase B payout transfers show status, masked method display, amount, included royalty expansion, and failed-payout remediation when available. The reserve ledger displays hold and release entries with kind, amount, reason, linked sale or dispute, status, and config version. Payout schedule settings display and update cadence labels, anchor and minimum, auto-payout pause and resume availability, payout-on-request state, and notification preferences according to permissions. Tax-statement export uses configured tax period and format options and does not expose full tax identifiers to unauthorised users.
When a designer replies to a review, draft, assistive draft, polish or shorten where configured, post, update, delete where allowed, and moderation and report state are preserved. When a designer answers a listing question, the answer can be drafted, posted or updated, shown with designer or verified context, and optionally converted into an FAQ candidate without mutating admin-managed Help content. When a designer handles a message thread or claim, unread, pinned, priority, and status state, threaded reply, internal note, report, approve-replacement, refund-instead, request-photos, and escalate actions use typed state and preserve linked order, support, and dispute references.
Account settings expose profile, avatar, addresses, saved Stripe payment references, privacy, security, notification, trust-restriction visibility, data export, pause-and-delete request state, and payout-and-tax settings according to role. A saved payment reference shows only masked Stripe card and provider display data. Help and Workshop content lives behind Docusaurus publication: opening Help or Workshop allows article search, browse-by-topic navigation, article-reader use, and support entry, and no acceptance criterion depends on a specific article slug, body, shipping window, material statistic, designer application statistic, or story fact — Docusaurus is verified as the publication and rendering layer rather than as content truth.
When an admin creates, edits, publishes, unpublishes, archives, deletes, or reorders Workshop or Help content, the action succeeds only for an authorised admin, is audited, and updates the Docusaurus public projection where publication is requested. A non-admin attempting to modify Workshop or Help content is rejected by authorisation. Article comments work as ordinary user-generated discussion data: a user can submit a non-empty comment or reply, like a comment, sort discussion, and report a comment where reporting is enabled, but submitting a Help comment, reply, like, or report never grants permission to create, update, publish, unpublish, archive, delete, reorder, or trigger Docusaurus publication. A Docusaurus publication or export triggered from admin content management records included content versions, status, actor, timestamp, and failure summary.
Support follows the same role boundary. A user starting or replying to a support conversation creates a conversation that stores subject, message, source language, related resource context, translation state, status, and unread and last-response state visible to the user. Staff opening the support queue can filter by status, priority, assignee, escalation, overdue first response, category, and related resource, reply to the user, add an internal note, and update status, assignment, and priority without exposing another user's private data. On the privacy surface, Manage cookies lets the user view, save, and later change cookie preferences, and the footer keeps privacy, terms, accessibility, sitemap, and data-request links reachable.
Audit and observability span the entire app. A security-sensitive, payment, pre-order, payout-readiness, payout-release, reserve, dispute, publish, order, upload, generation, Promo Studio, model feedback, return-assessment, trust-restriction, support-administration, operational-configuration, alert-rule, incident, or help-content action records an audit event with actor, resource, action, result, source surface, timestamp, and request ID — and that event never stores raw card data, OAuth secrets, payout account secrets, or unnecessary full tax identifiers. A product-event configuration request returns event dictionary version, allowed event names, property schema hints, consent classes, retention classes, and sampling guidance. A valid analytics event batch posted to /analytics/events returns an ingestion receipt with accepted and rejected counts; unknown event names, oversized properties, or disallowed consent class come back with rejected indexes and safe reasons without blocking the user workflow. The founder and admin beta dashboard returns activation, conversion, pre-order, designer, support, reliability, feedback, and product-learning metrics from backend APIs. Beta feedback submission stores feedback type, rating or severity, surface, route and screen context, related resource refs, source language, translation state, optional attachments, release version, and triage status. Alert rules expose severity, owner, trigger, current state, last trigger and resolution, user-impact summary, and runbook or action summary when critical operational conditions occur. A client error, backend error, worker failure, provider failure, support conversation, and relevant audit event referring to the same customer-visible problem are connected by a safe correlation and request id without exposing secrets or raw provider payloads. Logs, analytics events, support content, beta feedback, and audit events each carry their own retention, access, redaction, export, and deletion behaviour.
When the interface specification and the OpenAPI file are compared, every REST path in one appears in the other, and parsing the OpenAPI file resolves all local references. When an endpoint supports analytics events, beta feedback, support conversations or messages, the founder beta dashboard, alert rules, reliability incidents, saved carts, checkout step mutation, pre-orders, order notification items, order tracking, order actions, designer review, Q&A, message, or claim workflows, Help comments, projection, model, or block-kit job starts, Promo Studio job starts, or job retry and cancel controls, its OpenAPI request and response schemas are named product-domain schemas rather than generic object payloads. The OpenAPI Job schema exposes public status, progress, current step, steps, resource ref, result ref, artifacts, cost and config metadata, retry and cancel eligibility, safe error state, timestamps, and polling guidance without exposing worker lease internals or raw provider payloads. The OpenAPI security contract makes public endpoints explicitly allow unauthenticated access, requires authentication on private endpoints, supports standard error envelopes on mutating endpoints, and accepts Idempotency-Key on idempotent operations. Any endpoint that is rate-limited, payload-limited, unauthorised, forbidden, phase-blocked, or idempotency-conflicted responds with a typed error envelope carrying request id, safe message, retryability, and retry guidance.
The Stripe webhook contract is precise. A valid Stripe event posted to /stripe/webhook is signature-verified, its event id is stored before any business mutation, and duplicate delivery returns success without duplicating payment, pre-order, order, or payout state. A missing, invalid, stale, malformed, or duplicate signature or event payload returns the configured safe result and never exposes raw provider payloads or secrets.
An unauthenticated user calling a private endpoint receives a 401 without mutation. An authenticated user calling a resource owned by another user or a role-restricted endpoint receives a 403 or a phase- or resource-specific safe error without leaking private data. Replaying an idempotent mutation with the same Idempotency-Key and request hash returns the stored response or current resource state without duplicate jobs, provider calls, commitments, or records; replaying with the same key and a different request hash returns a 409 idempotency conflict and does not mutate state. Exceeding the configured search, upload, checkout, analytics, beta feedback, job-start, LLM, Help and support, or admin publication limits returns 429 with retry guidance and does not allocate downstream worker or provider work. A Web/PWA unsafe cookie-authenticated request lacking valid CSRF state is rejected before mutation.
An upload with a spoofed extension, unsafe filename, unsupported format, excessive size, failed scan, or invalid signature is rejected before preview, generation, public listing, or worker processing. Block-kit, model, Promo Studio, AI assist, or translation job parameters that exceed configured concurrency, voxel, batch, duration, prompt, timeout, or budget limits are rejected or safely rate-limited at job creation without corrupting existing draft, listing, or source state. The operational probes are predictable: /livez reports process health only, /readyz reports whether app traffic is safe, and /health returns sanitised dependency status without secrets, private URLs, raw provider payloads, internal hostnames, or connection strings.
The MongoDB failure envelope is deterministic. When MongoDB experiences temporary failover, transient transaction errors, write conflicts, duplicate-key races, commit uncertainty, connection-pool exhaustion, or timeout, critical mutations either complete once, replay through idempotency, reconcile safely, or return a typed retryable or service-unavailable error — without duplicate provider calls or corrupted domain state. When Stripe is unavailable during Phase A.5 SetupIntent, checkout confirmation, Connect onboarding, payout readiness sync, payment retry, or Phase B capture, the affected operation preserves interest reservation, cart, pre-order, order, and designer state, returns a safe retry or degraded status, and is recoverable through idempotency or reconciliation. A valid duplicate Stripe webhook returns success without duplicate mutation; a valid webhook that cannot be durably stored or enqueued returns a retryable failure so Stripe can redeliver.
The worker and provider envelopes are equally explicit. When a worker crashes, drains, loses its lease, or restarts during model, voxelisation, Promo Studio, translation, publication, notification, or future fulfilment work, the job recovers through lease expiry, retry, dead-letter, or manual repair without publishing partial artifacts or overwriting newer source state. When an AI or LLM provider is slow, rate-limited, disabled, or in extended outage, only the affected capability is unavailable or failed-and-retryable; source text, drafts, listings, carts, checkout, and public browsing remain usable where their own dependencies are healthy. When object storage is unavailable, an upload is interrupted, an object is written but DB commit fails, a DB media record points at a missing object, or a signed action expires, the API returns a safe retry or degraded state and repair, cleanup, or regeneration rules prevent public broken or private-by-accident assets. When Atlas Search or Vector Search is unavailable, public discovery degrades to configured fallback search, curated listing cards, or a typed degraded empty state; private drafts, private media, and inactive future-phase states are not leaked. When audit persistence fails during interest reservation, payment verification, pre-order, payout readiness or release, admin content mutation, privacy, trust, security, or provider-webhook mutation, the operation fails closed and records an observable operational failure where possible; analytics or telemetry dispatch failure does not block user workflows. Before open beta, Phase A staging readiness rehearses MongoDB restore, object and media consistency, interest reservation records, audit records, localised text variants, pending and dead-lettered jobs, and configuration according to documented recovery-point and recovery-time objectives — and Phase A.5 readiness adds checkout, pre-order, and webhook records.
A scan of the requirements turns up no unsupported payment-method requirements, no unphased pre-order or no-charge checkout semantics as product truth, no direct charge in Phase A, no fulfilment or payout release before Phase B eligibility, no obsolete upload-size limit, no fixed AI generation cost, no fixed moderation or ad cost, no fixed locale, currency, or jurisdiction list, no fixed Promo Studio generation cost, no post-checkout wait queue, no fixed per-block royalty copy, no fixed payout, reserve, or dispute demo values as product truth, and no specific Workshop or Help content-body requirements. Docusaurus is named only as the chosen public static Help and Workshop publication layer. Where mock copy conflicts with product decisions, the requirement set preserves the UI workflow only after documenting the override for Phase A interest reservations, Phase A.5 no-capture pre-order and payment plus designer acquisition and payout readiness, Phase B real orders, fulfilment, and payout release, VAT and delivery, saved cart, order tracking and action, designer engagement, and Help comment surfaces. The requirements and architecture together identify React Native and Expo with React Native Web as the universal app target, Web desktop as the current mandatory validation target, native iOS and Android release as deferred, and platform adapters as mandatory for platform-sensitive behaviour. The repository ignore rules keep the authoritative architecture, requirements, and delivery documents visible to git rather than hidden by broad ignore rules.