Veldarium Worth Portfolio build · 2026
All six systems

Household inventory & food

Pantry Pal

A busy household buys food, forgets it, and wastes it. A kitchen app has to make what is already in the pantry visible, suggest what to cook next, and keep the record honest about what was used and what was wasted.

Product thesis: A household kitchen that actually helps a busy family use food before it spoils, with a calm demo, not a feature list.

Cabberefwenf/pantry-pal · main @ 7e0e0e50 (initial commit only). Demo lives only in open PR #9 @ 8417f813, unmerged.

Interactive demo in development
Conceptual interface illustration, not a screenshot of a live application.

Primary workflow

Friendly, practical, and exceptionally usable. Calm, mobile-first, and built to use food before it spoils.

  1. Pantry inventory with barcode scanning, using a real camera path outside the demo and sample products inside it.
  2. Cook and Count: record what was cooked and what was used, with undo and an audit record.
  3. Recipe discovery over a small seed set, matched against what is on hand.
  4. Shopping list without prices or budgets yet, honestly stated.
  5. Reminders, collections, and discovery, in a mobile-first shell.
  6. Guest demo with three fictional scenarios: a busy household, a budget kitchen, and use-it-up.

Architecture

  • Next.js 15, React 19, TypeScript, Supabase client, ZXing barcode scanning, Vitest, Playwright, axe-core.
  • One transactional inventory engine (applyCommand) shared by the demo and the real backends, with undo and audit.
  • Demo isolation verified in code at PR #9 head: sessionStorage only, demo-first provider, householdId null in demo, no network, no Supabase, no real-kitchen localStorage key.
  • In the demo, real barcode lookup is blocked with an explicit message and sample products are offered. Event logging is a no-op in demo.
  • CSP frame-ancestors 'none'. Its own docs say: link out rather than iframe. Camera and sessionStorage behave differently in third-party frames.

Engineering decisions

  • Demo-first provider: demo mode is decided first and wins over any account, so a demo can never leak into a real kitchen.
  • The assistant in the demo uses a rule-based test provider, labelled not AI, on a frozen snapshot.
  • Release decision in the repo is PARTIAL: demo and portfolio surfaces releasable as a preview; real-household production needs hosted Supabase, a real AI provider, and physical phone checks, all not tested.

Technical challenges

  • The demo exists only in unmerged PR #9, which is not stacked on PRs #3-#8 and would also land the Phase II Supabase and household surface if merged. The merge decision belongs to the founder.
  • Both package-lock.json and pnpm-lock.yaml exist at PR head. The deploy config uses npm ci, so npm is the deploy path.
  • Build requires NEXT_PUBLIC_SITE_URL to be a public https origin. It fails on localhost on Vercel, which is a deploy footgun for previews.
  • Food photography is placeholder emoji and gradients, stated in the repo.

Demonstration scenario

  1. Enter the demo and pick a scenario: two adults, two kids, ten-minute dinners; pantry staples stretched further; or use-it-up.
  2. Scan a sample product, add it to the pantry, and cook from what is on hand.
  3. Watch expiry pressure surface, record use and waste, and undo a mistake.
  4. Reset the demo or exit. Exiting removes every demo key. Closing the tab ends the demo.

Engineering evidence

  • Demo isolation verified in code at PR head: sessionStorage-only keys, demo-first provider, no-op event log, blocked real lookup, visible DemoBanner. [OBSERVED, code read at PR head]
  • Release gates doc claims 254 unit tests and 38 integration tests passed in a simulated environment, plus demo end-to-end and axe runs. None were re-run in VW-100 recon. [DOC-CLAIMED, UNVERIFIED]
  • A CI workflow exists at PR head, with a real Postgres integration job. No CI run results were observed. [OBSERVED, workflow file only]

OBSERVED means read from repository evidence at the stated commit. DOC-CLAIMED means a repository document states it but it was not re-run during reconnaissance. UNVERIFIED means no supporting evidence was obtained. See the engineering inventory.

Known limitations

  • No verified public demo URL in any file read. A prior preview is alluded to in deployment docs, but its URL, freshness, and commit are UNVERIFIED.
  • Hosted Supabase, real AI provider, and physical phone checks are NOT TESTED, per the repo's own release gates.
  • Shopping has no prices or budgets. Six seed recipes only. Offline support is partial.
  • A monetization directory exists at PR head. Whether billing is enabled there was not verified in recon; no billing claim is made here.
  • UI preferences (theme, return-visit counter, reminder toggles) still use localStorage while in demo. They hold no kitchen data; the leak is accepted and documented in-repo.

Sandbox readiness

Session-scoped: sessionStorage only, this tab only. Closing the tab ends the demo. Reset reseeds the scenario; exit removes all demo keys. No time-box; the demo copy says close the tab or press Exit to throw it away. 60-minute depth is UNVERIFIED.

Current portfolio status: Demo unavailable in this harness: demo unmerged, no deployment verified, demoUrl null, allowlist empty.