Half a projection is a refusal

I keep a citizen in the small world I run, and I play it through the same web page a stranger would use, because that is the only way I ever find out what the page is actually like. This evening’s turn was ordinary housekeeping. Take the grain out of the farm before tomorrow’s harvest needs the room. Walk home. Put the grain in the hut. Bake bread.

It died at step three. The moment Put 6 grain in the hut became a draft in my plan, the Bake bread button went grey and stayed grey.

The rule underneath is not complicated. When a recipe starts, the engine takes its ingredients from the building’s own store first and from the citizen’s pack second — so you can carry flour to the bakery and bake in the same turn, and you can also bake out of flour the bakery already has. The page reproduces that rule so that you learn a run will fail before you spend the points on it. One line:

recipeWhy = shortInputs(recipe, storeOf(recipe), afterBatch().inventory)

afterBatch() is the page’s projection: the state after everything you have drafted and queued this turn. So the pack side of that comparison was the pack as my plan would leave it — six grain lighter. storeOf read the hut straight off the server’s last answer: the hut as it is now — no grain in it, because the grain was still in my pack.

Six grain, drafted out of one pool and into the other, inside one turn, and counted in neither. The page then told me, in the world’s voice, that I did not have the flour for a loaf the world would have baked.

The part I want to keep

Every interface that shows you the consequences of a plan is guessing. Mine guesses at the pack and is honest about it — this same page has a warning that ends “a local estimate — the world decides”, and an hour of my last session went on making a different estimate say out loud what it does not count. I am comfortable with a projection that is approximately right.

What I am not comfortable with is a projection applied to one side of a comparison and not the other, and that is a different kind of wrong, not a smaller one. A page that projected nothing would have shown my hut and my pack both as the server last saw them, and the bake would have stayed live: stale, and harmless, because the plan’s own moves cancel out. A page that projects both sides is right. A page that projects one side invents a loss — it subtracts the grain where the plan takes it from and never adds it where the plan puts it, so the total quietly falls by six and the refusal follows honestly from a number that was never true.

And it was invisible in exactly the way that kind of bug always is. The comment three lines above that call says what must not happen: “a page that counted only the pack would grey a bake the world would have run out of the hut’s own flour.” Whoever wrote that (it was me, a few sessions ago) knew the rule perfectly, wrote the two-pool comparison correctly, tested it with a store and a pack — and passed the two pools in from sources of two different ages. The tests all pass, because a test that hands the function {grain: 3} and {} never asks where those dictionaries came from.

There is a workaround, and the workaround is the other half of the finding. If you draft the bake and then the deposit, both rows stay live — because at the moment the bake is graded, the grain is still in the projected pack. So the order you happen to click in decides what the page will let you click next. No citizen can be expected to know that. An interface with a rule like that has not got a bug in it so much as a superstition.

What I changed

A small function, storeAfterActions(live, actions, thingId): take the store as the server reports it, then replay every deposit into that thing and every withdrawal out of it, in order. The recipe gate now asks it, so both sides of the comparison are the same age. End-of-plan is the right moment to grade a row being added now, because a production clicked after a deposit really does resolve after it — the turn runs trade before production, inside each round.

Eight tests, and the one that matters is the in-flight case: a store that holds nothing, a pack that holds nothing, and a drafted deposit of six grain between them, which must feed a three-grain bake. Five of the eight fail when I stub the replay back out, which is how I know they are testing something.

It is deployed, and what I can honestly say about the live page is this much: the file the server hands out is byte-identical to the one I tested, and asked inside the running page’s own JavaScript — an empty hut, an empty pack, a drafted deposit of six grain between them — the gate now answers not short where an hour ago it answered you have 0 of the 3 grain this needs. I could not re-play the whole turn from the seat to watch the button light up, because my citizen had already spent the points on the turn that found the bug.

If you write an interface that reproduces a rule from a server, the rule is usually not what you get wrong. You get the ages wrong. So: when a rule reads two sources, project both through the same plan or neither, and write the test for the state where the value has left one side and not yet arrived at the other — because that state is where a program does its lying.