Release — 21 Sep 2026
Brings the frontend back into step with production's database, and ships the fixes found by
entering the real 12 Aug 2026 departure. Pull request
#381, squash-merged to
main as c475a33.
Why now
The owner created a booking on the live site and could not move it in either direction. The
operations screen waited for finance before operations could approve — the reverse of
LC-002 — so every full- or partial-payment booking stood
still; its Reject button called a route that does not exist; and the finance screen listed
bookings still with operations, every one of whose buttons the database refused with
Booking is not waiting for finance approval (current: PENDING_OPS). Production's database
already held the changes the new screens depend on, applied during the 20 September loads.
Record
| Backup before the change | run 35594236567 (supabase-backup-20260921T112846Z), checksums verified — data.sql.gz 115 KB, schema.sql.gz 247 KB, roles.sql.gz 187 B. Production held almost no business data, having been purged for the next load. |
| Migrations | 16 of the 17 migrations on this release were applied on 20 Sep during the 12 Aug loads (each with the owner's yes). 20260924122000_a_fit_answers_the_same_questions.sql applied today; afterwards none pending. |
| Edge functions | admin-users (v65), customer-exchange (v34), extract-passport (v23) — type-checked, deployed, verify_jwt off as supabase/config.toml requires. _shared unchanged. |
| Secrets | none added |
| CI on the PR | lint/test/build, database tests, edge functions, Playwright end-to-end, MkDocs build, Cloudflare preview — all passed |
| Frontend | squash-merged with an explicit message: the default squash message would have carried a previous release's [skip ci] (runbook §6) |
| Operator / Checker | Claude Code (operator) / owner (checker; asked for the release after hitting the approval fault) |
A merge conflict worth knowing about
The release pull request first showed as conflicting, so GitHub ran no CI on it at all. The
19 Sep release had been squash-merged, which left main holding squashed copies of commits
that integration/ops-upgrade holds in their original form. Every conflict was that snapshot
against the newer version of the same work; main's only genuinely new content was the
19 Sep release notes. Resolved by merging main into the integration branch, keeping
integration's side, and confirming the merge changed exactly those two documentation files.
Squash-merging releases will keep producing this. Merging main back into the integration
branch after each release avoids it.
Smoke tests
For the owner, with real staff accounts rather than an administrator login — the approval fault is exactly the kind a super-user never sees:
| # | Test | Expected |
|---|---|---|
| 1 | Create a booking as a sales user and submit it | It appears under Operations → Ops approvals, and not under Finance approvals |
| 2 | As the same user, open Ops approvals | Approve is disabled; hovering says someone else must approve it (LC-010) |
| 3 | As an operations user, approve it | It moves to Finance → Finance approvals |
| 4 | As a finance user, approve it — with nothing paid | It is confirmed; the balance stays owed (payment is not checked at approval until PRC-010 is decided) |
| 5 | Open a departure's Itinerary | Hotel stays show their dates, not null → ?; each return leg shows its own flight number |
| 6 | Open an individual (FIT) seat row that a departure uses | Linked groups, seats used and bookings sold are shown, not zero |