Add BACKLOG.md and ideas.md from product exploration session

Captures the design direction from a multi-feature exploratory session:
- Multi-tenant Family epic (decided)
- Product + unit catalogs with family-scoped overrides and free-form additions
- Per-store sections / departments with grouped list UI
- Structured quantities + UoM (required on recipes, optional on lists with sensible defaults)
- Pick-up vs remove distinction for shopping list items
- Add-recipe-to-list flow
- Stores polish: types, confirm-before-delete, duplicate-name bug, toast component
- Foundational items (auth lifecycle, conflict resolution, offline PWA, backup/restore, onboarding, accessibility)

ideas.md holds longer-term explorations (recipe URL import, product images,
item notes, meal planning, observability).

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This commit is contained in:
Josh Rogers
2026-05-06 23:32:56 -05:00
parent cde619e730
commit 6780fb366e
2 changed files with 280 additions and 0 deletions
+30
View File
@@ -0,0 +1,30 @@
# Ideas
Speculative features and explorations — not committed, not scheduled. Captured here so we don't lose them. Items graduate to `BACKLOG.md` when there's appetite to do them.
## Recipe import from URL
- Most recipe sites publish JSON-LD `Recipe` schema.org markup. Parsing it gives ingredients, steps, yield, prep/cook time, and an image — most of what you'd want in our recipe model.
- Flow: user pastes URL → backend fetches the page → extracts JSON-LD → maps to our `Recipe` + `RecipeIngredient` shape, mapping ingredient names through the typeahead so they land with `ProductId` where possible → user reviews and saves.
- High-leverage for a recipe app — a single paste replaces 510 minutes of manual entry.
- Considerations: which sites to support (start with anything that publishes valid schema.org), failure handling for paywalled / JS-rendered pages, abuse prevention (don't make us a free URL fetcher).
## Per-product images
- Big typeahead UX win when a family has multiple "milk" entries (whole, 2%, oat). A small thumbnail in the dropdown disambiguates instantly.
- Storage: object store (Azure Blob / S3-compatible). Curated catalog ships with one image per product; family-uploaded products can attach their own.
- Affects catalog schema design — add an `ImageUrl` (or `ImageId` if we want a separate Images table) to `Product` and `FamilyProduct` so we don't have to migrate later.
## Item-level notes / "running low"
- "Get the organic kind", "the one in the green bag", "make sure it's gluten-free" — instructions that don't fit any existing field.
- Add a `Note` (nullable string) to `ShoppingListItem`. Render as a subtle subtitle under the item name.
- Adjacent: a "running low" mode where checking an item in the *pantry* (or the kitchen, or a recurring-list view) auto-drops it onto the next shopping list. Out of scope for now (pantry tracking is parked).
## Meal planning + auto-generated lists
- Calendar view: assign recipes to days of the week. Generate one consolidated shopping list for the week with quantities aggregated across recipes (e.g., 3 recipes calling for onions → "3 onions" on the list).
- Natural extension of the "add recipe to shopping list" flow once that's solid.
- Considerations: how aggressive the aggregation is (require same `ProductId` AND same `UnitOfMeasureId`? what about recipe ingredients without `ProductId`?), how to handle "I already have onions" (intersects with the parked pantry concept).
- v2 territory.
## Observability
- Currently no structured logging strategy, no metrics, no alerting. The deferred SignalR-versioning memory is the only ops-adjacent item.
- Likely path when it matters: structured JSON logs via Serilog, metrics via OpenTelemetry exporting to a hosted backend (Grafana Cloud or similar low-cost option), basic alerts on error rate and latency.
- Not urgent until the app has more than one family using it in earnest.