Tender

Help pair skippers with crew. The board that says who still needs a crew for Sunday.

At Hoover Sailing Club, crewed boats go short-handed or stay on the trailer most race days because the skipper and a willing crew never found each other. Tender is a race-day board: a skipper posts a need, the engine proposes crew by rung and tells them on their phones, someone taps I can, the skipper accepts, and the board shows the match. Open to anyone who has learned to sail at Hoover, member or not.

The decisions and their reasoning are in docs/charter.md (ratified 2026-08-21) and one ADR per architecture decision in docs/adr/. The idea's pressure-test is forged-idea.md. Read the charter before changing scope; it carries the non-goals and the constraints a story must not violate.

Non-goals (v1)

• No payments, fees or dues.
• No race management, results or scoring.
• No second club, no cross-club matching.

Stack

Decision	Choice	ADR
Language/runtime	TypeScript on Node 24 LTS	001
Framework	Next.js 16	002
Data layer	Supabase Postgres via supabase-js, RLS, SQL migrations in supabase/migrations/	003
Hosting & scheduler	Vercel Hobby + Supabase Free; the ladder clock is pg_cron	004
CI/CD & branches	GitHub Actions; develop (default) + release (production) + feature PRs	005
Testing	Vitest for the engine, pglite for RLS, jsdom for a click, Playwright smoke later	006, 008
Notifications — the bet	Web push from an installed PWA + email to the current rung (Resend)	007

Working on it

npm ci
npm run dev        # http://localhost:3000
npm test           # vitest: the engine (src/engine), the RLS harness (test/), the components
npm run lint
npm run typecheck
npm run check:live # read-only probe of the live Supabase project; needs .env.local
                   # first line: which of the 9 server env names THIS shell has (names only)
npm run migrate:live supabase/migrations/0015_anon_revoke.sql  # applies it; -- --dry-run rehearses
npm run verify:migrations # reads pg_catalog: is the live project in the state the files describe?
npm run icons     # re-render public/*.png from brand/hsc-mark-primary.svg (rarely)
npm run perf:floor -- --db-container supabase_db_<dir>  # Lighthouse on /board and /post, at a fixture volume
npm run smoke -- --db-container supabase_db_<dir>       # the core path in a real browser (CI runs it on every PR)

Node 24 (.nvmrc). Copy .env.example to .env.local — names only are committed, never values.

The engine is src/engine/ladder.ts, a pure function: a post, a pool and a clock in; the open rung and the candidates (each carrying their own rung) out. Its test is the scaffold's one real test: six mutations on 2026-08-21 reddened exactly the predicted 3, 1, 2, 3, 1, 1 of 14 (docs/adr/006-testing-strategy.md).

Installable to a home screen (#28). src/app/manifest.ts is the manifest, public/sw.js the service worker, and src/install/ the "add to home screen" banner on /board. The worker is online only and has no listener for network requests — a cached board would show a need that has already been filled — and test/service-worker.test.ts enforces that. The icons under public/ are committed; npm run icons regenerates them and test/manifest.test.ts reads their real pixel sizes back out of the PNG headers.

The served half of that — /manifest.webmanifest and the icons as a real build returns them — is test/manifest-served.test.ts, which runs only when pointed at a running server, because CI runs the tests before the build:

npm run build && npm start &
TENDER_BASE_URL=http://localhost:3000 npx vitest run test/manifest-served.test.ts

next build bakes NEXT_PUBLIC_* into the proxy. To run a production build against a local Supabase stack, those variables must be set for the build, not just for next start — the proxy runs in the Edge runtime, where they are inlined rather than read at runtime. Build without them and .env.local supplies the live project instead, so every local session is refused and /board redirects to /join with the cookie sitting right there (measured 2026-08-25 on #28).

Component tests come in two kinds, and the split is deliberate. Most .test.tsx files render with renderToStaticMarkup and assert the HTML a member is served — no effect runs and no event can be dispatched, which is enough for anything decided at render time. The two files that assert what happens after a click (src/auth/PasswordFields.test.tsx, src/app/join/JoinForm.test.tsx, both #100) opt into jsdom with a // @vitest-environment docblock on their first line. It is per file on purpose: vitest.config.ts stays environment: "node", whose shape test/harness-budget.test.ts asserts for #78. Each of those files declares the environment exactly ONCE — vitest reads that directive anywhere in a file, comments included, so a docblock quoting it in full silently declares it a second time and the real line can then be deleted with nothing going red (measured on #100).

A Chrome profile the suite cannot delete (#280). The Chrome-backed test files close their browser through closeChrome (test/chrome.ts). That matters because browser.close() returns only once Playwright has deleted the browser's temporary profile under %TEMP%, and on the owner's machine that deletion sometimes never finishes. You see it as a line in an otherwise passing run:

#280: Chrome (pid 12345) exited, but Playwright was still deleting its temporary profile 10000 ms later, …

Before #280 the same thing ended the run success: false with every test passed, one Chrome file's afterAll reading Hook timed out in 180000ms. That was 7 runs of 7 on 2026-10-12, in the checkout and in a develop worktree alike. Each one leaves a playwright_chromiumdev_profile-* folder behind whose Default\ files refuse to open, or be deleted, from node or PowerShell ("Access denied"), although the folder's ACL grants you full control. DEBUG=pw:browser shows that Chrome's starting temporary directories cleanup with no finished after it. The folder is locked while Chrome is still running, and fifty Chromes launched the same way outside the suite never were.

The likely cause is the machine's antivirus, ESET Internet Security. A secured browser's profile gets Enhanced data protection, which ESET documents as preventing unauthorized applications from reading and writing the browser's user profile folders. Every chrome.exe on that machine also hides its command line from other processes, which ESET's Enhanced memory protection would do. Both are reasoned, not measured. Do not raise CHROME_CLOSE_TIMEOUT_MS for this: the time goes on the deletion, not on Chrome's exit, which closeChrome still waits for in full. Removing the leftover folders has not been tried.

The RLS harness (test/pglite.ts) applies supabase/migrations/*.sql to an in-memory Postgres and runs SQL as anon, authenticated or service_role. Since #48 it reproduces Supabase's default privileges for the first two before applying anything, so a "this role is shut out" assertion is load-bearing rather than passing on a harness that never granted the role anything. It deliberately does not reproduce them for service_role, which is what makes a missing grant … to service_role redden here (that is why 0014 exists); the reasoning and the measured cost of each choice are in that file's docstring.

What it still cannot see is a grant the live project holds that no migration makes and no default explains — a hand grant in the SQL editor. npm run check:live is the instrument for that. It probes with limit=0 and by GET so it can never write, and since #48 it reports, per table and per function, whether the public anon key could still reach it — failing the run if any could.

Applying a migration is npm run migrate:live <file> (#114), and it does one thing a paste cannot: it proves the payload arrived. It embeds the file in a dollar-quoted literal, asks Postgres for the length, byte count and md5 of what it received, compares those against the file on disk, and refuses if they disagree — before applying anything. A file compared against itself would prove nothing, and on this machine a clipboard really does re-encode a file: the characters at risk are the ones inside comment on … is '…' literals, which persist into the database as schema documentation. Every migration here carries some — test/migrate-live.test.ts asserts 0015's byte count exceeds its character count, so the hazard stays reachable rather than being a number in prose that ages.

It takes a file from supabase/migrations/ and never SQL. That narrowing is the point: a general "run this against production" command is what the token makes easy and what was deliberately not built. -- --dry-run prints the plan and sends nothing, and needs no credential at all. Note that npm run claims a --dry-run of its own, so both -- --dry-run and --dry-run are honoured — a silently dropped flag here is a real apply somebody thinks is a rehearsal, and an unknown flag is refused rather than ignored.

It needs SUPABASE_ACCESS_TOKEN in .env.local — a personal access token from the account page, not a project key. It is scoped by project and by permission, and it must cover this project and allow writes. Measured 2026-08-31 across three tokens: one scoped to another project answered 403 to every tender endpoint; one scoped here but read-only read fine and answered 25006 to every write; only the third could apply anything. GET /v1/projects returns exactly the projects a token covers, which is the one call that tells the three apart — and a 403 from this API says privileges, never scope, so the message does not point at the cause.

It is still the widest credential in .env.local, so .env.example says how to revoke it and test/migrate-live-scope.test.ts refuses the name reaching a place it should not. The service-role key is not an alternative: it authenticates to this project's own API and cannot run DDL. Deciding to apply is still the owner's; this changes who can carry it out, and whether the result is verifiable.

Asking whether the migrations are in place is npm run verify:migrations (#117), and it is a different question from check:live's. check:live probes as a client, over PostgREST, with the anon key, so it can see tables and functions and nothing else — which leaves it blind to most of what this repo's recent migrations do. It reads the same number either side of pasting 0011 (three check constraints), 0014 (one grant), 0015 (revokes and default privileges) or 0009's two triggers. This reads pg_catalog with the management token instead, so a grant, a constraint, a trigger, an index and a row-level-security flag are all in view. Neither command can answer the other's question and neither replaces the other.

Its expectations are parsed out of supabase/migrations/*.sql, never listed in the script. That is the whole design rather than a convenience: a hand-written expectation has the same author as the migration, on the same day, from the same understanding, so it certifies agreement rather than presence — and agrees with itself in exactly the case the command exists for, which is the migration somebody wrote and forgot to apply. Adding a migration needs no edit to the command; a statement in a shape nobody has written before is refused rather than skipped, so a kind it cannot read can never be silently unchecked.

Two things it deliberately does not claim. It never says a migration was applied — a revoke of a privilege nobody held and an update matching no rows both leave the database in the asserted state without the file ever running, so every verdict is about state, and the run prints that in as many words. And it names the statements nothing can testify to rather than counting them as passes: today that is three backfills in 0011, a seed insert in 0005, and 0015's sequence sweep, which has no sequence to sweep because no file here creates one.

Every query goes with read_only: true, so the platform enforces that this command cannot write. That matters because omitting the flag connects a write-capable token as postgres with the transaction open for writing: without it, a command whose whole purpose is to look would inspect production over a connection that could change it.

The half of 0015 this project cannot reach (#118)

0015 revokes anon from the default privileges on public, and it worked. ALTER DEFAULT PRIVILEGES with no FOR ROLE alters the current role's defaults and nothing else, though, and this project has two roles holding default ACLs on that schema. Read 2026-09-01, read-only, from pg_default_acl:

defaclrole	tables	sequences	functions
postgres	postgres, authenticated, service_role	postgres, authenticated, service_role	postgres, authenticated, service_role
supabase_admin	postgres, anon, authenticated, service_role	postgres, anon, authenticated, service_role	postgres, anon, authenticated, service_role

So 0015 cleared anon from all three of postgres's rows, sequences included, and could never have touched supabase_admin's. (The issue that found this recorded the postgres/sequences row as absent — "nothing to revoke, so nothing was stored". Measured, the row is there and reads like its two neighbours. Whether that cell was a mis-reading or the row was written since is not knowable from here; the reading above is the one that was taken.)

Nothing this repo can apply will narrow the supabase_admin rows. Measured the same day: pg_has_role('postgres', 'supabase_admin', 'member') is false, usage likewise, and postgres is not a superuser on a Supabase project — so ALTER DEFAULT PRIVILEGES FOR ROLE supabase_admin … is refused whatever credential this project holds. Closing it is an owner or Supabase-support action, not a migration. It is recorded rather than fixed, deliberately: a statement that measurably does nothing is worse than an absent one, because it reads as cover.

It is inert while it is inert, which is not the same as safe. A default ACL governs only the objects its own role goes on to create, and every object in public here is created by the migrations, which run as postgres. A platform-installed extension landing in public is the realistic way that stops being true — and the exposure would then be silent, since 0015's sweep covers what existed when it ran.

That is why verify:migrations now asserts the premise as well as the statement: every table, sequence and function in public must be owned by the role that owns the tables the migrations created. It fails on an empty population rather than passing, so a reading of "nothing has the wrong owner" cannot come from having read nothing. The table above is a dated observation and will age; the check is the part that stays current, and a red on it means the sweep is owed a re-run over whatever arrived.

Branches and deploys

• develop is the default and integration branch. Feature branches → PR → develop.
• release is Vercel's production branch. Merging into develop deploys nothing; promoting develop → release is the deploy, and it is the owner's — after any new migration has been applied to the live project (npm run migrate:live <file>; see Applying a migration).
• main is the backup branch: a known-good working version to fall back to if release breaks and cannot be fixed in place. It is promoted from release by a pull request the owner merges — from the branch production actually ran, so the backup is by construction a state that has been live. It is never a base for new work, and a main that has moved is the backup being taken rather than drift. (Owner directive 2026-09-01; supersedes ADR 005's "retired at scaffold" consequence.)
• githooks/pre-push refuses direct pushes to develop, main, master and (via githooks/owner-only) release. Enable it once per clone: git config core.hooksPath githooks. It runs githooks/checks before any other push.

Build stamp

Every page ends in a footer such as Tender v0.1.0 · 3c7759e · feature/169-build-stamp · built 2026-09-19 (#169). It answers "is production on the new one yet?" from the page itself rather than from the Vercel dashboard, which a member cannot see and the owner cannot see from the water.

• v0.1.0 is package.json's version, and that field is the one place the number lives. Bump it in the PR that warrants it — edit the field, or npm version patch --no-git-tag-version (the flag matters: the repo has no tags and the promotion flow is a PR, so a tag here would be a second, unread record of the same fact). Nothing else reads the field. Forgetting the bump degrades to "which commit", not "no information", because the next two parts change per build.
• The commit is VERCEL_GIT_COMMIT_SHA on Vercel and git rev-parse locally. Absent both, the stamp omits it rather than the build failing over a footer.
• The branch appears only off release, so a preview deployment cannot pass for production.
• The date is when next build evaluated next.config.ts, where all four are computed and inlined through env. They are baked into the bundle, not read at request time, so the stamp on a page is the stamp of the build serving it — a stale bundle cannot claim a newer one.

A build the config did not stamp — vitest, for one — prints unstamped build in words. An empty footer would be indistinguishable from a page that has none.

The performance floor

npm run perf:floor measures /board and /post/[id] with Lighthouse — mobile, simulated throttling — against a production build served locally with a fixture of 80 people, 45 race dates and 50 posts, signed in through a real session cookie. It prices levers against a floor of 80; it does not decide the framework. On a deployed build of release at that volume (#185, 2026-09-22) /board read 66, and 70 with a new footer layout shift fixed. ADR 002's lab condition fired on that reading, and the owner decided the same day to stay on Next.js 16. The framework is now reopened only by field data from members' phones, against thresholds ADR 002 will carry before any such data exists. /post/[id] read 78, and 82 with the footer fixed. Method, readings and the levers priced are in docs/performance-floor.md.

A seeded run writes — 80 people, 45 dates, 50 posts — so it refuses any Supabase URL that is not loopback before touching a row. It is the opposite shape from check:live and verify:migrations, which are read-only by construction, and it says so rather than relying on the flag being passed. --no-seed writes nothing and may therefore read the live project as a named crew account; the doc's Against a deployment has both recipes, including the seeded Vercel preview #185 used.

Two traps it guards, both of which produce a reassuring number rather than an error:

• next build inlines NEXT_PUBLIC_* into the Edge proxy, so a build made without them pointed at the local stack silently talks to whatever .env.local names. src/proxy.ts then finds no valid session and 302s to /join — a small static form that scores well. The command fetches each route with the cookie before spending two minutes on it and refuses anything but a 200, and refuses again afterwards if Lighthouse's own finalDisplayedUrl is not what was asked for.
• A single Lighthouse run is not a measurement. /board's three runs span 72–78 and /post/[id]'s span 78–90 on identical builds, so the command reports every run beside the median and warns when a route's runs straddle the floor rather than letting a lucky median pass silently. That warning is not hypothetical: /post/[id] passes on its median of 83 with one run at 78.
• A score is a score of a page, and these pages differ per viewer. The command CHOOSES who signs in — rated, not the club admin, owner of an open post — because the first version took the first person in the fixture, who is unrated, and so measured a board with all 45 availability forms suppressed. It read 78 that way and 72 correctly.

Everything that decides an outcome is in scripts/lighthouse-floor-core.mjs, exercised by test/lighthouse-floor.test.ts with no stack, no browser and no network — the same split as check-live.mjs and verify-migrations.mjs.

The smoke

CI's smoke job drives the core path through a real browser on every pull request (#45, ADR 006's "Playwright smoke later"): two people seeded pre-confirmed with auth.admin.createUser, each signing in through /join; the crew marks a race day on /board; the skipper posts a need; the crew answers "I can"; the skipper accepts. It then checks that the crew's phone reached the skipper only after the acceptance: it is absent from the skipper's page before, raw HTML and flight data included, and present after in the same read and in the contact panel. Before any of that, it fetches /support and /privacy with no session and redirects off (#147), and requires 200, the page's own content (a streamed page answers 200 even when it fails), and on /support the address the seed put on the club row. Last, since #220, a third browser signs up: the Sign up tab, the seeded invite code, an email and a password, then /welcome ("Finish your profile", #219) pre-filled with the provisional name, then the board as the name they gave. Since #226 a fourth browser arrives by the invite link, which carries the code, and types none: first with last season's code, where it must read the route's refusal with no account made, then with this season's, where it must land on /welcome. Since #242 the crew's browser ends by walking the docked nav at 390px (Post, Boats, Profile, Board) without a reload, and the tab marked as the current screen must move with every tap. Since #207 the run ends by reading the security headers off one response of each kind: the root, /join, the proxy's redirect for /board, /sw.js, the manifest, the tick refusing a call with no secret, a 404 and a built chunk. Each must carry every header with exactly its value. The job starts a local Supabase stack from supabase/migrations, builds against it, and runs npm run smoke. It runs on pull requests only, and timeout-minutes: 8 cancels it red past AC 3's budget. test/smoke.test.ts holds both of those lines.

Sign-in is by password, not the admin-generated magic link #45 was filed with. #99 removed the magic link from the app, and an admin link could now reach a session only by injecting cookies around the sign-in screen (owner decision, 2026-09-21).

To run it locally, start a stack in a scratch directory (never the checkout), build against it, serve the build, then run the smoke with the same three variables set:

npx supabase init --force --with-intellij-settings=false --with-vscode-settings=false
rm -rf supabase/migrations && cp -r <tender>/supabase/migrations supabase/migrations
npx supabase start -x studio,imgproxy,edge-runtime,logflare,vector,postgres-meta,supavisor,realtime,storage-api,mailpit
# in the checkout, with NEXT_PUBLIC_SUPABASE_URL, NEXT_PUBLIC_SUPABASE_ANON_KEY and
# SUPABASE_SERVICE_ROLE_KEY set to the stack's printed values:
npm run build && npx next start -p 3145 &
npm run smoke -- --db-container supabase_db_<dir> --base-url http://localhost:3145

It writes: it deletes and re-creates its two users, their race day and their boat, so it refuses any Supabase URL that is not loopback, and its npm script loads no .env.local. A re-run starts from the state CI does. The browser is the machine's own Chrome through playwright-core (channel: "chrome"): nothing is downloaded, and CI's Chrome is whatever ubuntu-latest ships, so it is not pinned. On a red run it saves each person's page to --out (CI uploads it as the smoke-output artifact) and names the step that broke. The steps after that one print as not reached, never as failed.

What it cannot see:

• Email. CI sets no RESEND_API_KEY, so every send fails at transport construction and is caught: the log carries one RESEND_API_KEY is not set line each for the rung, answer and match notifications, which also shows each notify call was reached.
• The hosted project's grants. The stack is the CLI's image, whose default privileges differ from the live project's. That seam is check:live's and #48's, not this job's.
• Google sign-up and the password reset. Those are the other entrances to a session; this job exercises the one a returning member uses and, since #220, the email sign-up with the invite code. The local GoTrue has no Google provider, so the Google entrance stays unwalked here.

Everything that decides an outcome is in scripts/smoke-core.mjs, exercised with no stack and no browser. The steps themselves were proven against a local stack by three mutations, each red at the predicted step and nowhere earlier: the accept step deleted from the smoke, acceptAnswer never calling accept_answer(), and the contact policy narrowed back to self-only.

Owner runbook — the steps only the owner can do

1. Create the Supabase project (Free; region near Ohio). Then apply every supabase/migrations/*.sql — npm run migrate:live <file> per file once SUPABASE_ACCESS_TOKEN is set in step 2, or the SQL editor before it is. Either route uses the same order: numeric, except 0003 after 0004 (its functions call is_admin(), which 0004 creates). The revoke files must be last — 0015 and 0016 — which numeric order already gives you: they create nothing and only take privileges away from what the earlier files created, so a table applied after them keeps the platform's default grant to anon and the sweep never saw it. Until 0015 is applied, npm run check:live exits 1 and names what anon can still reach — on the live project as of 2026-08-30 that is club, answer_counts() and accept_answer(). Then seed the club row in the SQL editor — it is a row, not a migration, so migrate:live does not take it — which no migration seeds and without which /api/join answers a bare 500 and nobody can sign in (measured 2026-08-23 on the live project, whose club table was empty):

   insert into public.club (name, brand_disc, brand_mark, invite_code, admin_email)
     values ('Hoover Sailing Club', '#395FAC', '#FCCF0B', 'CHANGEME', '[email protected]');
   

   admin_email is yours: the person who signs in with that address becomes the admin (0009's trigger sets person.is_admin on their first sign-in, and on an existing person the moment the column is set), so /admin loads with no SQL run against person. It is also public: since #147 /support shows it to anyone, signed in or not, as the address to write to, so use one you are content to publish. The colours are the Hoover pair (brand/) — the club accepted them on 2026-08-22 (#11, docs/charter.md § Forge checks), which is why the seed carries them rather than the mark set's default green. Changing them afterwards is /admin/theme, not an edit to this row (#41): that screen previews the mark in the pair and shows the contrast, and set_club_theme() (0028) refuses a pair under 3:1 at save, which a hand update would not. The code is a placeholder you rotate from /admin once signed in. On a project whose club row already exists, set the address on it instead:

   update public.club set admin_email = '[email protected]' returning admin_email;
   select display_name, is_admin from public.person where is_admin;  -- your row, once signed in
   

2d. The race morning (#37). The same tick asks every crew still merely accepted on a match for that day to confirm — a push if they have one, an email with a Confirm link — at the first quarter-hour on or after 06:00 America/New_York, once (match.reminded_at). The crew's Confirm button and the skipper's Sailed / Did not show buttons call set_match_status(). All of it is 0021. Apply 0021 before promoting the develop that carries #37. Until then a tap on any of the three buttons is refused (PGRST202, shown as one sentence) and the morning-of pass logs a read error and does nothing, while the ladder half still runs — neither failure is loud, which is why the order matters. Nothing to enable and no new secret.

2e. Error email to the owner (#43). src/instrumentation.ts is Next's server error hook, and it is the club's entire observability layer — the charter asks for "errors emailed to the owner; nothing else", Hobby has no email alerting, and it keeps the function log for one hour, so an error nobody reads inside that hour is an error nobody ever reads. Two things:

1. Set OWNER_EMAIL — the address the reports go to, in Vercel's environment. A ninth server-only name beside the eight in steps 1, 2, 2b and 2c. Unset means no email at all: the report goes to the function log with OWNER_EMAIL unset on it and expires there in an hour, which is the same as silence. Nothing else breaks, so this failure is quiet by construction — the one to check for deliberately rather than wait to notice.
2. Apply 0025 before promoting the develop that carries #43. It adds notification_log.signature, which is how "the same error again" is recognised across Vercel's several instances. Without it the deduplication read fails and the app degrades quietly rather than loudly: there is no 500 and no visible symptom, but the only window left is the one held in each running instance's memory, so a cold start or a second instance can send the same report again.
3. Apply 0030 before promoting the develop that carries #198. It adds error_report_claim and claim_error_report(), the one-row-per-error claim taken just before a send, so that two instances failing in the same few seconds send one report and not two (0025's read cannot see a send still in flight elsewhere). Without it the claim fails and the reporter falls back to what #43 shipped, again quietly: no 500, just the occasional duplicate.

What lands: one email per distinct error — its name and the route template it threw on, TypeError /post/[id] — at most once an hour, carrying the method, the path with any query string removed (a reset code, an invite code and /auth/callback's PKCE code all live in one, and this text goes to an inbox), and the first 20 lines of the stack. It rides Resend on the same 100/day as everything else and stops at 95, like every other sender; past that the report goes to the function log instead and notification_log records an error_skipped_cap row.

One report is not a thrown error (#198). A refused read of the club row no longer fails the page: it is painted in the seed pair (#395FAC / #FCCF0B) and reported as ClubThemeReadError at loadClubTheme, whose message carries the platform's reason. The same one-an-hour rule applies, so an outage of that read is one email, whatever the number of pages it touched.

What it cannot see, so nobody hunts for it here: an error the app has already caught. Every …Live wrapper in src/notify/live.ts swallows its failure to a console line on purpose, and a swallowed error never throws out of the route, so it never reaches the hook. The same is true of anything that fails before the app runs — a bad deployment, a DNS mistake, Vercel itself.

Confirm it after the first deployment by reading the log rather than waiting for a fault:

select sent_at, kind, signature, error from public.notification_log
 where kind in ('error', 'error_skipped_cap') order by sent_at desc limit 5;

3. Vercel: import the repo, set the production branch to release, add the environment variables, turn on Deployment Protection → Standard Protection (previews carry the production Supabase host), add the domain tender.madcowsailing.com (CNAME per Vercel's per-project target).

4. GitHub secrets SUPABASE_URL and SUPABASE_ANON_KEY for .github/workflows/keepalive.yml, which reads the project once a week so Supabase Free never pauses it (7 idle days). GitHub disables scheduled workflows after 60 days of repo inactivity — check it in spring.

5. git config core.hooksPath githooks in every clone. .git/ is not tracked, so this is per-machine and per-clone; an uninstalled hook produces no error and no output, and every symptom of its absence is an absence. Two things it does not do on its own:

   • It fires on POSIX clones only if the executable bit is stored in the index. Git skips a non-executable hook silently. core.fileMode=false on Windows means chmod +x never reaches the index there, so the bit is set deliberately with git update-index --chmod=+x and the check is git ls-files -s githooks reading 100755 — not ls -l, which on Windows answers about a bit git is ignoring in both directions.
   • It is a local echo, not the wall. git push --no-verify skips it, and this repo is public, so the branch rules that hold against every client are GitHub's ruleset, which the provisioning story sets up. The hook stops the habit; the ruleset stops the push.

6. A member who wants out deletes themself — Leave the club at the foot of /profile (#42, 0027). Their profile, contact, availability, answers, messages, devices and suspension go; every match they were on stays as a row with that side null, shown as "former member", so the season's count is unchanged; their boats stay as ownerless names on the posts that already happened, and an open post of theirs stays on the board until its date passes (owner decision 2026-09-20). Removing someone else has no screen yet. delete_person() admits an admin, but the SQL editor is not a signed-in member, so from the dashboard delete the auth user: Authentication → Users, or delete from auth.users where id = '<uuid>'. person cascades from the auth user and 0027's rules do the rest. The send log's email addresses and device push addresses go by 0033's person_blank_log trigger, which fires however the person row goes (#201), so there is nothing to run first. If a member's own deletion lands on , their rows are gone and the auth user is not — delete it under Authentication → Users. Since #204 you are emailed when this happens: an error report named carries the auth user's id. The leftover cannot make itself a member again: since #263 () clears the 18+ attestation with the rows, so a password reset or a Google sign-in from that address is refused and removes the auth user itself, and only a sign-up with this season's invite code makes a new member, as it would after a complete deletion.

Brand

brand/ holds the mark set from the 2026-08-21 brand work. The four SVGs there are the Hoover-themed pair (#395FAC / #FCCF0B); the default-green exports the brand README's table names were never exported. The component that was brand/TenderMark.jsx is src/brand/TenderMark.tsx since #41 — typed, inside tsconfig, one copy — and its contrast rule is src/brand/contrast.ts, with the same rule spelled in SQL by set_club_theme() (0028) so it holds at save. Inline the component — never <img src> an SVG that uses the page's colours. The app's pair is the club row's (brand_disc / brand_mark): the root layout reads it on every request and sets --brand-disc / --brand-mark, the viewport and the manifest from it, and the admin changes it on /admin/theme.

The product's palette, type scale, spacing scale and motion are the token layer in src/app/globals.css (#153) — constants in the Hoover pair, not the row, because a pair an admin may save at 3:1 cannot promise 4.5:1 to the text on it. Every colour token has a dark value, and the pairs a surface may use are the table in test/tokens.ts: test/tokens.test.ts computes each one in both schemes and prints the ratio, and test/reduced-motion.test.ts reads transitionDuration in Chrome under prefers-reduced-motion. A surface that needs a new pair adds it to the table, which adds it to the proof.

Every page renders inside the app shell, src/shell/AppShell.tsx (#154): skip link, the mark, the signed-in person and sign-out, the navigation (docked to the bottom edge on a phone), the page in one frame, the build stamp. A page's <main> carries no frame of its own — test/no-inline-frame.test.ts refuses one — and data-measure="wide" is the one knob (tables). test/shell-focus.test.ts Tabs through the shell in Chrome, prints every stop's ring colour and ratio, and measures every target at 390px.

The six member-facing surfaces (#155) paint from data-attribute hooks in the same stylesheet — data-stack, data-row, data-list, data-banner, data-race-date, data-badge and the rest under the surfaces — and carry no inline style the tokens could express; the one survivor is the rung badge's --rung / --rung-dark, which is the ladder's data. test/surfaces.test.ts renders each surface through the real layout with fixtures (test/surfaces.ts), then reads it in Chrome at 390px in both schemes: every text element's contrast computed and the lowest printed, the board's rows and rules, the join tabs' selected state, and axe-core's WCAG 2.2 A/AA rules over every surface (#229; the version is pinned and recorded in the file's header, and target-size runs only because wcag22aa is asked for). The rung colours have a dark value each (RUNG_COLOUR[n].dark), proven in test/rung-contrast.test.ts.