A capacity witness that cannot flake, and the social card actually served

[caviri]

The soft spot

capacity.oversell-by-one was the last mutation judged by a coin flip. Its witness was a declared-flaky concurrency spec, which made the entry ambiguous in both directions: a MISMATCH might be the flake, and on 2026-08-14 an expected red simply failed to arrive because the flaky spec stayed green under its own mutation.

The mutation is one character in capacity.go:46 — >= becomes >, so the room seats one person too many and the queue starts one arrival late.

The witness

The race spec's real claim is an end state: the confirmed roster equals the capacity, read back from the DB. Only sharing the last seat needs concurrency — where the last seat is does not.

So the new spec fills an event to exactly its capacity one join at a time, counting the roster after each, then asserts the next arrival queues with the confirmed count unmoved. Same claim, same path through the handlers, no goroutines and no clock. Three capacities (1, 2, 3), because a rule that is off by one is off by one at every cap and a single number cannot distinguish "the boundary moved" from "this event was set up wrong". Under the mutation it fails in 0.012 s.

The flaky spec is dropped from expectReds, not deleted

expectReds is by design the one place KNOWN_FLAKY cannot reach, so a flaky test listed there makes the verdict unreliable both ways. The original justification — "a flaky test can still be a genuine witness" — was sound while it was the only witness hammering the cap; that premise is now gone.

Dropping it does not silence it: its red lands in extras, is excused, and is printed with its reason on every run. Evidence on screen, not on the ballot. The spec stays as a test, because it pins capacityMu, which once genuinely oversold an event. The flake itself is untouched and still reds CI — a test-side race, out of scope here.

Verdicts

Seven runs of mutate.sh run capacity.oversell-by-one, EXACT every time (7 reds observed / 6 expected / 1 excused). No MISMATCH in either column.

Full fast tier: 38 run — 37 exact, 1 known gap, 0 untested, 0 other failures. The baseline's "other failure" was this entry; nothing else moved. Backend green across three runs, ~10 s wall, the runner's Go arena 9.0–9.2 s against a ~9.3 s baseline.

And the social card is now actually served

:8081 had been serving the old 90,689-byte card because build/ snapshots static/ at build time. Rebuilt through the shared helper and restarted; served sha256 now byte-identical to the static file.

Two traps found doing it, both documented:

• The 9p EPERM on the atomic swap has a reproducible cause — with the :8081 server up, all five rename attempts burn; stop it and the next attempt succeeds. The order is stop, build, start.
• ⚠ The swap does not reach a server that booted against the old tree, and the bytes are still right. adapter-node serves through sirv, whose manifest is built once at boot — so :8082 streamed the current file while advertising the previous length and ETag: Content-Length: 85099, 58,130 correct bytes, curl: (18) transfer closed with 26969 bytes remaining on every request. Hashing the download says MATCH. The obvious check would have passed while every crawler saw a truncated image and every cache honoured a false ETag. Both ports now agree on bytes and headers.