Festival Stall — journey map & implementation readiness

The single visual source of truth for what is designed, what is implementation-ready, what still needs design, and what has an architecture dependency. Assessed 2026-08-11 by reading the design project, the repo and the database migrations directly — never inferred from a status page.

Re-assessed 2026-08-12, end to end through vendor step 11 plus the consumer journey — same method, all three axes re-read. The category counts did not move; several cells did, and the two biggest changes are invisible in any count: the backend closed four design-assumed gaps in one day (collect_on · is_unique · advance_pct/advance_terms · industry-grain item attributes), and the design project grew a whole order-handover proof loop (ScanCollect · OrderCode · ScanVerify + order-qr.js/qr-verify.js) that no backend document knew about. See "Implementation-readiness classification" below and QRS-574..579.

Setu Card TEMPLATE exploration is deliberately excluded from this assessment (owner decision, 2026-08-11). The Setu Card framework is in scope and assessed; the six festival template directions are a parallel track and are not allowed to gate anything here.

Why this page exists

Design has run well ahead of implementation, and the gap was not measurable from any single artifact. The design project's own READINESS list (in prototype/mobile-console/vendor-core.js) reports what is unfinished on the design side. It cannot see the repo. This page joins that to the two axes it does not know about — client code and backend contract — so a screen is only ever called "done" when all three are true.

How to read a status

A screen has three independent axes, and conflating them is what produced the July merchant slice (four screens "built" against stubs, backend integration still open a month later).

Axis	Question	Source of truth
Design	Does an approved screen exist in the Claude Design prototype project?	633dc069-6df8-4408-b625-068907c60c33, SCREENS.md
Client	Does a real screen exist in apps/mobile or apps/web?	src/tiers/*/features/*, route files
Backend	Can it actually read and write? A real RPC for reads, a real Edge Function for writes	supabase/migrations/, supabase/functions/, packages/data/src/index.ts

The status vocabulary

• 🟢 BUILT — all three axes real.
• 🔵 IMPL-READY — design complete and the backend contract exists. Client work only. This is the queue.
• 🟡 PARTIAL — client exists, but one axis is materially missing, so what it shows is not the product.
• 🟠 BACKEND-BLOCKED — design complete, but there is no read or write contract to build against.
• 🔴 NO DESIGN — nothing designed. Cannot enter implementation.
• ⚫ DARK BY DESIGN — deliberately switched off, not incomplete.

⚠ "Design-complete" alone is NOT a licence to implement. A screen is only implementation-ready when it is 🔵 or 🟢. The distinction is the whole point of this page: 11 of the 15 unfinished vendor steps are blocked on a missing RPC or Edge Function, not on a missing design. Reminders was the twelfth until 2026-08-11, when its backend was built (QRS-564); it is now the mirror case — working client and contract, no design.

The headline numbers

	Vendor journey	Consumer journey
Steps / screens in scope	19	8
🟢 Built end to end	4	0
🔵 Implementation-ready now	2	0
🟡 Partial	5	0
🟠 Backend-blocked	7	7
🔴 No design	0	0
⚫ Dark by design	1	0
Client code exists at all	8 of 19	0 of 8 — the tier does not exist

Design is not the bottleneck. The backend contract is. Of 19 vendor steps, 18 are designed. Only 7 have a working read contract and only 5 have a working write contract.

The relationship: Vendor → Store → Setu Card → Consumer → Marketplace

Read the chain left to right and the break is obvious. Everything from the vendor writing an item to a buyer browsing it on a real public card works today. The chain breaks the moment the buyer tries to transact: order has no contract, payment is deliberately dark, chat can be read but not sent, and the consumer app that closes the loop back into discovery has no tier in the codebase.

The loop is not closed, and that is the single most important fact on this page

QRSETU's growth mechanic is card → buyer → account → marketplace → more cards. Today the arrow from buyer to consumer app does not exist in code, so every buyer who scans a card is a terminal leaf. The vendor gets value; the platform gets none of the network effect it is designed around.

Vendor journey — 20 steps

The step list is not invented here. It is the JOURNEY array in the design project's prototype/mobile-console/vendor-core.js, filtered by the festival stall's own feature keys — the same array that generates prototype/vendor-journeys/ganapati.dc.html. bookings is the one entry of the 21 that drops out, because a stall sells objects, not slots. So "Point 2" is Business profile and "Point 3" is the Setu Card, matching the earlier review rounds.

⚠ This section still describes the 19-step shape and the step numbers from 12 onward have SHIFTED by one. Round 18 inserted Payments at step 12 (and retired Invoices), so chat is 13, notifications 14, reminders 15, QR tools 16, settings 17, banking 18, plan 19 and analytics 20. The authoritative, current per-step verdicts are in the classification table below; read the matrix in this section for the axis detail and the numbering from that table.

The matrix

RPC = a real read contract. EF = a real write contract. stub = packages/data still exports the stub implementation, so the screen renders illustrative data.

#	Step	Design	Client	Backend	Status
01	Onboarding	✅ Onboarding.dc.html	✅ features/onboarding	✅ get_industries · is_slug_reserved · provision-workspace EF	🟢 BUILT
02	Business profile	✅ Profile.dc.html, 4 tabs	✅ features/profile	⚠ profileService stub · write EF exists · no read RPC	🟡 PARTIAL
03	Setu Card, public	✅ SetuCard.dc.html	✅ apps/web route + renderer + 7 blocks	✅ get_public_setu_card · get_public_catalogue	🟢 BUILT
04	Card editor	✅ CardEditor.dc.html	❌ none	⚠ manage-setu-card EF exists · no read RPC	🟠 BLOCKED
05	Catalogue	✅ Catalogue.dc.html	✅ features/catalog	✅ get_my_catalogue RPC · manage-item EF	🟢 BUILT
06	Add an item	✅ sheet inside Catalogue	✅ CatalogItemComposer	✅ manage-item EF	🟢 BUILT
07	Inventory	✅ inside Catalogue	⚠ partial	✅ store.stock feature · catalog_items	🟡 PARTIAL
08	Dashboard	✅ Home.dc.html, widget registry	✅ features/dashboard	❌ dashboardService stub · no summary RPC · no rollup table	🟠 BLOCKED
09	Orders	✅ via Collections	❌ none	⚠ tables + RLS + collect_on + pro/enterprise grants + @qrsetu/domain orders/status.ts · no RPC, no EF (QRS-579)	🟠 BLOCKED
10	Collections	✅ Collections.dc.html + ScanCollect.dc.html	❌ none	⚠ same as 09 · handover proof loop additionally needs QRS-574	🟠 BLOCKED
11	Order detail	✅ OrderDetail.dc.html — day strip · record-a-payment (cash/UPI) · cancel with refund decision	❌ none	⚠ same as 09 · counter payments expressible (payments.provider in cash/upi_manual)	🟠 BLOCKED
12	Payments and invoices	⚠ Invoices.dc.html, stale figures	❌ none	⚠ tables exist · availability DENY by design	⚫ DARK
13	Chat	✅ Messages + Thread + shared chat-core.js	❌ route placeholder, 25 lines	⚠ reads ready — incl. states/labels/quick replies/away/blocks/reports/realtime and per-thread order context · send EF missing (QRS-432/444) · no data service	🟡 PARTIAL
14	Notifications	✅ Notifications.dc.html	✅ features/notifications	⚠ no table needed — the design derives from orders + chat records; blocked by the same missing orders read (QRS-579)	🟠 BLOCKED
15	Reminders	⚪ ships without one — owner decision 2026-08-12	✅ features/reminders	✅ built + verified + DEPLOYED to Dev 2026-08-12 (CR-26.0.1-29 pushed all 13 pending migrations)	🟡 PARTIAL
16	QR tools	✅ QRTools.dc.html	❌ none	✅ none needed, client-side generation	🔵 IMPL-READY
17	Settings	✅ Settings.dc.html	✅ features/settings	⚠ settingsService + accountService stub · manage-account EF exists	🟡 PARTIAL
18	Banking and payouts	✅ Banking.dc.html, 5 states	❌ none	❌ no payout_accounts · no provider integration	🟠 BLOCKED
19	Plan and billing	✅ PlanBilling.dc.html	❌ none	✅ get_platform_plans · resolve_workspace_plan	🔵 IMPL-READY

Step 15 was inverted — and the inversion CLOSED on 2026-08-12

When first assessed, reminders had working client code, no design, and no backend at all — the one step where the usual order ran backwards (QRS-564). The backend half is now built, verified and deployed to Dev: 3 tables, 2 read RPCs, the manage-reminder EF, the features registry row and a platform entitlement grant (CR-26.0.1-27/28, deployed by CR-26.0.1-29 one commit after this page was first written). What remains inverted is the design axis only: the screen ships without a Claude Design source per the owner decision of 2026-08-12, and the design project's own READINESS list still describes the data layer as "being wired" — stale on its side now, not ours.

Consumer journey — 10 screens

Every consumer screen is designed, and designed thoroughly — consumer.prompt.md is one of the strongest specs in the project, carrying the CTA rule, the reservation window, anonymous-first browsing and the full chat organisation model. None of it exists in code.

Ten, counted off prototype/consumer/: ConsumerHome · ItemFeed · VendorFeed · ItemView · VendorView · Chats · Notifications · OrderCode · ScanVerify · Account, plus Featured.dc.html, which is a reusable block rather than a screen (mounted by both the Setu Card and VendorView; the copy under prototype/setu-card/ is deliberate and kept byte-identical, not a divergence). The earlier count of 8 predated Notifications and Account. Round 18 changed exactly one thing on this side, and it was a correction I asked for: ScanVerify no longer shows a scan count, and it now names why — that number needs the cardActivity rollup and a QR placement registry, neither of which exists (QRS-576). The screen cites the tracker id itself.

Screen	Design	Client	Backend	Status
Consumer home	✅ all states, section stack	❌	❌ no discovery RPC exists	🟠 BLOCKED
Item feed	✅ facets, sparse-first	❌	❌ no cross-workspace read exists at all	🟠 BLOCKED
Vendor feed	✅	❌	❌ same	🟠 BLOCKED
Item view	✅ 3 payment outcomes	❌	⚠ per-slug catalogue read only · no order write	🟠 BLOCKED
Vendor view	✅	❌	⚠ get_public_setu_card covers most of it	🟠 BLOCKED
Featured block	✅ reusable, CSS-only swipe	❌	❌ no table behind it	🟠 BLOCKED
Chats	✅ full organisation model	❌	⚠ reads ready · conversations_consumer_insert policy ready · send EF missing	🟡 PARTIAL
Notifications	✅ derived, no preferences	❌	❌ no table	🟠 BLOCKED

Three structural facts about the consumer half

1. It is a THIRD TIER, not a folder of screens. apps/mobile/src/tiers/ contains user and admin. A consumer tier is a new tier plus a resolveEntryRoute branch on account_type. Already tracked as QRS-500 — "the consumer tier's placement" — and the decision that the marketplace is in-app rather than Stack 1 is QRS-494.
2. Every public read today is per-slug. get_public_setu_card(slug) and get_public_catalogue(slug) answer "show me this one stall". Discovery asks "show me idols near me under 3 feet in shadu clay" — a cross-workspace read that does not exist in any form, and QRS-506 already records why item discovery is a larger access class than vendor discovery and must not be one function. This is the single largest missing backend contract in the product, and it is a decided-but-unbuilt one rather than an unexamined one.
3. ✅ The security guardrail is already in place, which materially de-risks this.supabase/tests/database/v2_isolation_test.sql §B1 asserts consumer isolation against a fixture that includes a user with no workspace at all, and orders.buyer_user_id is already nullable with on delete set null. So the hard part CLAUDE.md warns about — consumers changing what authenticated means — was designed for up front rather than retrofitted.

One design debt to retire, not build

prototype/customer-flows/ holds Book, Order, Pay and Review, and all four are superseded. consumer.prompt.md replaced them with inline bottom sheets inside the item flow, retired ENQUIRE, and bans a standalone UPI pay surface outright. Review has no ratings table anywhere in v2. These four should be marked superseded in the design project, not queued for implementation.

Implementation-readiness classification — the full vendor 01→20 + consumer, re-assessed 2026-08-12 (round 18)

The owner's four buckets, applied after validating the flows as a system: every design data contract was checked against the live migrations, not against the design's own claims. ✅ = build now against existing contracts · 🔧 = minor design fix · 🏗 = architecture/backend dependency · ❌ = major gap/redesign.

Round 18 closed the design axis. The journey is now 20 steps for the stall (the 21-entry JOURNEY array minus bookings, which the stall's capability set filters out), and 19 of the 20 carry a screen. The one that does not is Reminders, deliberately: it ships without a design per the owner decision of 2026-08-12, and the step says so on its own card rather than linking nowhere. Three screens are new since the 01→11 pass: Payments (the money passbook, which also retired Invoices.dc.html), Analytics (Card and QR activity), and the rebuilt QR Tools. Every one of the nine follow-up prompt items landed, including the order-reference format (QRS-580, approved) now carried by all 16 demo orders, Crockford-clean.

The verdict distribution did not change, and that is the finding. There is still no ❌: not one screen needs redesign. What the extra nine steps add is not new blockers but the same one — the orders contract (QRS-579) — plus four genuinely new backend deltas (QRS-584 counter-sales table · QRS-585 payment-method vocabulary · QRS-586 plan renewal + charge history · and the standing QRS-576 rollup). The one thing that got worse is bookkeeping, not product: the handover entry point drifted badly (QRS-581) and the registry now contradicts its own newest screen (QRS-587).

#	Screen / flow	Verdict	The one sentence that matters
01	Onboarding	✅ built	The 14 design industries match the industries seed key-for-key and archetype-for-archetype. Residual risk is QRS-285 (email OTP broken at SMTP), which is owner-track, not a screen
02	Business profile	🏗 backend	Client + design done; profileService is a stub with no read RPC, and the v2 write path is a split across workspaces (identity, GSTIN, advance) and manage-setu-card (hours, socials, about) that no service maps yet
03	Setu Card, public	✅ core · 🏗 round-16 deltas	The shipped card is production-real. The festive layer, moments, Featured, composed grid and season-scale filters are blocked on QRS-577 + QRS-578, not on design
04	Card editor	🏗 backend	manage-setu-card already covers update/publish/links/hours — but featured/moments/festive edit data with no schema home (QRS-578), and there is no draft-read RPC for the editor
05	Catalogue	✅ + small deltas	Real end to end. Round-15 deltas are additive: attribute entry chips (attributes jsonb + industries.item_attribute_schema both exist), the one-of-a-kind switch (is_unique exists but is projected by no read RPC — QRS-577), quick-add is pure client work
06	Add an item	✅	Same contract as 05; the sheet, idempotency keys and manage-item are live
07	Inventory	🏗 blocked by QRS-579	Stock columns and store.stock are real; Reserved/Sold/available is derived from orders (itemQuantities()), and no orders read exists
08	Dashboard	🏗 backend + 1 decision	Every widget except one derives from orders + items + chats reads that QRS-579 provides; the card_activity widget needs the QRS-576 decision (the design tolerates its absence). Client shell exists but is the pre-round-8 layout — a rebuild, not a patch
09	Orders	🏗 blocked by QRS-579	Design complete; tables, RLS, grants, collect_on, domain vocabulary all live; the contract slice is the only missing thing
10	Collections	🏗 QRS-579 (+574 for scan)	Ships with manual mark-collected on the base contract; the QR handover proof is a separable second slice
11	Order detail	🏗 blocked by QRS-579	Everything on the screen — day strip, record-a-payment (cash/upi_manual rows with zero commission), cancel-with-refund-decision — is expressible in today's schema. Verified column-by-column
12	Payments (money passbook)	🏗 QRS-579 + QRS-584	New in round 18, and it retired Invoices.dc.html. paymentLedger/moneySummary read the SAME order payment rows Collections and OrderDetail read, so the three can never disagree — that half rides QRS-579. The second money source has no table: counter sales are first-class on this screen and daily_sales exists only as a feature key (QRS-584). Method split hits QRS-585
13	Chat (merchant side)	🏗 send EF (QRS-432/444)	Best-aligned slice in the product. Round 17 re-anchored chat-data.js onto the real order book, so the invented references are gone and the chips are vendor-core's own vocabulary. Reads incl. per-thread order context are live; only the send EF is missing, and one EF serves both sides
14	Notifications (merchant)	🏗 rides QRS-579	Fully derived by notificationFeed() from orders + chats over a 7-day window; read state persists per slug. No notifications table needed. What does not exist is DELIVERY — no push, email or SMS — so the feed is only seen by opening the app
15	Reminders	⚫ dark by design — backend 🟢 built and DEPLOYED	Three tables, two read RPCs, manage-reminder, feature row + grant, all on Dev as of 2026-08-12 (CR-26.0.1-27/28), and the screen exists in the app. The only missing axis is a design, and it ships without one per the owner decision. The step correctly carries no button rather than a button that goes nowhere
16	QR tools	✅ + 1 product decision	Rebuilt in round 17 around the one code that exists. The Setu Card QR from the industry record's slug, with copy/share/print — buildable now (qrcode + react-native-svg, no new dep, see the S-D13 size note). The eight fabricated tiles became an honest Not built yet list. ⚠ Per-placement scan counts are not a missing table but a slug-namespace decision the product has not taken
17	Settings	🏗 backend (same split as 02)	Round 17 made the advance % and the advance terms read/write the same card-overrides row the Card editor writes and the public card reads — one source, three surfaces. Blocked on the same profile write-path mapping as step 02, plus QRS-577 for the advance projection
18	Banking and payouts	🏗 provider integration, not a screen gap	Three cards, eight fields, one save, with screenState covering all five provider states, and round 17 put activation in one store the Settings row and the Payments prompt both read. The whole screen is a client for Razorpay Route onboarding that does not exist yet (payout_accounts, the 4-call sequence, activation_status). Deliberately last in the money loop
19	Plan and billing	🏗 QRS-586	Round 17 deleted the fabrications (invented UPI handle, download-invoice button, implied plan changes). What is left needs two stored facts the schema does not have: a per-workspace subscription with a renewal date, and a charge history. Free tier needs neither, so this is off the launch critical path
20	Card and QR activity (Analytics)	🏗 QRS-576, and it ships anyway	New in round 18 and the best example of the null-path discipline in the product. Every figure comes from cardActivity(model, days) — the same derivation the dashboard widget reads, so screen and widget cannot describe one week differently. There is no rollup table, so a real workspace lands on the null path, which is a first-class state: it says nothing is recorded yet and offers the counts that DO exist. placements was removed from the contract outright, because one code on one flat URL cannot attribute a scan to a board
C1	Consumer chats	🏗 send EF (QRS-432/444)	Reads, organisation, realtime authz and conversations_consumer_insert are all live; the send EF is missing on both sides — one EF serves both
C2	Item view / order+pay	🏗 place-order EF + payments dark	The three-outcome payment flow is sound and correctly depends on the availability axis: with payments platform-denied there is no ORDER control at all, by design on both sides
C3	Consumer home / feeds / vendor view	🏗 tier + discovery	Blocked on the consumer tier (QRS-500 — resolveEntryRoute has a two-value account type today) and the cross-workspace discovery read (QRS-506). Decided, unbuilt
C4	Order code / Scan & verify	🏗 QRS-574 / QRS-575	New trust subsystems, designed to EF-shaped contracts (verify_order_qr, verify_qr) that need schema + ADR decisions first
C5	Consumer notifications	🏗 rides QRS-579	Derived from stored orders + chat, exactly like the vendor side — no notifications table needed on either side
—	customer-flows/ Book · Order · Pay · Review	✅ closed 2026-08-12	SCREENS.md now banners all four SUPERSEDED, DO NOT IMPLEMENT. ⚠ But PrototypeHub.dc.html still links all four as a live "Customer" group — QRS-581
—	PrototypeHub.dc.html (the handover entry point)	🔧 design bookkeeping, high impact	One dead link (Invoices.dc.html, deleted), nine live screens unreachable (Collections · OrderDetail · ScanCollect · Payments · Thread · Settings · consumer OrderCode · ScanVerify · Account), four superseded screens still linked, and descriptions teaching deleted features. Absence here is invisible, which is why it outranks its size — QRS-581
—	Welcome / Flash (BrandSplash)	🔧 client rebuild against the improved design	The improved BrandSplash.dc.html is now the reference and differs from shipped BrandSplash.tsx in six places, one a direct contradiction (the design puts the attribution in solid white because gradient text would disappear on the gradient; the app renders it in the gradient). Needs a new brand-on-gradient token + Wordmark tone/typing props (both systemic ⇒ design-first) and the native splash colour #FFFFFF → #FFC229 with its test — QRS-583

What the system-level validation proved (rather than assumed):

1. The status vocabulary is one vocabulary in three places — the design's canonical keys, the orders CHECK constraints and @qrsetu/domain orders/status.ts agree exactly, including ready and the two-axis split. The consumer chips are display translations of the same keys.
2. Money agrees end to end: integer paise everywhere, payments as child rows with per-capture refunds, counter cash/UPI as first-class zero-commission providers, paidSoFar/balanceDue arithmetic identical in design and domain code.
3. Chat is the best-aligned slice in the product: pins capped at 3 by trigger, labels, quick replies, away-reply once-per-closed-period, bidirectional blocks, item-share messages with price snapshots and read-time item_unavailable, per-thread order context already projected by get_my_conversations — every one of these is a design feature with a live schema mechanism.
4. The advance is modelled where the design needs it: workspaces.advance_pct + advance_terms (the legal disclosure) — but neither is projected by any read yet (QRS-577).
5. Vendor and consumer describe the same order because there is only one orders row with RLS giving each side its lawful view — the design's "one enum in the database" intent holds.
6. The free-plan boundary is coherent: no orders entitlement on free (owner decision, CR-26.0.1-26) ⇒ Collections/OrderDetail are paid surfaces; the design's plan copy says the same thing, and the item cap now agrees at 25 on both sides (PLANS.free.includes says "Up to 25 catalogue items", the grant caps store at 25) — reconciled 2026-08-12.
7. Round 18 added a seventh proof, and it is the one that generalises: the design's own bookkeeping is now trustworthy where it is DERIVED and stale where it is HAND-MAINTAINED. The two vendor journey pages generate themselves from JOURNEY in vendor-core.js, so they cannot disagree about what is shared, and their READINESS list sits in the same file as the steps it describes — both were accurate on inspection, including the three stale items closed this round. The two artifacts that drifted, PrototypeHub.dc.html (QRS-581) and SCREENS.md's analytics preamble (QRS-587), are exactly the two that are written by hand. That is the same lesson this repo keeps relearning at the gate layer — a claim nothing derives or checks decays — and it is worth acting on design-side: the hub should be generated from SCREENS.md, not maintained beside it.

What is genuinely implementation-ready

The honest answer is small, and stating it small is the point.

Wave	Work	Why it is safe to start now
W0	Freeze the systemic surface. Port the current console-kit.js contract into apps/mobile/src/ui as one design-first pass with drift-ledger rows	ADR-0015 makes src/ui/** design-first with no exceptions. Rounds 12 to 16 moved the radius scale, the toast and the type scale. Implementing screens before this means re-touching every one of them
W1	QR tools and Plan and billing	The only two steps needing no new backend contract. QR generation is client-side; plans already have get_platform_plans and resolve_workspace_plan
W2	Chat, read-only — conversation list and thread rendering	get_my_conversations and get_conversation_messages are live. Sending needs the chat Edge Function the migration already names
W3	Contract-first slices, one screen with its RPC and EF and pgTAP together — and the 2026-08-12 assessment says do the orders slice first (QRS-579): orders read + manage-order EF + place-order EF unblocks steps 07/08/09/10/11/14 and the consumer transact flow in one move. Then: profile read · card editor read · dashboard summary	Each is blocked only by its own contract. Building the contract and the screen in one slice is the strangler-fig unit this repo already mandates

Gaps that are not screens

These do not appear on any journey step and will not be found by designing more screens.

Gap	Consequence
⚠ Email OTP fails at the SMTP layer — QRS-285, relay pointed at the wrong provider	Step 01 is 🟢 only via Google sign-in. A merchant who enters an email cannot create an account. This is the first step of the journey
No landing page — apps/web/src/app/routes/home.tsx is a 10-line placeholder	There is no way in for anyone who did not scan a card
No cross-workspace discovery read	The marketplace and both consumer feeds are unbuildable, not just unbuilt
No cache invalidation on any write path — QRS-350	✅ CLOSED 2026-08-12. invalidateCardCache runs in manage-item and manage-setu-card and logs card_cache.purged (QRS-573). Two caveats keep this from being "done done": Cloudflare credentials are unset on Dev (QRS-306) so only the failure branch has ever executed, and the purge is best-effort by design
No orders or payments write path, and no orders read — QRS-579	orders + payments tables, RLS, grants, collect_on and the domain status vocabulary all exist with nothing able to read or write them. One contract slice (orders read RPC + manage-order EF + place-order EF) unblocks steps 07/08/09/10/11/14 and the consumer transact flow at once
The order-handover proof loop has no backend — QRS-574	The design's signed order-code token, share grants, verify_order_qr and the collection audit record (ScanCollect/OrderCode) have no tables, no EF and no ADR. Separable: Collections can ship with manual "mark collected" first
Scan & Verify has no backend — QRS-575	verify_qr, the minted-code registry with revocation, community reports and VPA ownership are designed (qr-verify.js) and entirely unbuilt — an R1 scope decision, not a screen fix
No analytics rollup table — QRS-576	Every number on the dashboard's insights widget and on the new Analytics screen is illustrative. ✅ Round 18 softened the design side rather than the backend side, which is the right half to move: vendor-core.js's header now states plainly that as of 2026-08-12 no rollup, ratings table or placement registry exists (citing this id), placements was removed from the contract outright as an attribution the product cannot make, and both the widget and the screen ship on a first-class null path. What remains: no event stream, no rollup, no ratings table — and cardActivity() still returns a rating from a.ratings that nothing renders
Counter sales have no table — QRS-584	The new Payments screen has two money-in sources and only one is storable. daily_sales exists as a feature key (granted free) and a migration comment; there is no table, and it cannot ride payments because payments.order_id is NOT NULL. Sequence it inside QRS-579 or the Payments screen gets built twice
Payment-method vocabulary disagrees — QRS-585	Design cash/upi/online vs schema provider cash/upi_manual/razorpay. The status keys were deliberately made identical across all three layers; the method keys were not. A one-line decision now, a data migration after the first live payment. Also: the design tolerates a payment with no method, so provider must be nullable
Plan renewal date and charge history are not stored — QRS-586	platform_plans answers which plan; nothing stores a per-workspace subscription, so step 19's renewal date and derived charge history have no source. Free needs neither, so this is off the launch critical path — but do not solve it by pasting a date onto workspaces
The design handover entry point is stale — QRS-581	PrototypeHub.dc.html is what the project tells you to hand to a developer. One dead link, nine live screens unreachable, four superseded ones still linked, and copy teaching deleted features. A dead link announces itself; a missing card does not
The desktop target is undecided — QRS-588	ADR-0011 puts the merchant tier on Stack 2 with no user tier in apps/web. Desktop merchant is therefore either responsive RNW inside apps/mobile or a new DOM tier whose primitive layer does not exist (apps/web/src/ui/ is a README; no shadcn/radix/cva dependency). The two produce different designs from the same brief, so this decision must precede a desktop design round
Public projections miss the fields the approved design binds — QRS-577	get_public_catalogue omits attributes (the filter facets), is_unique and the item slug; get_public_setu_card projects no archetype/shape, no payments-enabled signal and not the advance_pct/advance_terms legal disclosure; is_unique is write-only even to the merchant. The card's CTA rule and season-scale filters cannot render from today's reads
Featured · moments · festive season context have no schema home — QRS-578	The round-16 card layers and half the Card editor's sections edit data no table holds
No in-app QR scan	A scanned card leaves the app: iOS associated domains and an Android assetlinks file are both absent
reminders has no feature registry row — QRS-564	✅ CLOSED 2026-08-11. Registered universal with a platform entitlement grant; a bare consumer now resolves it enabled. Only the DESIGN is still missing
Admin tier is two README files	Nothing can change a feature grant, take down abuse, or fix a merchant's data except hand-written SQL

Parity status

Not applicable per-screen yet: of the 20 vendor steps, 8 have client code and those 8 inherit the existing parity posture of apps/mobile. Every screen entering implementation from W1 onward names its divergence seams at G0, per QRS-297. The seams already visible in this journey are camera and QR scan, share, image picker, push for chat, and deep links for the in-app scan gap above.

Proactive-value answer

This page is infrastructure for the proactive surfaces, not one itself. The journey's genuinely proactive steps are step 08's derived action items and step 15's reminders, and the matrix records that both are blocked on the same missing thing — a read model. That is the useful finding: the proactive layer is not under-designed, it is unsourced.

Sources

• Design: Claude Design prototype project 633dc069-6df8-4408-b625-068907c60c33 — SCREENS.md, prototype/mobile-console/vendor-core.js for JOURNEY and READINESS, prototype/consumer/consumer.prompt.md
• Client: apps/mobile/src/tiers/user/features/*, apps/mobile/src/app/(user)/*, apps/web/src/*
• Contracts: packages/data/src/index.ts barrel, supabase/migrations/*.sql, supabase/functions/*
• Related: Festival Stall discovery brief · Screen Coverage Mandate · Store / Catalogue Spec · Consumer Marketplace Spec · architecture/current-state

Living doc: this is a point-in-time join across three sources. Re-verify before using it to plan a release — a status here is a claim about 2026-08-12 (first assessed 2026-08-11), not a standing fact.