Repository navigation
feat(data): real amounts for catalog recipes rcp-000377..rcp-000934 - #195
Conversation
Packet burst11-fridgeluck-recipe-amounts-b (base alpha ef236fc): - data/recipes/fixes/amounts-b.json: 85 fixes covering all 106 non-staple unknown-quantity lines in the band; 37 lines stay to-taste with notes, 69 get real amounts - evaluation/recipe-quality/amounts_b.py: band reproduction, before/after nutrition, exception markers, report writer - evaluation/recipe-quality/amounts-b.md: per-recipe report - data/recipes/fixes/test_amounts_b.py: 15 tests pinning the fix file, the recompiled records, the nutrition bars, and the validate_corpus gates over the patched corpus
Co-authored-by: obvious-autobuild[bot] <262744130+obvious-autobuild[bot]@users.noreply.github.com>
|
Important Review skippedBot user detected. To trigger a single review, invoke the ⚙️ Run configuration
You can disable this status message by setting the Use the checkbox below for a quick retry:
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
Note Review skipped Codemetrics is installed on this repository, but it hasn't been added to your team yet. To enable AI code reviews for this repo, go to your dashboard and add FridgeLuck to your team's repositories. |
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
What changed and why
The recipe catalog carries 106 non-staple ingredient lines with
unknownquantities inrcp-000377..rcp-000934(85 recipes). Unknown-quantity lines render "to taste" in the app and are excluded from nutrition math, so recipes in this band showed incomplete ingredient amounts and understated per-serving nutrition. This packet replaces each affected corpus record with one that quantifies every substantive line and keeps only genuinely taste-adjusted lines unknown.Files (all new, no existing file modified):
data/recipes/fixes/amounts-b.json— the fix file (schemafridgeluck/corpus-fixes/v1, packetburst11-fridgeluck-recipe-amounts-b, base commitef236fcd): 85 fixes, each pinning the base record'sbefore_sha256and documenting itschanges. Of the 106 band lines, 69 get real amounts (source_grams or a pinned household conversion) and 37 stay unknown with an explicit to-taste note (chiles, finishing herbs, garnishes, salt/pepper).data/recipes/fixes/test_amounts_b.py— 15 tests: band coverage is exact,before_sha256matches the base corpus, titles and ingredient names (the rights-pin inputs) are unchanged, household refs resolve, recompiled records pass the compiler/validator checks, nutrition bars hold, andvalidate_corpus.pyexits 0 over the patched corpus.evaluation/recipe-quality/amounts_b.py— reproduces the band definition from the shipped bundle, compiles before/after nutrition per recipe, and writes the report.evaluation/recipe-quality/amounts-b.md— the per-recipe before/after nutrition report (85 rows).Method: amount anything a cook would weigh or measure to make the dish (proteins, starches, sauce bases, binders, structural produce); leave heat (chiles), finishing herbs, garnishes, and salt-and-pepper "to taste" with a note saying why. Household rows reuse the 129 existing pinned conversion references — no new conversion rows. Exceptions are explained in the fix's
changestext: the ackee-and-saltfish sodium stays high because the dish is built on salt cod (the steps soak and boil it to draw off salt), and the duck-ragu / short-rib recipes sit above the kcal bar because a braise serving carries 200+ g of bone-in meat; the salt-pork red beans and rice quantifies the pork at the classic 150 g soffritto portion for 6 servings.How I checked it
Commands and results (Linux sandbox, CPython 3.12):
python3 -m pytest data/recipes/fixes/test_amounts_b.py -q— 15 passed. Includes: fix file covers exactly the 85-recipe band; everybefore_sha256matches the base corpus line; titles/ingredient names byte-identical; all 106 band lines quantified or explicitly to-taste; household grams equal value × pinned row mass; recompiled records pass vocabulary keys, claim-vs-composition, Atwater, sodium ceiling, timer rule, and thermometer-check placement; kcal 150–1300 and sodium ≤ 2300 mg per serving for all recipes without an explained exception (one initially over-bar recipe was re-portioned to one drained 280 g jar of roasted peppers and re-verified);validate_corpus.pyexit 0 over the patched corpus; committed report matches a fresh render.python3 -m pytest data/recipes/tools/tests -q— 38 passed, 1 skipped (same as base).python3 data/recipes/tools/validate_corpus.py— VALIDATION GREEN on the working tree (rights-clear, claims verified, ids unique, no quarantined recipe;resolved_pctrises on the patched corpus).python3 evaluation/recipe-quality/amounts_b.py— report regenerated; per-recipe kcal and sodium inside bars except the three documented exceptions.What I couldn't check
What I assumed
rcp-000377..rcp-000934, 85 recipes / 106 lines) is reproduced from the shipped bundle inevaluation/recipe-quality/amounts_b.pyand pinned by test.changesfield records the basis. Where the catalog's per-100 g row made a generous portion blow the kcal bar, I sized the portion to the dish's serving count.source_refand ingredient names untouched, nochanges_rights_pinused.feat(data); base branchalpha; draft PR, not merged.