Tap a dish: it centers with green checks for what you have, red for what's missing, and the steps.
Missing an onion or some butter? Cook with what you have, or make a shopping list to restock later.
Press My Recipes and the top three dishes appear as notes, "rice pudding" have all ingredients, others show "You have 2/3 - Missing: 1".
Open the door to see your shelves by category; each bubble holds a group and its item count.
First open: an empty fridge says "tap to open", with one bubble per category waiting to be filled.

Inspiration

At 7pm I'm standing in front of an open fridge with half an onion, three eggs, two tomatoes, half a kilo of potatoes, and a tub of rice going hard, and I know there's a meal in there. I just don't know which one suits the best, and finding out costs ten minutes of opening recipe pages and checking ingredient by ingredient against the shelf until one of them asks for something I don't have.

That gap isn't a shortage of recipes. There are more recipes online than I could cook in a lifetime. The shortage is that none of them know what's in my kitchen, and none of them remembers it tomorrow.

So the question I actually wanted answered is smaller and more useful than what should I cook: given what's in this fridge right now, what's the best thing I can make?

What it does

Two things: it remembers your kitchen, and only suggests food you can actually make.

Tracking your food

Add something by tapping or dragging the ingredient to fridge door, e.g. after your grossary shopping
Deduct the amount of ingredients when you click "cook this"

Recipe Recommendation You get at most three dishes ranked against what's actually in there, each with an honest fit line, e.g. it will tell you if there is a few ingredients missing and generate a shopping list. Open one recipe, it will show recipe details. Press Cook this, and the ingredients it uses will leave the fridge. Press My Recipes again and the answer has changed, because your kitchen did.

That's the whole app: the list stays updated, and the recommendation follows the list.

How we built it

The project started with a simple idea to suggest recipe based on the fridge leftovers. The first agent interviewed me on idea, experience on working with agent, and learning goal. APP concept is then summarized into one sentence: “a fridge-door companion that remembers what's in your kitchen and recommends recipes from what you actually have”.

Further details are produced by a flipped interview given by first agent,

scope.md grew out of an unstructured brain dump sharpened by two questions: what makes a recipe the "best fit," and what the app's distinctive kernel is. That kernel set the proof-of-concept boundary: first-use ingredient entry, a built-in recipe collection, top-2–3 matching, and stock that persists.
prd.md then walked the same journey, one screen at a time until every behavior was concrete. E.g. drag or tap an ingredient into the fridge, cards reading "You have 4/5," green/red have-missing marking, "Cook this" versus "Generate the shopping list". And each is paired with a checkable acceptance criterion.
spec.md mapped those behaviors onto the smallest stack that could prove them: plain HTML/CSS/JS with no framework, browser storage standing in for the "text file that is rewritten on every update," and a scoring rules for the best recipe. Each document was approved before the next began, so the build never had to re-litigate a settled decision.
Finally the agent prepared checklist.md as execution plan.

The second agent then took over, following checklist.md, and implemented the app step by step, stopping at something I could run to verify the progress. Categories and stock that survive a reload; then the ranking engine; then the recipe view and cooking; then the shopping list that closes the loop. Every stop was a working app, so my feedback was about the thing instead of a description of it. It stayed small on purpose — 121 KB of vanilla HTML/CSS/JS, no framework, no build step, no dependencies, three layers in app.js (pure functions, storage, UI).

Where the build proved the plan wrong, the plan was corrected and the correction recorded. Fifteen revisions, plus one hands-on checkpoint that never happened and stays unticked. That record is the whole reason the documents were worth writing: without them, the only instruction available is "make it better."

Challenges we ran into

Three rounds of feedback surfaced bugs that only real input could find. A full-stage overlay with pointer-events never disabled blocked every click and drop on the fridge, which is invisible to automated checks, because .click() and synthetic DragEvents skip hit-testing.

A duplicate id on

and the door button made every tap open the fridge, caught only in the browser. Since the harness couldn't reliably produce a drop, the drag gesture was rebuilt on pointer events: 7px threshold, ghost chip, hover-to-open door, swallowed follow-up click. Float chips were measured while hidden, so adaptive sizing had never worked.

Decisions carried costs: a length bias let a 5/6 bolognese outrank complete scrambled eggs, and at bonus 0.2 two assertions failed, so it was reverted; staples fixed near-universal incompleteness but made Rice Pudding a one-ingredient recipe; missing meat and fish grew the collection from 26 to 35 recipes with a fifth category; the layout settled at a 2/5 fridge after a below-fridge tray and a cramped third, and a door opening past 90° shows its mirrored back, so it darkens with the nameplate hidden.

Accomplishments that we're proud of

The kernel is visible instead of asserted. The state change is the demo, and nothing needs explaining over it.

123 assertions run in node against a stubbed storage object: ranking, deduction and the shopping list, zero dependencies, no framework to maintain. And when that same suite went green on an app nobody could click, the fix wasn't more assertions. The suite didn't get softer; it got honest.

A plan that recorded its own contradictions. Fifteen revisions, each naming what the build discovered that the plan got wrong — including the early hands-on checkpoint that never happened, left visibly unchecked rather than back-filled. The plan bent; it didn't break, and the record is how I know that instead of claiming it.

It survived five rounds of my own criticism and one full rebuild. The tray became bubbles, the fridge grew a door that opens, cooking learned to announce what it removes, the shopping button learned to disappear when there was nothing to buy.

What we learned

Having the rule written down is what makes disagreement productive. When I bumped the length bonus from 0.1 to 0.2, exactly two assertions failed — not twenty, and not zero. The two that guarded the agreed rule. A suite that fails precisely where the contract changed is worth far more than one that fails everywhere.

Test what a person does, not what the code accepts. Green means the code took the input, not that anyone can use the result. The only verification that counted was a real hand at real coordinates.

Name the cost at decision time, not at review time. "A nearly complete long recipe can outrank a complete short one" is a decision I can revisit later. The same behaviour, undiscovered, is just a bug.

Slices paid for themselves. A demonstrable app existed a quarter of the way in, so every later decision had something real to be wrong about, which is why the feedback got specific instead of aspirational. The rework I'd most like to have avoided was the opening screen: a detail discussed too shallowly at the start, rebuilt twice.

What's next for Fridge Door Companion

Shared fridges. A shared kitchen is the point where local storage stops being enough and a backend finally earns its place. I'm still the only person who has used it, and that is the biggest gap in everything above.

Expiry. The fridge knows what is in it; the next question is how long. "Cook this before it goes bad" is what this data was always for.

Real units, more recipes. Amounts are whole numbers today (2 eggs, 200 g flour); conversion is the rabbit hole I cut to get a demo out. And 35 recipes proves the ranking, not a life; the collection is the app's knowledge, and it should grow.