A longevity platform of the group now serves three different audiences out of one cabinet. Until this week the difference between them lived in the routing map — one audience owned the cabinet, and the other two were to be given addresses of their own. That rule had never been switched on, which means nobody would have noticed it until the day it was. The owner replaced it on 8 September: there is one cabinet, and the difference lives inside it as a mode the person switches — research, clinic, shop.
That is a short sentence and a dense few days. Most of the work was not the switch. This is an account of what it actually took, including the half that did not work, the guard whose own description of itself was false, and the part of the plan we withdrew.
A mode belongs to a person, not to a browser
The cheapest implementation keeps the chosen mode in browser storage. It works on the machine you tested it on, and it is wrong in a way that never reports itself. Browser storage lives in one browser and disappears quietly in a private window, on a phone, and after a clear. Somebody who picks a mode at a desk opens their phone and meets a different screen — and the only symptom is their own confusion.
So the mode is a column on the person's own record, never empty, defaulting to research, with a constraint in the schema that names the three known words. Browser storage stayed, demoted to the one thing it is good for: painting the first frame with the last value this browser saw, instead of flashing the default. When the server answers, its answer wins — including when the two disagree.
Strict on the way in, forgiving on the way out
The part worth copying is an asymmetry. Writing is strict: an unknown word is refused by the interface and refused again by the constraint behind it. Reading is lenient: a value nobody recognises becomes the default rather than an error.
That reads like an inconsistency, and it is not one. The value does not arrive only from our own column. It arrives from an old session, from a deployment that knew a fourth mode and was rolled back, from a request somebody forged. If reading were strict too, a person would meet an empty screen instead of their own data because of a word they never chose.
The asymmetry is not a claim you have to take on trust. It is visible from outside, in the platform's own published interface description:
"cabinet_mode": { // update schema — what may be written
"anyOf": [ { "type": "string", "enum": ["research", "clinic", "shop"] },
{ "type": "null" } ]
}
"cabinet_mode": { // user schema — what is read back
"type": "string",
"default": "research"
}A save that did not happen must not look like one
A browser request is rejected only when the network fails. A refusal from the server — a rejected value, an expired session, an error — arrives as a successful promise. Code that only catches rejections reads a refusal as a save, and it looks like perfectly reasonable code while it does so. This is the most likely way to lie in this feature, which is why the response status is checked explicitly rather than inherited.
When a save does not land, the screen still shows what the person pressed — taking a button back from under somebody's finger because of the network is its own kind of rudeness. But a line appears beneath the buttons saying it was shown and not saved. It carries the polite status role rather than the alarm role, because it is not an emergency. It is the one fact the person cannot learn any other way: in that state the promise that the mode survives a reload is false, and the only alternative discovery is to open another device a week later and find the old mode waiting.
One thing we will fix rather than defend: that line is drawn in the colour reserved for failures, which is the exact habit criticised further down this page. It is a small inconsistency and it is ours.
The race that has no symptom
Another one that never shows up in a demonstration. A person can choose while the very first read is still in flight. That read describes the world before the choice. Applying it would move the screen silently back to the old mode with the new one already saved — no error, no flicker anybody would call a bug, just the wrong answer.
The flag that prevents it cannot be ordinary component state, because it is read inside an effect that has already started, and that effect cannot see state written after it began. It lives in a reference instead, with the reason written next to it.
And then the switch switched nothing
All of that was merged onto the integration branch. And the composition of the cabinet in research, in clinic and in shop was identical: the same panels, the same menu, the same screen. Only the highlighted button moved.
The mode existed as state and did not exist as a difference. A switch in that condition is decoration — and, this is the part worth sitting with, it passes every test written about the switch. Every assertion was about storing, restoring and refusing a mode, and all of them were true.
The fix is not a list. Three lists — what is visible in research, what in clinic, what in shop — drift from the panels they describe, and they drift silently: the panel is edited in its own file, the list lives in another, and the divergence is visible only to somebody holding both open, which is nobody. So every panel declares its own modes beside itself, in its own file. The overview takes a tile as a whole module, so the component and its declaration arrive from one place and cannot come apart. Menu entries get a stronger guard still: the field is not optional, so a forgotten declaration is a compiler error rather than a test failure.
As the material stands today, nine tiles and six of the eight sections belong to research: they are about a person's health. Overview and account are visible in every mode. The door of the cabinet and the login are not medical, and without them an empty mode would be a blank page with no way out of it.
A premise we withdrew
The plan asked the shop mode to show orders and launch notices. It does not, and the reason is worth stating rather than papering over: no shop surface exists in the cabinet. Not one route in the map belongs to that universe, and not a single panel or menu entry declares itself for it. Where the word does appear in the source, it is naming a hostname, not a screen.
Writing those screens into the interface would have been an invention, which is the precise thing the next piece of work exists to forbid. So the plan item was rewritten to match the observation, and the work about emptiness was widened from one mode to the mechanism that both empty modes share. No second ticket was opened for the second mode: two rules about one thing diverge silently, which is the failure this whole article keeps circling.
An empty mode has to say that it is empty
Two of the three modes have no panels. A person switching into one of them would have met an empty grid and not a single word. A blank page reads as breakage exactly as reliably as an endless loading skeleton does; the person who sees it writes to support about a defect that does not exist.
When those modes are filled is the owner's decision, not ours. So our task was never to fill the mode. It was to make the product say so.
| The tempting version | What it actually tells the reader |
|---|---|
| Grey placeholder rectangles | A screen that failed to load |
| A demonstration record in the list | A made-up fact, indistinguishable from a real one |
| A counter reading zero where nothing is counted | A measurement that was never taken |
| A blank page | Breakage — which is what it was meant to replace |
Three details in the implementation are the ones we would defend in a review:
The condition is composition, not the name of the mode. «Not research» and «nothing is visible» are indistinguishable today and part company on the day the clinic mode is filled — the «nothing here yet» screen would then sit on top of that mode's own panels.
The list of what is coming is optional, and one of the two empty modes does not have one. A made-up feature on an empty screen is a made-up fact in the future tense, so where there is nothing to promise, silence is the honest option. The guard then demands that the list exist in all three languages of the product or in none — and that the three be the same length, because two bullets against three is the same broken promise, only quieter.
It is not an error state. No alarm role, no colour reserved for failures. «Not open yet» and «broken» are different messages, and colouring the first like the second is lying with colour.
How we know, and where it is still thin
The strongest thing to report here is not a pass. While the composition guard was being written, its first description of itself turned out to be false — so the claim was measured instead of asserted. A deliberate breakage removed the overview's mode filter altogether, the panels went back to being identical in every mode, and the entire frontend suite stayed green. Not one test noticed. That measurement is recorded beside the guard, and it is the reason the guard exists in the shape it does: a test about declarations stays green in a world where the declarations are made and nobody reads them, so there is a second test about what is actually drawn.
A component can be mounted, drawn, pressed and do nothing. If the provider holding the mode is not mounted, every consumer sits on the value the context was created with: the buttons render, they answer to a finger, and nothing happens — silently. So reachability is its own assertion. The provider is checked to be inside the consent gate and outside the shell, the switcher is checked to be mounted, and every button caption is checked to exist in all three languages, with the list of captions read out of the component rather than retyped beside it. A retyped list falls behind quietly, and it nearly did here.
Both suites also refuse to judge an empty sweep. A comparison over an empty set succeeds every time, so a guard that has lost the corpus it walks — a renamed directory, a changed suffix — would be evergreen and useless, which is the worst condition a guard can be in.
Every guard was then checked by breaking the thing it watches, and each breakage reddened the guard written for it — sometimes a single case, sometimes the handful of cases that describe the same rule. Two are worth naming: making the empty screen depend on the mode's name instead of on its contents, and giving that screen an alarm role. Both mistakes are invisible to somebody reading the change.
Why this is published
A distributor or a partner weighing up a group is not really asking whether it can build a mode switch. They are asking what happens in that shop when the plan turns out to be wrong, and whether something that looks finished is finished.
So the answer is on the record, including the unflattering half. The plan asked for a shop screen; there was no shop; we said so instead of inventing one. The switch was built and changed nothing — we found that ourselves, before it reached anybody, and wrote down how. A guard described itself in terms a measurement then contradicted, and the measurement won. A test layer we would have liked to cite as proof turned out never to have passed, and it is named above rather than left out. None of that is remarkable engineering. It is the ordinary discipline that decides whether the thing you buy behaves the way the demonstration did.
The platform this was built in is Lonevi, the group's longevity product. Its cabinet is the one described above.