Discovery Sprint 1

Sprint 5 Story Specifications

Implementation-ready specs for 4 stories: making it easy to get data in, then making that data useful.

2026-03-31 · Pantry App · 6-role discovery team

Sprint Scope

Four stories selected to close two critical gaps:

Adding items is too slow. The full-form approach and email-gated onboarding mean getting data into Pantry requires too much effort. GRY-002 and GRY-001 attack this: per-item friction and first-use friction.
Inventory data is static and underutilized. Once items enter the system, Pantry just displays a list. INT-001 and GRY-003 add intelligence: "what can I cook?" and "what do I actually have left?"

These four stories form a coherent progression: make it easy to get data in (GRY-002, GRY-001), then make that data useful (INT-001, GRY-003).

Stories

Priority 1

GRY-002: Quick Add P1

Replace the 8-field form with a one-field quick-add (name only). Optional fields behind "Add details" toggle. Frontend-only, no schema changes.

FE 4h BE 0h QA 2h

Priority 2

GRY-001: Time-to-Scan P2

Collapse new-user journey from 8 screens / 125s to 4 screens / 20s. Defer email confirmation, redirect to scanner after household creation.

FE 3.75h BE 0.5h QA 2.5h

Priority 3

INT-001: Recipe Matching P3

Save recipes with ingredient lists, check against inventory. Per-ingredient status: have enough, running low, missing. New top-level nav item.

FE 22.5h BE 4h QA 4h

Priority 4

GRY-003: Passive Depletion P4

Infer consumption from purchase frequency. Flag items as "Likely low" when past their average purchase interval. HA sensor slot for Phase 2.

FE 12h BE 4h QA 3h

Recommended Build Sequence

Sprint 5, Week 1

GRY-002

Quick Add

~1 day

→

Sprint 5, Week 1

GRY-001

Time-to-Scan

~1 day

→

Sprint 5, Week 2

INT-001

Recipe Matching

~3-4 days

→

Sprint 5, Week 2

GRY-003

Passive Depletion

~2 days

Minimum viable pair: If capacity is limited, GRY-002 + GRY-001 address the most urgent pain (getting data in) and deliver a measurably faster experience. INT-001 and GRY-003 can slip to Sprint 6.

Key Design Decisions

Progressive disclosure over separate pages (GRY-002) Expand/collapse toggle within the existing BarcodeScan page. Avoids navigation overhead. Uses max-height + opacity CSS transitions.
Email confirmation deferred, not removed (GRY-001) Supabase auto-confirm returns a session immediately. Non-blocking banner nudges verification within 72 hours. Balances speed against account security.
Recipes as top-level nav item (INT-001) Distinct domain, not a sub-feature of inventory. 5 items in mobile bottom tabs (maximum for comfortable thumb targets).
Dashed badge for inferred vs solid for manual (GRY-003) .badge-inferred with dashed border visually distinguishes machine-predicted "Likely low" from user-set "LOW". Manual baselines always take priority.
Purchase events as append-only log (GRY-003) New purchase_events table rather than deriving history from inventory_items. Clean, immutable data source for the depletion model.
Name-based matching with normalization (INT-001, GRY-003) normalize_ingredient_name() Postgres function: lowercase, collapse whitespace, naive de-pluralize. Fuzzy matching (pg_trgm) deferred.

Effort Summary

Story	Frontend	Backend	QA	Total
GRY-002: Quick Add	4h	0h	2h	6h
GRY-001: Time-to-Scan	3.75h	0.5h	2.5h	6.75h
INT-001: Recipe Matching	22.5h	4h	4h	30.5h
GRY-003: Passive Depletion	12h	4h	3h	19h
Total	42.25h	8.5h	11.5h	62.25h

Schema Impact

Story	New Tables	New Columns	New Functions
GRY-002	None	None	None
GRY-001	None	None	create_household_with_owner() RPC
INT-001	recipes, recipe_ingredients	None	normalize_ingredient_name()
GRY-003	purchase_events	7 cols on inventory_items	recalculate_depletion() trigger

Dependencies and Risks

Cross-Story Dependencies

GRY-001 depends on GRY-002 for fast post-scan experience. GRY-003 benefits from GRY-002's date_of_purchase defaults. INT-001 is independent but benefits from more inventory data.

Key Risks

Risk	Severity	Mitigation
Email confirmation change affects existing users	High	Only new signups change. Test on staging first.
Fuzzy name matching is inaccurate	Medium	Start with substring match. Add pg_trgm if insufficient.
Depletion estimates unhelpful with sparse data	Medium	3-event minimum. Confidence indicator. Per-item dismiss.
No default categories on new household	Medium	Seed 10 defaults in create_household_with_owner RPC.
Bottom nav overcrowded with Recipes	Low	Move Budget out of tabs (Sprint 4 feature).

Further Research Needed

Auth flow options (GRY-001): Validate which of 4 approaches (disable, auto-confirm, magic link, anonymous) are feasible with current Supabase config.
Fuzzy matching strategy (INT-001): Prototype client-side (Fuse.js) vs server-side (pg_trgm). Compare accuracy with real SA grocery names.
Item name normalization (GRY-003): "Clover Milk 2L" vs "Full Cream Milk" vs "Milk" must group. Decide approach: input-time, query-time, or catalogue table.
Consumption model validation (GRY-003): Is linear depletion good enough for SA households? Category-based models may be needed.