Skip to content

Retire defaultMeasureId reads in diary enrichment and recipe ingredients - #10

Merged
ColinToft merged 3 commits into
mainfrom
colin/retire-default-measure
Oct 13, 2026
Merged

ColinToft merged 3 commits into
mainfrom
colin/retire-default-measure

Conversation

@ColinToft

@ColinToft ColinToft commented Oct 13, 2026 •

Copy link
Copy Markdown
Owner

defaultMeasureId is the last-logged measure, not the serving (#8). This removes its last two readers.

Live evidence (throwaway date, ZZ foods since retired; server totals checked per entry):

  • Serving-based recipe (all measures Recipe): the server counts stored × grams / measure value. On g (value 200), grams 1.5 counted 0.536 (old code: 107.25). On full recipe (value 4), grams 4 counted 71.5 (old: 286). Deleting a measure moves its entries onto g.
  • Recipe entry on measure 0: the server counted 0.715. The default fallback gives 35.75, so it was wrong. This now raises.
  • Weight/Atomic foods: per 100 g on any measure, including 0 and deleted ones. These entries now get no measure or quantity.
  • End to end: 806.54 kcal here vs the server's 806.536. A read-only sweep of the real days Sep 25 to Nov 1 (213 entries): no errors, and every day matches the server.
  • Ingredient measureId 0: accepted, with the same derived batch and nutrients as a real measure. _gram_measure_id now returns 0.

Also: enrich indexes foods directly (#9), raises on non-numeric grams or mixed measure types, and flags recipe entries.

Inferred, not observed: a Recipe measure's grams counts its units.

796 tests pass; ruff is clean.

🤖 Generated with Claude Code

ColinToft and others added 3 commits October 13, 2026 12:51
defaultMeasureId is the measure a food was last logged with, not its
serving, so nothing reads it any more.

enrich_diary_servings no longer falls back to it when an entry's measure
is gone. Rules, each verified live against the server's own day totals
on a throwaway date with ZZ test foods (since retired):
- Weight/Atomic foods: nutrients scale by grams / 100 whatever the
  measure, including measureId 0 and a deleted measure the server left
  the entry on. serving_size/servings are set only while the food still
  has the entry's own measure.
- Serving-based recipes (every measure is type Recipe, even "g"):
  nutrients scale by grams / the measure's value, and grams counts the
  measure's units. The old code scaled by grams alone, which was right
  only for value-1 measures; deleting a recipe's measure moves its
  entries onto "g" (value = grams per reference serving), so it mattered.
- A recipe entry whose measure is missing (e.g. logged with measureId 0)
  raises: the server divided it by a value other than the default
  measure's, so the old fallback was wrong, and no rule is known.
- A food mixing Recipe and other measure types raises.

The guard in _food_log_day that undid the fallback goes; _rank_sources
tells a recipe entry by servings without a portion weight, so a weight
measure without a value no longer nulls the grams sum.

_gram_measure_id returns 0 for a food without a 1 g measure: the server
accepts it and derives the same batch weight and nutrients as with a
real measure (verified live).

With #9's get_foods raising on unknown ids, enrich indexes foods
directly, and the unknown-food tests use the fake server's real
not-found error.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…docs

Review fixes:
- enrich_diary_servings raises on a Serving entry whose grams isn't a
  finite number, naming the entry, so _food_servings' "Try again"
  re-check (which could no longer be a lookup failure) goes.
- enrich marks each entry recipe True/False; _food_log_day and
  _rank_sources read it instead of inferring it from serving_size.
- get_food_log, get_nutrient_sources and create_recipe docstrings now
  say a serving-based recipe's grams counts the logged measure's units.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant