Tighten the release process: two identical faults reached dev and were found by hand

[Devski]

What happened

On 05.09.2026 the same root cause shipped to dev twice, and both times the person who found it was Dawid, on his phone, using the product.

1. Changing a profile address failed with Saving failed. Try again.
2. Uploading a photo failed with Something went wrong. Try again.

Both were one mistake: a new CHECK constraint plus an upsert that spelled a now-empty column into its INSERT values. PostgreSQL evaluates constraints on the tuple being inserted before ON CONFLICT turns it into an update, so the constraint fired on writes that never touched the constrained column.

The gate was green for both. The deployment reported healthy for both.

Why nothing caught them

The full journey does not run on a pull request, or on a push to main. e2e-full — register → verify → name → address → photo → public page — runs only on workflow_dispatch and on version tags. Both faults sit squarely on that path. This was raised on 05.09.2026 and deliberately deferred; the deferral is what let both through. Measured cost of running it: 227 seconds.

The unit fixtures describe a world that no longer exists. Every account in profile.test.ts and profile-handle.test.ts is created with a non-empty users.name. Registration stopped filling that field in #36 — so the tests kept proving the old reality, and the new one was untested by construction. A change to a shared assumption made every existing test simultaneously less true and still green.

The deploy proves liveness, not function. remote-deploy.sh waits for the container's HEALTHCHECK, which asks whether the process answers. Neither fault stopped it answering.

One fix, one instance. The first was fixed in setHandle while the comment beside it read "setAvatar does the same". Nothing made the second location visible; nothing checked whether the class was closed rather than the case.

Acceptance criteria

• The full journey runs on every pull request and every push to main, not only on demand
• At least one fixture account per database-backed suite is created the way registration actually creates one, so a change to that path breaks tests instead of hiding in them
• The deploy verifies one real write end to end after the container is healthy — not merely that it responds
• Adding a database constraint forces the paths that write that table to be exercised: an inventory test, a checklist in the migration template, or an equivalent that fails when it is skipped
• A written rule for fixing a class rather than a case: when a fix touches a shared pattern, the other occurrences are enumerated in the change

Verification

• Re-introduce either fault on a branch and confirm CI is red before a human sees it
• Confirm the added time per run against the measured baseline (a normal run bills about 7.6 job-minutes today)

Why this matters more than the two bugs

Both were cheap to fix and neither destroyed data. What they cost was confidence: two stages of a pipeline passed something a person found in under a minute of ordinary use. A release process that needs the product owner as its last line of defence is not a release process.

Spec: SPEC.md §6 · Size: M · Label: enhancement

[Devski]

Correction to the emphasis above, 05.09.2026

Dawid asked the sharper question: do the unit tests write to a database at all — isn't that where this belongs?

They do, and it is. src/db/test-db.ts runs PGlite — real PostgreSQL compiled to WebAssembly. The suite writes real rows and real constraints fire; today's reproducing tests failed with PostgreSQL's own error text. So the database layer is genuinely covered, at a cost of seconds rather than the four minutes a browser journey takes.

Both of today's faults were catchable there. They were not caught because every fixture account is created with a non-empty users.name — the world before #36 stopped filling it. The layer was right; the data in it was stale. Changing a shared assumption made every existing test quietly less true while all of them stayed green.

That reorders this issue. The first criterion is not "run the browser journey more often" — it is:

Fixtures must be built the way the product builds them. Where a suite creates an account, at least one must be created through the same path registration takes, so that changing that path breaks tests instead of hiding inside them. A fixture that hard-codes what the code used to do is a test that proves history.

Running e2e-full on every pull request is still worth its 227 seconds — it is the only thing that exercises the browser against a database, and it would have caught both as a backstop. But it is the second line, not the first. A fault that a three-second database test can catch should never need a four-minute browser to find it.

[Devski]

Done, in two halves, both merged today.

Half one: the full journey runs on every change

It fired only on a vX.Y.Z tag or on demand. deploy-dev now depends on it, so the instance receives only a build whose journey passed — and a pull request cannot be merged with the journey broken.

Twice per change is deliberate: on the pull request it is the gate, on main it is the deployment's precondition, since a job on a branch cannot decide what the instance gets. Measured cost: 216 s, in parallel. Critical path from push to a running dev is now 6 min 42 s; a run bills about 11 job-minutes against 2000 free each month.

Half two: fixtures built the way registration builds accounts

This was the cheaper and more important half, and the one that would have caught both of 05.09's faults in seconds rather than minutes.

Fixtures inserted their own idea of a new user, hard-coding a name the product had stopped writing. REGISTRATION_NAME now says what a sign-up sends; the register form and the test factory both use it, and one test pins the factory's row against a real sign-up through Better Auth. Change what registration sends and either the factory follows or that test goes red.

Going through the real endpoint in every fixture was rejected on evidence: scrypt costs about three seconds per account, fixtures run before every test, and a registration bug would then fail fifty tests that are not about registration. The shortcut stays; it stops being a copy nobody owns.

What honest fixtures exposed

• Twenty tests claimed an address with no display name — something onboarding never does.
• users.name is no longer read anywhere. It was the middle link in two fallback chains, holding the e-mail local part; that is how an address reached the display name and the proposed handle in The public profile shows the user's e-mail address as their name #36. Registration leaves it empty, so the branch could only return nothing.
• Two writes could still create a nameless profile row and die on the database CHECK as a 500. setHandle now refuses with displayNameRequired; setAvatar refuses outright. The second is the fault that broke photo uploads on dev, and it was reachable, because the session exists before onboarding does.

What is not covered

The acceptance criteria also asked for a post-deploy check that exercises a real write, and for something that fails when a database constraint lands with no UI counterpart. Neither is here. The first is small; the second overlaps #39 and belongs there.

Recorded in SPEC §6, with the reasoning and the measured cost, so the arrangement is not quietly reverted as excessive.

Merged in #45 and #46.