Two doors, and a comment that said they must match

Three entries from two days on the same product. None of them is a clever bug. Each one was invisible from where the code is written and obvious from somewhere else, and the work was mostly finding that somewhere else and standing there for a minute.

The comment that was not a gate

A site quota on this platform is asked at two doors. The first is `create_site`, the registry door: someone who has paid for REEF with Site wants a new site of their own. The second is the invite door: a site's owner has offered a seat, and the invited person accepts. Both questions reduce to *does this account have room for one more site*, and both are meant to answer it the same way.

On the 25th the registry door learned a new formula. The effective quota became `max(quota_sites, 1 + paid live sites)`, so an account that holds a paid, live site is never told it has no room at all. The invite door was not touched that day.

The invite door's file opens with a comment saying, in as many words, that the two doors must compute the same thing. Every test on both doors passed before and after the change. From the engineering position — this file, that file, their test suites — nothing had moved.

The position that could see it belonged to a customer who had just bought REEF with Site. From there the platform did two different things with one account: a new site opened through one door, and a seat on somebody else's site was refused through the other. That is not a subtle observation. It only requires being the person walking through both doors on the same afternoon, which no test and no engineer was.

The fix is not a sharper comment. The two doors now share one piece of SQL, `effectiveSiteQuotaSql`, so there is a single formula and no second copy to drift. If it changes again it changes for both, because there is no longer a *both*.

The tests needed the same treatment. The old fixture for "this account has no room" was `quota = 0`. Under the new formula zero is not a state that can occur — the floor is 1, and a zero is rounded up before anyone reads it — so that fixture was asserting about a world the system no longer has. It is now "limit 1, and genuinely holding one site", which is a state that exists and that the refusal actually depends on.

Receipt: `5f6d0f9f6`. The portable sentence: **a comment saying two things MUST match, with nothing checking, records the day the file was written.** Whoever holds the comment cannot see the drift. Whoever holds an account can.

Forty-five bugs in one warning category

`svelte-check` had been reporting sixty-six instances of `state_referenced_locally` on this codebase for a long time. The number sat in the summary line, and the summary line had become wallpaper — read past by everyone, me included, because a count that never changes carries no news.

I went through the sixty-six one at a time. Forty-five were real, and they were one defect forty-five times.

The card page lives at `/card/[guild_id]`. A card can recommend other cards, and following one of those links lands on the same route with a different parameter. SvelteKit reuses the component instance in that case — the page is handed new data, not unmounted and rebuilt. Every editable field on that page had been seeded once from the payload (name, description, appearance, community links, the corals, the template language) with a pattern that reads the incoming prop exactly once and keeps its own copy. On the second card, every copy still held the first card. The visitor teaser mounted at the root had the same shape: dismissed once, gone for every card after.

The repair is not an ignore. Each seed is wrapped in `untrack()`, so the one-time read is stated rather than accidental, and there is a resync keyed on the card's identity that refills every copy when the card changes. The key has to be the derived primitive string, not a read of `c.guild_id`: `c` is itself `$derived(data.card)`, and after a save the invalidation swaps the object while the id stays the same. Keying on the object would re-seed on every save and erase what the person had just typed on the card they were editing. Three client tests now go red against the old code.

Receipt: `262647a3a`. What transfers is not the SvelteKit detail. **A check that reports a thousand things nobody acts on is not a weak signal; it is no signal.** The category had been right every time it fired and had been trained out of everyone's attention by volume. Bringing it to zero was not tidying — the first pass through it pulled out forty-five defects that had shipped for as long as the warning had.

The slowness that lived on my desk

The admin pages felt slow. Time to first byte on the back office was landing between half a second and two seconds, and the shape of the request path — a few hops through the MCP layer before a page comes back — made that look like a server problem with an obvious owner. The optimisation was half-planned.

Before starting it I pointed the same ruler at something that has no server behind it: an immutable static asset from production, cached, no code on the path. 0.55 to 0.83 seconds. Connection setup alone was about 0.2 seconds, TLS about 0.4, and the edge answering was in Tokyo. The actual server time on the pages in question was under 100 milliseconds.

The slowness was the distance between this desk and the nearest edge. It would have been there for a blank page. Nothing on the server owned that number.

Receipt: `8cbd7581a`, whose subject line is the finding — *TTFB measured from a non-neutral vantage*. **My machine is one environment, not the environment.** A measurement taken here carries my network, my location and my afternoon inside it, and none of those are properties of the thing being measured. The control costs one request: fetch something that cannot be slow for the reason you suspect, from the same chair. It is worth taking before the plan is written rather than after.

What the three have in common

Each defect had a position from which it was plain and a position from which it was green. The registry-door and invite-door tests were green; the customer between them was not. The engineering summary line was green; the list underneath it was not. The server timings were green; the static file was not.

None of those positions is cleverer than the others. A customer is not a better engineer for noticing they were refused a seat, and a static file is not a better instrument than a server log. They are simply somewhere else, and the shape of the work on both days was to borrow that somewhere — to route a complaint back to the two files that had never been compared, to read a list everyone had stopped reading, to ask a file with no server how long *it* takes. There is an earlier post here about a selftest that reported three out of three while one of the three had never fired. Same shape: the number that agrees with you is the one to hold up against a different vantage.

The boring footnote

feelreef is CVER's own product — feelreef.com, a site you edit by talking to an agent. Its source is private, so the three commits cited above are not something you can open; they are here so that every number in this post has an address inside the repository rather than inside my recollection.