Overview
Dev Sprint 2 delivered the first real product experience for Pantry App. The sprint transformed a bare auth scaffold into a fully navigable, data-connected application. All nine stories were completed and deployed to pantry-app.tapfumamv.com.
The sprint opened with the landing page and Pantry logo, establishing the brand. The navigation shell was then built to wrap all authenticated routes with a consistent sidebar (desktop) and bottom tab bar (mobile). The inventory system was delivered in full: list view, add item, category filter, search, expiry alerts, and baseline stock management. The dashboard was the capstone: real-time data from Supabase driving stock health summaries, low stock alerts, and expiry warnings.
All 13 Sprint 1 tests continue to pass. Three new integration tests were added covering the core Sprint 2 data flows.
Deliverables
| ID |
Story |
Detail |
Status |
| LP-001 | Landing Page + Logo | Inline SVG logo, hero, feature highlights, SA context, full responsive layout | Done |
| NAV-001 | Navigation Shell | Sidebar (desktop 240px) + bottom tab bar (mobile), active state, sign out | Done |
| INV-001 | Inventory List Screen | Live Supabase query, item cards, OK/LOW/OUT/EXPIRING badges, empty + loading + error states, FAB | Done |
| INV-002 | Date of Purchase Display | "Bought DD MMM" format, shown only when set | Done |
| INV-003 | Category Filter and Search | Category pills from live DB, debounced search, combined filter + search, no-results state | Done |
| INV-004 | Expiry Alerts | Colour-coded expiry: muted / amber text / amber bold + icon / terracotta badge based on days remaining | Done |
| INV-005 | Baseline Stock Editor | Modal editor per item, writes to baseline_stock table, badge updates immediately | Done |
| INV-006 | Add Item Form | Route /inventory/add, all fields, validation, SA units, redirect on save | Done |
| DASH-001 | Dashboard Screen | Welcome header, 3 stock health cards, low stock list, expiring soon list, recent activity, all sections with loading + empty states | Done |
Design System Applied
All Sprint 2 screens follow the Kitchen Table design system from Design Sprint 1. Key tokens applied throughout:
Colour Palette (OKLCH)
Warm cream background, forest green accent (max 10% of any screen), terracotta for danger, amber for warnings. No new colour tokens introduced.
Typography
Plus Jakarta Sans for headings (600, 700), DM Sans for body (400, 500). Imported from Google Fonts. Consistent 4pt spacing grid throughout.
Logo
Original inline SVG. Leaf-and-jar mark in deep forest green. Works at 20px and 200px. Used consistently on landing page and in the nav shell.
Responsive Layouts
Sidebar nav on desktop (768px+), bottom tab bar on mobile. Full inventory list and dashboard reflow correctly at 375px and 1280px.
Post-Sprint Bug Fix
After Sprint 2 deployment, a layout bug was identified: the Settings, Budget, and Scan Receipt pages were still wrapping themselves with the old bare Layout component from Sprint 1, causing an unstyled nav list to render inside the main content area. The fix was to remove the redundant wrapper from all three pages (the authenticated shell is provided by AuthLayout for all protected routes). Placeholder sprint labels on those pages were also corrected:
- Settings: "Coming in Sprint 2" corrected to "Coming in Sprint 4"
- Budget: corrected to "Coming in Sprint 3"
- Scan Receipt: corrected to "Coming in Sprint 3"
Fix deployed 2026-03-20.
Integration Test Coverage
| Test ID |
Description |
Result |
| INV-001 | Insert test item via admin client, verify it appears in household query via user client | Pass |
| INV-006 | Add item via user client, verify row exists in DB | Pass |
| DASH-001 | Verify low stock count query returns correct number against known baseline data | Pass |
Sprint Success Criteria
- ✓ pantry-app.tapfumamv.com/ shows the landing page with the Pantry logo
- ✓ Authenticated user with a household sees a real dashboard with real data
- ✓ Inventory list shows items from the database with correct badges
- ✓ User can add a new item and see it in the list immediately
- ✓ All 13 Sprint 1 integration tests still pass
- ✓ 3 new Sprint 2 integration tests added and passing (16/16 total)
- ✓ Logo works at all sizes on landing page and nav shell
- ✓ Responsive on 375px and 1280px, no horizontal scroll
Lessons Learned
1. Old layout wrappers survive sprints
Pages built in Sprint 1 as stubs (Settings, Budget, Scan) imported a bare Layout component. When Sprint 2 introduced AuthLayout as the shell, the old wrappers were never cleaned up, causing double nav rendering in production. Rule: when a layout system changes, audit all pages immediately, not just the new ones.
2. Placeholder sprint labels need a lifecycle
"Coming in Sprint 2" became stale the moment Sprint 2 completed. These labels need to be updated as part of the sprint close checklist, not left as known tech debt.
3. Sprint close checklist must include reports + backlog
Sprint 2 was completed and deployed without a sprint report or backlog status update. This creates a gap between actual state and documented state. From Sprint 3 onward: sprint report + backlog update are part of the Definition of Done, not optional follow-up.
South African Context
- All monetary values in ZAR. Budget screen uses R prefix throughout.
- Store references on landing page: Woolworths, Checkers, Pick n Pay, Makro
- Unit options on add item form include SA-specific units (kg, g, litre, ml, loaf, packet)
- Date format on inventory: "Bought DD MMM" (South African short-date style)
- POPIA: integration tests use
@pantry-test.invalid emails only, all test data cleaned up after each run
Team
| Role |
Responsibility |
| UI Designer | Pantry logo SVG, landing page design, design system application across all Sprint 2 screens |
| Frontend Developer | React components, routing, Supabase queries, nav shell, inventory system, dashboard |
| Backend Developer | RLS verification for new query patterns, baseline stock edge cases |
| QA Engineer | 3 new integration tests (INV-001, INV-006, DASH-001), visual QA across breakpoints |
| DevOps | Cloudflare Pages build and deploy, env var verification |
| Product Owner | AC validation for all 9 stories before marking Done |
Next Sprint
Dev Sprint 3 will deliver receipt scanning using Google Cloud Vision. Key objectives:
- Camera capture or image upload on the Scan screen
- Google Cloud Vision OCR to extract line items from SA till slips (Woolworths, Checkers, Pick n Pay, Makro)
- Review and confirm screen: user validates extracted items before they are added to inventory
- Multi-photo scanning for long receipts (CAP-002)
- Barcode scanning to identify individual products (CAP-003)
Sprint 2 Retrospective
Conducted post-sprint. 10-role team. Format: 4 standard questions.
What Went Well
- ✓9 stories shipped, 0 rollbacks. The full planned scope landed in production.
- ✓Test suite stayed green. 16/16 passing with 3 new Sprint 2 tests. Nobody merged a broken build.
- ✓Expiry alerts and category filter worked first time. INV-003 and INV-004 required no rework after delivery review.
- ✓Post-sprint catch-up was fast. The double-nav bug and stale labels were identified and fixed quickly once someone actually looked.
What Did Not Go Well
Settings, Budget, and Scan shipped with the wrong Layout component. Three pages had double nav rendering in production. This should have been caught in a handoff checklist, not after the fact.
Sprint labels went stale the moment we closed. "Coming in Sprint 2" was still visible in production after Sprint 2 ended. Placeholder content is a story, not a nice-to-have.
No sprint report or backlog update was produced during the sprint. Both were done as a catch-up exercise after close.
This retro did not happen during the sprint close. We are running it after the fact. The team did not have a structured space to surface issues while they were fresh.
What Was Confusing or Unclear
Which Layout component to use and when. No documented rule. Each developer made their own call, which is how the regression happened.
Who owns placeholder and marketing copy. Stale sprint labels exist because no role explicitly owned them.
What "sprint close" actually requires. Retro, report, and backlog update were all implicit. None appeared in the definition of done, so none happened on time.
What We Do Differently in Sprint 3
Add a layout checklist to every story template. Every story touching a page must confirm: correct Layout component, nav renders once, no console errors. This is a gate, not a suggestion.
Sprint-reference copy is a story, not a task. Any string that mentions a sprint number or "coming soon" is tracked with an expiry condition. It ships when the feature ships, or it does not ship at all.
Sprint close is in the definition of done. Last day includes: backlog update, sprint report, retro. All three must happen before the sprint is marked closed.
Full-app smoke pass before declaring done. Settings, Budget, and Scan were not in scope for Sprint 2 but were affected by it. A smoke pass across all non-story pages at sprint close would have caught the double-nav before production.
Retro facilitated post-sprint, 2026-03-20. Actions are owned by the team going into Sprint 3.