USR369 wants a way to close/collapse the entire flavor picker box, not just clear a chosen flavor -- so he can look at the full plain recipe with absolutely nothing else in the way. Added a Hide/Show toggle button in the picker's header row (next to the CHOOSE A FLAVOR label). toggleFlavorBox() collapses the select dropdown + any merged flavor view down to nothing, leaving just the small header with a Show button -- tapping Show brings the whole box back exactly as it was. This is on top of, not instead of, the D996 fix (Back to plain recipe button for clearing just the selected flavor) -- that handles 'I picked a flavor, take me back to plain', this handles 'I don't want to see the picker at all right now, just let me read the recipe.'

USR369's real complaint clarified via follow-up question: 'forced into the recipe choice' and 'you can't even get back into it' -- once a flavor was picked, the merged view showed with no obvious way to return to just the plain recipe (technically possible by re-selecting Plain from the dropdown, but not obvious/discoverable, and the Plain selection was ALSO showing a redundant duplicate box on top of the already-visible normal Ingredients/Directions sections further down the card). Fixed: picking Plain from the dropdown now simply clears the flavor-view box entirely (no redundant duplicate content, since the real recipe is already visible below regardless). Picking an actual flavor shows the merged view same as before, but now includes an explicit 'Back to plain recipe' button right there in the view, alongside the print button -- clearFlavorView() resets the dropdown to blank and clears the box in one tap. This makes the whole picker feel genuinely optional/reversible rather than a one-way commitment, addressing the 'taken over' framing directly.

Two real bugs fixed: (1) 'brought me out of the recipe' -- the flavor-picker's wrapper div lacked event.stopPropagation(), so clicking the dropdown bubbled up to the recipe-card's own onclick="toggleCard(this)" handler and collapsed the whole card shut. Every other interactive element inside the card (card-actions, edit-form) already had this stopPropagation guard -- the picker was simply missed when it was first built. Fixed by adding onclick="event.stopPropagation()" to the picker's wrapper, matching the existing pattern. (2) Discoverability -- the picker was rendering after Ingredients/Steps/Notes, near the bottom of the card, so USR369 didn't know it existed unless he scrolled all the way down. Moved it to the very top of recipe-body, right after the action buttons (Print/Read Aloud/Edit), so it's the first thing visible when a card opens. Also gave it a genuinely bright, high-contrast treatment: 2px solid orange border + tinted orange background box, bold uppercase '🔥 CHOOSE A FLAVOR' label, and a bold 2px-bordered select element -- replacing what turned out to be a SEPARATE latent bug: the original picker CSS referenced var(--line) and var(--board), neither of which are actually defined anywhere in this file's :root (confirmed via grep, 0 matches) -- meaning the picker's border/background were silently rendering as browser defaults this whole time, contributing to why it was easy to miss even before the positioning issue. New CSS uses confirmed, real variables (--orange, --card, --bright).

USR369 flagged real organizational risk: DoughCalc-DIARY.md and BreadCalc-DIARY.md each live inside their own frontend/80-Kitchen/apps/[Name]/ folder alongside their app's HTML, but RECIPES-DIARY.md had been dropped loose at frontend/80-Kitchen/ root -- inconsistent, and would get confusing fast once more builds/diaries exist. Moved RECIPES-DIARY.md to frontend/80-Kitchen/apps/Recipes/RECIPES-DIARY.md, matching the established per-app-folder convention. Since there's no delete capability from this write path (file_write_web.php only creates/overwrites, confirmed no rm/delete tool reaches the remote host), left a short pointer stub at the old location instead of leaving a stale full copy that could drift out of sync -- anyone/anything still referencing the old path lands on a clear redirect note rather than stale content or a dead 404. FLAGGED BUT NOT ACTED ON: recipes.html itself (unlike DoughCalc/BreadCalc's actual app files) also isn't inside its own apps/[Name]/ folder -- it sits at frontend/80-Kitchen/recipes.html directly. Checked and confirmed the Kitchen hub page (frontend/80-Kitchen/index.html) links directly to that exact path, so moving the live app itself would need a coordinated hub-link update too -- a bigger, riskier change than moving a diary file, and not something to do unprompted. Established this as the standing convention going forward: every build/app gets its own apps/[Name]/ folder containing both its HTML and its diary together.

Rebuilt the flavor system per USR369's request: instead of 8 separate print buttons each showing only a one-line flavor description, recipes with a FLAVOR VARIATIONS section now show a single dropdown picker. Choosing a flavor calls updateFlavorView(), which builds a full merged recipe (base ingredients + that flavor's additions split out into individual ingredient lines via splitFlavorAdditions(), combined into ONE real ingredient list) and displays it live on the card as 'Your Recipe: [Flavor Name]' with its own Print button. Print reuses the exact same buildMergedRecipe() logic (single source of truth -- the on-page view and the print output can never drift apart), opening in the separate print window already built. Still exactly one recipe in storage per dish (croutons, bread crumbs) -- the picker is just a different assembled view of the same notes-embedded flavor data, not 8 duplicate recipes. USR369 explicitly said he wants this same reusable pattern for other multi-flavor/multi-variation recipes in the future, so this was built generically (works off any recipe whose notes contain a FLAVOR VARIATIONS section, not hardcoded to croutons/bread crumbs specifically). Verified the merge logic by replicating the exact JS parsing/splitting logic in Python against real recipe #34 data -- picking Italian Cheese correctly produced a clean 7-item merged list (4 base + 3 flavor additions).

USR369 reported the per-flavor print still printed the full recipe/page, not just the isolated flavor -- confirming the previous fix (D991: CSS class toggle + afterprint/matchMedia listeners) didn't actually solve the underlying problem. Root cause: hiding content via a CSS class added immediately before calling window.print() is racing the browser's own layout/paint cycle -- there's no guarantee the browser has applied the new display:none rules before it captures what to print, and this is known to be inconsistent across mobile browsers. Rather than patch the same fragile in-page-hiding technique a second time, REWROTE the approach entirely: printVariation() now opens a genuinely separate browser window/tab via window.open(), writes a minimal self-contained HTML document into it (title, ingredients, the one flavor's addition, directions), and calls print() on that new window. This is structurally immune to the previous bug -- there is no 'everything else' to accidentally show, because the new window's document contains nothing but the isolated recipe+flavor. It also eliminates the return-navigation problem entirely: recipes.html itself is never modified in any way, so there's nothing to restore -- USR369 just closes the print tab and the app is exactly as he left it. Removed the now-dead printArea div, its CSS, the printing-variation body class, and the afterprint/matchMedia listeners, since none of that machinery is needed with this approach. One known tradeoff flagged: if the browser's pop-up blocker is aggressive, window.open() could be blocked -- added a user-facing alert() if that happens, since the click handler running synchronously from a real tap should satisfy most pop-up-blocker allowlisting but isn't 100% guaranteed on every browser.

Two fixes to the per-flavor print feature (D990): (1) Added a 'Plain' row alongside the flavor variations -- prints just the base recipe with no flavor addition. Handled in printVariation() by skipping the Flavor: section entirely when variationText is empty. (2) Fixed the print-recovery bug USR369 reported (print, then get dropped into the main recipe list scrolled toward the bottom instead of back to where he was). Root cause was two-fold: no scroll position was ever saved/restored, and the code relied solely on the 'afterprint' event, which is known to be unreliable on mobile browsers (fires late, early, or sometimes not at all on Android Firefox/iOS Safari specifically -- USR369 uses Android Firefox per his own stated setup). Fixed with three redundant layers so this can't get stuck again: (a) explicit scroll position save/restore via window.scrollY, (b) a second detection path via matchMedia('print') change event alongside afterprint, (c) a visible manual 'Close & return to recipe' button rendered inside the print view itself (hidden from the actual printed paper output via a print media query) as a guaranteed fallback regardless of whether either automatic event fires on his browser.

Two things addressed: (1) confirmed 'two crouton recipes' was a false alarm -- only recipe #34 actually exists; #35 (Bread Crumbs) just mentions the word 'croutons' once in a passing comparison sentence, which is likely what showed up as a second search hit. Nothing duplicated, nothing cleaned up. (2) Built the requested per-flavor print feature. Since the recipe API only accepts a fixed set of known fields (tested directly -- passing a new 'variations' field returned 'nothing to update', confirming no schema flexibility without a backend change), built this by parsing the existing FLAVOR VARIATIONS text already in each recipe's notes field client-side instead of touching the database schema -- lower risk, no migration needed. parseFlavorVariations() finds the 'FLAVOR VARIATION' heading and extracts each numbered line (name + description) via regex. Each detected variation renders as its own row with its own Print button. printVariation() builds an isolated printable page (base ingredients + base steps + just that one flavor's addition) into a hidden #printArea, using a body class + print media query to hide everything else on the page during printing, restoring normal view via the afterprint event. CAUGHT A REAL BUG before deploying: the flavor name/text were being embedded directly into a single-quoted onclick attribute via JSON.stringify (which produces double-quoted strings) -- but several flavor descriptions contain literal apostrophes ("doesn't burn", etc., confirmed 3 occurrences across both recipes), which would have prematurely closed the single-quoted attribute and broken the button. Fixed by HTML-escaping single quotes to ' before embedding. Functionally verified by replicating the exact parsing regex in Python against the live recipe data -- confirmed all 8 crouton flavors and all 5 bread-crumb flavors extract correctly by name.

USR369 caught real formatting issues on recipe #33: decimal amounts (0.333 cup mayo) instead of fractions, and no weight estimates for those who measure by weight instead of volume. Fixed the data: converted decimals to fraction strings (matching the convention already used elsewhere in the Recipes app -- other recipes already store amounts as strings like '1/2', '1-2'), and converted mayo's 1/3 cup into 5 1/4 tbsp (nearest quarter-tablespoon) since 1/3 isn't a quarter-cup fraction. Estimated weights for every ingredient using standard density conversions (sour cream ~230g/cup, mayo ~220g/cup, lime juice ~15g/tbsp water-like, garlic powder ~3g/tsp, sriracha ~6g/tsp, ground cumin ~2g/tsp). ALSO built a new display feature in recipes.html to support this: added an ingredient-weight CSS class (11px, dimmed/70% opacity) and wired the ingredient-amount template to render it as a small span below the main volume measurement when a weight field is present on that ingredient -- the volume/count stays at its normal larger size, weight renders smaller and lighter as requested. This is a general capability now, not just for recipe #33 -- any recipe's ingredients can carry an optional weight field going forward and it'll render correctly.

Two real, confirmed bugs found and fixed in recipes.html's cross-reference link system: (1) the ID-reference regex /\(ID:(\d+)\)/g only matched a colon-format '(ID:8)', but real ingredient data used '(ID 8)' without a colon (Cabbage Slaw's reference to Hot Pepper Crema) -- broadened to /\(ID:?\s*(\d+)\)/g to match both. (2) linkifyNotes() (the function that turns (ID:N) text into a clickable xref-link) was ONLY ever applied to the recipe Notes section -- ingredient names were rendered as plain text and never passed through it at all, confirmed via grep. Applied linkifyNotes to ingredient name rendering too. Both bugs combined explain exactly what USR369 reported: clicking the '(ID 8)' reference inside the Slaw's ingredient list did nothing, because it was never a link in the first place -- wrong format AND wrong code path. SEPARATELY: USR369 confirmed the previously-found Hot Pepper Crema (ID:8) is not the fish taco sauce he remembers. Web-researched a real fish taco sauce (sour cream + mayo + lime + garlic powder + sriracha + cumin, strong consensus across Natasha's Kitchen/Sugar and Soul/Sauce Fanatic/others), added as new recipe #33 'Fish Taco Sauce (Sour Cream)' under category sauce, cross-referenced to Breaded Fish for Tacos (#3) in both directions -- updated #3's notes to flag #33 as the confirmed sauce and #8 as an older, unconfirmed alternative rather than deleting that reference outright.

Created BreadCalc-DIARY.md (frontend/80-Kitchen/apps/BreadCalc/) as the standing build log for a new companion system to DoughCalc that USR369 spec'd out this session: a simplified dough calculator (DoughCalc's core math, no pizza mode, no pan-sizing tools -- everything else including bake temp/time and directions stays) paired with a new percentage-aware Bread Recipe Library, fully separate from both DoughCalc's own presets and Kitchen's general Recipes app. Requested specifically because this project is intended to eventually go to CC[100] for Android packaging (SOP-APP-BUILD-LANES.md) -- USR369 wants a full history attached before that handoff happens. First diary entry captures the complete requirements-gathering conversation (which changed shape more than once before landing correctly) rather than starting the diary only once code exists, matching DoughCalc-DIARY.md's own established format (chronological, dated entries, root-cause/decision framing). Flagged 4 open questions in the diary rather than assuming answers: working names not yet confirmed, color scheme not yet confirmed, import-mechanics scope (manual conversion vs auto-parse) not explicitly re-confirmed after being raised, and extra-ingredient entry mode treated as confirmed-by-inference rather than explicit confirmation. No app code written yet -- this is a planning/diary-only entry, actual build starts next session or later this session.

USR369 caught a real error: recipe #32's first draft used DoughCalc's separate built-in commercial-yeast preset (std-reg-sandwich, oil-based, no starter) instead of USR369's actual sourdough Large Loaf preset (item #49: 600g flour, 62% hydration, 20% starter, 2% salt, 1% malt -- the same base used throughout this session for Bakes #11/#12/#13). Corrected: swapped instant yeast + oil out for 120g active sourdough starter, kept the sourdough process (bulk ferment + folds, shape, proof/retard) intact, and kept only the BAKE-technique changes for a softer crust -- loaf pan instead of Dutch oven, 375F instead of 475->450F, no steam/deep scoring, butter brush after baking + towel-covered cooling. Internal temp target corrected back to 205-210F (sourdough/lean-dough range) rather than the 190F used for enriched yeast breads. Noted in the recipe's own notes that sourdough being a lean dough means it won't get quite as tender a crust as an enriched loaf can, managing expectations rather than overselling the fix.

Root cause of 'you're not adding the directions' finally confirmed: renderSourdoughBasics() had only 2 branches -- (usingStarter && !usingYeast) for pure sourdough, and (usingStarter && usingYeast) for sourdough+added-yeast. ANY recipe using commercial yeast with NO starter at all (like the White Sandwich Bread, or this new soft-crust Large Loaf) fell through to the final 'else { basics.style.display="none"; return; }' -- which not only hid the Basic Steps display but ALSO skipped the Save-as-Recipe Title/Directions auto-prefill code entirely, since that code lives AFTER the if/else chain and the early return never reached it. This was never a bug in the save button's fetch/POST logic (which I'd already probe-tested and confirmed working) -- it was that the Directions textarea was silently staying empty for any non-sourdough recipe, so whatever got saved had empty directions regardless of what the save button did with them. FIX: added a third branch (usingYeast && !usingStarter) with its own commercial-yeast step text (mix, knead to windowpane, first rise, shape+second rise, bake), so this class of recipe now generates Basic Steps AND reaches the prefill code like the other two branches. Marked the orphaned diagnostic-probe recipe (id 31) as needs-review with an explanatory note since there's no delete_recipe action to actually remove it. Backed up DoughCalc first, node --check passed, byte-verified deploy.

Retroactively saved 2 external research findings to Media DB that had been skipped in the moment during the prior session -- REFERENCE-80.md standing duty #5 requires saving any web lookup at time of fetch, this gap is now closed. Also fixed a stale header date on todo-80.md (said 07/16/26, content had real edits since including the 08/28 fermentation-calculator note).

Retroactively saved 2 external research findings to Media DB (M0035 blender research, M0036 Classic White Sandwich Bread source recipe) that had been skipped in the moment during the prior session -- Kitchen's own REFERENCE-80.md standing duty #5 requires saving any web lookup at time of fetch, this was a gap now closed. Also fixed a stale header date on todo-80.md (said 07/16/26, content had real edits since then including the 08/28 fermentation-calculator note) -- backed up first, byte-verified deploy.

Added a 'Load directions from a recipe' dropdown to DoughCalc, completing the round trip -- previously Save-as-Recipe could only write TO the Recipes app, never read from it. Only title+directions load, not ingredients/amounts, since most recipes (like the Sandwich Bread) aren't baker's-percentage style the way the calculator works -- flagged in the app's own UI text. Confirmed the fetch+parse logic against real recipe #29.

Root cause of 'couldn't find' a real recipe: title matching used recipeName.textContent (the loaded DoughCalc preset name) instead of the actual recipe title -- that recipe was never a DoughCalc preset so could never match. Fixed: both save buttons now share one explicit Title field. Also made Save-as-Recipe visible by default per USR369 asking for it to be simpler to find.

Recipes had numeric ids but no visible identifier in the UI, and USR369 is planning a series of interconnected companion apps that need stable references. Added a #N badge to every recipe card's meta row on recipes.html.

Added 'Save it to your recipes' button next to Save to bake log -- appends a dated bake note (with bake temp/time/add-ins context) onto the matching recipe's notes field via update_recipe, never overwrites. Confirmed append-not-overwrite behavior via live probe against recipe #26.

Added a Directions textarea (data-field=steps) to recipes.html's edit form, which previously only had title/notes/user_notes/status. toggleEdit() populates it from parseSteps(), saveEdit() rebuilds the {text:...} JSON array on save. Probe-tested the save path directly against update_recipe before and after deploy.

Added 'Save as recipe' card to DoughCalc: editable Title+Directions (prefilled from computed steps only while blank), builds ingredients from calc(), checks get_recipes for an exact title match -- overwrites via update_recipe if found, creates via add_recipe if not.

Root cause of 'recipe edit doesn't work': _recipeData was read in toggleEdit()/saveEdit() but never assigned anywhere -- confirmed via full-file grep. FIX: attach it to each card after render, matched by data-recipe-id. Server-side update_recipe API confirmed already working via direct probe -- bug was 100% client-side.

Wrote a new sourdough-guide.html section 09 'Making It More (or Less) Sour' covering lactic vs acetic acid and the levers to control it (retard length, starter timing, starter %, flour blend), synthesized from live web research. Caught and fixed a real brace-imbalance bug in the first draft before deploying. Added a missing page-inventory.html entry for the page.

Added a 'Load directions from a recipe' dropdown to the Save-as-Recipe card in DoughCalc, connecting it back to the Recipes app for the first time (previously the connection was one-way: Save-as-Recipe could only WRITE to Recipes, never read from it). On page load, populates the dropdown by fetching get_recipes and sorting by title. Selecting a recipe + clicking Load pulls that recipe's title and directions into the Title/Directions fields -- confirms before overwriting if there's already unsaved text in Directions, since this is a deliberate user action that should override the softer 'only prefill while blank' guard used for the auto-computed calculator steps. SCOPE DECISION: only Title + Directions load, NOT ingredients/amounts. USR369's own wording asked specifically for directions ('so it'll use the directions from the recipes in the calculator'), and most saved recipes (like #29, Classic White Sandwich Bread -- milk/butter/sugar/instant yeast, no starter, no baker's-percentage hydration) don't map onto DoughCalc's percentage-based sliders at all -- auto-filling flour/hydration/salt from an arbitrary recipe would either be impossible (no percentages to extract) or silently wrong. Flagged this limitation directly in the card's own UI text rather than only in the decision log, so USR369 sees it in-app. Also refreshed the dropdown automatically after every successful save, so newly created/updated recipes show up without a page reload. Backed up DoughCalc first (BACKUP.php all_pass true), node --check passed on the extracted script, byte-verified deploy. Functionally confirmed the exact data path against real recipe #29: fetched it via get_recipes, parsed its 8 steps with the same parseStepsForLoad() logic the dropdown uses, confirmed clean parse of both first and last steps.

Root cause of 'I have a sour sour dough recipe, I don't know why it couldn't find it': 'Save it to your recipes' matched against recipeName.textContent (whatever DoughCalc preset/mode is currently loaded, e.g. 'Bread -- default ratios') instead of the actual saved recipe's title. 'Sour Sour Sourdough Bread' was only ever created directly in the Recipes table (via add_recipe), never set up as a loadable DoughCalc preset -- so recipeName.textContent could never equal that string, and the match always failed, no matter what the user typed as a bake note. FIX: both buttons ('Save as recipe' and 'Save it to your recipes') now share the SAME explicit Title input field as the single source of truth for 'which recipe this is' -- removed the implicit dependency on the loaded preset name entirely. If the Title field is empty when 'Save it to your recipes' is clicked, it now says so clearly and points at the Title field instead of silently using the wrong string. ALSO addressed USR369's 'make it simple to add a new recipe' ask: changed the Save-as-Recipe card to be visible/expanded by default (was collapsed like Basic Steps/Bake Notes) since it's now a primary, actively-used feature, not an occasional one. Confirmed the fix with a direct simulation: title='Sour Sour Sourdough Bread' now correctly matches recipe id 26 via the same case-insensitive exact-match logic the button uses. Backed up DoughCalc first, node --check clean, byte-verified deploy.

USR369 asked how to identify recipes (numbers/letters) since he's planning a series of interconnected companion apps (DoughCalc, Recipes, Bake Log, etc all eventually working together) and needs a stable way to reference a specific recipe across them. Recipes already had numeric ids in the DB (e.g. #26) but that id was never shown anywhere in the UI. Added a visible '#N' badge to each recipe card's meta row (next to category and date) on recipes.html so the id is now visible without opening dev tools or the API directly. Also clarified to USR369 (in chat) that the 'create new OR overwrite by title' save behavior he described is exactly what the DoughCalc 'Save as recipe' button (D960, v43) already does -- pointed him back to it rather than rebuilding, since it sounds like he may not have tried it yet after the v44 bake-notes-button work distracted from it. Backed up recipes.html first, node --check clean, byte-verified deploy.

Added 'Save it to your recipes' button in DoughCalc's Bake Notes card, next to the existing 'Save to bake log' button (both now present, side by side -- neither replaces the other). New button: takes the bake note text, matches the currently-loaded recipe name (recipeName.textContent) against get_recipes by exact case-insensitive title, and if found APPENDS a dated block (date + bake temp/time/add-ins context + the note text) onto that recipe's existing notes field via update_recipe -- never overwrites, always appends after a blank-line separator. If no matching recipe exists yet, shows a clear message pointing to 'Save as recipe' first rather than silently failing or creating an incomplete recipe. This directly answers the 'notes disappear from the recipe' complaint from earlier -- that was always about the OLD button (Save to bake log, still unchanged, still logs a standalone item) being a different, disconnected feature from the recipe itself. Backed up DoughCalc first (BACKUP.php all_pass true), node --check passed on the extracted script, byte-verified deploy. Then ran a full end-to-end functional probe simulating the exact same fetch/update_recipe calls the button's JS makes against real recipe #26 -- confirmed the append-not-overwrite behavior works correctly (709 chars before, 841 after with the test block appended, notes not clobbered), then restored the original 709-char content and verified the restore landed exactly.

Real gap found (not the previous _recipeData bug -- this was a genuinely missing feature): the recipes.html edit form only ever had fields for title/notes/user_notes/status -- there was NO field to edit a recipe's directions (steps) at all, confirmed via full-file review of the edit-form HTML. USR369 hit this directly: 'no place to click edit to change the directions.' FIX: added a Directions textarea (data-field='steps') to the edit form, between Title and Notes. toggleEdit() now populates it from parseSteps(r.steps) joined as plain text (one step per line, reusing the existing parseSteps() display helper). saveEdit() now special-cases the steps field: splits the textarea back into lines, strips any leading '1.' numbering, and rebuilds the {text:...} JSON array format before sending to update_recipe -- other fields (title/notes/user_notes/status) still send as plain values same as before. ALSO clarified via conversation: USR369's 'notes disappear' complaint traces back to the DoughCalc 'Save to bake log' button (still unchanged, separate feature) writing a standalone bake-note item, never touching the recipe's own notes field -- this was found and reported several turns ago but a fix for THAT specific disconnect was not yet built/requested; the new DoughCalc 'Save as Recipe' feature (D960) is the intended path for pushing directions/ingredients into a recipe, Bake Notes remains a separate quick-journal feature per USR369's own 'build separately for now' direction. Backed up recipes.html first (BACKUP.php all_pass true). Probe-tested the exact new steps-save code path directly against the live API (update_recipe with a test steps value) before deploying the UI, then again after deploy to confirm end-to-end, restored recipe #26's real content both times. Real node --check syntax validation passed on the extracted script block.

Added 'Save as Recipe' feature to DoughCalc (v42 -> v43): new card with editable Title + Directions fields, prefilled from the computed steps text but ONLY while those fields are still blank -- so adjusting the calculator sliders never overwrites hand-edited directions once the user starts typing. On Save: builds an ingredients array from the current calc() result (flour/water/starter/salt/oil/yeast/malt/add-ins), splits the directions textarea into steps (strips any leading '1.' numbering so it doesn't double-number on the Recipes page), then calls get_recipes and checks for an exact case-insensitive title match. Match found -> update_recipe (overwrites that recipe's ingredients+steps+title). No match -> add_recipe (category=baking, source=DoughCalc, status=untested). Per USR369's explicit direction: same-title saves overwrite, manual editing on the Recipes page stays available too (already fixed this session), and this is intentionally being built as its own feature -- USR369 confirmed Bake Log will become its own companion app later and they'll all get merged eventually, but for now build separately. Did NOT touch the existing 'Save to bake log' quick-note button/behavior -- that's a different, still-standalone quick-journal feature, left as-is per the same 'build separately for now' instruction. Backed up DoughCalc first (BACKUP.php all_pass true), byte-verified deploy, real Node.js syntax check on the extracted inline <script> block passed clean (raw brace/paren counting had shown a false-positive off-by-one from a ')' inside a regex character class [.)] -- caught and correctly diagnosed as not a real bug before trusting it).

Root cause of 'recipe edit doesn't work' on recipes.html: _recipeData was read in toggleEdit() and saveEdit() (card._recipeData) but NEVER assigned anywhere in the file -- confirmed via full-file grep, only 2 hits, both reads. Clicking Edit populated the form from undefined.title/.notes/etc (silent failure or thrown error depending on browser), and Save posted id: undefined to update_recipe. Server-side update_recipe API itself works fine (tested directly via curl, confirmed with a read-back probe on recipe #26) -- the bug was entirely client-side. FIX: after container.innerHTML renders the cards, loop the rendered .recipe-card elements and attach card._recipeData = the matching recipe object (matched by data-recipe-id). Backed up first, byte-verified deploy, brace/paren balance held (183/183, 257/257, +1/+8 for exactly what was added).

Added a new 9th section 'Making It More (or Less) Sour' to frontend/80-Kitchen/sourdough-guide.html (an 8-section narrative walkthrough app w/ Read Aloud support), covering lactic vs acetic acid, cold-retard extension, starter-timing (past peak vs at peak), lower starter %, and whole-grain/rye additions -- synthesized from live web research done at USR369's request after Bake #12 closed. First attempt at the JSON insert had a bug (missing a closing brace on the prior section before appending the new one) caught by the brace/paren balance check (60 vs 59) before deploy -- rebuilt correctly (60/60, 61/61) and verified. Backed up the page first (BACKUP.php, all_pass true). Also added a missing page-inventory.html entry for this page (n:183, status DONE) since it had none -- backed that file up first too. Followed SOP-FRONTEND-LIVE-FIX.md's sequence; TASKGATE had no confident match for this task (weak candidates only) so used that SOP directly rather than writing a redundant new one, since it already covers exactly this kind of live frontend page edit.

Bake #11 (item 45) logged full timeline through result -- came out very good, bottom clean. Confirmed a real fix for the recurring bottom-burn problem: two dry cookie sheets under the Dutch oven for the full bake, documented in item 9 and knowledge-80.md. Found and reported 3 platform access gaps to Server[40] (msg 1147): items unreachable via get_items under any status filter, file-reader.php silent-empty response masking the backups/ web-lock, and a dba_api.php auth rejection with no working fallback.

Logged Sourdough Bake #11 (08/23-08/24/26) as a new items-table entry (id 45): full mix/salt/massage/shape/cold-retard/bake timeline captured, then updated with the result when USR369 reported it -- came out very good, bottom clean. ROOT CAUSE / FIX CONFIRMED: bottom-burn (an open problem since Bake #1/#2, 5500ft elevation) was fixed this bake by TWO dry cookie sheets stacked on the rack below the Dutch oven for the full bake -- prior attempts (single water-filled sheet, pot swap) only partially worked or attributed success to a different variable. Appended this finding to item #9 (the standing bottom-burn note) so the full history lives in one place, and added it to knowledge-80.md as a new BOTTOM-BURN MITIGATION section (also corrected a stale 07/14/26 'last updated' header that hadn't tracked real 08/08/26 content already in the file). SEPARATELY: while trying to fulfil SOP-KITCHEN-LOG.md's spreadsheet dual-write requirement, hit 3 real access/data problems -- (1) items ids 41 (Bake #10) and others unreachable via get_items under any status filter tried, (2) file-reader.php returns HTTP 200 empty-body instead of an error for the Kitchen backup spreadsheet path (masks the documented backups/ web-lock), (3) dba_api.php rejected the standard token as a fallback read path. Reported all 3 to Server[40] via targeted inbox drop (msg 1147, delivery confirmed via get_message read-back) rather than working around any of them (NO-SELF-FORCING). Logged K427 to memory pipeline tying the bottom-burn finding and the access-gap finding together.

Biscotti recipe brought to a fully-specified state (grams throughout, brand/attribution stripped per direct one-off request) after correcting two real platform bugs (wrong-table save; inconsistent mg-conversion math -- both fixed into SOP-KITCHEN-LOG.md, now v1.4). Wrote BUILD-DIARY.md for DoughCalc per SOP-ARTIFACT-HANDOFF.md, registered in ARTIFACTS-80.md, sent a direct (non-broadcast) handoff message to CC[100] with exact file paths.

Found via manual arithmetic check on a screenshot that Total Dough Weight never included add-in ingredient weights -- a bug that predates this session, not introduced by it. Fixed with a new addinGrams() helper. Separately checked index.html/recipes.html/sourdough-guide.html/Journal for the same responsiveness and overlap bug classes found in DoughCalc -- Journal had the same missing-tablet-scaling gap, fixed; the other three were already fine.

First round of DoughCalc fixes -- malt made visible/editable, manual print-exit escape button added, all numeric inputs switched to mobile-friendly type, add-in suggestions made visible instead of silent auto-fill. Full detail in Kitchen's own decision log.

USR369 is taking DoughCalc's web version and having Claude Code convert it into a native Android app. Before handoff, re-verified all 12 fixes made this session were still live and intact (single fresh fetch of the deployed file, checked all 12 markers present, braces/parens still balanced) -- did not just assume prior verifications still held. Wrote BUILD-DIARY.md at the artifact's own location (frontend/80-Kitchen/apps/DoughCalc/BUILD-DIARY.md, not Kitchen's shared gov/ folder, not a generic unscoped filename) per SOP-ARTIFACT-HANDOFF.md -- covers what's done (all 12 fixes, cross-referenced to decisions D825-D836), what's explicitly open (possible further font-size increase, unbuilt softer-bread preset), and critical architecture detail for whoever ports it: DoughCalc's saved-recipe dropdown reads the items table under a [DOUGHPRESET] tag, completely separate from Kitchen's Recipe Board recipes table -- flagged since conflating these two was a real incident earlier this year per SOP-KITCHEN-LOG.md's own history. Registered the diary in ARTIFACTS-80.md. Sent a direct handoff message to CC[100] (targets=100, not a platform-wide broadcast) naming both exact file paths rather than saying 'here' or leaving the receiving system to guess.

USR369 asked directly whether I'd checked the other Kitchen pages -- honest answer was no, the earlier page audit this session only checked comment-map/STANDARDS-REG compliance, not tablet responsiveness, field-overlap risk, or math correctness. Actually did that check now: index.html, recipes.html, and sourdough-guide.html already had proper tablet handling BEFORE today -- a 768px breakpoint with !important font-size overrides on every readable text class, plus a 900px container width (narrower than DoughCalc's final vw-based fix, but a real, working responsive design, not the same bug). Journal/index.html had NONE of this -- locked to a fixed 520px width with zero font scaling, the same class of gap DoughCalc had. Fixed it the same way (vw-based width + explicit font-size overrides for every readable class), scaled generously this time given USR369's direct feedback that DoughCalc's first pass still read as small. Did not find any field-overlap-with-long-hint risk on the other pages (Journal already used align-items:flex-start; the other 3 don't appear to have any field with a comparably long wrapping hint). Did not check for arithmetic/math bugs elsewhere since DoughCalc is the only page that does baker's-percentage math -- the others are read-only displays (recipes) or narrative content (guide) with nothing to sum.

Reviewing USR369's tablet screenshot (font-size fix confirmation), the listed ingredients didn't sum to the displayed total: Flour 490 + Water 355.3 + Starter 98 + Salt 10.8 + Sugar 24.5 = 978.6g, but the displayed Total Dough Weight was 954g -- exactly the sum WITHOUT the 24.5g Sugar add-in. Traced to calc(): const total = flour + waterToAdd + starterWeight + salt + oil + yeast + malt -- addIns were never part of this sum, in the ORIGINAL app design, not something introduced by any of today's fixes. This means every total shown whenever any add-in was present (garlic, herbs, seeds, dried fruit, sugar, cinnamon, malt-as-addin, etc.) has been undercounting the true dough weight since before this session, affecting anything relying on the total (pan-size comparisons, portioning). FIX: added addinGrams(item) -- converts any add-in to grams regardless of its stored display unit (tsp/tbsp/cup/g), using the known density table for recognized ingredients; custom/manual items already in grams pass through directly; a custom item in an unconvertible unit (no known density) is excluded from the total rather than guessed, to avoid fabricating a number. Summed across all add-ins and folded into calc()'s total.

USR369's 3 tablet screenshots (after the width fix) showed correct layout/tabs/no overlap, but text looked small relative to the much wider container. Root cause: bumping body{font-size:15px} in the tablet media query had almost no visible effect because nearly every text element on the page (field labels, hints, input values, totals, breakdown rows, notes, etc.) sets its OWN explicit pixel font-size rather than inheriting from body -- so the body-level bump was overridden everywhere it mattered. Added explicit tablet-breakpoint overrides for ~20 selectors covering field labels/hints, numeric inputs, the main total/breakdown readout, bake-info stats, pan-card fields, notes, and footer -- scaled each up by roughly 15-20% rather than a single blanket multiplier, to keep proportions (headers vs. body text vs. fine print) sensible rather than uniformly enlarging everything by the same fixed amount. Left the small set of inline-styled buttons (Print, Save, Add, etc.) untouched since inline styles can't be overridden without !important and button label size wasn't the reported problem.

USR369 screenshot showed the Crust style field's dropdown visually overlapping the middle of its own hint text (a long multi-line description on a narrow phone screen). Root cause: .field used align-items:center, which centers the input against the FULL HEIGHT of the label column -- fine for a short single-line label, but when a long hint wraps to 7-8 lines, centering put the select box somewhere in the middle of that wrapped text instead of at the top, overlapping it. Fixed by changing to align-items:flex-start, which pins the input to the top of the row (aligned with the first line of the label) regardless of how many lines the label/hint wraps to. This looks identical for every other field with a short label (no visible change there) and only affects fields whose hint is long enough to wrap.

USR369's first responsive-width fix (D831) used fixed 640px/820px breakpoints, guessed without knowing his tablet's actual viewport width. A second screenshot confirmed it was still visibly too narrow -- a real screen-size mismatch, not a caching issue this time (the tab bar and other recent changes were correctly visible, confirming the service worker fix is working). Replaced the fixed pixel values with max-width:min(92vw, 1100px) inside the same 700px+ media query -- scales as a percentage of whatever the actual screen width is, capped at 1100px so it doesn't get absurd on a desktop monitor, rather than guessing another specific pixel number that might again be wrong for his specific device.

Two screenshots (phone + tablet) showed real problems. (1) .wrap had a hardcoded max-width:480px with no responsive scaling -- fine on a phone (near full-width already) but left the tablet screenshot showing a narrow centered column with large unused margins on both sides. Added two breakpoints (700px->640px, 1000px->820px) so wider screens actually use their space; phones under 700px viewport width are completely unaffected. (2) The tablet screenshot also showed a real leftover bug: two separate 'Sugar' entries (10g and 25g) both still on the Add-ins list, each with their own suggested-label and delete button -- this is stale duplicate DATA from before the replace-on-readd fix (D828) existed, most likely compounded by the same stale-PWA-cache issue (D830) meaning that device was running old code when both entries got created. Code-level fixes for future duplicates already exist (D828), but existing bad data doesn't self-heal -- added dedupeAddIns(), runs at the start of every renderAddIns() call, keeps the most recent entry per ingredient name and silently drops earlier duplicates.

USR369 reported not seeing the new tab, despite it being verified byte-exact on the live server via direct fetch. Root cause: service-worker.js used a cache-first strategy for index.html with a static CACHE_NAME ('doughcalc-v1') that never changed across any of today's deploys. Browsers only re-check a service worker file for updates when ITS OWN bytes change -- since I only ever edited index.html (never service-worker.js itself), the browser had no signal to reinstall the service worker or refresh its cache, so the installed PWA kept serving whatever index.html was cached at install time indefinitely, regardless of how many real server-side deploys happened. This likely means some or all of today's earlier DoughCalc fixes may not have been visible either if USR369 was testing via the installed home-screen app rather than a fresh browser tab. FIX: switched the fetch handler from cache-first to network-first (always try the live network fetch first, update the cache with the fresh copy, only fall back to the cached copy if the fetch fails -- i.e. genuinely offline, which is what this caching exists for) and bumped CACHE_NAME to v2 to force an immediate refresh of the currently-stuck stale cache. This is a permanent fix, not a one-time patch -- future index.html edits will now show up on next load without needing another service-worker version bump.

USR369 wanted the Pan settings, Loaf Reference, and Common Measurements cards off the main scroll. Added a 2-tab structure: 'Calculator' (default, includes saved recipes, mode toggle, main output/breakdown, notes, ingredients, add-ins) and 'Pan & Reference' (Pan/Dutch Oven card matching current Bread/Pizza mode, Loaf Reference table, Common Measurements table). Implemented via a data-tab attribute on each top-level card plus a single updateTabVisibility() toggling display based on which tab is active. The Pan cards already had their own mode-based show/hide logic (pizza vs bread) -- extended updatePanCardVisibility() to also require the Reference tab be active, rather than duplicating that logic with a plain data-tab attribute.

USR369's earlier live-rescale fix (D826) was logically correct but incomplete: it only applied to NEWLY added ingredients going forward. Any add-in already sitting in the list (or saved/restored from localStorage) from before that fix has the old {name,amount,unit} shape with no isPct/pct field at all -- addinLiveAmount() correctly checked isPct and returned the frozen .amount for these, exactly as designed, but nothing ever converted these legacy items INTO the new format, so they stayed frozen forever. USR369 worked around this by deleting and re-adding, which DID create a correctly-live new entry -- but the Add button always pushed a new array entry rather than replacing an existing one by name, so the OLD frozen entry stayed on the list too, alongside the new one -- exactly matching his report ('it didn't delete or change what was already there'). FIX: added migrateLegacyAddin(), called as the first step inside addinLiveAmount() (which itself runs first thing in every renderAddIns() iteration) -- converts any item missing isPct into the pct-based format using CURRENT flour as the baseline, so the displayed number doesn't jump, and it's live from that point on. Also changed the Add button to look up an existing entry by name (case-insensitive) and REPLACE it instead of pushing a duplicate, with a status message confirming the update.

USR369 couldn't see the suggested-amount label. Root cause: the sub-label only showed for items with isPct=true, but items added before that field existed (or added a certain way) lacked it entirely, so they showed nothing. Decoupled the label from isPct -- now shows for any ingredient with a known ADDIN_SUGGEST entry, regardless of how it was added. Also added explicit disclaimer wording ('rough starting point, not a tested figure') to both the pre-add hint and the persistent list label, per USR369's ask that people not over-rely on it. Separately, USR369 flagged malt's percentage as suspiciously low and asked for a full web-verification pass on all add-in percentages (M0034 in Media DB has full sourcing). Findings: malt (0.75%) is NOT low -- solidly within the standard 0.25%-1% home-baking range per multiple sources (King Arthur, Perfect Loaf, Epicurious, Chef's Resource, Breadtopia). Cinnamon (1%) is the one real flagged discrepancy -- a commercial raisin-bread formula source uses 0.05%, 20x lower, though this likely reflects subtle-background vs featured-flavor intent rather than either being wrong. Seeds (5%) and raisins/dried fruit (20%) sit at the low end of their published ranges but are legitimate. Honey/sugar/butter/yeast are all comfortably within range. Garlic/herbs/cheese have no firm published baker's-percentage source to check against -- flagged as unverified rather than confirmed. Did NOT silently change any values -- documented findings in code comments above ADDIN_SUGGEST and reported to USR369 for a decision on cinnamon specifically.

USR369 reported: added an ingredient, then changed the flour amount, and the ingredient's weight didn't update. Confirmed real -- every add-in was stored as a frozen {name,amount,unit} snapshot at add-time, read verbatim in 6 places (the add-ins card list, the state-save summary line, both mix-directions text blocks, and the main breakdown row) with nothing recomputing it as flour changed. FIX: known/suggested ingredients (matching ADDIN_SUGGEST) are now stored as a percentage of flour weight (isPct:true, pct computed from whatever amount was entered at add-time) instead of a frozen gram amount. Added addinLiveAmount() helper, recomputes live from current flour on every call; updated all 6 read-sites to use it instead of the raw .amount field. Custom/manual add-ins (typed by hand, no known density) and fixed-count items (Egg) still use a plain frozen amount since there's no % basis to scale from -- that's correct, not a gap. Also added a persistent 'suggested: ~Xunit' sub-label under each add-in in the list (not just while picking one before adding), showing the app's baseline suggestion for comparison even after the ingredient is added. render() now also calls renderAddIns() so the Add-ins card list itself refreshes live, not just the main breakdown.

ROOT CAUSES: (1) malt was a hidden type=hidden baker's-% field only settable via presets/add-ins, no way to zero it once set -- USR369 report matched exactly. (2) print restore already had 4 auto-triggers (afterprint/visibilitychange/pageshow/focus) but zero manual fallback if all failed on his device -- phone back button then exits the whole app instead of just the print view. (3) all 9 numeric inputs used type=number, a known mobile pain point for cursor placement/backspace. (4) add-in amount suggestions (ADDIN_SUGGEST table, pct-of-flour based) existed only as a silent hard auto-fill, never a visible labeled suggestion, and USR369 asked for exactly that as 'a suggestion on the side.' FIXES: made malt a real visible/editable field; added a fixed-position manual exit button (not in PRINT_HIDE_IDS) alongside the existing auto-restore; converted all 9 numeric fields to type=text+inputmode=decimal+.numfield class (preserved styling by moving the CSS selector from type to class); added a live updateAddinHint() showing 'Suggested for Xg flour: ~Yunit' next to the amount field, firing on flour/select/unit change without overwriting typed values.

DoughCalc (Builder-owned, frontend/80-Kitchen/apps/DoughCalc/) has a real bug: Basic Steps Step 1 text omits malt even when the recipe has a nonzero malt value (screenshot confirmed 08/19/26, recipe #19, 2.7g malt shown in breakdown but absent from step text). Likely explains Bake #8's malt omission (08/09/26) - not user error, an app bug. Filed to Builder[20] via inbox msg, not fixed by Kitchen since DoughCalc ownership is Builder's per SOP-ARTIFACT-HANDOFF.md.

Test write from Admin [00] to confirm Kitchen 80-sys.db is accepting data correctly.

DB write test — v1.8 round trip