v2.1.0 — cooked check-offs

Meals in a plan can now be checked off as cooked, so the active plan shows at a glance what's been made and what's still ahead.

Cooked check-offs

• Every meal card on an active or completed plan gets a Complete button — tap to mark it cooked ("Completed ✓", the card dims), tap again to undo. The plan header counts along: "5 meals · 2 cooked · active".
• Check-offs follow the plan's lifecycle: revising a plan keeps the check-off for meals that survive the revision (same recipe, same meal type — mirroring how grocery items keep their checked state); completing a plan keeps them as history; reactivating a completed plan ("Cook it again") starts a fresh run with everything unchecked.
• Upcoming plans don't show Complete buttons — nothing's been cooked from a queued plan.

Snappier recipe cards

Recipe cards no longer expand into an accordion with a second "Open recipe" step — tapping a card goes straight to the recipe.

MCP

Additive only, no breaking changes: every plan-reading tool (get_active_meal_plan, get_meal_plan, list_meal_plans, and push_meal_plan results) now includes mealId and cookedAt on each meal, so the agent can answer "what's left to cook this week?". Check-offs happen in the app UI; restart your MCP client (e.g. LibreChat) after upgrading so it picks up the refreshed push_meal_plan tool description.

Upgrading

Back up ./data/, then docker compose pull && docker compose up -d. The database migrates automatically on boot — a single added column, no table rebuilds.

v2.0.1 — migration data-loss fix

Patch release fixing data loss during the v2.0.0 database migration. If you upgraded to v2.0.0 with existing data, your plans survived but their meals and grocery items were deleted — restore your pre-upgrade ./data/ backup and start the container on this version instead. If you haven't upgraded yet, skip 2.0.0 and go straight to 2.0.1.

The bug

The migration runner executes each migration inside a transaction, where the PRAGMA foreign_keys=OFF embedded in the migration SQL is silently ignored. With foreign-key enforcement still active, v2.0.0's meal_plans table rebuild (DROP TABLE) fired ON DELETE CASCADE on meals and grocery_items, deleting every row. Fresh installs were unaffected.

The fix

Migrations now run with foreign-key enforcement disabled at the connection level (re-enabled afterwards), and a regression test walks real v1-model data through the actual migrator asserting meals and grocery items survive the week→plan conversion.

Upgrading

• From pre-2.0 with data: back up ./data/, then docker compose pull && docker compose up -d. Weeks convert to plans exactly as described in the v2.0.0 notes — meals and grocery lists intact this time.
• From 2.0.0 (migration already ran and ate your meals): stop the container, restore your pre-upgrade data/ backup over the current one, pull 2.0.1, start. The migration re-runs correctly against the restored data.
• Fresh installs: nothing to do.

v2.0.0 — plans, not weeks

Caution

Do not upgrade an existing install to this version — its migration deletes your meals and grocery items. Use v2.0.1 instead, which fixes the migration. Fresh installs are unaffected.

Meal plans are no longer chained to the calendar. A plan used to be "a week", and every meal a weekday slot — now a plan is whatever you're actually planning: a full week of dinners, a weekend of brunches, breakfast-lunch-dinner-snacks, or one big Sunday cook.

Highlights

• Plans of any size. A meal plan holds 1+ meals, each typed breakfast, lunch, dinner, or snack. The plan view groups meals under those headings instead of weekdays.
• A plan lifecycle. Plans move through upcoming → active → completed, with exactly one active plan at a time (enforced right down to the database). Push a plan while another is active and it queues as upcoming; promote it when you're ready; complete it when you've cooked through it.
• New Plans section in the app. The old "This Week" tab is now Plans with four sub-tabs — Active, Upcoming, Completed, and Favorites. Upcoming and completed plans show as cards listing their recipes; tapping one opens a full plan view with activate/complete actions.
• Named + favorite plans. Rename plans inline ("Meal Plan 3" until you do), and star the keepers — a plan needs a name before it can be favorited. Your assistant can recall favorite plans and rebuild them on request.
• Meal-typed recipes. Recipes carry meal types too — set explicitly or learned automatically from how they get planned. The recipe list gained meal-type filter chips, and search by type works over MCP.
• Grocery list follows the active plan. Same derived, section-grouped, check-off-preserving list — now tied to whatever plan you're cooking from rather than "this week".

MCP changes

The tool surface grew from 7 to 10 tools: push_meal_plan (now takes name, optional planId to revise, and typed meals — no more weekStart/dayOfWeek), list_meal_plans (filter by status or favorites), get_meal_plan, get_active_meal_plan, activate_meal_plan, complete_meal_plan, plus the existing recipe tools. The wire layer still tolerates small-model quirks (string numbers, "1/2", double-wrapped arrays) and now canonicalizes meal types ("Dinner", "SNACKS" → dinner, snack).

The agent skill was rewritten for the new model and moved: skills/weekly-meal-planning/ → skills/meal-planning/.

Breaking changes

• push_meal_plan arguments changed: {planId?, name?, meals: [{mealType, recipeId | recipe}]} — weekStart and dayOfWeek are gone. Revising a plan now means passing its planId instead of re-pushing the same week.
• get_recent_meal_plans and get_meal_plan_for_week were replaced by list_meal_plans and get_meal_plan.
• tRPC: plans.byWeek / plans.current were replaced by plans.byId / plans.active (+ activate, complete, rename, toggleFavorite mutations); get_recipe returns usedInPlans instead of usedInWeeks.

Upgrading

1. Back up ./data/ (it's one SQLite file — copy the folder).
2. docker compose pull && docker compose up -d — the database migrates automatically on boot. Existing weeks become plans named "Week of {date}": past weeks land in Completed, the current week becomes Active, future weeks become Upcoming. Weekday order is preserved as meal order and recipe meal types are backfilled from history.
3. Re-copy the agent skill from skills/meal-planning/ (the old path is gone), and refresh/reconnect the MCP server in your chat client so it picks up the new tool list.
4. Optionally verify with scripts/verify-mcp.sh http://<host>:8090 — it now pushes a test plan and marks it completed, so it never touches your active plan.