The Question the Membership Test Never Asked
The membership test asks whether a module needs to know what an app is about. A list of model names passes it easily: the list knows nothing about journeys, journals or quests. So does a list of image sizes, a timeout, a port number in an install script. None of them branches on an app's name. All of them went into the kit at one time or another, and in September and October every one of them came back out.
They came out because of a second question: is this a fact some other system owns? The model menu belongs to the assistant's settings, which decide which models each brain offers. Image sizes belong to the image engine, which knows what each model can render. A port belongs to the family's registry of members. A copy of any of those in the kit is not plumbing. It is a second owner, and two owners of one fact is the vocabulary bug from track 1 in a new place.
Six Facts Handed Back
- Model menus. Launching a new model used to mean editing the assistant's lists and the kit's hand-kept copy, then syncing that copy to ten consumers. The copy had one reader, and that reader could not build a menu without the owner anyway. It was deleted. The owner now publishes each brain's model options alongside its configuration, and a model launch is an edit to the owner and a restart of the owner — no kit edit, no consumer sync.
- Reviewer routes. Which tool reaches which brain for a review, with which arguments, moved to the system that owns multi-brain calls. The kit keeps a client that fetches that catalog and runs a route on the calling machine. There is no fallback table: an unreachable owner fails the round and says where it looked.
- Image sizes and aspects. The kit's proxy, its web client and its Swift client each kept a list of sizes. All three were dropped; the image engine's catalog says, per model, which sizes and aspects exist, and the pickers show what the selected model offers.
- Reference and count ceilings. A shared ten-image ceiling on reference images, and default caps on how many images a capture could carry, were removed. The model owns its reference limit; the provider's documented limits decide what an inline batch can hold.
- Hidden caps on a turn. A five-minute ceiling on a whole assistant turn cut every turn past five minutes on four apps and surfaced as a network fault. An eight-megabyte budget could end a long streamed turn. A one-turn limit refused a model's own second pass at structured output. Length caps on command proposals rejected valid, wordy answers as malformed. All were dropped; stopping a turn is the user's kill switch, not a number in the kit.
- Ports, hosts and URLs. The install and network scripts used to get ports, hosts and repository paths stamped into them as per-repository template variables. Now no template variable may carry any of those — a test refuses one — and the scripts ask the family registry at run time and find their own repository from their own location.
No Fallback Copy
Each retirement met the same temptation: keep the old list as a fallback, in case the owner is unreachable. The answer was the same every time. A fallback list is a second owner that only speaks when the first is silent, and it speaks with yesterday's facts. For the model menu, the reader could not build a menu without the owner's other data anyway, so a fallback could never have been used. For the reviewer routes, an unreachable owner is an operating-state error that should be seen, not quietly bridged with a table that drifts. The kit's own guidance now says it outright: do not re-add a list here, not even as a fallback.
What Giving Back Costs
Handing a fact back makes a coupling visible that a copy used to hide. The kit's review client is tested against a snapshot of the routing owner's catalog, and the routing owner builds part of that catalog from the kit's own brain vocabulary. When the kit added four spellings to its vocabulary, the routing owner's test went red for sixteen hours while every kit test stayed green. The fix was not to copy the catalog back. It was a kit test that holds the vocabulary and the snapshot together, and a documented two-pass order: change the vocabulary and deploy, then refresh the snapshot from the owner and deploy again.