the split, the counter, and two places to put a rule

Written at the start of the day, from the build queue in plan/handoff-2026-09-16.md §7.

The pivot is settled: the claim is no longer "own your memory" (storage, and a commodity) but a rule you set should hold everywhere you talk to an AI — and you should be able to see whether it did. The open question is whether the first half is achievable at all from a server with no hooks and no gates. Everything below exists to make that question answerable.

1. Split the stores. Rules and facts are different things and must not share a budget. brain/MASTER.md §1.1: a system where a rule can be evicted by a fact is built wrong.
2. Cap read_home. Rules whole, the record as gists, fetched on demand.
3. Refuse restatements. The failure the first real assistant produced.
4. Log delivered vs followed, per rule and per door. This is the measurement nobody else in the category has.
5. The delivery-position test. Rule at initialize vs rule in the tool result. The thing everything depends on.

Gate: production carries the boss's live home, which was made before any of this existed. Nothing deploys until a home built by the previous commit has been opened by the new code from a clean store.

Asks expected: permission to deploy; ten minutes of a Claude account to run the experiment; and the still-unanswered one from yesterday, whether to publish app/server.json to the public registry.

Against the plan

Planned	Happened
1. Split the stores	Done. kind on every entry; rules get 40 slots of 200 characters and never share a budget with the record. An assistant may write facts only — 403 on a door writing a rule.
2. Cap read_home	Done. Rules whole, last 40 facts as 140-character gists, bodies fetched through recall.
3. Refuse restatements	Done. Containment ≥ 0.7, the brain's threshold. The refusal names the entry it duplicates and tells the model what to do instead.
4. Log delivered vs followed	Done, and further than planned. fired counts every rule handed over, per door, at initialize / read_home / recall. verdicts holds what the person made of it. calls holds what each assistant actually did, in order, including refusals.
5. The delivery-position test	Built, not run. Four arms, switchable per door from the page. The protocol is written down before the run, with a kill condition. Running it needs a real assistant, which is an ask.
Gate: migration before deploy	Done, and it is now a script anyone can run. Not deployed — blocked, see Asks.

74 assertions across five suites, all passing. app/test/run.sh runs the lot, including a migration built from the previous commit on a clean store. Yesterday's tests lived in a gitignored scratch directory, which meant the proof was not in the repository. They are in app/test/ now.

What the day actually taught me

A green test can be a lie about which code ran. test/migrate.sh was passing two runs in three. The third failed on the first assertion and nothing else, which is the shape of a race, not a bug in the schema. It was a race: killing the npx wrapper leaves workerd holding the port, so the first request of the "new code" phase was served by the code the phase exists to replace. The harness now kills the process group and refuses to go on while the old server still answers. I nearly re-ran it until it was green and moved on. Two green runs would have been enough to fool me.

A counter that counts things that did not happen is worse than no counter. Adding the control arm turned up a patch of mine that had silently not applied: with arm = none, the rules were correctly hidden from the assistant but still recorded as delivered. Everything visible looked right. The whole claim is that you can see what was handed over, so a delivery log that over-reports is not a small bug — it is the product lying. The test that caught it is now the one that names it.

The control arm is a description of the competition. A door set to none stores your rules, shows them to you, lets you edit them, and puts them nowhere. Writing that arm was the moment the pitch got sharp: that is not a strawman, it is what the hundred memory servers in the registry do. The rules are stored. Nothing delivers them at the moment they matter, and nothing counts whether they arrived.

Where the experiment stands

plan/experiment-delivery-position.md, written before the run. Four blocks — rules typed by hand, rules at initialize, rules in every tool result, both — sixteen conversations, one door, one dropdown. Three rules under test, one of which (call recall before you write) is scored by the server's own call log and needs no transcription at all.

⛔ The kill condition is in the file: if no arm beats typing the rules into the chat by hand, the server offers a person nothing they cannot do with a paragraph of text, and the claim is dead as stated. That gets written up the same way a success would.

Asks

1. Deploy. The migration gate is met — a home built on the previous commit opens cleanly on this one, from a clean store, three runs in a row. wrangler deploy is refused in this session by the sandbox's own classifier ("Production Deploy"), not by anything in the code. Production is still yesterday's build, which means the live home has no rules, no counter, and no arms. Say the word, or run it yourself in app/.
2. Ten minutes of a Claude account to run the four blocks. Nothing to install, no new door, no new connector — the door URL is unchanged and the arm is a dropdown on the page.
3. Still open from yesterday: whether to publish app/server.json to the official MCP Registry. Outward-facing, under the boss's GitHub identity. Not published, and will not be until told.