# Changelog ## v6.2.3 — 18 August 2026 **The full-sweep review pass.** Ten module-by-module reviewers over the shipped v6.2.2, then every finding fixed: 5 crash/data-loss items (a prototype-named custom-plant id could kill Seed & supply or the whole Catalog permanently; deleting a journal entry in a read-only-latched tab destroyed its photos irreversibly; ~30 write paths still bypassed the refuseWrite guard, several overwriting the refusal with a success toast; stored content packs were never re-sanitized after import), 19 wrong-behaviour items (zones 9–10 lost their spring stage tasks to a calendar-year test; section-2/3 annuals got perennial windows and care; "Plan a putting-up day" died across New Year; Diagnose's sticky-film key counted "plants" as "ants"; the Kitchen invented a false batch ceiling; containers were still charged field row spacing in the overlap and qty checks; the Jars & lids card — lid-safety line included — never reached either supply export; an unknown pantry method was relabelled "Frozen" with freezer safety copy; and more), and 16 polish/a11y items (including a v6.2.2 regression: the empty savebar left a permanent 8 px band on phones). Full accounting in `CODE-REVIEW-v6.2.3.md` and `FIXES-APPLIED-v6.2.3.md`; two design calls deliberately deferred and written up there. Suites 851/851. ## v6.2 — 15 August 2026 **The diagnosis release. Fourteen views could plan a garden, and none of them could answer the question a gardener actually asks out loud:** *what is wrong with this plant?* The catalog carried a "Common troubles" strip on fifty crops, and the Pests & Disease pack deepened it — but both start from the culprit and work toward the symptom, which is exactly backwards from how the question arrives. Nobody walks in from the garden knowing they have a diamondback moth. They walk in holding a yellow leaf. **Diagnose is the fifteenth view, and it starts where the gardener starts.** Which plant, where it shows, what you can actually see, what has changed lately — then every cause in the key ranked against those answers, each one carrying how to be sure, what to do least-drastic-first, and what it is most often mistaken for. A symptom key sits behind the second tab for anyone who would rather scan a list than be led through one. **The half that was missing is the abiotic half.** "Why is my plant failing" is answered *the hose* far more often than *a beetle*, and an app that only knows pests will confidently name one. So the key was written the other way round: 37 causes, of which 14 are watering, nutrition, weather and culture — over- and under-watering and the wilt that tells them apart, seven nutrient deficiencies with their look-alike traps, heat and frost and light, herbicide drift, transplant shock, root-bound pots, pH lockout, bolting and pollination failure — sitting as equals beside 23 pests and diseases. Blossom end rot is filed under nutrition and its entry says plainly that it is a watering problem wearing a calcium costume, because the eggshells advice has killed more tomatoes than the rot has. **Where the answer is uncertain, it says so.** When the top two candidates land within a point of each other the view says *several causes fit* before it says anything else, and points at the checks that split them apart. The threshold for that admission is deliberately low: one tick of "lower leaves yellowing" scores nitrogen hunger three against drowning two, and feeding a plant whose roots are drowning is the classic way to finish it off. A wrong certainty kills more plants than an honest maybe. **Nothing here is behind the paywall, and nothing here is automatic.** Every tier gets the whole key — diagnosis is correctness, and the rule has always been that correctness ships in every tier. Suite 9 pins that as a source-level guarantee: the module may not call `requirePro`, and may not draw a ✦. Likewise, a diagnosis writes nothing to the garden until asked: the treatment plan and the links to the catalog and the guide are always on screen, and "Log to journal" and "Add follow-up to Today" are buttons. Verified by nine suites — 792 checks, all passing (82, 60, 53, 87, 159, 49, 121, 76, and suite 9's new 105). The badge reads v6.2; the hosted and download builds ship byte-identical. ### The view - **A fifteenth view, `diagnose`**, in Reference beside the catalog and the guide rather than in My garden: it is consulted *about a plant* when something has gone wrong, not walked through as part of the daily round. The sidebar is fifteen and the phone's More sheet is ten; the five-item bottom bar is unchanged, on purpose. suite5's and suite6's pins move with it, as they did for the Pantry. - **The guided read** asks in the order a house call would: the plant (chips for what is in your beds, a dropdown for anything in the catalog, and "not sure" is a valid answer), the part affected, the symptoms — tick as many as fit — and finally what has changed lately. Conditions season the ranking; they never invent a candidate, so ticking "a heat wave" cannot conjure a cause that no symptom supports. - **The symptom key** is the same engine held the other way up: 42 symptoms grouped by plant part, each one opening the causes that produce it. Both doors share one scoring function, so they can never disagree. - **Ticking a symptom repaints the answer in place.** `go()` re-renders the view, scrolls to the top and moves focus to the `h1` — correct on navigation, and violence mid-checklist. Only the choices at the top of the page (the plant, the door, Start over) go through it. The symptom key's list is built once and only re-lit for the same reason the guide's contents list has to hunt down its equivalent anchor after every repaint: the node the reader just pressed should still be the node they pressed. - **A crop gate.** A cause flagged `onlyCrops` — blossom end rot, the squash vine borer — is dropped outright when the named plant is not a host, however well the symptoms match. A diagnosis that cannot apply must not appear. With no plant named it stays in, because generic mode is allowed to say "if this is a squash". - **The crop's own troubles ride along.** Whatever `DATA.troubles` holds for the named plant — the fifty baked strips, and whatever the Pests & Disease pack has filled in — is cross-matched against the ticked symptoms and shown beneath the ranking, matches first. The pack fills that table before this view reads it, so pack depth arrives here without the view knowing packs exist. - **A way in from the plant itself.** The drawer grows a "Something wrong with this one?" button that opens Diagnose pre-filled. Offered on every plant, not only the fifty with a troubles strip — those are exactly the crops nobody wrote a strip for, and the watering half of the key applies to all of them. - **Addressable**, like every other view: `#diagnose/tomato` restores the reading. A plant id naming nothing clears rather than sticks, the same discipline the Kitchen's crop and the bed editor's id already follow. ### Following through - **`RW.diagTasks()` returns tending rows** shaped exactly like `puttingUpTasks()`'s, so a "recheck the soil in two days" flows into Today's Tending card and the calendar's six-week list, and Done / 7d / Not mine work on it through `careDone` and `taskState` with no special handling anywhere. Done writes the journal `task` entry; the journal is the record, as it has been since v5. - **The rows are not bed-filtered**, deliberately, where the care engine's are. A diagnosis is made about a *plant* — often one in a pot on the step, or one the gardener could not name a bed for — so there is no bed to filter by, and dropping the row for want of one would silently lose the recheck the app had just promised to remember. - **`state.diag`** is the new list, hardened in `normalizeState` exactly as the pantry and the seed drawer are: plain objects only, every field clamped, an entry with no label or no valid date dropped, guard-if-present on the optional fields so a normalize pass stays a no-op on clean state and export still round-trips byte-identically. Rows older than roughly a season are pruned — a recheck nobody did last year is not a job, it is a reproach. - **Confirming the same diagnosis twice does not stack the same job**, and a follow-up whose plant has since been deleted still surfaces, filed against the garden rather than dropped. ### The suites - **Suite 9 is new: 105 checks** over the baked key's shape (every cause cites only symptom and condition ids that exist; every cause carries both a way to be sure and a plan), the scoring engine, the honesty gate, the crop gate in both directions, ten named pictures that must each land on their own answer, both doors, the troubles cross-match, all three follow-through paths, the new state and its normalize hardening, the routing, the drawer's way in, the phone, and the every-tier promise. - **Suite 5's sidebar and More-sheet pins move to fifteen and ten**, suite 6's sidebar pin to fifteen, and the version-badge assertions in suites 5 and 8 to v6.2. Those are the pins that are *supposed* to move with a new view; that they had to be edited is the suites working. - **The service worker is `bloomsteader-v6.2.0`**, so an installed copy fetches the new build rather than serving v6.1 out of the cache. ### Known, and not introduced here - **Suite 6's cart section is flaky**, failing eight checks in roughly one run in three on a loaded machine. It is a race in the suite's own `reload()`-then-`sleep(1600)` step, not a defect in the Shop: the untouched v6.1 build fails at the same rate under the same conditions. Re-run before believing it, exactly as suite 1's check #30 has always been re-run. Worth fixing properly — by waiting on a readiness signal rather than a stopwatch — in a release that is about the suites. ## v6.1.6 — 10 August 2026 **A fifth sweep over the putting-up release, and the theme is the number that took the long way round.** v6.1.4 gave `putUpCrops` a default bed list so that a season surface which forgets to ask still describes the garden the global setup filter is showing, and v6.1.5 pushed the area filter through the four surfaces that default could not reach. Both fixes live in `putUpCrops`. Two screens quote pounds without going through it — the decision helper's own pre-fill, and the Kitchen's scaled-batch line — and both called `projectedLb` with no bed list at all, which has always meant every bed you own. **So the helper opens on a garden the card that sent you there is hiding.** Filter to containers with two hundred onions in a raised bed and two hundred in pots, and the Seed & supply list costs 90 lb of onion at 36 quart jars, the pantry-door sheet says 90 lb, the season share card says 90 lb — and "Put it up" opens with **180** in the box, under a caption reading "Pre-filled from this garden's projection — 120–240 lb across the season", and then works that out to "roughly 72 quarts". Four screens, one crop, one filter, two answers, and the wrong one is on the screen whose whole job is to be the place the gardener decides what to do with the pile. The fix belongs in `projectedLb`, not at the two call sites: it is the function that does the counting, so it is the function that should know which garden it is counting. `RW.setupBeds()` is that rule, written once, and `putUpCrops` reads it too rather than keeping a second copy of it. Verified by the eight suites (700 checks, 700 passed — 82, 60, 53, 87, 172, 49, 121, 76, unchanged) and by a probe driving the real build in Chromium, which reproduced each defect below before the fix and asserted against it after. The badge still reads v6.1; the hosted and download builds ship byte-identical. ### The filter that never reached the pounds - **`projectedLb` defaults to the setup-filtered garden**, the same rule `putUpCrops` has defaulted to since v6.1.4. Today's glut warning and `putUpCrops` pass their own lists and are unchanged; the decision helper and the Kitchen's ✦ "your garden projects…" line passed nothing, and now get the garden the rest of the app is describing. - **`RW.setupBeds()`** is the one answer to "which beds is the filter showing". `putUpCrops` had it inline; two copies of a rule is two places for it to drift, which is the whole reason the last two releases exist. ### The count that was right and useless - **The cook-through-the-glut week sheet caps its batch counts at `BATCH_CAP`.** That constant's own comment says it is "shared by the helper's phrase and the pantry-door calendar's column so the two cannot describe the same pile differently" — and the third surface doing the identical division never got it. Twenty-four pounds of onion a week against a half-pound recipe printed **"roughly 24–48 batches at 0.5 lb each"** in a column headed Scale, on a sheet planning seven days, while the pantry-door sheet for the same crop correctly said "12+". It now names the size of the job — "more than 12 batches … split this one across methods" — exactly as the other two do. ### The Pantry - **The shelf caches its photos for the life of the view.** v6.1.1 replaced `RW.go('pantry')` with an in-place `repaint()` and listed "re-reads every shelf photo out of IndexedDB" among the costs it was written to avoid — then `repaint()` called `paintShelf()`, which rebuilt every row and fetched every image again. Ticking three jars off a twelve-jar shelf read thirty-six base64 images back out of the store to redraw pictures that had not changed. Half the fix had been shipped; this is the other half. - **The container latch starts closed.** `unitTouched` exists so a hand-picked container is never overwritten by a later change of method, and it was seeded from the *prefilled* container — which is set to quarts on exactly the path that prefills it. So arriving from "Into the pantry →" on a canning method latched the box on the way in, and switching the method to Frozen left the container reading "quarts". That is the one field the supply list's "N quart jars are currently full" counts, so it miscounted the shelf in the opposite direction from the defect v6.1.5 added the latch to fix. - **The focus restore reads `dataset` instead of building a selector.** The shelf was the only place in the build that spliced stored data into a CSS selector, and `normalizeState` leaves `id` alone the way it does everywhere (`x.id = x.id || uid()`). An imported garden carrying an id with a quote in it made `querySelector` throw a `SyntaxError` out of the Ate one / Remove handler — after the save, so nothing was lost, but the focus restore never ran. Nothing there needed a selector. ### Looked at and left alone - **Today's "Big weeks ahead" ribbon filters on the raw `gap` without consulting `ahead`**, which is the shape of the bug v6.1.3 fixed on the season readers. Swept across all 446 crops: no window in the catalog can satisfy one test and fail the other, because a `gap` inside the ribbon's sixty days can only wrap for a harvest window longer than about 245 days and there is none. A second test that can never change an answer is noise. - The annual-window-into-current-year date resolution, `emit()`'s unconditional "saved to your downloads" toast, the share cards not reflowing for short content, the 14-row year cap, and `putUpCrops` using the first bed's `bedAdj` for a crop planted in several — all as before. ## v6.1.5 — 10 August 2026 **A fourth sweep over the putting-up release, and the theme is the second filter.** v6.1.4 found four season-long surfaces that took no bed list and so never heard about the global setup filter, and gave `putUpCrops` a default that fixed all four at once. That default can only ever know about the setup filter. Today and the Calendar each carry a *second* one — the area — and every surface handed the fix in v6.1.4 is still deaf to it. **So the two buttons sitting on Today's own filtered Tending card describe a different garden from the card they sit on.** Filter Today to "Back", and the "Big weeks ahead" ribbon correctly names one crop, the Tending list correctly carries one putting-up row, and then *Share the season* renders a card headed "2 crops coming in quantity" and *Putting-up calendar* prints a sheet headed "2 crops projected in glut quantities", both of them listing the front bed the same screen is hiding. The Calendar has the identical defect in its own head: a chart filtered to one area, one row on it, and a **Share as image** button beside it that draws every crop in the garden. That is the same sentence v6.1.4 was written to stop, at the one filter it did not reach — and it is worse on a share card than anywhere else, because the card leaves the device. Verified by the eight suites (700 checks, 700 passed — 82, 60, 53, 87, 172, 49, 121, 76, unchanged) and by a probe driving the real build in Chromium: 31 assertions, each defect below reproduced before the fix and asserted against after it. The badge still reads v6.1; the hosted and download builds ship byte-identical. ### The filter the fix could not reach - **`sharePuttingUp` and `puttingUpCalendar` take a bed list.** Today passes the one it has already built from the setup filter *and* the area filter — the same list the ribbon and the tending rows are drawn from. The default is unchanged, so every other caller keeps v6.1.4's behaviour. - **`shareYear` takes a bed list and the name of the area it came from.** The Calendar resolves the area once, above its own page head, and both the care card and the Share button read that one answer instead of computing it twice. The card prints "Year at a glance · zone 7 · Back" when it is filtered, because a filtered card that does not say so is the other half of the same lie, and "Nothing is planted in Back yet" rather than "Plant something in a bed first" when that area is empty. ### The bloom bar nobody could see - **The year share card put `bloom` in the wrong lane, and on 41 of the 446 crops its gold bar was painted straight over the green transplant bar.** The Calendar's chart splits each row into two lanes — sowing above, harvest and bloom below — with a comment saying it exists so "a cool-season crop's four windows pile up illegibly" cannot happen. The card had the same split hardcoded by kind and disagreed about exactly one entry: bloom went in with the transplants. Every flowering perennial in the catalog is affected — yarrow, echinacea, scarlet bee balm, wild bergamot, catnip, catmint, marshmallow, valerian, mullein, rugosa rose, anise hyssop, mountain mint — and on all of them one of the two bars simply vanished, on the card whose legend v6.1.2 rewrote so that every colour on it could be read. The card shares the chart's `LANE` map now, and draws one centred lane where a crop only needs one. Collisions across the catalog: 45 → 4, and the four left are indoor-against-sow, which collide on the chart too. One layout, one set of compromises. ### The pantry - **The container the Pantry's own add form writes was invisible to the only join between the pantry and the rest of the app.** The form defaults to `jars`; the Seed & supply list's "N quart jars are currently full in your pantry — those come back into circulation as you eat them" counts `quarts` alone, and rightly, because a "jar" of unstated size is not a quart and costing it as one would be a guess. So a gardener who canned twenty quarts through the main way in got credit for none of them on the card that exists to stop them buying jars they already own. The container now follows the method — quarts for water-bath and pressure, jars otherwise — which is the rule `pantryOpen` has always applied coming in from "Into the pantry →" and this form did not. A hand-picked container is never overwritten. - **"13 put up and not yet eaten, across 2 crops", on a shelf holding three.** The subtitle's crop count keyed a plain `{}` on the crop NAME, which is free text a gardener types: `a['__proto__'] = 1` adds no own key at all, so the entry vanished from the count while its jars stayed in the total. v6.1.4 gave `pantryDiff`'s `byCrop` a null prototype for this exact reason and left the identical reducer three hundred lines below it alone. - **Cold storage contradicted itself once it aged out.** Every other method in the shelf-life table has a real quality window; `coldstore`'s own line says the figure is not the thing to go by — so a five-month-old crate printed "Past its best window — Depends on the crop and the room more than on any figure." It reads "Long enough in storage to be worth going through" now. The months stay: they are a prompt to go and look, not a verdict. ### Two that fire twice - **The decision helper rebuilt itself on every keystroke.** `paintPaths` tears down and rebuilds five cards, re-filters the recipe list, walks the installed packs and builds up to six `
` equipment blocks — and it was wired straight to `input`, so typing "12.5" ran all of that four times. Debounced at 120 ms, the way the Kitchen's search box has been, and the timer is cleared on close so a rebuild cannot land in a sheet that has gone. - **Every share button ran its card again on a double-tap.** All five cards await — the canvas, and three of them one or more photos out of IndexedDB — so a render takes the better part of a second, and two taps put two identical PNGs in the downloads folder. `shareBtn` latches and disables while it works, which is the guard the Pantry's Add button got in v6.1.2. ### Housekeeping - **Today walked the season twice per render.** The "Big weeks ahead" ribbon asked `putUpCrops` for the next 60 days and the Tending card asked `puttingUpTasks` for the same season a second time, each walking every bed, every planting and `projectedLb` per crop. It is computed once now and handed to both; `within` was only ever a filter on that list, so the ribbon applies it rather than buying a second walk. `puttingUpTasks` takes `opts.crops` for this and keeps its own default for every other caller. - **The "Replace everything?" dialog counts the pantry.** It itemised beds, journal entries and photos so the gardener could tell the right file from the wrong one, and replaced the shelf in silence — the one collection in the app that cannot be re-derived from anything else. - **Five exports with no reader are gone:** `RW.EQUIP`, `RW.SHELF`, `RW.PANTRY_INSPECT`, `RW.equipBlock` and `RW.TESTED_LINE`, none of them read by the app or by any of the eight suites. `RW.LID_LINE` stays, because the Seed & supply list genuinely prints it. ### Known, and deliberately unfixed - **The year card still shows the garden in all three Calendar tabs.** In "Plantable in the next 6 weeks" and "Everything in my zone" the chart is zone-derived and is not this garden at all; the card is always the garden, because a shareable image of 446 crops nobody planted is not a thing anyone posts. The area mismatch was a card and a chart disagreeing about the same subject; this is the card declining a subject that has no card in it. - **The Jars & lids count still reads `quarts` only.** Counting a `jar` as a quart would be the guess the whole card is written not to make. The fix belongs at the point of entry, and that is where it went. - Everything recorded under this heading in v6.1.2, v6.1.3 and v6.1.4 stands: the annual-window-into-current-year date resolution, `emit()`'s unconditional "saved to your downloads" toast, share-card reflow for short content, the 14-row year cap, `putUpCrops` taking the first bed's adjustment, and no "Put it up" button in the plant drawer. ## v6.1.4 — 10 August 2026 **A third sweep over the putting-up release, and the theme is a list with two things in it that the code read as one.** v6.1.2 was a filter half a card obeyed; v6.1.3 was a flag the app computed and never read. This one is the same shape one step earlier: `windows()` hands back a *list* of harvest windows, and `putUpCrops` took the first one it found and stopped looking. **63 of the 446 crops carry two harvest windows.** Every cool-season crop in the catalog gets "Harvest — spring sowing" and then "Harvest — fall sowing", in that order — and the whole putting-up layer only ever saw the spring one. Plant cabbage, broccoli and kale, ask the app on 10 August, and 240 lb of brassicas arriving 25 October – 8 December produced **no "Jars & lids" card at all**, a pantry-door calendar headed *every window has closed for this year* with three rows marked "· closed", a season share card that toasted *nothing in this garden has a glut window still ahead of it*, no "Big weeks ahead" ribbon, and no "Plan a putting-up day" row — on the same screen that was telling the gardener to sow the succession row that feeds it. Verified by the eight suites (700 checks, 700 passed — 82, 60, 53, 87, 172, 49, 121, 76, unchanged) and by a probe driving the real build in Chromium: each defect below was reproduced before the fix and asserted against after it. The badge still reads v6.1; the hosted and download builds ship byte-identical. ### The season the app could not see - **`putUpCrops` picked the first `harv` window rather than the nearest one.** It now ranks every harvest window a crop has by the same test `ahead` and `rank()` already use — open now, else soonest opening, else most recently closed — and takes the best. The window chosen, the tense written over it and the order it sorts in are now one decision instead of three. Cabbage on 10 August moves from "closed, 11 weeks, ended 22 July" to "ahead, 6 weeks, 25 Oct – 8 Dec", and all five season surfaces follow it. ### The four smaller ones behind it - **The season-long readers ignored the global setup filter.** Today and the Seed & supply list have always handed `putUpCrops` their own filtered bed list; the printable calendar, the season share card, the glut week plan and the Kitchen's week-plan test handed it nothing and got the whole garden. So the calendar offered from Today's filtered Tending card listed the raised beds that same card was hiding. `putUpCrops` now defaults to the beds the setup filter is showing. - **The share card printed "0 lb" as its hero number.** The journal form always writes an `amount` for a harvest — a blank box stores a hard `0` — and the timeline correctly hides its weight pill on `if (e.amount)`. The card tested `!= null`, so an entry showing no weight on the screen the Share button sits on came out as a 96px clay **0 lb** under a subtitle reading "0 lb · 10 August 2026". Same test as the timeline now. - **The "Can it" card advertised the Preserving pack to people who own it.** Ten of the 41 crops the pack covers carry no jar route in it — cabbage, onion, garlic, leek, basil, parsley, dill, cilantro, melon and horseradish — and on every one of them the card closed with "The Preserving pack carries the prep and the safety notes crop by crop", which is the sentence for somebody who has not bought it. Three sentences now: the pack covers this crop and has no jar route for it, the pack does not cover this crop, or the pack is not installed. - **A `nocan` crop lost its whole equipment list, not just the canning half.** The guard dropped every pack method the crop had, so broccoli — which this screen has just told you in red to freeze, and which the pack carries a full freezing method for — got no "What the day needs" card at all, while cabbage beside it got two. Only `waterbath` and `pressure` are dropped now. ### Housekeeping - **The put-up-versus-eaten review walked `Object.prototype`.** `byCrop` was keyed on the crop NAME, which for a free-typed pantry entry is the only lookup table in this build fed straight from the keyboard. A jar labelled "constructor" kept Object's own constructor through `|| {}`, wrote `NaN` onto it, and printed a row reading *constructor · NaN · NaN · Plan for less, or eat more of it*. Null-prototype, like `tierOf` and `sanitizePack`. - **A rejected photo write leaked its id into `pendingPhotos` forever**, where it counts against `PHOTO_CAP` for the rest of the session. `photos.put` resolves `false` for the failures it expects but can still reject — `db.transaction()` throws synchronously inside its promise executor once IndexedDB has closed — and both the pantry and the journal deleted the id on the happy path only. - **The "N quart jars are currently full in your pantry" line lived inside `if (needQt)`.** A card whose every row read "not canned" or "no figure" printed no total and took that line down with it — the one number on the card that is not an estimate at all. - **Batch counts are capped at a dozen.** A 0.5 lb recipe against 50–72 lb of kale printed "99–144 × Kale chips" in a column headed *Batches* on the sheet that goes on the pantry door, and "about 144 batches" in the helper. The arithmetic is right and the instruction is absurd; both now say "12+" and the helper names the size of the job instead of counting it out. - `wrap()` on a share card checks its floor before the first line as well as between them, and `shareYear` builds its legend from the bars as it draws them rather than walking every row's windows a second time to ask what it had just painted. ### Known and deliberately unfixed - The annual-window-into-current-year date resolution, `emit()`'s unconditional "saved to your downloads" toast, share-card reflow for short content, and the 14-row year cap — all as recorded in v6.1.2 and v6.1.3. - `putUpCrops` still takes the bed adjustment of the first bed a crop appears in. A crop under glass in one bed and in the open in another is projected across both and dated from one; the alternative is a per-bed row for one crop, which is a worse answer on every screen that reads this. - The plant drawer still has no "Put it up" button. Five other surfaces open the helper; the drawer is a reference screen and the harvest card directly above it in Today is the moment that question gets asked. ## v6.1.3 — 10 August 2026 **A second sweep over the putting-up release, and the theme is a flag the app computed and never read.** v6.1.2 was about a filter half a card obeyed and a season described in the wrong tense. This one is the same shape one layer down: three of the four findings are a value that already existed, already correct, sitting in the object every reader was handed — `nocan` on the jar arithmetic, the bed list on the calendar's tending card, the window's own closing date — while the surface above it went on stating something else. The app was not missing the information. It was not asking. The one that matters most is a safety contradiction. **The Seed & supply list's "Jars & lids" card and the printable pantry-door calendar were both handing out quart-jar counts for the five crops the app elsewhere says in red must never be canned on their own.** Nothing throws, all of it passed 700 checks, and a gardener reading the shopping list would have bought 34 quart jars for elderberries. Verified by the eight suites (700 checks, 700 passed — 82, 60, 53, 87, 172, 49, 121, 76, unchanged) and by a probe driving the real build in Chromium: each defect below was reproduced before the fix and asserted against after it. The badge still reads v6.1; the hosted and download builds ship byte-identical. ### The shopping list costing jars for a crop that must not be canned - **With elderberries coming in, the Seed & supply list printed "Elderberry · 30–90 lb · 34" under a red box about lids, and totalled "About 34 quart jars' worth across the season".** The printable putting-up calendar said "about 34 quarts" in a column headed *In jars*, and "about 23 quarts" for brussels sprouts. Open the same crop in the decision helper and it prints, in the warning band: *No safe home-canning process for this crop on its own — do not improvise one, and do not adapt a recipe from another vegetable.* The catalog says it. The Preserving pack says it. Two surfaces were selling jars for it. `jarsFor()` has returned `nocan` since the day it was written and **no caller had ever read it** — the pounds-per-quart figure exists for the harvest planner's "I want twenty quarts, how much do I plant?", and run backwards onto a shopping list it stops being a conversion and becomes an instruction. Both surfaces now print `not canned` where the flag is set, keep those crops out of the jar total, and carry the same sentence the helper does. The supply list's explanatory lines were split apart while I was there: they used to hang off the end of the total, so a table of nothing but refusals said "None of these crops has a published figure" — a sentence that would have been false the moment one of them was counted. ### A tending list that had not been told which garden - **On the calendar, with the setup filter on "container", "Tending — the next six weeks" opened with "Broccoli — cover direct-sown brassicas" for a raised bed the app was hiding.** This is exactly the defect v6.1.2 fixed on Today, at the second site nobody looked at: Today filters its beds and hands the same list to both engines, and the calendar's copy of the card called `careTasks({horizon: 42})` and `puttingUpTasks({horizon: 42})` with no bed list at all, above a chart drawn from a bed list that *had* honoured the filter. It takes the filtered list now. The area filter rides along too, but only in the mode that draws an area control — a remembered area quietly narrowing a list on a screen with no visible way to widen it would be the same bug pointing the other way. ### A season that had been over for five months, still "coming" - **On 10 August, a crop whose harvest window ran 10 February – 7 March was headlined "coming in quantity" on the share card, printed its February dates with no `· closed` beside them, counted itself in "still ahead" on the pantry-door sheet, and had jars bought for it on the supply list.** `ahead` was `gap >= 0`, and `gap` comes from `daysToWindow`, which wraps at ±180 because it answers a different question — how far to the nearest edge of the next occurrence. A window that shut 156 days ago comes back as **+184**, and every one of the four sentences v6.1.2 was written to stop came back with it, at a boundary nobody had looked at. The flag is measured from the window's own close now: the crop is ahead if it is open today, or if its next opening is nearer than its last closing is far behind. The sort learned the same thing — the closed ones rank on how long ago they closed rather than on a negated gap, so a wrapped one can no longer sort in among the crops genuinely arriving. ### Two counters walking one list - **The seven-day glut sheet could serve the same recipe twice and never reach the third.** v6.1.1 gave the rotation a counter per crop and per job, which was right; it keyed the counter on the job the day *asked* for. A crop whose recipes are all one category falls back to the other pool — broccoli has three fresh recipes and no preserve one — so that single pool got two independent counters walking it. The key is the pool actually used now, which is the same test the Job column prints, so the counter and the column cannot disagree about which list was read. ### Smaller - The decision helper called `preserveWays()` twice per render, and it repaints on every keystroke in the amount box: typing "12" walked every installed pack and every method in it four times to answer the same question about the same crop. Once, at the top, like the projection above it. ### Known and deliberately unfixed - **The season surfaces still resolve an annual window into the current calendar year** (`fmt` drops the year, so the month and day are right). With `ahead` now measured from the close, the only rows this can reach are ones genuinely arriving in the next few months, which is the case the shortened date reads correctly for. - **The helper hides the Preserving pack's pickled route for a `nocan` crop.** The pack carries an honest "pickled per a tested recipe is the only safe jar" entry for broccoli and cauliflower, with its own red safety block, and the catalog drawer shows it; the helper's refusal branch fires first and shows only the red line. Conservative on purpose, and the catalog is one tap away. - **Share cards still do not reflow for short content**, `emit()` still toasts unconditionally, and the year card's 14-row cap is still a cap — all measured again this pass, all still deliberate. ## v6.1.2 — 10 August 2026 **A review sweep over the putting-up release, and the theme is a filter that only half the card obeyed.** v6.1.1 fixed a sort that ran the wrong way; this one is about what got *written over the top* of that sort, and about the second engine on a screen where only the first one had been told which garden it was describing. A bed list passed to one function and not the one beside it. A season list sorted correctly and then counted as though every crop in it were still coming. A box holding one number under a caption quoting another. None of it throws, all of it passed 700 checks, and every one of them is the app stating something it has no basis for. Verified by the eight suites (700 checks, 700 passed — 82, 60, 53, 87, 172, 49, 121, 76, unchanged) and by a probe driving the real build in Chromium that rendered every share card to disk: each defect below was reproduced before the fix and asserted against after it. The badge still reads v6.1; the hosted and download builds ship byte-identical. ### The card said "coming" about a season that was over - **On 10 August the share card read "Putting up 2026 · 5 crops coming in quantity" and three of them had finished in May, June and July.** `putUpCrops()` returns the whole year when no `within` is passed, which is exactly what the three season-long readers want and exactly what none of them then said out loud. v6.1.1 sorted the closed windows to the bottom and stopped there; the headline above them still counted all five as arriving, and **Jars & lids on the Seed & supply list asked a gardener to buy 58 quart jars for a tomato window that had closed on 21 July** — a shopping list costing a crop that was already eaten. Each row now carries `ahead`, computed beside the `gap` it reads, so the three surfaces cannot drift apart again: the share card takes only what is still coming, the printable pantry-door calendar keeps the whole year but marks a finished window `· closed` in the cell and counts how many are still ahead in its subtitle, and the jar arithmetic buys for the future only. ### Half a card obeying the filter - **With the setup filter on "container", Today's Tending card listed "Cabbage — thin seedlings" for a raised bed the app was hiding.** The putting-up rows beside it correctly vanished, because they had been handed the filtered bed list since the day they existed — and the comment above them said that made the whole card honour the filter. `careTasks` was still walking `st.beds`. It takes a `beds` option now, the way `puttingUpTasks` always has, and Today passes the same list to both: two halves of one card had been describing two different gardens. ### A box and its own caption disagreeing - **Opened from Today with a filter on, the helper's amount box said 150 lb and the line underneath it said "Pre-filled from this garden's projection — 70–240 lb".** Today passes the pounds *its* filtered beds project; `paint()` ignored that and recomputed the projection over the whole garden to write the caption. The projection is now computed once, at the door, and the caption prints what was actually used — or says the number was carried over from the screen you came from, which is the truth when one was. It also stops a second whole-garden walk on every open. ### The pantry - **Eating the last jar of a row threw focus, and the scroll with it, to the crop box at the top of the form.** The row disappears when the count hits zero — exactly as Remove does — and only Remove knew it: `repaint` hunted for a button on a row that no longer existed and fell through to its `nameIn` fallback. Ate one hands off to the neighbouring row now, and the fallback itself uses `preventScroll`, because it exists to keep focus off `` and not to move the page. - **An emptied shelf rendered the "On the shelf" card with its heading, its three buttons and nothing underneath**, over a subtitle reading "0 put up and not yet eaten, across 0 crops — oldest first, because that is the order to eat them in". The empty state was gated on every entry ever made and the list is built from what is left of them; those are the same array until somebody eats the last jar. Two empties, and they are not the same thing: never filled gets the explanation, emptied gets congratulated. - **The share card walked storage order** while the shelf, the labels and the "eat these first" line are all oldest-first — so the card disagreed with the screen it was launched from, and the twelve-row cap kept an arbitrary twelve rather than the twelve the app everywhere else says matter. Sorted now, and the shelf shot leads with the *newest* photo rather than whichever entry happened to sort first, which after the sort would have been the oldest thing in the pantry. - **The count column was laid out by measuring the numeral**, so every row past nine pushed its text 20px right of every row under it — a ragged edge down the middle of the app's most-postable image. Right-aligned in a column of its own now. - **The add form was the only data-entry form in the app with no visible labels** — a box containing "1" beside a box containing a date, and nothing on screen to say what either was for. The aria-labels stay; the words are above the controls now, as they are in Settings, the journal and the bed editor. - **The photo cap counted what had landed, not what was in flight.** The journal adds `pendingPhotos` to its own count for exactly this reason; a shot picked here while a journal entry's images were still being written measured a store already fuller than it said. - **Add to the pantry had no double-submit guard.** With a photo attached it awaits twice before the entry is pushed, and a second press inside that window wrote a duplicate jar. The no-photo path never awaits, so the twenty-in-an-afternoon case is untouched. - **A `plantId` that no longer resolves printed the literal word "Something"** on the shelf, the labels and the card. It falls through to the id now — not pretty, but the only thing left that says which jar it is. - **"1 quarts · Tomato."** The shelf row, the "eat these first" line and the share card all print the count immediately in front of the container and none of them had a singular. This app counts "1 crop", "1 photo" and "1 quart jar is currently full" correctly everywhere else; the pantry was the one collection that did not. The picker keeps the plural, because a picker names a container in general rather than one of them. ### Smaller - The year card **drew bars in two colours it never keyed**: `indoor` in lilac and `bloom` in gold were missing from the legend, so every crop started indoors — most of them — carried an unexplained purple bar in February. The key is built from the kinds actually on the card, and wraps. - Every Share button on the journal timeline **announced itself as "Share"**, so a screen reader offered one identical name per harvest. `shareBtn` takes an accessible name where the visible label cannot be unique. - The four overlay guards each **hand-rolled the `#putup` selector** that 89-putup exports `RW.putUpOpen()` for. Four copies of one test is four places to miss. - The Jars & lids **"no published figure" sentence lived inside the branch that only runs when some other crop had one** — so a table consisting entirely of refusals carried no explanation at all, which is the case the sentence was written for. - `glutWeekPlan` **shared two recipe counters across every crop on the sheet**, so with three crops in the rotation it skipped recipes they had and repeated ones they did not; the counters are per crop and per job now. A crop whose recipes are all herb or staple **silently dropped its day**, so a sheet headed "Seven days from …" came out with six rows and nothing to say which day was missing; it walks on to the next crop that can fill it. ### Known and deliberately unfixed - **The share cards do not reflow for short content.** A two-crop putting-up card now leaves roughly 800px of blank paper above the wordmark, and the fix above makes short cards more common. Filling it is a typographic decision about a shipped artifact, not a defect, and it is not a review sweep's call to make. - **`emit()` toasts "Card saved to your downloads" whether or not the anchor click was honoured.** There is no callback that says it was. - **The printable calendar resolves an annual window into the current calendar year**, so a January window listed in November prints this year's dates. `fmt` drops the year, so the month and day are right and only the sheet's own heading disagrees. ## v6.1.1 — 7 August 2026 **A review sweep over v6.1's day-old putting-up code, and the theme is the oldest one there is: a fixed number that used to be right.** A canvas 1350px tall that nobody measured against. A sort that was ascending on a quantity which turns negative. A head built once beside a filter that repaints. A threshold copied into a second file by the comment promising it had not been. An altitude stored without the unit it was typed in. All of it passed 700 checks, because every one of these produces output that is the right *shape* — a card, a list, a button, a number — and simply says the wrong thing. Verified by the eight suites (700 checks, 700 passed — 82, 60, 53, 87, 172, 49, 121, 76, unchanged) and by a twelve-point probe driving the real build in Chromium: each defect below was reproduced before the fix and is asserted against after it. The badge still reads v6.1; the hosted and download builds ship byte-identical. ### The bed card had no bed on it - **Every bed plan ever shared said "This bed could not be drawn."** `planSvg` writes `` with no `xmlns`, which is correct for what it was built for — the print sheet drops it into a document, where the HTML parser already knows what an `` tag means. The share card is the one consumer that does something else with it: a `data:image/svg+xml` URL handed to an ``, which is parsed as **XML**, where a root element in no namespace is a parse error and nothing else. So `img.onerror` fired every single time, the catch printed its apology, and the flagship card of the release went out carrying a title, a plant list and a blank rectangle. The namespace is forced on in `svgImage` beside the width and height it already forces on, because that is the one call site that parses the string as XML. ### Sorted by a number that goes negative - **In the first week of August, the putting-up sheet led with April.** `putUpCrops` sorts ascending on `gap`, and `daysToWindow` returns a *negative* number for a window that has closed. On today's date a sixty-crop garden ordered mizuna at −121, komatsuna at −121, bok choy at −111 — and put the one crop actually harvesting **twenty-third**. The three readers that ask for the whole season are all of them: the ✦ printable pantry-door calendar, the "Putting up 2026" share card, and the Jars & lids table on the Seed & supply list. The day-planning callers pass `within`, which drops closed windows entirely, which is exactly why nobody saw it — the option added to fix this at v6.1 was fixing it only for the callers that used it. Open now first, then soonest arriving, then recently-closed ahead of long-gone, then no window at all. ### A fixed canvas nobody measured against - **Three of twelve pantry entries were drawn off the bottom of the image.** The shelf shot claimed 460px, the rows stepped 62px from wherever it left off, and neither knew the card is 1350px tall: with a photo the twelfth row landed at a baseline of **1510**, six draw calls entirely outside the image and four more across the wordmark. Same untested assumption, three more places: the bed card's eight plant rows ended at 1288 against a footer at 1298; the harvest card wraps `e.text`, which is the one string in the app with **no length cap anywhere**, at 42px a line until it runs out of card; and the year card divided the leftover height by a fixed fourteen, which can squeeze a row to 10px under 25px type. Every list is now clipped against the footer, the photos yield to the text rather than the other way round, and what did not fit is counted honestly — *"and 5 more"* — through one shared helper, so the four cards cannot drift apart again. ### Built once, beside a control that repaints - **The Kitchen's "Put up ‹crop›" button never appeared, and once it did it pointed at the wrong crop.** It is built into the page head at render time and gated on `K.crop`; the crop dropdown runs through `apply()`, which repaints the list and — deliberately, correctly, and documented three comments below — nothing else. So choosing tomato from the dropdown left the head empty, and arriving with a crop already set (from Today's harvest card, or a `#kitchen/tomato` bookmark) and then switching to basil left a button still reading *"Put up tomato"* and still opening tomato. The head is repainted from `markControls()` now, which also puts it after the stale-choice guard: a crop that no longer has recipes cannot leave a button offering to put it up. ### The one view whose main interaction is a repeated small edit - **Ticking a jar off the shelf threw you back to the top of the page.** "Ate one", "Remove" and Add all ended in `RW.go('pantry')` — a whole-view rebuild that re-creates the 446-option crop datalist, re-reads every shelf photo out of IndexedDB, scrolls `#main` to 0 and moves focus to the `

`. Measured: scroll 600 → 0, a half-typed crop name in the form above **wiped**, focus gone. A pantry is filled and emptied one jar at a time, so this is the view that could least afford it. The subtitle, the shelf and the all-time line repaint in place now; focus returns to the button that was pressed (`preventScroll`, for the reason `go()` uses it on the heading — the button is already under the reader's finger); and the add form clears crop, count, source and picture on a successful save while keeping method, unit and date, which are what a canning day repeats twenty times in an afternoon. ### Numbers that had lost the unit they were typed in - **A garden at 5000 ft announced "You are at 5000 m."** The altitude field's placeholder switches between metres and feet with the units setting, and the value was stored as a bare number with no record of which one had been typed — so flipping the setting reinterpreted it, a threefold misstatement of the single variable the whole feature exists to name. The clamp gave it away: 20000 is a feet ceiling, and it was being applied to metres too. Stored in feet now and displayed in the live unit, exactly as pounds and lengths already work, through `RW.altToFt` / `altField` / `altText`. It is still never used to compute an adjustment, and never will be. - **`GLUT_LB` was defined, exported, and ignored by the screen it was defined to agree with.** 89-putup's constant carries the comment *"same threshold as Today's glut warning, deliberately: a crop that warns there and is missing here would read as a bug"*, and Today kept its own literal `20` four thousand lines away. Today reads the constant. ### The pantry was an unmetered door into the photo store - **A free-tier browser could store its 63rd photo through the Pantry.** The journal checks `PHOTO_CAP` before every add; the pantry's save path, whose own comment claimed *"the same cap-and-resize path the journal uses"*, did the resize half and none of the cap. Verified with 62 journal-referenced photos already stored: accepted, no warning, and the tier's own feature list promises sixty. It refuses now with the journal's wording — and still saves the **entry**, because the record is the point and a full photo store is no reason to lose what was put up. The picker carries the same slot count the journal's does. - **And the photo-failure messages were never seen anyway.** `toast()` replaces the message and restarts its own timer, so both *"the photo could not be stored"* and *"that image could not be read"* were overwritten by *"Into the pantry."* microseconds later: the entry saved without its picture and the app said nothing. One toast at the end now, carrying whichever note applies. - **A restored backup dropped pantry photos first.** The import's photo priority list was built from journal ids and then padded with whatever was left, so at the cap the shelf shots went regardless of how few journal photos the file held — the entry came back with its id and no image. Pantry ids join the list, in the same spirit as the boot prune, which learned about them during v6.1 for the same reason. ### Housekeeping - **`putUpCrops` re-projected the crops it was about to reject.** `projectedLb` walks every bed and every planting in the garden, and the `seen` flag was set *after* the glut threshold — so the crops that fail it, which is most of them, were re-projected once per planting. An eight-bed, eighty-planting garden ran it **94 times for one Today render**. The flag moves above the test: the answer cannot change between two plantings of the same crop against the same bed list. - `#putup` and `#drawer` shared `z-index:41` and the putting-up sheet won only because it happens to come later in the markup — the same tie `#toast` and `#locked` were on until v6.0.1. It has an explicit `42` now. - The helper borrowed the plant drawer's focus-return slot. Nothing opens it from the drawer today, but the guard that anticipates one is already written two lines below, so the sheet has its own slot rather than a hazard waiting for the feature. - Copy: *"No safe home-canning process for this crop plain"* → *"…for this crop on its own"*. - `emit()` constructed a `File` unguarded, so a browser without the constructor lost the plain-download fallback as well as the share — the fallback taken away by the failure of the thing it was the fallback for. - `go()`'s comment said "five of the thirteen views" for the second release running. The list is fourteen. Nothing here touches the no-canning-figure rule, and suite 7's scan over the helper, the equipment lists, the Today rows and the Pantry is unchanged and green. ## v6.1 — 7 August 2026 **The putting-up release: the season between the harvest and the seed catalog, finally on screen.** Bloomsteader walked the gardener from seed to harvest better than anything at its price, and then went quiet at the exact moment a food garden works hardest. August and September are the weeks of jars, lids, blanch pots and freezer Tetris, and until now the app had nothing to say about any of them: the harvest planner spoke in quart jars going *in* to a plan, and nothing spoke in quart jars coming *out*. This is `PUTTING-UP-PLAN.md` implemented in full — all four numbered items and all four LATER ones — plus the share cards from `UI-RECOMMENDATIONS.md` items 8 and 10, which came along because the pantry photos depended on them. Verified by eight suites: **700 checks, 700 passed** (82, 60, 53, 87, 172, 49, 121, 76), up from 651. The hosted and download builds ship byte-identical. **Almost none of this is a new engine.** The yields already projected pounds; every glut-crop recipe already carried the pounds one batch eats, authored at v5.1 for exactly this and never read until now; the care engine already dated checkable rows onto Today; the Preserving pack already held the method text. The work was wiring between things that already existed, which is why a release this size added one view and one overlay. ### The line that shapes every screen here **This app states no canning process figure — no time, no pressure, no headspace — and v6.1 does not soften that by a word.** It would have been easy to: the moment you build a canning-day planner, printing "process 35 minutes" looks like the helpful thing to do. It is not. The moment the app states a time it owns the altitude table, the jar-size matrix, the errata and the liability, and its whole differentiator dies. Every hobby-canning forum is a graveyard of invented process times; the app that *refuses* to state them, names NCHFP/USDA/Ball on every entry, and still plans the day better than anyone else is the one an extension agent would recommend. So every canning surface prints the same sentence — *times, pressures and headspace come from your tested source, for your jar size and your altitude* — which is also, not coincidentally, the single most important habit a home canner can be taught. The `CANNING_FIGURE` scan that has guarded pack prose since v5 now guards the app's own copy too, and suite 7 checks the helper, the equipment lists, the Today rows and the Pantry for digit-bearing process text. ### What landed - **The Kitchen knows about the glut now.** The Harvesting-now card carries a Kitchen link beside its storage line, and the glut warning finally got its second half: *"roughly 40 lb of tomatoes is on the way"* is a problem statement; *"the Kitchen has 9 ways through it"* is the app being on the gardener's side. ✦ adds batches scaled to the projection and a printable seven-day sheet that alternates eating it now with putting it up — because a week of nothing but canning is how you end up with forty quarts of something nobody wanted to eat fresh even once. - **"Put it up" — the decision helper.** The question at the counter is not "show me recipes", it is *"I have twelve pounds of green beans; now what?"* One screen answers it, crop first, in honest order: eat it fresh (with the storage clock attached, so "do nothing yet" has a deadline), cure and store, freeze/dry/ferment/fridge with the recipes scaled against the pounds you typed, and then the jars. **The triage order is the teaching**, which is why the beginner needs no special casing. It is an overlay, not a view — a question is not a place — hash-addressable so Back closes it, and every overlay guard in the app knows it exists. - **The canning row tells the truth in all three states.** With the pack: the prep prose, the red safety note, the named tested source. Without it: the path is still named, because pretending an option does not exist in order to sell a pack is a lie. And for the five crops with no tested home-canning process at all, a red refusal that says *do not improvise, and do not adapt another vegetable's recipe* — that is the branch where people get hurt. - **The canning day, planned in jars, lids and Saturdays.** The researched pounds-per-quart the harvest planner uses, run backwards: this pile is about that many jars — and a refusal where no figure is published, because inventing one for the 65 crops that lack it would undo the reason to trust it for the 278 that have it. Jars and lids join the Seed & supply list, dated putting-up rows join Today through the care engine's own contract (Done, 7d and Not mine work on them unchanged), and a method-aware equipment checklist carries the two lines that matter: **new lids every time**, and **have a dial gauge tested — extension services do it free**. - **The Pantry, the fourteenth view.** The seed drawer for the other end of the year. Crop, method, count and container, the date, a photo, and — for the two canning methods — the tested source, because a jar's provenance *is* its safety record. Honest shelf life, with the distinction almost nobody makes: for home-canned goods the clock measures **quality, not safety**. A jar that sealed and stayed sealed does not become dangerous on its birthday, and saying it does teaches people to trust a date instead of their eyes and nose — exactly backwards, because the date cannot detect a failed seal. Free, per the house rule that the record is never paywalled; ✦ holds the labels and the put-up-versus-eaten review that quietly corrects next year's targets. - **Share cards.** The bed plan, the year at a glance, a journal harvest, the pantry shelf and the putting-up season, rendered to PNG on canvas — offline, no font fetch, no pixel. Free at every tier, because paywalling your own advertising is a strange way to sell software. The footer is the wordmark alone: these images outlive the release, and a URL that changes turns every card ever posted into a broken link. - **The four LATER items:** a putting-up strip in the Kitchen's Preserving chapter, an optional altitude on the garden profile, a glut-horizon ribbon on Today, and pantry photos. Altitude is shown back on canning rows and **never used to compute an adjustment** — teaching the variable without touching the figure is this app's posture in miniature. An altitude calculator would be the same mistake as printing a process time. ### Three things the tests found - **The putting-up row expired while the crop was still coming in.** A flat three-week duration meant the reminder vanished about a week into the harvest window — precisely when the gardener is standing in the pile it was warning them about. It now stays due for the whole window, with the three weeks as a floor. - **And it disappeared entirely once the season had passed.** A harvest window is annual, but `fromDoy` resolves it into one calendar year, so anchoring on the current year produced no row at all for a crop whose season had finished — invisible in August, but it silently emptied the calendar's six-week list in November. It now falls through to the next occurrence. - **`putUpCrops` was planning Saturdays around crops that finished in July.** The season calendar wants the whole year; anything planning a *day* has to drop the closed windows. That is what the `within` option is for, and the week plan and the Kitchen button both use it. ### Housekeeping - Badge, service worker and `package.json` to **v6.1** / `bloomsteader-v6.1.0`. suite 5's badge literal and suite 8's brand check move with it, on purpose. - **Sidebar 13 → 14, More sheet 8 → 9.** Pinned in suites 5 and 6; both updated deliberately, which is what those pins are for. - The Preserving pack gained an `equip` field and went to **version 2**, in all three places a pack lives: the unsigned payload, the baked `rw-packs` block Full buyers actually read, and `sanitizePack`'s whitelist — a field the schema does not name is a field the pack loses silently. The equipment lines go through the same canning-figure scan as the prose. **The copy in `packs-unsigned/` must be re-signed before it is sold again**; the baked copy needs no signature and already carries it. - Because an imported pack beats the baked copy *whatever its version* — which is deliberate, so a buyer sent a corrected file gets the file they were sent — a Full buyer holding an old import would silently miss the new content. Rather than change a rule that exists for a good reason, the Packs view now says so and offers to fall back to the built-in copy. - The boot photo prune only knew about the journal, so it would have deleted every pantry photo 2.5 seconds after boot. It knows about the pantry now. ## v6.0.2 — 5 August 2026 **A second sweep over v6, and this one looks the other way down the seam.** v6.0.1 was about everything the app failed to tell the gate; the theme here is the reverse and the older kind: whitelists that do not whitelist, a global control two views disagree about, and three claims — in a comment, a test name and a changelog — that were true of one call site and asserted of all of them. Every one of these was green through all 642 checks. Verified in-browser over HTTP at 1280 and 375px with the service worker and caches cleared before every reload, and by eight suites: 651 checks, 651 passed. The hosted and download builds ship byte-identical. The two whitelists nobody had got to yet were the two fed by the address bar: - **`#toString` blanked the app; `#constructor` opened Settings under an error.** `parseHash` tested a view id with `if (!renderers[id])` — a bare bracket lookup on a plain object literal, so every name on `Object.prototype` came back as an inherited function and cleared the guard. `SUB[h.id].set(h.sub)` then threw, because `Object.prototype.set` is not a function. From a hashchange that was an uncaught TypeError with the URL left disagreeing with the screen; from a reload or a bookmark it reached `paintFirstView`'s catch, so a mistyped address opened Settings under *"Bloomsteader could not draw that view"* — the sentence reserved for a renderer that actually failed. This is the eighth and ninth prototype-walking lookup found in this build (after `tierOf`, `PACK_TYPES`, `SHOP_VENDORS`, the cart and the rest), and the only two that took their key from the user. `hasView` and `subOf` are own-key checks now, and `go()` uses the first, so no id can talk it into rendering into a host that is null. A paid app said no to somebody who had paid: - **A verified key that could not be *written* kept the gate shut.** "The key verified but could not be stored — browser storage is unavailable." So a browser with localStorage switched off — Safari's *block all cookies*, a managed or locked-down profile — took the purchase and then refused to open the app, over a setting this app already knows how to run under: `read()` latches such a session read-only and the savebar states it plainly (*"Nothing will be remembered between launches — export before you close the tab"*), and everything works from there. The branch immediately above it reaches the opposite conclusion from exactly the same reasoning, about a browser with no `crypto.subtle`: a limitation the buyer did not cause and cannot fix must not cost them the app. It opens now, for the session, and says what will not survive it — that the key has to be pasted again next launch, and that nothing else will be remembered either. The gate's warning space is unchanged: this is news about the session, not about the licence, so it goes to the toast layer, which since v6.0.1 outranks the gate. One global control, three scopes: - **Today went on telling you to water a bed the app had just hidden.** The setup filter in the top bar sits on every view and toasts *"Filtered to container"* when you set it. The Beds view honours it, and 90-list's own header comment records this being fixed for the Seed & supply list — *"it shopped for beds the app said it was hiding"*. Today's "Your beds" card was built from `S().beds` unfiltered, so it kept the hidden beds' watering rows, and the harvest rows underneath came off the same list. Area chips still read from the whole garden: an area is a garden-level idea, and dropping the chip you are standing on is worse than leaving it. - **And the Beds badge counted findings you could not reach.** It read every bed regardless of the filter, so a filtered garden could carry a red count with nothing on the page behind it. It counts the beds the Beds view will show — which is the view it opens — and the filter buttons rebuild the nav now, as the zone select two cards down has done since the badge existed. Three claims that were true once each: - **The ✦ had a tooltip, not a name.** v6.0.1 gave every marker a `title` and said in this file that it gave them an accessible name too. A `title` is a description; the name of a button that has text comes from its text — so all five were still announced as the bare glyph. Only the seed drawer's germination button carried a real label, and its wording is the one the new `RW.liteLabel()` uses everywhere. - **Three buttons reading "Buy", on the one screen where choosing between them is the whole task.** The tier name sat in a sibling `div` that nothing associated with the control, so a screen reader's button list was three identical entries. The visible word is still *Buy*; the accessible name carries the tier and its price, the way every other control in this app is labelled. - **`RW.countProblems` was defined twice**, identically but for the memo, and 50-beds parses after 20-checks — so the first copy never ran. Dead code, and the dangerous kind: the day module order moved, the badge would quietly go back to a full `checkBed` per bed on every nav rebuild. And three smaller things the gate had not been told about either: - **Export from the gate was fire-and-forget.** `exportData` is async and the handler ignored its promise, so a rejection settled into nothing and the button appeared to do nothing at all — on the screen whose first rule is that it never traps data. It reports now, and says the garden is still safe in the browser. - **Printing the licence screen produced a blank sheet.** `#locked` was in the print stylesheet's blanket hide list, and because `boot()` returns before `bootShell()` while the gate is up, there is nothing behind it. It is also the only screen carrying the three prices and the safety notice, which is what someone printing it wants. The gate prints; its controls carry `.noprint`. Suite 8's check that asserted the old behaviour has been rewritten to assert this one. - **No script, no page.** The whole app is one `