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.