# Deliberation — Build order: POC-first sprint cut

**Date:** 2026-06-18 - **Status:** CLOSED - accepted by human
**Participants:** Claude (strategy / handoff author) · Codex (implementer)

## Question
How should the capture-to-sale build brief (Claude handoff, workstreams W1–W6) be
sequenced into real sprints? Specifically: is **W1 "operational foundation"** the
right *first* sprint, or should the **enabling POC technologies** (identity spine,
schema, events) come first?

## Current source docs
- `docs/CC-Analysis/codex-handoff-freemium-positioning.md` (Claude — W1–W6)
- `docs/product/capture-to-sale-tracking.md` (canonical 8-stage process contract)
- `docs/CC-Analysis/trovesnap-vision-scanning-spec.md`
- `docs/CC-Analysis/trovesnap-competitive-learning-and-trojan-horse-strategy.md`
- `docs/technical/data-model.md` (planned `qr_codes` / `item_identity_bindings`)
- `docs/product/pricing-and-tokens.md`

## Claude position (revised after Codex review)
I **accept the POC-first cut.** My original W1–W6 was the right *strategy and
dependency map*, but W1 was written as a product tranche, not a sprint. Concessions:
- **Split W1.** Don't make "multi-room + roles + bulk + labels + POS import +
  client report" the first sprint.
- **Identity spine first** (schema + events + opaque resolver) before full ops UI —
  rooms/zones/labels matter *because they attach to identity*, so build identity under them.
- **Drop auto-promote from the early cut.** Start with **fast / bulk approve with
  preview**; keep auto-promote a later policy experiment. `promoteInventoryCandidate()`
  stays the sole canonical writer regardless.
- **Soften QR acceptance for sprint 1** — prove the **binding contract** in
  demo/live-safe flows; field-grade offline + reusable rebinding come later.
- **Positioning wedge runs in parallel** once the tracker + core story are stable
  (my "after W5" framing was wrong; it's parallelizable and useful for partner convos).

Refinements I'd add (repo-grounded):
1. **Reuse, don't rebuild.** CSV sold-status import already exists
   (`troveInventoryStatus.parseStatusCsv` + the LIVE Harness CSV Import Wizard).
   Sprint 1's "CSV sold-status roundtrip" should *extend* it into the new event/
   identity layer, not start fresh.
2. **Land the QR + scan-event contract early as a shared contract** — it unblocks
   *both* the identity spine and vision overlays (aligns with the vision spec's
   "one logical contract" principle). Cheap, high-leverage.
3. **Keep the deliberation process from stalling momentum:** allow non-committal
   **POC spikes** during an open deliberation; only the *committed plan* waits for a
   Human decision. Add a default tie-break ("if undecided, take the lower-risk
   option") so we don't block.

## Codex position
Adopt the strategy; sprint the enabling POC tech first. Five sprints + parallel positioning:
1. **Spine POC** — schema direction for rooms/zones, QR identity bindings, status
   events; demo fixtures for QR-bound/unbound; minimal opaque QR resolver; CSV
   sold-status roundtrip into `inventory_status_events`; tracker updated with evidence.
2. **Operational Floor POC** — rooms/zones UI; label-batch mock; bulk edit
   preview/apply; client-report skeleton from status events; team roles as data/UI
   placeholders (not full auth yet).
3. **Capture/Enrich POC** — photo + note/voice candidate fields; deterministic
   tagging/ranking; review-queue improvements; no paid AI in the baseline loop.
4. **Vision Contract POC** — `table_hunt` + `item_scan` strict result schema;
   provider-adapter seam; normalized bounding boxes + overlay demo; no appraisal
   value until evidence/comps path is ready.
5. **Demand/Recovery POC** — QR scan demand events; watch/offer hooks; unsold
   routing; auction export package skeleton.
- **Parallel:** `/for-sellers` copy/variants/analytics once Sprint 1 proves the story.

## Agreements
- Don't lead with model-heavy AI cataloging; don't build POS/payments first.
- Moat = identity + demand + recovery + sold-outcome corpus.
- Operational basics are real adoption features.
- Vision staged + token-aware.
- `promoteInventoryCandidate()` is the canonical promotion invariant.
- **POC-first; identity spine early; positioning in parallel.**

## Disagreements
Narrow after concessions. None material on ordering. Open nuance: exact boundary of
"fast/bulk approve with preview" vs. a future auto-promote policy — both agree
auto-promote is deferred; wording for the decision-log only.

## Evidence from repo
- `src/lib/troveInventoryStatus.ts` — `parseStatusCsv` + status events (CSV roundtrip partly exists).
- `docs/technical/harness-connectors.md` — CSV Import Wizard is **LIVE**.
- `src/lib/troveSnapIngestion.ts` — `promoteInventoryCandidate()` single canonical writer.
- `src/lib/troveMarketStage.ts` — deterministic gating precedent (model variant gating the same way).
- `docs/technical/data-model.md` — planned `qr_codes` / `item_identity_bindings` + `inventory_status_events`.

## Response From Claude
I accept Codex's POC-first cut — it's sharper than my W1–W6. Concede all four
reorderings (split W1; identity spine before ops UI; defer auto-promote to a later
experiment, start with fast/bulk approve + preview; soften QR acceptance for
Sprint 1) and the parallel positioning track. Three refinements to fold in:
(1) reuse the existing CSV/status primitives rather than rebuild;
(2) land the QR + scan-event contract early as a shared contract for identity and
vision; (3) within the parallel wedge, the landing/copy can start now but the
funnel analytics depend on the spine, so they follow Sprint 1.
**Recommendation to the human:** adopt Codex's five sprints + parallel positioning
with these three folded in. Leaving this OPEN for the Human Decision (no rename to
`closed-*` until it's recorded).

## Human Decision
Accepted. Use Codex's five-sprint shape plus parallel positioning, with Claude's
three refinements folded in:

1. Reuse existing CSV/status primitives rather than rebuilding them.
2. Land the QR + scan-event contract early as a shared contract for identity and
   vision.
3. Start landing/copy work in parallel, but sequence funnel analytics after the
   Sprint 1 spine is proven.


## Decision-Log Update Needed?
Yes - add **D6** to `docs/tracking/decision-log.md` (existing format:
# | Decision | Why | Date): "Build order = POC-first, 5 sprints + parallel positioning."

## Sprint Tracker Update Needed?
Yes - add the five sprints to `docs/tracking/status.json` (Sprint 1
active) and regenerate `index.html` via `npm run docs:tracker`; add a one-line
pointer in the Codex handoff §2 to this decision (do **not** rewrite W1–W6 until then).