App surface map

How the trovesnap.com app gets built across the roadmap — which screen, which sprint.

Source: app-surface-map.md
Updated: 2026-06-22

App Surface → Sprint Map

How the trovesnap.com seller app gets built across the roadmap, and in what order. Use this to answer "when does this screen become real?"

The key fact

The seller web app you see today is S1 "Web command center" — and S1 is done. So the shell, navigation, and layout exist, but the data behind most panels is mocked. The functional fill-in is spread across the POC phases (Spine → Operational Floor → Capture → Vision → Demand) and wired up in Surfaces & Delivery (S2–S4). Underneath everything sit the Platform & Contracts specs (P1–P8) the features conform to, and the Spine (identity/QR/status) that inventory rides on.

Surface → phase/sprint

App surface Built by Sprint
Dashboard shell, nav, Create New Sale, layout S1 ✅ done Surfaces & Delivery
Sales → "photos into publish-ready inventory" D (capture) + E (vision) + B (identity) Sprints 1, 3, 4
Inventory Review D3 + E3 (review / overlay) Sprints 3–4
Workflow Center (rooms, zones, labels, bulk) C (Operational Floor) Sprint 2
"items need better photos" card D1/D3 + E5 (follow-up guidance) Sprints 3–4
"appraisal may be needed" card E6/E7 (appraisal_prepare / value) Sprint 4
"wishlist matches nearby" card E8 (watchlist) + F (demand) Sprints 4–5
"unsold items have buyer demand" card F1/F3 (demand, unsold routing) Sprint 5
Buyers & Demand / Trove Go marketplace F + P6 (marketplace data layer) Sprint 5
Connected Apps / Harness / Import Audit / Sale Submissions P5 + P7 + D4 + S3 P&C → Sprint 3 → Surfaces
Analytics G3 + P8 (observability) after Sprint 1
Plans / Appraisal tokens / Trust score G4 (monetization) + E7 Positioning + Sprint 4
Marketing (boost / local search / map pin) G + buyer map (F) Positioning + Sprint 5

Sprint sequence (per D6/D9)

  1. Platform & Contracts (P1–P8) — the contracts every feature conforms to. (now)
  2. Spine POC (B1–B5) — identity / QR / status events.
  3. Operational Floor (C) — rooms, zones, labels, bulk → fills Workflow Center.
  4. Capture / Enrich (D) — photo capture, review, import → fills Sales, Inventory Review, photo cards, Import Audit.
  5. Vision Contract (E) — scans, overlays, appraisal, watchlist → fills appraisal + wishlist cards, scanning.
  6. Demand / Recovery (F) — demand signal, offers, unsold, disposition → fills Buyers & Demand, Trove Go.
  7. Surfaces & Delivery (S2 mobile, S3 harness, S4 deploy) — delivery surfaces; S1 shell already done.
  8. Positioning / GTM (G) and Research (R) — run in parallel.

Best implementation order (critical things first — D30)

The 8 P&C contracts aren't equally critical. Freeze them in dependency order:

  1. P1 scan I/O + normalized 0–1000 coords — everything vision rides on.
  2. P5 ingestion + promotion contract — single canonical writer; unblocks Spine + import.
  3. P6 data-model layers + RLS path — schema everything reads/writes; unblocks Spine + Operational Floor.
  4. P2 provider-adapter started early — highest API/cost risk; pair with P8 budgets.
  5. then P3 validation → P4 ranking → P7 MCP.

Hybrid parallelization: the moment P1 + P5 + P6 freeze, Spine (B) starts in parallel — it consumes exactly those three. P2/P3/P4/P7/P8 continue alongside.

See the technical specs for each P-gate contract.