Planning the week

• The plan is the one thing not folded from a graph. "I'm cooking this on Thursday" is a decision; it lives in MealPlan behind the third store port, with the ticked grocery lines.
• A night holds any number of things, and a thing is a dish or a note. Owner, 4 October 2026: "when you've planned one recipe for a day, you should get a new add recipe row for that same day if you need to plan multiple" and "a way to put a note instead of a scheduled recipe if im planning to be out or have something frozen or instant." A main and a side share a night, and nothing planned on it replaces anything else. An entry is its night and its dish, or its night and its words (plannedMealKey, meal-plan.model.ts), so the same dish twice on one night is one entry and two phones that each add a different one both keep theirs: the merge is a union per entry (applyPlanDelta), and retyping a note reads as one taken off and one put on. A note is the cook's own words and nothing else — out, something frozen, something instant, or anything typed. It counts as the night planned, and it carries no shopping and no cook: no recipe, so nothing reaches the list, nothing is ranked against it, and no question follows it when the night goes by. views/plan-night.ts is the one home for how a night is written, which every screen below uses (§1b, §2, home's line about a dinner nobody cooked).
• A dinner you planned and nobody cooked is asked about on home, for six nights. Owner, 4 October 2026: "if a recipe is planned on a day but we don't see them cook it, can we prompt to reschedule it". A plan is pinned to a date, so an uncooked one used to leave the screen at midnight in silence, and carrying it forward would put a dinner on a calendar nobody agreed to. So the dish stays where it was planned and home offers the two things a cook can do with it: move it to another night, or let it go, one tap each. The plan itself does not list it (6 October, below).
  • Cooked is read, never stored (uncookedNights, libs/core). A dish planned on a night that has gone is uncooked when the cook log holds no session of that recipe started on that night, by the device's clock — the clock the plan's dates are already in. Started, and not finished: an evening that reached the stove was not missed. That night, and not a later one: cooking the dish on Thursday does not make Tuesday's plan true, and Clear is one tap away. Nothing is written — no flag on the plan, no event — so a move or a Clear changes the answer by changing the plan, and there is nothing to forget to unset. The two screens ask one hook (useUncookedNights), which reads the log only when a night in the window holds a dish.
  • Six nights, and then not again. A night is asked about from the midnight that makes it a night gone until it is a week old, and then nothing says a word: the plan shows it as history and home never names it.
  • A note is never asked about, and a night that held two dishes asks about each. The question is about a dish; a night spent out or on something frozen went by as it was meant to, and answering one dish touches nothing else the night held.
  • On home it is one quiet line under tonight's card (§1), and Move there names the night it lands on — the first with nothing planned, which is tonight unless tonight is taken, a note taking a night as much as a dish — so it opens nothing and takes one tap. On the plan it is no row and no word (§1b, 6 October 2026); a seven stepped back to keeps Move and Clear on the dish.
  • Quiet, and never the loud thing. The one yellow action belongs to cooking or planning tonight. Clear does not ask: it lets go of a night that has already passed.
  • One fact, in the owner's short declaratives. Not cooked, and no reason, no schedule, and no claim about whether the shopping was done: an unticked list is not evidence nobody shopped.

The plan and the shopping list belong to the kitchen, and this is the case that is broken today rather than merely unmodelled: two people in a house shop from one list, and if she adds milk and he cannot see it, the feature has failed exactly the household it exists for.

Which forces one thing that was already queued and now stops being optional: a grocery list is rows, not part of the plan document. One document per tenant with two shoppers in it means one of them ticks an item in an aisle and the other's write erases it, and a lost tick costs a second bottle of milk — the failure a shopping list exists to prevent. The plan stays one document: two people rarely edit the same night, a calendar is read whole and is small, and a clobbered dinner is visible and re-typed in seconds where a clobbered tick is silent. And what actually stops either being clobbered is a merge, not the rows: a device pushes what it changed since the plan it last took, and the kitchen folds that in by night, by aisle, by list and by line — what a side changed is its answer, everything else the other's (ARCHITECTURE, "A push carries what changed since the plan it took"). aisles stays on the plan and becomes the kitchen's, which is a small gift — it is knowledge about milk rather than about Tuesday's milk, so a correction one member makes is one the other never has to make.

The hob belongs to the kitchen. Kitchen is the tenant row itself — kitchenSchema in libs/model, carrying its id, its name, when it was made and what it can cook on. It became that from a bare burner-and-oven count in libs/core, which is what the count was always waiting to be: you join a kitchen and it says what it has, so several people cooking in one place agree about the burners they are sharing. Two people who share a kitchen only to share recipes will sometimes be standing at different hobs, and then the count is wrong for one of them. That is tolerable, and worth saying why rather than leaving as a hole: kitchenLoad only ever reports overflow — it never refuses a step and never reschedules — so a wrong count is a slightly wrong warning, never a wrong dinner. A per-cook override is additive if it bites.

The plan is one document (every other family merges by id), so two phones in one kitchen once took turns erasing each other: a night planned at home pushed the whole cached copy over the ticks made at the shop, and the shop's next push put its copy back. So a push carries only what this phone changed: each write to the plan is noted as what it changed from the plan the cache held (diffPlan), an operation of its own (below). The server lays each over what the kitchen holds by applyPlanDelta (merge-plan.ts states the one rule and what an absence counts as), which only ever carries the keys that moved, under the kitchen's advisory lock, read and write on one connection, so two pushes fold in turn rather than over each other. A first plan made before a phone ever synced folds into the household's rather than over it. A tap on the phone goes the same way into IndexedDB (PlanStore.apply). The journal still keeps planBase, the plan as the phone last took it (advanced only to a pulled plan the cache applied), for the kitchen's list order and for a journal with no operations to send.

The delta is keyed by what the merge already keys (plan-delta.model.ts): nights by date and dish, learned aisles by food, kitchen aisles by id, each as set and unset; lists by id, each with only the lines that moved, a line as the item or its tombstone, and its name only where this phone made or renamed the list, so a tick from a phone holding the old name never undoes another phone's rename. Every store's apply and put write only the rows that differ. On six lists of 30 lines, one tick's push went from 31,366 bytes (plan plus planBase) to 249 (the change is 167 of them, its operation's id and wrapper the rest), and the IndexedDB write from seven rows to one. The pull is cut the same way: cursors.plan is the newest list stamp the device has been answered, plan.lists carries only the lists stamped after it, and planLists names every list the kitchen holds, in order, so the phone lays the answer over what it holds (layPulledPlan); the plan's own row still comes whole. That tick's pull went from 15,663 bytes to 2,634.

Protocol 6 changed the shape and closed no window. SYNC_PROTOCOL and PARTIAL_PLAN_PROTOCOL are 6; OLDEST_SYNC_PROTOCOL did not move. A protocol-5 or -4 build still pushes its whole plan with planBase, folded as the change between them (mergePlanInto is diffPlan then applyPlanDeltaInto, so one rule serves both), and is still answered the whole plan without planLists; a push with no base at all (a build older than the field) is applied whole. Neither is deduplicated: only a protocol-6 push carries operation ids. The push channel still tells the other phones the whole merged plan.