Skip to content

fix: list every meal that a shopping trip buys for in the PDF - #70

Merged
guplem merged 3 commits into
mainfrom
fix/shopping-pdf-trip-meals
Sep 24, 2026
Merged

guplem merged 3 commits into
mainfrom
fix/shopping-pdf-trip-meals

Conversation

@guplem

@guplem guplem commented Sep 24, 2026

Copy link
Copy Markdown
Owner

The shopping PDF dropped meals from the "Needed for" list of items that keep long. With the bundled defaults, trip 1 bought 28 eggs but listed only the 8 eggs of week 1. The meals of weeks 2 and 3 appeared on no page.

Cause

The PDF assumed that a trip buys only the weeks up to the next trip (_weeksByTrip). The planner puts an item that keeps on an earlier trip, also for later weeks (ADR 0014, 0015). So the trip that bought the item listed only its own week, and the later trips did not buy it at all. The same rule also chose the "Recommended" product from the wrong cooking events.

Fix

  • TripItem.cookDays: the planner records the cook days that each trip item buys.
  • IngredientMealRequirement.cookDayIndex replaces the stored cookWeekIndex, which is now a getter. The model is never saved to a file.
  • buildShoppingPdfDocument puts each meal and each ranking event under the trip whose items hold its cook day. A meal that the owned stock covers goes under the first trip that buys the ingredient, because the list shows the whole need.
  • ADR 0014 now states the day rule.

Result on the bundled defaults (trip 1)

Item Bought Listed before Listed now
Huevo 28 pieces 8 pieces 28 pieces (weeks 1 to 3)
Aceite de Oliva 34 cl 10 meals 28 meals
Pimienta 32 grams 4 meals 12 meals

Tests

  • Red-green TDD. A test with the real planner reproduced the bug first. New tests cover the planner cook days, the requirement cook day, and the owned-stock case.
  • I reverted each rule once, and the matching test failed.
  • 1053 tests pass, flutter analyze is clean, and the format check passes.

🤖 Generated with Claude Code

guplem and others added 3 commits September 24, 2026 13:19
The planner puts an item that keeps on an earlier trip, also for a later
week (ADR 0014, 0015). The week of a trip therefore does not say which
meals its items feed, and callers had no way to know it.

TripItem.cookDays now holds the day of every cooking event that the item
buys for. The next commits use it to justify each trip in the shopping
PDF.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
A shopping trip buys cook days, not weeks, so a meal can only be matched
to its trip by the day of its cook event. _fedSubMeals already tracked
that day and dropped it.

IngredientMealRequirement now stores cookDayIndex. cookWeekIndex stays
as a getter derived from it, so the week is not stored twice. The model
is never saved to a file, so the renamed JSON key breaks no user data.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The shopping PDF assumed that a trip buys only the weeks up to the next
trip. The planner puts an item that keeps on an earlier trip, also for
later weeks, so the PDF dropped those meals. With the bundled defaults,
trip 1 bought 28 eggs but listed only the 8 eggs of week 1, and the
meals of weeks 2 and 3 appeared on no page.

Each meal, and each cooking event that ranks the products of a trip,
now goes under the trip whose items hold its cook day. A meal that the
owned stock covers goes under the first trip that buys the ingredient,
because the list shows the whole need. ADR 0014 now states the day rule.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@guplem guplem added the waiting-for-human-check No human has verified this yet -- direct AI output label Sep 24, 2026
@guplem guplem self-assigned this Sep 24, 2026
@guplem
guplem enabled auto-merge September 24, 2026 11:20
@guplem
guplem merged commit f97bb70 into main Sep 24, 2026
1 check passed
@guplem
guplem deleted the fix/shopping-pdf-trip-meals branch September 24, 2026 11:21
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

waiting-for-human-check No human has verified this yet -- direct AI output

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant