Skip to content

Roadmap Item: Release 0.2 — Prepared Foods & Consumption

Status

DRAFT

Date: 2026-02-07

Changelog

Date Revision Description Author
2026-02-07 1.0 Initial version @souperk

Context

After v0.1 delivers the core platform, the biggest gap in the daily user loop is tracking what happens after cooking. Currently, cooking a recipe consumes inventory but creates no record of the resulting meal, its portions, or its shelf life. Users have no way to know what prepared food is in the fridge, how many portions remain, or when leftovers expire.

Users also lack a quick way to log common meals without navigating the full recipe→cook flow. Everyday combinations like "yogurt + granola + honey" require multiple API calls. A quick meal template solves this by saving common ingredient+quantity combos for one-tap consumption.

Additionally, the current cookability check is binary — a recipe is either fully cookable or not. An "almost cookable" threshold would surface recipes where the user is only missing one or two items, making meal planning more practical.

Proposal

Overview

New domain area for prepared foods (cooked meals, leftovers, portions) plus quick meal templates for frictionless consumption logging. Enhance cookability with "almost cookable" threshold support.

Goals

  • PreparedFood aggregate tracking cooked meals with portions, storage location, and expiry
  • Quick meal templates (saved ingredient+quantity combos for one-tap consumption)
  • One-tap consumption endpoint that deducts approximate amounts via FIFO
  • Expiry cleanup mode showing expiring items across batches and prepared foods by location
  • "Almost cookable" threshold parameter on cookability check

Non-Goals

  • Shopping suggestions or auto-generated lists (v0.3)
  • Retailer-specific routing (v0.4)
  • Nutrition data attached to prepared foods (v0.5)
  • Recommendation engine for what to eat (v0.7)

Technical Details

Approach

  • New PreparedFood aggregate with PreparedFoodActivity for portion tracking
  • New QuickMeal entity with QuickMealItem children
  • Extension of existing RecipeService.check_cookability with threshold parameter
  • Unified expiry view combining InventoryBatch and PreparedFood

Dependencies

  • v0.1 must be complete (test stabilization done)
  • loryth-domain: BaseAggregate, AuditMixin (existing)
  • loryth-persistence: BaseRepository, @transactional (existing)

TDs

Backwards Compatibility

  • New aggregates and endpoints only; no changes to existing APIs
  • Cook recipe flow gains an optional create_prepared_food flag (defaults to false)

Implementation Plan

Phase 1: Prepared Foods

  • PreparedFood aggregate + repository
  • PreparedFoodActivity entity for portion consumption/discard
  • PreparedFoodService (create, consume portion, discard, list)
  • Cook recipe optionally creates PreparedFood record
  • API endpoints + Pydantic schemas
  • Migration v07: prepared_foods + prepared_food_activities tables
  • Tests: CRUD, portion consumption, expiry, cook→prepared food flow

Phase 2: Quick Meals & Consumption

  • QuickMeal entity + QuickMealItem children + repository
  • QuickMealService (create, update, delete, list)
  • One-tap consumption endpoint (POST /inventory/quick-consume)
  • API endpoints + Pydantic schemas
  • Migration v08: quick_meals + quick_meal_items tables
  • Tests: CRUD, one-tap consumption, FIFO deduction

Phase 3: Cookability Enhancement & Expiry Cleanup

  • "Almost cookable" threshold on GET /recipe/{id}/cookability
  • GET /recipe/suggestions returning cookable + almost-cookable recipes
  • Unified expiry view: GET /inventory/cleanup?location=FRIDGE
  • Tests: threshold behavior, suggestion ordering, cleanup view

Open Questions

  • Should PreparedFood track the exact batches consumed during cooking?
  • Should quick meal templates be user-scoped or global?
  • What is the default expiry window for prepared foods when not specified?

References