CHANGELOG

League pages keep the shared TFCL layout by default. Operators can opt into league-owned header and footer chrome while retaining league branding, custom pages, links, and CSS controls.

League owners and operators can replace the shared TFCL header and footer with sanitized custom HTML while required TFCL Play attribution remains visible.

Adds league-owned header title, logo, navigation, footer copy, links, layout, and colors while preserving the required TFCL Play attribution.

Allows operators to publish league rules and edit descriptions for leagues and seasons.

Allows league operators to customize the public league page with a header image and custom CSS.

Allows league operators to assign a map to each regular-season week.

Allows roster changes during the regular season and locks them a configurable number of weeks before playoffs, defaulting to two weeks.

Stores reusable division names at the league level so future seasons can reuse and edit the same divisions.

Allows operators to generate rounds on one recurring day while assigning matches to a separate default day and time.

Adds public match discussion threads and leader-only server connection details with a TFCL reservation link.

Operators can set the first match due time, recurring weekly match day and time, and the roster lock deadline when creating a season.

Seasonal league pages now use /l/<league-slug> and /l/<league-slug>/<season-slug>; the original league 1 uses the canonical slug /l/ultiduo.

Adds reusable leagues, seasons, up to five divisions, weekly Swiss-style team pairings with one to four matches per team, and configurable eight or sixteen team single-elimination playoffs.

Tournament creators can choose Swiss competition with 1-7 rounds. Pairings are generated round by round from standings, prefer equal-score opponents, avoid rematches, award deterministic byes for odd fields, and finalize standings after the last round.

A site-wide safety-net sweep now periodically cross-checks the actual list of running Vultr servers against every place TFCL Play tracks them, and destroys any real server that somehow has no record anywhere (e.g. if a creation call succeeded but the follow-up database write failed). Also broadened the existing expired-server cleanup so it runs from high-traffic pages instead of only the page that created the reservation.

- The persistent server pool (previously "Ultiduo Pool") now supports both ultiduo and sixes/highlander server plans. - Admin panel routes renamed from /ultiduo-pool to /pool with new plan_type parameter. - Admins can now manually provision a pool server of any plan type, and destroy a pool server at any time (even if busy). - Under the hood: the table is renamed from ultiduo_server_pool to server_pool and gains a plan_type column.

- Ultiduo lobbies now provision their server the MOMENT the lobby is created, not after gathering/ready-check/voice-check finish - no more waiting on a cold Vultr boot right when you expect to connect. - One Ultiduo server now runs persistently 24/7 as an always-ready baseline. If it's already in use when a new lobby is created, a second on-demand server boots immediately so there's always at least one instantly available. - The persistent baseline server is automatically reinstalled (fresh Docker image pull) once every 24 hours, but only while idle - a live match is never interrupted.

After v0.158.15 fixed the "Network error" crash, captains hitting the `team_too_large_for_cup` / `team_too_small_for_cup` 409 saw the inline banner render with garbage placeholders: *"this cup's ceiling is ?, your roster has ? ... Remove 0 players to register."* Separately, captains with a roster that correctly fit the cup's format were still rejected as "too large" — reported live on Ultiduo Cup #1 (cup #8) for a 2-player team against a 2-player cap.

Two independent bugs.

1. "?" placeholders. The register page's `call()` helper returned only `{ __error, __status }` when the server responded with non-2xx, silently dropping the `rescue` object (ceiling, roster size, surplus player ids) and the human-readable `message`. `showRosterAlert()` rendered with `rescue` fully `undefined`. Fix: `call()` now preserves the full server response body on error, spreading it before adding the `__error`/`__status` markers.

2. Departed members inflating roster count. The query that auto-fills a cup roster from a captain's `/teams` row never excluded team members who had since left the team — every historical member of the parent team was still counted toward the cup's player cap. A team with 2 active players but 1 former member showed up as a 3-player roster. Fix: all three roster auto-fill queries in `cups-db.ts` now filter `WHERE team_id = ? AND left_at IS NULL`, matching the pattern in `teams-db.ts`.

Right after v0.158.14 shipped the correct `team_too_large_for_cup` / `team_too_small_for_cup` 409, captains hitting that 409 saw the register form report a generic "Network error" instead of the intended inline roster-size banner. Console showed `esc is not defined`.

Root cause. The register page's inline `<script>` calls `showRosterAlert()` when the server returns those 409 codes, and that function calls `esc(...)` to HTML-escape the cup format name. `esc()` is a server-side TypeScript helper defined at the top of `cups-pages.ts` for building the page HTML on the Worker — it does not exist in the browser's JS scope. The undefined-function reference threw inside the fetch handler, which the generic catch-all reported as "Network error" even though the server had responded correctly.

Fix. Added a small client-side `esc()` helper inside the register page's inline script so both call sites resolve correctly and the roster-size banner (with "remove/add N players" copy and surplus player ids) now renders as intended.

Captains registering a `/teams` roster that didn't match the cup's format player limits (e.g. a 3-player team for a 2-player Ultiduo cup) got stuck in a loop: `/register` would 409 with `cup_has_unpaid_ghost_teams` and never let them pay, even after withdrawing every named registration and retrying.

Root cause. `registerTeamForCup` inserted the new `cup_teams` row BEFORE checking the roster against the cap/floor. When that check failed, the function threw — but the row it had just inserted was never cleaned up, leaving a permanent `status='registered'` row with zero players and no PayPal order. The newer ghost-row guard (v0.157.19) then treated that row as an unresolved pending registration on every subsequent attempt, masking the real roster-size error.

Fix. The roster ceiling/floor check now runs BEFORE the `cup_teams` row is inserted, so a captain whose roster doesn't fit the format sees the real `team_too_large_for_cup` / `team_too_small_for_cup` error immediately and no orphan row is ever created. Two pre-existing orphaned rows on Ultiduo Cup #1 (cup #8) were cleared from production.

Two independent fixes:

1. "Loading your teams" never resolved. Captains registering with their existing `/teams` row for a league cup saw "Loading your teams…" in the dropdown and nothing ever replaced it — the captain's `/teams` row never appeared in the picker. `src/lib/cups-pages.ts` lines 1700/1703/1707 each had a single-quoted JS string containing an escaped apostrophe (`'cup\\'s'`). Vite/Rollup stripped the backslash at bundling time, so the browser-side script saw `'cup'` followed by literal `s` outside the string — a `SyntaxError` that aborted the entire `<script>` block before `loadTeamsForLeague()` could be called. The three buggy strings are written as `'cup&apos;s'` instead — the apostrophe is an HTML entity so it cannot terminate the JS string. Bonus: `loadTeamsForLeague` now has explicit fail/empty-array branches.

2. Full 4xx envelope in console. A single `console.error('[cup-register] server rejected', j)` line fires inside the fetch catch before the typed alert/banner handler runs, so the next captain-side 409 report includes the full `{ __error, __status, ...j.rescue }` envelope alongside the existing user-facing banner.

Captains who weren't already signed in and clicked register or create-cup hit a `404 Not Found | TFCL Play` page instead of being routed through Steam OpenID back to where they were headed. They never reached the PayPal Smart Buttons on the post-register block.

Root cause. `src/routes/cups.ts` was redirecting unauthenticated captains to `/login?next=…` on three paths — `GET /cups/create` (line 133), `GET /cups/:slug/register` (line 272), and the cup-detail "Login to register" button. There is no `/login` page handler — the actual entry point is `/auth/steam?next=…`, which 302s to Steam OpenID. So every `next=` flag was pointing at a route that didn't exist.

Fix. All three call sites now redirect to `/auth/steam?next=…` instead. The two `/docs/api-keys` status cards are patched in the same commit so anonymous docs readers → "Sign in with Steam" reach the actual Steam OpenID flow.

A captain registering a roster that exceeded the cup's cap got a single-line `team_too_large_for_cup: roster of N exceeds cup cap 2 (format=ultiduo)` toast with no actionable info: they couldn't tell whether to drop a teammate from the cup roster or remove them from the parent `/teams` row, and didn't know which player_ids were the surplus.

Three-layer fix.

1. Lib (`src/lib/cups-db.ts`) — the existing `team_too_large_for_cup` / `team_too_small_for_cup` throws now attach a structured `err.rescuePayload = { cup_id, roster_size, roster_ceiling, floor, format, direction, surplus_player_user_ids: [...], missing_player_count, friendly }`. For too-small we report `missing_player_count` instead of surplus ids.

2. Route (`src/routes/cups.ts`) — catch-block forwards `rescue` to the 409/422 envelope; the `team_too_large_for_cup` arm is `startsWith()`-matched so lib-side string variants funnel to the same UI pathway.

3. UI (`src/lib/cups-pages.ts`) — new `<div id="roster-alert">` red banner under the pending banner. Builds copy from the typed payload: ceiling, current roster size, surplus ids rendered as a `<ul>` of `user_id <code>NNN</code> (surplus — remove from parent /teams row to fit the cap)`, plus a "For league cups, this usually means…" hint linking to `/teams`.

Community-cup form copy is now accurate: `Format ultiduo roster: 2–3 players (captain counts as one). Roster of exactly 2 is the smallest legal roster; anything below or above is rejected at submit.`

A captain could create TWO pending `cup_teams` rows under two different display-names without paying for either, then have NEITHER show up in the "you have a pending team to resume" rescue banner because the pre-flight query was `LIMIT 1` AND only matched by display_name. After re-trying they got an opaque "display name taken" error pointing at the *second* ghost with no way to know about the first, so they couldn't withdraw it.

Three-layer fix.

1. Lib (`src/lib/cups-db.ts`) — server-side ghost-row guard runs BEFORE the display-name dup check; covers ghost rows for DIFFERENT names (the Adrian Blud / Adrian Bludd scenario). Throws `Error('cup_has_unpaid_ghost_teams')` with `rescuePayload = { existing_ghost_teams: [...], requested_display_name, rescue_actions: [...] }` so a captain cannot create a third ghost.

2. Route (`src/routes/cups.ts`) — `GET /api/cups/:id/my-pending-team` widened from `LIMIT 1` to full set; new 409 mapping for the ghost arm added.

3. UI (`src/lib/cups-pages.ts`) — rescue banner renamed from singular `myPendingRow` to plural `myPendingRows`; lists ALL unpaid rows with four action buttons: Resume PayPal for the most recent team, Withdraw this team's name, Withdraw ALL unpaid teams (red `#dc2626` button — the killer feature), Change the name and retry.

Also relaxed CSP: `'unsafe-eval'` added to script-src so the PayPal SDK can `Function()`-evaluate its `react-is` session-stability check.

v0.158.7's static-asset fix bumped the two HTML references to `?v=0.158.7`, but the URL itself had already been cached at the edge against the prior text/plain 500 with `cdn-cache-control: public, max-age=31536000, immutable`. Even though v0.158.8 added a Worker-side fallback that served the file correctly on a fresh cache key, the existing `?v=0.158.7` requests still returned the old 500 — so the 1-year immutable directive was winning over every deploy's intent.

Fix. Bump the cache-buster query string from `v=0.158.7` to `v=0.158.9` (`src/lib/layout.ts`) and rebuild `dist/_worker.js`. The new URL is a fresh cache key that the v0.158.8 Worker fallback handles correctly.

After v0.158.7 removed the `serveStatic('/static/*')` middleware, the Cloudflare Pages native asset handler took over `/static/*` — but `play.tfcleague.com`'s zone had cached `GET /static/tfcl.css` against the prior failure with `cf-cache-status: HIT, age: 77565`, and the immutable 1-year directive blocked revalidation. Separately, `/api-docs/*` (the developer docs SPA bundle, served from `public/api-docs/`) was returning 404 on `tfcl-pugs.pages.dev` and `play.tfcleague.com` because the Pages runtime had stopped honoring `dist/_routes.json` exclude rules for files derived from `dist/` at vite-build time.

Fix. Two `?raw-import` modules let `vite-rollup` inline the bytes straight into `dist/_worker.js`:

- `src/lib/api-docs-assets.ts` — pulls in the `public/api-docs/*` source files; Hono's RegExpRouter matches `/api-docs/*` and serves the inlined payload with the right MIME itself, bypassing the broken Pages exclude routing. - `src/lib/tfcl-css-asset.ts` — same pattern, but only for `tfcl.css` (the one file the failure reproduced for); other `/static/*` assets are untouched. Mounted as `app.use('/static/tfcl.css', serveTfclCss)`.

A `/static/tfcl.css` early-return in the response-wrap middleware prevents the 5-minute `Cache-Control` from being clobbered back to the long-lived immutable version.

After v0.158.6 shipped, every browser visiting `play.tfcleague.com/admin` saw two console errors: `GET https://play.tfcleague.com/static/tfcl.css` and `GET https://play.tfcleague.com/static/admin-approvals.js` both returned `HTTP/2 500` with `Content-Type: text/plain; charset=UTF-8`. The browser refused to apply the CSS or run the script, visually breaking the redesigned admin panel. The 500 was cached at the Cloudflare edge with `cdn-cache-control: public, max-age=31536000, immutable` — a one-year-stale record.

Fix. The original production deploy added an `app.use('/static/*', serveStatic({ root: './' }))` middleware in `src/index.tsx` BEFORE `_routes.json` exclude rule could hand off to the Pages asset layer. v0.158.7 removes that middleware so the Pages asset layer serves `/static/*` natively with correct MIME. Long-term prevention: the two HTML references now carry `?v=0.158.7` cache-busters so a future failure cannot pin to the same cache key. To flush existing stale cache, dev_mode was turned on for 10800 seconds (3 hours); `GET /zones/{id}/purge_cache` returned 401.

What to do. Hard refresh (`Ctrl+Shift+R` / `Cmd+Shift+R`) on `play.tfcleague.com/admin`. The page should now load with the v0.158.5 redesigned admin sidebar and the API KEYS mint modal working.

v0.158.5 admin redesign was redeployed 5 times but on `play.tfcleague.com` the footer still read `v0.157.21`. The CHANGELOG and README were bumped to `v0.158.5` correctly, but neither is read by browsers — the visible version was hardcoded in `src/lib/layout.ts` (line 1511 nav badge, line 1973 footer) which was never updated.

Both hardcoded `v0.157.21` strings bumped to `v0.158.5` in `src/lib/layout.ts`. Visible footer/nav version now matches what is actually deployed. Lesson reinforced: bump the user-visible string first, not just README/CHANGELOG.

After three prior attempts (add `!important` overrides, replace collision with `class=hidden` + inline `display:flex`, remove collision entirely), the admin screenshot still showed sidebar buttons stretched with ~50-80px vertical gaps and the API KEYS card overlapping the nav.

What now works. Admin panel redesigned so layout cannot depend on class CSS rules: the entire `<style>` block (`.admin-layout`, `.admin-nav`, `.admin-nav-link`, `.admin-nav-badge`, and the responsive override) is removed. The shell and sidebar are bare HTML wrappers with inline `style="display:flex;..."` directly on the elements. The 15 sidebar buttons are no longer hardcoded in the template — they are built by a JavaScript IIFE from one data array, and every dynamically generated button has its own inline `style.cssText` with all sizing properties explicit. `switchTab` now applies hover/active visuals via inline-style mutations (`_tdApplySidebarVisuals`). The active tab gets a left-edge red shadow band so its position is unambiguous without external CSS.

Scope: admin panel only (`/admin` and `/admin/approvals`). Other pages untouched. Read-only confirmations: API key mint modal stays in the v0.158.4 dual-defense state. New diagnostics ship: `[TFCL ADMIN REDESIGN] sidebar mount point missing`, `sidebar built (N tabs)`, `build failed`, and `missing panel for tab`.

What broke. A captain trying to add a teammate on a cup team could paste either of two things from the teammate's profile page (the raw Steam64, or the full `/profile/<id>` URL) and neither one would take. The form gave a different error per format, so it looked broken in two unrelated ways.

What now works. The captain can paste any of three forms and the team will accept them: the internal user ID, the raw Steam64, or the `/profile/<id>` URL (absolute or relative). A new "Find player" button previews the matched username before adding, so the captain can confirm they picked the right person. If the identifier is unknown, the form now shows a clear "user not found, use Find player first" instead of a silent failure.

Why it broke. Three layers were quietly inconsistent: the form was treating the input as a numeric user ID (Steam64 parsed fine but is the wrong column; URLs gave `NaN`), the route was forwarding whatever number came in with no existence check, and the database write didn't verify the target row existed before inserting. A phantom insert would silently disappear from the roster view because that view joins on the real users table.

Scope. No database migration. The fix benefits every cup, not just the one where the bug was reported. Header and footer version badges bumped to `v0.157.21`.

Playwright console capture against the just-deployed `https://play.tfcleague.com/docs/api-keys` flagged a fatal client-side JS error on both pages: 6 newly-added panel generators used the pattern `<span style="...font-family:\'Exo 2\',sans-serif;...">` — single-quoted JS strings whose CSS values used escaped apostrophes for the "Exo 2" font name. After SSR, the browser-side `<script>` block contained the unescaped form, and the apostrophe terminated the surrounding JS string at `\'Exo\'`, producing `SyntaxError: Unexpected identifier 'Exo'` and blocking every script on the page.

Fix (`src/lib/pages.ts`): swapped the inner CSS font-family value from `\'Exo 2\'` to `"Exo 2"` (double-quoted inside the single-quoted JS string) at all 6 sites — 5 on the docs page (key-prefix span, status-pill span, MINT KEY button, YOUR KEYS heading, Revoke button row) and 1 in the admin-SPA revoke button (`_apiKeyRow`). 278 single-quoted CSS-form usages elsewhere on `pages.ts` are unchanged because they live inside HTML template literals and never reach the browser as raw JS strings. Rebuilt `dist/_worker.js` (1,705.25 KB). Committed `99eee14`, deployed via wrangler pages byok to `https://00186ef9.tfcl-pugs.pages.dev`.

Closes the missing-UI-affordance gap from v0.124: the `POST / GET / DELETE /api/admin/api-keys` endpoints have been minting admin `tfcl_ak_<43 chars>` keys for a year, but the only way for an admin to actually use them was DevTools `fetch()`. Same story on the public `/docs/api-keys` page.

Two new SPA panels in `src/lib/pages.ts`:

1. New `API KEYS` tab on `/admin` — sidebar button right after Gift Codes (red `#FFB800` accent to match premium-scope gold), with a Mint card (label input + MINT button → POST, one-shot raw-key modal with copy-to-clipboard + meta line showing prefix/scope/label), and the existing GET keys list rendered with scope pill / created / last-used timestamps / per-row REVOKE button → DELETE.

2. New `YOUR API KEYS — LIVE` card on `/docs/api-keys` — inline `<script>` self-probes GET `/api/premium/api-keys` on page load and renders ONE OF THREE states: 401 → "Sign in with Steam" link, 403 → "Subscribe on /premium" link, 200 → mint UI spread above the keys list with per-row revoke.

No schema migration, no auth changes, no route-handler changes — pure UI affordance wrapping existing endpoints. Build clean: 88 modules, 1,705.25 KB worker bundle. Committed `d8518d0` + `6b0678f`, pushed to `Sidular/TFCL-PLAY:main`.

What broke. A finished match was awarding ELO and points to the wrong players. The match-record row said one team won, but the page grouped players by the column that was filled at lobby-pick time, which did not always agree with the actual team in the logs.tf log. Result: the players who actually won did not get the winner bonus, and the players who actually lost did. Leaderboards and standings drifted from the truth even when the match itself was solid.

What now works. When logs.tf settles a match (the daily-stable final iteration), the lib treats logs.tf as the canonical team source. It builds a per-player map from logs.tf first, then reverses and re-applies ELO using that map, updating the per-player team column to match logs.tf before any points are written. New matches cannot drift; the page always agrees with logs.tf.

Scope. Forward only. The historical match 12 row still shows the old wrong team labels until an operator runs the prepared reconcile SQL on the live database. The lib does not auto-correct old matches because correction touches the points ledger (referral bonuses, idempotency, audit trail), which is an operator call. No schema migration.

What broke. A captain whose own team had active TFCL Premium (so the team was comped into the paid cup at signup, no PayPal needed) still saw the lock banner: "Rename / add / kick are disabled because not all roster seats are paid." Clicking rename, add, or kick flashed "Team is locked - pay first to edit." Physically there was no PayPal order to pay against.

What now works. The lock helper now runs the same roster-wide premium scan that the signup-time approval runs, so the two cannot disagree. If any active roster member carries premium, the lock is treated as open for rename, add, kick, and (already) withdraw. The captain just sees the buttons work.

Scope. All paid cups. Behavior change is invisible except for captains of premium-comped teams, who now see an open control card instead of a "pay first" message. No schema migration.

What broke. A captain whose PayPal capture never finished (closed the popup, sandbox error, abandoned the screen) returned to retry the same team name and hit an opaque "this name is taken" error, even though the row holding the name was their own unpaid in-progress registration. The unique-name index had no UI surface explaining that, and no path to resume PayPal or free the name short of an admin poking the database.

What now works. The lib now distinguishes two failure modes: "someone else's active team holds this name" (real conflict, refuse), and "your own unpaid pending team holds this name" (your own stuck row, offer to fix it). The register page pre-flights on load, and if the captain has a pending unpaid matching their draft, it shows a panel with three clear actions: resume PayPal for the existing row, withdraw (which uses the v0.157.17 unlock so it works even without payment), or change the name. The names-clash alert is reserved for real conflicts only.

Scope. All cups, all captains. No schema migration.

What broke. A captain who registered but never finished PayPal (couldn't recruit teammates, paywall exceeded budget, the signup was an accident) was trapped: "pay to edit" was correctly required for rename / add / kick, but it had been rolled into "pay to leave" too, so the team stayed registered, held the display name, and counted against the cap indefinitely until the cup started. The admin-facing withdraw was never gated this way, so the captain-facing path was the strict one, which is the wrong way around.

What now works. Withdrawing is the failure-mode escape hatch. A captain on an unpaid paid-cup team can now withdraw freely. Already-paid teammate seats are preserved (marked released) so those players can rejoin another team in the same cup without re-paying; the cup slot opens back up automatically. Rename / add / kick still require payment, because those change the team's shape, not just its seat count. The withdraw confirm dialog is worded differently on locked teams so the captain doesn't expect a PayPal refund that does not exist. Audit table records `withdrew_while_unpaid: true|false` so reporting can answer how often this rescue path fires.

Scope. All cups, captain-facing withdraw path. No schema migration.

What broke. A captain trying to register (or rename) a team could be blocked by their own earlier `withdrawn` or `rejected` row from the same cup, or by anyone else's terminal-status row. The unique-name constraint treated every row the same regardless of status, so a name that had been released back into the wild was effectively dead until the cup itself was over.

What now works. The unique-name index now only applies to active statuses. A team row that is `registered`, `approved`, or `paid` still blocks duplicate names; a `withdrawn`, `rejected`, or `disqualified` row is free for re-use. Real conflicts (someone active has the name) still get the same "this name is taken" error.

Scope. All cups. Migrated the live database. Build-only change is a single partial unique index, applied once at deploy time.

What broke. The moment PayPal tried to mount on a paid cup the user got a stylized "Network error: PAYPAL_BUTTON_STYLE is not defined." The constant was declared correctly at the top of the cup pages module, but inside the SSR'd `<script>` block three call sites reached it with a bare word (`style: PAYPAL_BUTTON_STYLE`) rather than a template interpolation. The literal text leaked into the browser-side script, where that identifier does not exist, so mounting crashed.

What now works. All three PayPal mount sites now wrap the constant in `${JSON.stringify(…)}` so the TypeScript template emits a real JSON object. The PayPal SDK receives a normal style object and mounts cleanly.

Scope. Three call sites in `cups-pages.ts`. No schema migration.

A premium member (captain or teammate) on a paid-cup team now marks the whole team as paid at signup. Before this, only a premium captain got through the PayPal wall; a non-premium captain with a premium teammate still got a stuck, unpaid team row. Now the signup-time scan reads the entire prospective roster and approves the team if any member carries active premium. Prize-pool math picks up the same comped teams with no further changes. No schema migration.

Cup owners and admins can now set an owner-contributed base amount (in cents) on `paid_with_prize_pool` cups. The pool reads as `base + signup contributions`, clipped to the cap, so an admin who wants to guarantee a minimum payout can spool it up without depending on signups alone. Existing cups default to zero base (no behavior change). Owner-facing surfaces (create-cup form, edit-cup form, listing card, detail page, dynamic-pool banner) show the base-and-signups breakdown when a base exists. Cross-field validation rejects a base greater than the cap before it reaches the prize-pool ledger.

Premium-comp teams now contribute to the same `prize_pool_actual_cents` number that PayPal-paid teams do, with no separate "premium contributions" line anywhere. A premium comp is, after all, an entry that landed in the cup, and the pool should reflect that without a parallel row. The premium-only display surfaces from v0.157.11 (purple sub-line, listing-card prefix, banner sentence) are removed; the helper functions and intermediate `premium_pool_*` fields that drove them are removed too. The pool just reads as if every comp had been a normal paid entry.

What broke. A captain could register a paid cup, get an unpaid row published on the cup page, mint a PayPal order, then never come back to capture. The cup ended up with publicly listed ghost teams that paid nothing and counted against the bracket cap. Cup 393 ended up with 8 of these.

What now works. Registration now refuses any case where PayPal is missing or the order failed - the team is auto-withdrawn in the same round-trip and a `team_paywall_blocked` row goes into audit. A red paywall banner sits above every paid cup's team list, and the submit button now reads "Submit & Pay $X.XX" so the commitment is explicit. Distinct error alerts for `paypal_not_configured` (admin must set the env var) versus `paypal_order_failed` (try again). The 8 ghost teams on cup 393 are discarded by a one-shot migration with full forensic audit rows, and the cup regenerates from real signed-up teams.

The PayPal SDK was being eagerly included as a parser-blocking script at the top of `/points`, so any slow CDN or blocked extension left the page frozen on "Loading…". The SDK is now injected on-demand only when the buy-points card actually renders for a signed-in user.

The Section 1 avatar now renders (and pulls in every makeover-related field). The "Edit profile" link that 404'd is replaced with an inline editor for bio and accent-color theme, gated by the Profile Makeover reward the same way as before.

Logo bumped from 54px to 75px and the navbar height grown to 80px to fit. The logo now reads as the dominant visual anchor in the top bar.

The TFCL Sentry logo in the top navigation bar is bumped from 40px to 54px tall (~35% larger), and the bar itself grows from 56px to 64px to fit the bigger logo with the same breathing room on each side.

The "no active PUGs" illustration went back to the emoji after briefly being ASCII `:(`; the ASCII variant needs monospace overrides that misalign the glyph, so the emoji wins. Still bobs in place.

The platform's first real outbound email channel. Anything async (premium receipts, unfamiliar sign-ins, lobby invites while the tab is backgrounded) now has somewhere to land, with GDPR double-opt-in enforced before dispatch and per-category feature flags that let admins enable each category one at a time after preview lands in their own inbox.

Capture. `/auth/email/add` stamps `users.email_unverified_pending` plus a random `email_verified_token`, fires a single SendGrid mail (bypassing the per-category flag gate because this IS the verification request) carrying a click-confirm link at `/auth/email/verify/:token`. Only on click do we flip `users.email` / `email_verified_at` / clear `email_unverified_pending`. Every other category refuses to dispatch to a user whose `email_verified_at IS NULL` - the `canSend()` predicate centralises the email-verified + per-category preference + global flag check into one decision.

Outbox + log + dedupe. New `notification_email_outbox` table with a UNIQUE `dedupe_key` (so round-trip replays self-dedupe, e.g. `premium_receipt:<order_id>:<user_id>`), a sibling `notification_email_log` that records `sendgrid_msg_id` from SendGrid's 202 response plus HTTP status + retry count for forensics, and `notification_email_preferences` keyed by (user_id, category, channel) so future SMS/push channels slot in without a rewrite.

Unsubscribe. Per (user, category) HMAC-signed tokens in `notification_email_unsubscribe_tokens` (30-day expiry, stored as sha256 of the raw token - matching the v0.137 PBKDF2 envelope pattern). One-click `GET /u/:token` flips per-category preference to disabled without sign-in (the HMAC IS the auth); `POST /api/notifications/preferences` lets the same user flip it back via the `/account/notifications` management page.

Per-category feature flags + preview. `notification_email_feature_flags` table seeded with all 11 categories at enabled=0. Every `notify()` call short-circuits to no-op when its flag is off. Admin verifies `POST /api/notifications/preview` returns a real `sendgrid_msg_id` in their own inbox, then flips the category via `POST /api/admin/notifications/feature-flag`. Same staged-launch workflow as v0.122 to v0.141; a misbehaving category can be turned off in under a second without a deploy.

Hook emitters. Four real-world actions gained fire-and-forget `notify()` calls inside `try { notify() } catch {}` envelopes so a SendGrid outage cannot block the user-side action: premium receipts on PayPal capture, API-key-created security alerts, lobby-invite shareable links, and ban-issue operational notices.

UI. New `/account/notifications` page renders all 11 categories as per-category `<form method=POST>` toggles plus an `+ ADD EMAIL` / `VERIFY PENDING` block with a RESEND button. Endpoints page + 8 APIs mounted under the existing root in `src/index.tsx`.

Backward compatibility. Migration 0147 only ADDs columns and tables - no removal/rename/rebuild. Pre-existing users keep their `users.email*` columns NULL until they opt in themselves; auth is unchanged everywhere except where token-self-authenticating is the documented design (`/auth/email/verify/:token`, `/u/:token`). The inline `INSERT INTO changelog` row was intentionally omitted from the numbered migration so it stays schema-only and replay-safe on partial DBs - the public `/changelog` body lives in the companion underscored shard `_db_changelog_v0.156.sql`.

Before v0.155 a captain could register a paid cup with an empty wallet and sit on the row indefinitely; no UI to back-fill payment, no "manage my team" surface, no enforcement of "everyone pays before the team can change shape". v0.155 closes this from four angles:

Lock predicate. New `isTeamLocked(cup, team)` helper returns true iff the cup is paid AND `paid_player_count < roster_size` (per_team: `paid_player_count == 0`). Every captain mutation (edit team, withdraw team, kick/add player) opens with that check and short-circuits to a typed `is_team_locked` error → 409. Pre-existing unpaid rows are LOCKED automatically; once paid in full via `/register` they unlock on next page load.

Paid-seat portability. When the captain of a paid cup kicks a teammate who's already paid, the row is NOT deleted - marked `released_at = now()` with `paid_at` and `paypal_order_id` preserved. That released row becomes addressable by `rejoinFromReleasedIfAny`, so the same player can join another team in the same cup without hitting PayPal again. `addCupPlayerByCaptain` tries the recycle path first, falls back to a fresh INSERT.

Schema. `migrations/0146_cup_players_released_at.sql` adds nullable `released_at` and rebuilds to relax UNIQUE(cup_team_id, user_id) to UNIQUE(cup_team_id, user_id, released_at). Hot-path index on (user_id, released_at, paid_at) keeps the recycle scan constant-time.

Captain management card on `/cups/<slug>`. Each roster card the viewer is captain of now renders a per-team `PAID`/`PARTIAL`/`UNPAID` badge plus a Manage sub-card with: rename (display_name, lock-gated), add teammate (with "recycles paid seat if released" hint), kick non-captain (releases the row, decrements paid_player_count if applicable), withdraw (lock-gated). Every button on a locked team is toggled off client-side; the server is still source of truth. Five new endpoints sit under `/api/cups/:id/teams/:teamId/...`: GET manage, POST edit, POST withdraw, POST players/<id>/remove, POST players/add. All open with requireAuth + captain-actor + (where applicable) isTeamLocked short-circuit; locks deliver a friendlier "Pay your team in full before editing." instead of a bare error code.

No backfill. Migration 0146 does NOT fill `paid_player_count`; existing unpaid rows stay unpaid. So immediately after deploy every roster with unpaid seats is locked.

Files touched: `src/lib/cups-db.ts` (7 new exports), `src/routes/cups.ts` (5 new routes), `src/lib/cups-pages.ts` (per-team pill + Manage card + disabled-on-lock), `migrations/0146_cup_players_released_at.sql` (schema-only), companion `_db_changelog_v0.155.sql` carries the public `/changelog` body, `package.json` bumped to 0.155.

- Supporter Pack now grants an animated gold glow ring on your avatar and an animated "Supporter" tag next to your name everywhere - profile page, profile card popup, lobby slots, lobby chat, leaderboard, and match detail pages - The previously-unused light-gold chat colour perk is now live: Supporters without a purchased Name Colour will see their name tinted gold in lobby chat and the points leaderboard - Dropped the "prioritised lobby matchmaking" line from the reward description - it never had a working mechanic behind it in the current draft-based lobby system - Existing Supporters have been backfilled with the light-gold chat colour so this applies retroactively, no need to re-purchase

- Admins can now destroy any on-demand Server from the admin panel's Servers tab, not just the ones they personally reserved - Adds a DESTROY button next to every active/provisioning reservation in that list - Destroying a server this way actually terminates the underlying game server instance, just like a player destroying their own server early - No change for regular players - you can still only manage your own reservations from the Servers page

- The in-game LogsTF and demos.tf plugins on our on-demand Servers need their own API keys to auto-upload a match's log/demo when it ends - neither had ever been configured, so both reported "No API Key" on every match - Both keys are now written into every newly-provisioned server automatically - Already-running servers self-heal the fix the next time their config is applied - no reboot needed - Scoped only to TFCL's own on-demand Servers - PUG lobby servers (rented from serveme.tf) already had their own working logs.tf/demos.tf integration and are unaffected

- Previously, activity logs stored your raw IP address in plaintext, visible to site admins - Your IP is now immediately converted into a one-way cryptographic hash the moment it's received, and only that hash is ever stored - the real IP is never written to our database - This is irreversible: nobody, including our own admins with full database access, can recover your real IP from what's stored - The hash is still consistent per-IP, so we can still catch the same address being used across multiple accounts for abuse/ban-evasion detection, without ever seeing what that address actually is - Purged the small number of previously-stored raw IPs, since they predate this change - Updated the Privacy Policy's "Technical Logs" section to reflect this

- The Privacy Policy hadn't been updated since these features shipped and was missing coverage of them - Added disclosure sections for TFCL Premium payment data (PayPal order info - we never receive your card or PayPal login details) - Added disclosure for on-demand Server data (region, map, config, and the connect info/RCON password needed for you to use your own server) - Added disclosure for custom map upload metadata - Clarified what data is and isn't shared publicly, and how long different types of data are retained