Expanded from the provisional POC-scoped requirements.md (now superseded). Existing REQ IDs are preserved verbatim because roadmap.json gates and status.json work items reference them. Source docs are cited rather than copied. Status reflects real implementation state, which can differ from a gate's status (a requirement's code can exist before its phase gate is formally frozen/verified).
Tracking & Tooling — Tracking Foundation · 13 reqs · 8 built
REQ-TRACK-009 accepted P1
TH1 · Tracker Hardening
Plan integrity must be machine-checked before build/deploy (tracker:check).
Accept: A script fails on duplicate WI codes, unresolved gate/requirement refs, invalid sprint names, owner/reviewer labels not in PEOPLE, broken doc paths, and overlapping pointed summary/slice rows.
REQ-TRACK-010 accepted P1
TH2 · Tracker Hardening
Story points must count each work item once, with one canonical sprint-complete rule.
Accept: Per-sprint summary rows are zero-pointed; granular slices carry the points; static + live use the same items-done complete rule (gates a separate axis).
REQ-TRACK-011 accepted P1
TH3 · Tracker Hardening
The Supabase reseed must be decoupled from local builds and the SQL seed must preserve live HITL state.
Accept: Local docs:tracker does not write the prod DB; the deploy path does; tracker-seed.mjs no longer overwrites HITL status/waiting_on/notes on conflict (or is marked bootstrap-only).
REQ-TRACK-012 accepted P1
TH4 · Tracker Hardening
Every gate must enumerate its requirements and every accepted requirement must map to a work item; owners assigned + validated.
Accept: Platform + Spine gates list their sub-requirements; accepted reqs in a sprint have a work item; owners are set and resolve to PEOPLE.
REQ-TRACK-013 accepted P1
TH5 · Tracker Hardening
Tracker docs/links must be consistent and plan docs refreshed.
Accept: No stale paths in status.json/docs; plan-doc refresh (WI-022-025) tracked.
REQ-TRACK-006 implemented P1
A5 · Tracker Foundation
The tracker must be a live edit surface backed by Supabase with who/when/why audit, behind Cloudflare Access, with no redeploy to see changes.
Accept: app.html reads/writes via the Access-gated Function; each change records actor, time, and reason; canonical identity maps logins to one person.
REQ-TRACK-007 implemented P2
A5 · Tracker Foundation
The tracker must be versioned with a What's-new changelog and surface gate-to-work-item/HITL linkage and per-sprint detail.
Accept: tracker-version.json + changelog page render; sprint pages show gates with their satisfying work items/HITL tickets.
REQ-TRACK-008 implemented P2
A3 · Tracker Foundation
The requirements register itself must be a structured, full-vision artifact rendered in the tracker (grouped/filterable, linked to gates and work items).
Accept: requirements.json drives a generated requirements view; every gate's requirements resolve to register entries.
REQ-TRACK-001 verified P0
A1 · Tracker Foundation
Agents must resume from handoff, status, latest deliberation, decision log, and source docs.
Accept: Handoff names the required read order and current deliberation state.
REQ-TRACK-002 verified P0
A2 · Tracker Foundation
Partners must have a generated sprint tracker that can publish through the docs site.
Accept: index.html is generated from JSON and published via Cloudflare Pages.
REQ-TRACK-003 verified P0
A3 · Tracker Foundation
Partners must see how phases, milestones, sprints, requirements, and evidence relate.
Accept: roadmap.json, requirements register, and the generated overview exist and cross-link.
REQ-TRACK-004 verified P0
A5 · Tracker Foundation
Partners need an overview landing, milestone dashboard, phase timeline, per-item detail pages, and a kanban board.
Accept: index.html, sprint.html, and items/*.html are generated with those sections.
REQ-TRACK-005 verified P1
A6 · Tracker Foundation
The tracker needs a landscape layout, a product-milestone rollup track with percent-complete, and requirement IDs as individual badges.
Accept: Overview renders the product-milestone strip with rollup %; layout is landscape; requirement IDs render as badges.
Human-in-the-loop & Business — Tracking Foundation · 6 reqs · 3 built
REQ-BIZ-001 proposed P0
A7 · Foundation HITL
S-corp filing work must start with a written initial plan and Paul review before any filing decision, ending in a formed & signed entity.
Accept: Mark drafts the plan (HITL-BIZ-001); Paul reviews rules/direction (HITL-BIZ-002); entity is filed and S-election made (gate A7).
REQ-BIZ-002 proposed P0
A8 · Foundation HITL
Trademark research must be summarized with proof before any filing decision, ending in a cleared mark or variant decision.
Accept: Mark uploads research with screenshots/links (HITL-BIZ-003); a file/variant decision is recorded (gate A8).
REQ-PARTNER-001 proposed P1
A4 · Foundation HITL
Justin's partner work must be tracked by accepted contribution evidence and business value, separate from claimed effort.
Accept: Justin's contributions are logged with evidence and marked accepted before any partnership-percentage decision; sprint work items reference HITL-PARTNER-001.
REQ-HITL-001 implemented P0
A4 · Foundation HITL
Human-owned tasks must be tracked by owner, reviewer, waiting state, milestone, evidence, and notes.
Accept: hitl-tasks.json exists and the tracker renders waiting-on tasks with owner/reviewer/evidence.
REQ-HITL-002 implemented P0
A4 · Foundation HITL
Partner contribution work must be tracked separately from product/code tasks (accepted evidence vs claimed effort).
Accept: Partner tasks show owner, reviewer, evidence, and status in a contribution ledger.
REQ-HITL-003 implemented P1
A4 · Foundation HITL
HITL tasks must support uploaded evidence with an in-app review/approve flow and per-task ticket pages.
Accept: An owner uploads a doc (signed URL to private Storage) which sets evidence + flips to review; a reviewer approves/returns; upload/download/decision are audited; each task has a detail page.
LLM I/O Contracts — Platform & Contracts · 9 reqs · 0 built
REQ-CONTRACT-001 accepted P0
P1 · Platform & Contracts
Scan I/O contract schemas and versioning must be frozen before vision features build on them.
Accept: Request envelope, per-scan_type result schemas, scan_version/result_version, shared enums, and the normalized 0-1000 coordinate contract are specified and frozen.
REQ-CONTRACT-002 accepted P0
P2 · Platform & Contracts
A provider-adapter boundary must normalize all vision providers into one canonical result.
Accept: OpenAI, Gemini, Claude, and local VLMs return one canonical result via strict structured output.
REQ-CONTRACT-003 accepted P0
P3 · Platform & Contracts
Model output must pass a validation pipeline with retry/fallback before use.
Accept: Syntax -> schema -> enum -> coordinate -> business-rule validation with the documented 2-attempt retry/fallback policy (same model simplified, then fallback provider).
REQ-CONTRACT-004 accepted P0
P4 · Platform & Contracts
Candidate ranking must be deterministic, computed by TroveSnap from model evidence (not by the model).
Accept: The model returns component scores; TroveSnap computes the final ranking with documented per-profile weights (personal_hunt vs estate_organizer).
REQ-CONTRACT-005 accepted P0
P1 · Platform & Contracts
All seven scan types must be defined as versioned, UI-triggered contracts.
Accept: table_hunt, room_scan, item_scan, mark_scan, condition_scan, appraisal_prepare, appraisal_value each have input/output schemas, rules, and acceptance criteria; UI actions resolve to scan_type + version.
REQ-CONTRACT-006 accepted P1
P1 · Platform & Contracts
Watchlists must be a separate, versioned, tenant-scoped input whose match IDs are restricted to those supplied in the request.
Accept: Watchlist entries (query/aliases/makers/clues/priority), the allowed match types, and the restriction that result watch_id values must be supplied IDs are enforced.
REQ-CONTRACT-007 accepted P1
P1 · Platform & Contracts
Shared enums and the category taxonomy must be canonical, versioned inputs the model is constrained to.
Accept: identity_certainty, visibility, condition, priority, appraisal_state/readiness, reason codes, next_action, overlay_state, and the category roots/hierarchy are defined; the profile compiler can send relevant subsets.
REQ-CONTRACT-008 accepted P1
P2 · Platform & Contracts
Scan configuration must be authored as YAML and compiled into provider-specific JSON Schema / grammar (separate config from output).
Accept: Human-authored YAML compiles to strict schemas/grammars; models return schema-constrained JSON while YAML stays the config/doc format.
REQ-CONTRACT-009 accepted P1
P1 · Platform & Contracts
Scans must store both raw and normalized results with full provenance.
Accept: scan_record persists scan/version, input image ids, watchlist/taxonomy versions, provider+model, prompt/schema hashes, result refs, and metrics; raw + normalized results both stored.
Platform & Data Model — Platform & Contracts · 7 reqs · 0 built
REQ-PLAT-001 accepted P0
P5 · Platform & Contracts
The ingestion + promotion contract must be the only path into canonical inventory.
Accept: Connectors/MCP/harness/buyer write candidates and events only; promoteInventoryCandidate() is the single canonical writer with traceability (source_import_records.promoted_record_id).
REQ-PLAT-002 accepted P0
P6 · Platform & Contracts
Data-model layers must be consolidated with a documented RLS upgrade path.
Accept: Canonical, marketplace, seller-intelligence, tracking-identity, disposition, and ingestion layers are documented with an owner-scoped RLS path.
REQ-PLAT-004 accepted P1
P8 · Platform & Contracts
Observability and cost controls must bound scan spend and surface quality.
Accept: Scan trace structure, per-scan_type token/tier budgets, and quality/cost metrics (precision/recall, retake rate, cost per scan type) are defined.
REQ-PLAT-005 accepted P0
P6 · Platform & Contracts
The canonical seller data layer must model sales, items (with lifecycle/appraisal/demand fields), photos, AI runs, exports, seller profiles, and discount phases.
Accept: estate_sales, estate_sale_items, estate_sale_item_photos, estate_sale_ai_runs, estate_sale_exports, seller_profiles, discount_phases exist in schema.sql with the documented fields.
REQ-PLAT-006 accepted P1
P6 · Platform & Contracts
The marketplace/buyer data layer must model taxonomy/tags, buyer profiles, saved searches, watches, saves, wanted items, match alerts, followers, notifications, tokens, submissions, discount codes, and appraisals.
Accept: The listed buyer tables exist with buyer_id scoping ready for Auth.
REQ-PLAT-007 accepted P1
P6 · Platform & Contracts
The seller-intelligence layer must model alerts, demand signals, wishlist matches, appraisal recommendations, and status events.
Accept: seller_alerts, item_demand_signals, wishlist_matches, appraisal_recommendations, inventory_status_events exist.
REQ-PLAT-008 accepted P2
P6 · Platform & Contracts
Documented upgrade paths must exist for pgvector (semantic search) and PostGIS (geo).
Accept: Search/geo helpers (troveSearch haversine; FTS/RPC/Meilisearch later) have a documented path to pgvector/PostGIS without contract changes.
Security & Privacy — Platform & Contracts · 5 reqs · 0 built
REQ-SEC-001 accepted P0
P5 · Platform & Contracts
Third-party credentials must never be stored in app tables; credential_refs holds pointers only, with three documented levels (OAuth server-side, local harness, manual fallback).
Accept: credential_refs.storage_location is oauth_server | local_harness | vault; no raw secrets in any app table; no server-side scraping with stored passwords.
REQ-SEC-002 accepted P0
P5 · Platform & Contracts
Supabase key boundaries must be enforced: browser/mobile use anon key + user JWT + RLS; server/edge use the service role; the harness uses a scoped device token, never the global service role.
Accept: The service role never ships to the browser; OAuth tokens (oauth_tokens) are RLS service-role-only; the harness validates a scoped token.
REQ-SEC-003 accepted P0
P6 · Platform & Contracts
Public QR/buyer pages must never expose private notes, internal pricing guidance, margin, consignor details, or seller PII.
Accept: Public QR payloads use opaque IDs and resolve to buyer-safe pages; staff/binding views are auth-gated; internal pricing is hidden from buyers.
REQ-SEC-004 accepted P1
P8 · Platform & Contracts
Vision image access must be scoped and minimized: scoped to sale/user/org, accessed via expiring signed URLs, sending providers only required images/context, with configurable provider retention.
Accept: Signed URLs expire; watchlists stay tenant-scoped; raw model output is treated as untrusted until validated; external appraisal queries cannot leak private client info.
REQ-SEC-005 accepted P1
P6 · Platform & Contracts
RLS must move from MVP-permissive to owner-scoped on a documented path, and buyer tables scope by buyer_id once Auth lands.
Accept: owner_id = auth.uid() policies are the documented upgrade for seller tables; buyer_id scoping activates with Auth.
MCP Tool Surface — Platform & Contracts · 4 reqs · 2 built
REQ-MCP-003 accepted P1
P7 · Platform & Contracts
Approval-gated MCP tools (promote_candidate, publish_sale, update_item_status, notify_matched_buyers) must require explicit seller approval or an auditable, revocable automation policy.
Accept: No tool bypasses promoteInventoryCandidate(); none touch credential_refs contents; live publishing/paid/destructive actions are never auto-approved by default.
REQ-PLAT-003 accepted P1
P7 · Platform & Contracts
The MCP tool surface must expose safe tools first and gate dangerous ones.
Accept: Read/search/candidate tools land first; publish/bulk/delete tools require explicit approval or an auditable, revocable automation policy.
REQ-MCP-001 implemented P1
P7 · Platform & Contracts
A read-only MCP tool tier must be available (list/get sales, list items, search marketplace, demand signals, import runs).
Accept: A stdio MCP server exposes the read tools; without env it serves mock data; with env it reads live.
REQ-MCP-002 implemented P1
P7 · Platform & Contracts
A candidate-writing MCP tier must create candidates/imports/events only (create_candidate, run_manual_import, map_csv_columns, draft_listing_copy, stage_export).
Accept: These tools write source_import_records / inventory_candidates / plugin_events; nothing canonical; every call logs plugin_events.
Item Identity & Status Spine — Spine POC · 7 reqs · 0 built
REQ-SPINE-001 accepted P0
B1 · Sprint 1 - Spine POC
Items need stable identity suitable for sale operations and later recovery.
Accept: A POC item keeps a stable identity across status updates and CSV roundtrip.
REQ-SPINE-002 accepted P0
B1 · Sprint 1 - Spine POC
Status changes need an event contract that can support audit and reconciliation.
Accept: Status event fields (previous/new status, source, final price) are documented and used by the POC path.
REQ-SPINE-003 accepted P0
B2 · Sprint 1 - Spine POC
QR codes need opaque resolver bindings rather than exposed mutable internal IDs.
Accept: A QR demo resolves item state through an opaque binding; a code can start unbound, bind on first scan, be released, and be rebound.
REQ-SPINE-004 accepted P1
B3 · Sprint 1 - Spine POC
Sold/status CSV roundtrip needs to work with existing primitives before richer workflows.
Accept: CSV export/import can update sold/status state in demo fixtures.
REQ-SPINE-005 accepted P1
B4 · Sprint 1 - Spine POC
QR/identity binding needs durable tables with opaque public codes.
Accept: qr_codes / item_identity_bindings model opaque codes, binding state, bound/released timestamps, and binding history.
REQ-SPINE-006 accepted P1
B5 · Sprint 1 - Spine POC
Status transitions need an audit trail for reconciliation and recovery.
Accept: inventory_status_events records transitions (with source: manual|csv_import|platform_sync|barcode|harness) that reconciliation and recovery read.
REQ-SPINE-007 accepted P1
B1 · Sprint 1 - Spine POC
The canonical item lifecycle and its events must be defined, including disposition branches and an event stream safe to replay into analytics.
Accept: Lifecycle draft->reviewed->published->active_sale->pending->sold->picked_up plus not_sold->disposition branches; the ~21 named events are emitted without implying every event mutates canonical inventory.
Operational Floor — Operational Floor POC · 7 reqs · 0 built
REQ-OPS-001 accepted P0
C1 · Sprint 2 - Operational Floor POC
Rooms, zones, and pickup areas need to be first-class tracking fields across setup, capture, labels, checkout, pickup, and reports.
Accept: Items can be grouped and filtered by room/zone/pickup area, and those carry through to labels and client reports.
REQ-OPS-002 accepted P0
C2 · Sprint 2 - Operational Floor POC
Label batches need a first-class print/pack workflow synchronized through the binding model.
Accept: Mass label printing, reprints, skipped labels, room/zone grouping, preprinted sticker-pack codes, and a list of unlabelled high-value items all bind through the same model.
REQ-OPS-003 accepted P1
C3 · Sprint 2 - Operational Floor POC
Bulk operations need early operational support with a conflict preview before applying.
Accept: Bulk price/category/room edits, mass label generation, batch discount changes, and duplicate-room setup between sales all show a reviewable conflict preview before applying.
REQ-OPS-004 accepted P1
C4 · Sprint 2 - Operational Floor POC
Client reports need to summarize sale/reconciliation outcomes with audit links.
Accept: A report package generates sold/pending/unsold/donated/removed lines, totals by room/zone/consignor/category/day, gross/fees/net/recovered, and an exception list, each linked to status events.
REQ-OPS-005 accepted P1
C5 · Sprint 2 - Operational Floor POC
Team roles and permissions need first-class support with an RLS path.
Accept: Roles owner/admin, cataloger, pricer, label/runner, checkout, and client-report viewer exist with an owner-scoped RLS upgrade path.
REQ-OPS-006 accepted P1
C6 · Sprint 2 - Operational Floor POC
Markdown/discount phases need a timed pricing model.
Accept: discount_phases supports timed sale pricing stages; calculateSaleDiscountState returns current/next/urgency/percent.
REQ-OPS-007 accepted P1
C4 · Sprint 2 - Operational Floor POC
POS imports must reconcile item identity without TroveSnap becoming a POS (interop-first).
Accept: Square quick-amount, EstateSail/PROSALE itemized exports, and Shopify/Whatnot online-channel exports import and reconcile by QR/labels/lot IDs/room/manual; payments, refunds, receipts, tax, and cash drawers stay out of scope.
Capture & Enrichment — Capture / Enrich POC · 5 reqs · 1 built
REQ-CAPTURE-001 accepted P0
D1 · Sprint 3 - Capture/Enrich POC
Photo and note capture needs a review queue before enrichment becomes operational state, capturing room/zone/pickup context on site.
Accept: Demo captures media/notes + room context and queues them for review; output stays an inventory_candidate, not canonical inventory.
REQ-CAPTURE-002 accepted P1
D2 · Sprint 3 - Capture/Enrich POC
Deterministic enrichment should be used where rules are clear (on-device/low-cost before paid AI).
Accept: Rule-based tags/enrichment are distinguishable from guesses; deriveTreasureTags + buildSearchVectorText power search without paid calls.
REQ-CAPTURE-003 accepted P0
D3 · Sprint 3 - Capture/Enrich POC
Suggested enrichment must be human-reviewed before operational mutation.
Accept: Seller approves/edits/rejects/merges/sends-back-for-better-photos before any state change; promoteInventoryCandidate() remains the only canonical path.
REQ-CAPTURE-004 accepted P1
D4 · Sprint 3 - Capture/Enrich POC
The source-import pipeline must run end to end into candidates.
Accept: source_import_runs/source_import_records -> inventory_candidates is demoable end to end with plugin_events audit.
REQ-CAPTURE-005 implemented P1
D5 · Sprint 3 - Capture/Enrich POC
Deterministic enrichment mocks must have stable contracts gated behind review.
Accept: Tags/enrichment/copy/anti-cheat mocks (troveTags, troveSnapEnrichment, troveCopyGen, troveAntiCheat) have stable contracts and never mutate canonical state without review; LLMs swap in behind the same contract.
Connectors & Harness — Capture / Enrich POC · 5 reqs · 3 built
REQ-CONNECT-004 accepted P2
D4 · Sprint 3 - Capture/Enrich POC
Additional source types must follow the one-door rule (manual paste, marketplace/auction CSVs, Gmail alerts, custom links, browser extension, buyer submissions).
Accept: Every source writes source_import_records -> inventory_candidates -> review; buyer submissions (garage_sale_submissions) follow the same review-then-canonical pattern.
REQ-CONNECT-005 accepted P2
D4 · Sprint 3 - Capture/Enrich POC
External channel links must be captured per sale with click-through attribution.
Accept: Sellers add EstateSales.net/Facebook/HiBid links (external_listing_urls); /api/out logs click-throughs for cross-channel attribution.
REQ-CONNECT-001 implemented P0
D4 · Sprint 3 - Capture/Enrich POC
A CSV/Excel import wizard must normalize any platform sold-report into status events with a confirmable column mapping and conflict preview.
Accept: Upload -> suggestCsvMapping guesses columns -> seller confirms -> statuses normalize via synonyms -> preview rows + conflicts -> apply writes inventory_status_events + an import run.
REQ-CONNECT-002 implemented P1
D4 · Sprint 3 - Capture/Enrich POC
OAuth folder connectors (Google Drive, OneDrive, Google Photos) must pull images into import records + photo candidates, deduped, with server-side-only tokens.
Accept: start->consent->callback (tokens server-side in oauth_tokens, RLS service-role-only)->sync pulls new media deduped by file/media id into candidates.
REQ-CONNECT-003 implemented P1
D4 · Sprint 3 - Capture/Enrich POC
A zero-dependency desktop harness must watch a local folder and upload normalized records via a scoped token, with files/credentials never leaving the machine.
Accept: apps/harness/harness.mjs posts to /api/harness/ingest validating x-harness-token, deduped by device+path, creating an import run + photo candidates; only filename/size/mtime metadata is sent in this version.
Vision Scanning — Vision Contract POC · 10 reqs · 0 built
REQ-VISION-001 accepted P0
E1 · Sprint 4 - Vision Contract POC
Table hunt and item scan schemas need accepted contracts rendered as overlays.
Accept: table_hunt + item_scan schema examples validate; candidates render as tappable overlays.
REQ-VISION-002 accepted P1 💲 API COST
E2 · Sprint 4 - Vision Contract POC
Vision providers need an adapter boundary (consuming the P2 boundary).
Accept: Provider-specific code is behind an adapter scaffold returning the canonical result.
REQ-VISION-003 accepted P1
E3 · Sprint 4 - Vision Contract POC
Vision confidence and corrections need a visible review UX.
Accept: Overlay/review demo shows confidence and captures bounding-box and identity corrections.
REQ-VISION-004 accepted P1
E4 · Sprint 4 - Vision Contract POC
room_scan must handle multi-image coverage, counts, dedup, and sightings.
Accept: Multi-image coverage, category counts, approximate dedup, multiple sightings per candidate, and a missing-coverage checklist validate.
REQ-VISION-005 accepted P1
E5 · Sprint 4 - Vision Contract POC
mark_scan/condition_scan must extract marks and grade visible condition.
Accept: Literal OCR preserved + normalized maker/model/serial; visible-condition grading links each observation to an image; functionality is never inferred.
REQ-VISION-006 accepted P1
E6 · Sprint 4 - Vision Contract POC
appraisal_prepare must report readiness and a search fingerprint without pricing.
Accept: Returns readiness state + missing evidence + a normalized search fingerprint and never estimates value.
REQ-VISION-007 accepted P1 💲 API COST
E7 · Sprint 4 - Vision Contract POC
appraisal_value must produce comps-based ranges and adjustments from supplied comparables.
Accept: Returns multiple sale-context ranges, adjustments, and strongest comps; TroveSnap computes the quantitative baseline; unsupported model memory is never treated as a comparable.
REQ-VISION-008 accepted P1
E8 · Sprint 4 - Vision Contract POC
Watchlists must be versioned, tenant-scoped, and restricted to supplied IDs (POC enforcement).
Accept: Result watch_id values are restricted to those supplied; watchlists are tenant-scoped and versioned.
REQ-VISION-009 accepted P2
E9 · Sprint 4 - Vision Contract POC
A local VLM adapter must support grammar-constrained output and routing.
Accept: Local VLM adapter produces grammar-constrained output and participates in provider routing/benchmarking (local-vs-hosted quality delta tracked).
REQ-VISION-010 accepted P1
E3 · Sprint 4 - Vision Contract POC
Per-scan UI/UX requirements must be met for each scan type (overlays, ordinal labels, semantic icons, tap selection, why-flagged, next-scan launch, retake guidance).
Accept: Table-hunt/room-scan/item-scan/appraisal UIs meet the listed UX requirements; the UI owns colors/icons/animation while the contract owns overlay_state.
Appraisal Workflows — Vision Contract POC · 5 reqs · 3 built
REQ-APPR-003 accepted P2
E6 · Sprint 4 - Vision Contract POC
Appraisal sharing must support privacy modes and toggles that never expose private addresses or buyer identity.
Accept: share_status private|link|public|seller_inventory with toggles (photo/range/sale-link/city-only/hide-profile); sellers see only aggregates for linked sales.
REQ-APPR-005 accepted P0
E6 · Sprint 4 - Vision Contract POC
Appraisal language must avoid certified-appraisal / guaranteed-value claims everywhere.
Accept: Every appraisal surface shows 'AI estimates are not certified appraisals'; uses 'suggested range/estimate/research recommended'; never 'certified appraisal/guaranteed value/auto-publish'.
REQ-APPR-001 implemented P1 💲 API COST
E6 · Sprint 4 - Vision Contract POC
A buyer Quick Appraise surface must identify an item from a photo and return range, confidence, condition, market context, tags, and photo coaching.
Accept: /trovesnap/appraise takes a photo (+ optional hints + where-found context) and returns identification/range/confidence/condition/tags with photo coaching; token-metered behind /api/appraise.
REQ-APPR-002 implemented P1
E6 · Sprint 4 - Vision Contract POC
Quick Appraise must compute a value signal comparing observed price to the range (bargain/fair/overpriced/research-needed) and offer routing actions.
Accept: deriveValueSignal returns the signal; actions include save (with found context), share, find similar nearby, add to Hunt, add to inventory, create saved search.
REQ-APPR-004 implemented P1
E6 · Sprint 4 - Vision Contract POC
A seller Review Queue must turn bulk photos into flags, editable AI copy, hidden internal pricing guidance, and publish readiness.
Accept: /trovesnap/review-queue surfaces appraisal-recommended / better-photos / demand / wishlist flags, editable copy, internal pricing (hidden from buyers), and feature/hold/door-code controls.
Disposition / What's Next — Demand / Recovery POC · 5 reqs · 2 built
REQ-DEMAND-005 accepted P1
F5 · Sprint 5 - Demand/Recovery POC
Unsold lots must export to external auction pipelines as seller-reviewed packages (never auto-published).
Accept: buildAuctionExportCsv produces a reviewed CSV (title/description/category/condition/suggested starting bid ~40% high est/reserve/tags/notes); auctions are channels, not competitors; nothing auto-publishes.
REQ-DISP-001 accepted P1
F3 · Sprint 5 - Demand/Recovery POC
Wishlist recovery must re-match unsold items against the cross-sale buyer demand graph and offer one-click buyer notification.
Accept: After a sale closes, unsold items match against wanted_items/saved_searches/item_demand_signals; the dashboard + What's Next banner offer 'notify interested buyers' / enable offers to anonymous buyers.
REQ-DISP-003 accepted P2
F3 · Sprint 5 - Demand/Recovery POC
Post-sale analytics must derive recovery metrics from status events + offers.
Accept: Unsold value, recovered revenue, recovery success rate, auction conversion, and disposition outcome breakdown derive from inventory_status_events + buyer_offers.
REQ-DEMAND-004 implemented P1
F4 · Sprint 5 - Demand/Recovery POC
A disposition engine must route post-sale outcomes with explainable recommendations including responsible disposal.
Accept: recommendDisposition() applies the documented priority ladder (wishlist->auction->republish->offers->consignment->clearance/donation) with shown reasons; responsible_disposal is a terminal route; buyer_offers + disposition_recommendations model the flow.
REQ-DISP-002 implemented P1
F4 · Sprint 5 - Demand/Recovery POC
A Workflow Center (Kanban) must make dragging the status transition across two boards with bottleneck counts.
Accept: /trovesnap/workflow shows Inventory Workflow (Imported->Needs Review->Needs Appraisal->Needs Photos->Ready->Published) and What's Next (Unsold->Review->Auction->Offers->Donation->Archived) with demand/wishlist/appraisal chips + recommended next step.
Seller Alerts & Intelligence — Demand / Recovery POC · 3 reqs · 0 built
REQ-NOTIF-001 accepted P1
F3 · Sprint 5 - Demand/Recovery POC
Seller alerts must cover the full set of alert types driven by item/demand/sale state.
Accept: seller_alerts.alert_type spans appraisal_recommended, better_photos_needed, buyer_demand, exact_wishlist_match, publish_readiness, discount_opportunity, unsold_demand_recovery, buyer_offer_received, disposition_review, post_sale_reconciliation, and source_harness, each with its documented actions.
REQ-NOTIF-002 accepted P1
F3 · Sprint 5 - Demand/Recovery POC
The primary appraisal-recommended alert must trigger on high-value categories with clear seller actions.
Accept: Jewelry/watches/coins/sterling/art/antique furniture/vintage audio/cameras/designer/rare collectibles/instruments/etc. trigger 'appraisal may need to be run' with run/request-photos/mark-reviewed/dismiss actions.
REQ-NOTIF-003 accepted P2
F3 · Sprint 5 - Demand/Recovery POC
Alert surfaces must include a dashboard Action-Needed panel, a sidebar Alerts badge, review-queue flags, and demand-page actions, delivered via in-app notifications with per-audience settings.
Accept: The four surfaces render; troveNotifications manages in-app notifications + notification_settings per audience.
Trove Go (Buyer) — Surfaces & Delivery · 4 reqs · 1 built
REQ-BUYER-002 accepted P1
S1 · Surfaces & Delivery
Buyers must save searches, watch sales, save items, and maintain a Hunt/wishlist that drives match alerts.
Accept: saved_searches, watched_sales, item_saves, wanted_items, match_alerts work; Hunt list feeds wishlist matches.
REQ-BUYER-003 accepted P2
S1 · Surfaces & Delivery
Buyers must be able to submit missing sales with confirmation photos through an anti-cheat-scored review flow.
Accept: garage_sale_submissions(+photos) follow review-then-canonical; scoreGarageSaleSubmission + analyzeGarageSalePhoto gate submissions.
REQ-BUYER-004 accepted P2
S1 · Surfaces & Delivery
Buyer tokens must be earned (not bought) and unlock badges, early alerts, and boosted saved searches.
Accept: Tokens earned via submissions/confirmations/check-ins; spendable only on optional perks; token_ledger pending->approved/rejected with balances.
REQ-BUYER-001 implemented P1
S1 · Surfaces & Delivery
Trove Go (buyer) must provide discovery: home, marketplace, map, and item/sale search by item/tag/distance/discount.
Accept: Buyer pages Home/Marketplace/Map render; searchMarketplaceSales + featured sidebar + haversine distance power discovery.
Surfaces (Web / Mobile) — Surfaces & Delivery · 4 reqs · 2 built
REQ-SURF-002 accepted P1
S2 · Surfaces & Delivery
A mobile capture app must support fast sale-floor capture and sync (one app, two modes).
Accept: The Expo RN 'Trove Go' app (Buyer Mode + TroveSnap Capture) supports create/select sale, photos, room labels, notes, sync, and simple review; no keys on device.
REQ-SURF-004 accepted P2
S2 · Surfaces & Delivery
Mobile is capture-first/action-first and web is management-first/analytics-first, with shared domain logic lifted to a shared package.
Accept: Mobile owns photos/check-ins/on-site appraisals/alerts; web owns review/harness/analytics/publishing; shared trove*.ts helpers/types move to packages/core when mobile work starts.
REQ-SURF-003 implemented P1
S3 · Surfaces & Delivery
A connector harness must collect and normalize outside data without exporting secrets.
Accept: TroveSnap Local stores credential/session pointers, runs source connectors, and uploads normalized records; plugin manifests supported; none write canonical inventory.
REQ-SURF-001 verified P0
S1 · Surfaces & Delivery
The web command center must support sales, photos, items, enrich, review, publish, and import history.
Accept: The Next.js web command center is live in apps/web (buyer zone + seller zone chosen by route).
Infrastructure & Deploy — Surfaces & Delivery · 3 reqs · 1 built
REQ-INFRA-001 accepted P1 💲 PAID INFRA
S4 · Surfaces & Delivery
Deploy/infra must take Supabase schema to Cloudflare Workers with analytics.
Accept: Supabase schema deploys first, then Cloudflare Workers via OpenNext, with analytics wired.
REQ-INFRA-002 accepted P2 💲 PAID INFRA
S4 · Surfaces & Delivery
Analytics must combine Cloudflare Web Analytics, PostHog, and Supabase aggregates, following the spine proof.
Accept: Funnel analytics are wired after Sprint 1 spine proof; event volume has a documented paid-tier migration point.
REQ-INFRA-003 implemented P2
S1 · Surfaces & Delivery
A demo mode must serve fixtures with writes as no-ops so every surface is demoable keyless.
Accept: NEXT_PUBLIC_TROVESNAP_DEMO=1 serves src/lib/*DemoData.ts fixtures; writes are no-ops; Storage buckets (estate-sale-photos, garage-sale-submission-photos) defined.
Pricing, Tokens & Monetization — Positioning / Go-To-Market · 3 reqs · 0 built
REQ-MON-002 proposed P2
G4 · Parallel Positioning
Seller plans and token packs must be defined (prototype direction; Codex-owned final pricing).
Accept: Free/Garage, Estate ($12), Estate Pro/Agency ($29) tiers + token packs are specified; payment/POS processing stays out of the early plan; physical SKU pricing stays internal until validated.
REQ-MON-001 accepted P1
G4 · Parallel Positioning
A hybrid model must include routine automation in subscriptions and meter expensive AI with tokens; the QR/identity layer is operational, not premium.
Accept: Included: photo intake, item cards, tag detection, basic copy, sale page, discount phases, CSV import/export, review queue, demand counts, wishlist alerts, basic QR + sold/not-sold tracking. Token-metered: deep appraisal, comp research, batch pricing, image enhancement, marketplace copy, card gen, advanced targeting.
REQ-MON-003 accepted P2 💲 API COST
G4 · Parallel Positioning
AI routing must minimize cost: deterministic mocks first, Workers AI / economy pass, Gemini escalation, deep comps only via tokens.
Accept: No paid APIs required for MVP; live Gemini behind /api/appraise (key optional, simulated fallback, retry on 429/5xx); per-scan_type token/tier budgets enforce cost ceilings.
Customer Research & Beta — Research & Discovery · 6 reqs · 0 built
REQ-RESEARCH-001 proposed P1
R1 · Research & Discovery
Collect a garage-sale field corpus: consistent sample photo sets + item samples for reference and future vision training.
Accept: Sample sets uploaded with consistent capture (scene + item shots), reviewed and accepted by Paul; usable as vision reference/training seed.
REQ-RESEARCH-002 proposed P1
R2 · Research & Discovery
Collect an estate-sale field corpus: consistent sample photo sets + item samples for reference and future vision training.
Accept: Sample sets uploaded with consistent capture, reviewed and accepted by Paul; usable as vision reference/training seed.
REQ-RESEARCH-003 proposed P0
R3 · Research & Discovery
Capture estate-seller pain-point research: conversations/interviews synthesized into themes that inform the build.
Accept: Interview notes uploaded and synthesized into a themed summary; findings feed status.json/roadmap decisions; reviewed by Paul.
REQ-RESEARCH-004 proposed P1
R4 · Research & Discovery
Recruit and onboard an early beta cohort of real sellers to trial enhancements, with feedback captured.
Accept: A small beta-seller cohort is onboarded; feedback is logged and reviewed; consent/privacy respected (no public PII).
REQ-RESEARCH-006 proposed P1
R6 · Research & Discovery
Compile a list of estate sellers / liquidators in Sacramento and surrounding areas (source + contact) for outreach and beta recruiting.
Accept: A deduped prospect list (name, area, source, contact/handle where available) is compiled and reviewed/accepted by Paul; feeds pain-point interviews (R3) and the beta cohort (R4); no scraped private data.
REQ-RESEARCH-005 accepted P2
R5 · Research & Discovery
Prototype the Gmail local-sales discovery module: with seller Gmail consent, surface recent garage/estate sales from subscribed email lists, cross-reference new addresses, and nudge promotion in exchange for free tokens.
Accept: OAuth Gmail consent (tokens server-side only); parses subscribed sale emails into normalized candidate addresses with dedupe; a clean visual list cross-references new vs known addresses; promotion nudge grants tokens; assigned to a contributor and reviewed/accepted by Paul before merge.
Ecosystem — Positioning / Go-To-Market · 2 reqs · 0 built
REQ-ECO-001 accepted P2
G1 · Parallel Positioning
The three product areas (Trove Go buyer, TroveSnap seller, TroveSnap Harness) must keep clear boundaries and a single canonical platform.
Accept: Trove Go = discovery/gamification/alerts; TroveSnap = seller operations; Harness = ingestion/normalization inside TroveSnap; none mutate published inventory without explicit seller approval; naming is consistent.
REQ-ECO-002 deferred P2
G1 · Parallel Positioning
TroveSnap must remain an amplification layer over external channels, never requiring sellers to abandon them, with downstream products deferred.
Accept: External channels are amplified, not replaced; treasure cards (GCMD/CardForge), AtlasIQ routing, and the full gamified Trove Go are explicitly later-phase, not current scope.