[MattA-Official]

Fourteen medium findings, in ten commits grouped by cause. Gates: lint, typecheck, comments, build. No test suite here, so each change was reasoned against the code and the affected paths driven by hand.

The outgoing committee kept receiving booking requests forever. users.is_rooms_admin is refreshed from the session, but only while that person keeps using this app. rooms:ADMIN carries a committee-year expiry, so the whole committee loses the role on one day and has no reason to sign in here again: their mirror rows kept the flag set for good, and every new request went on being bcc'd to them with the requester's name, the event title, the date, the attendee count and their free-text notes. Nothing in either app could have cleared it, since role changes are not pushed to consumers and a committee-year lapse has no revocation event to push. The fan-out now resolves recipients from stage-door's role-holders endpoint, intersecting against the local mirror in chunks so it still honours notification preferences, cached ten minutes per isolate and falling back to the stale flag with a warning if stage-door is unreachable, because sending nothing means a booking request nobody sees. proscenium already consumes that endpoint the same way. The lookup existed twice, in notifications.ts and inline in POST /api/bookings; there is one now.

A slot was decided by a SELECT and applied by an UPDATE that bound only the booking id, so nothing held it in between. Two admins triaging the Monday queue could each confirm a different request into Rehearsal Room 3 for the same evening: both checks saw it free, both writes succeeded, both casts were emailed a confirmation, and nothing in either row recorded the clash, so it surfaced when they both turned up. The UPDATE now carries the occupancy rule as a NOT EXISTS predicate built by the same planner every write path goes through, binding a fixed number of parameters. ADR-0008 records what a mid-batch clash still leaves behind under ?scope=series.

Two write sequences could half-run and leave a row holding a room nobody knew about: deleting one occurrence of a series ran three promotions and a delete as four statements after telling the member it was cancelled, and a recurring create wrote the head, then the pattern, then the occurrences, so a failed occurrence batch left the head committed, unannounced, and holding its slot. Both land in one db.batch now.

An owner could edit a confirmed booking by cancelling it. The route checked only the status on the cancellation branch, and the owner schema accepts startTime, endTime, eventTitle and the rest alongside it, so a member could send CANCELLED with a new window and have the lot written. The admin alert telling the committee to ring an external venue was then built from the rewritten row. The rule now lives in the schema, and the route narrows the patch to the status alone so the write cannot widen again if the schema is relaxed.

Two things members were told that were not true. The bulk Reject button sent the literal string "Bulk rejection" as the reason, which was emailed to every member in the selection, written to rejection_reason, shown on /requests and returned by a subject access export; the mandatory-reason rule exists because the reason is read by the requester, and a placeholder satisfied the rule while defeating it. And rejecting a twelve-week recurring request sends ?scope=series but built its notification from the single booking in the URL, so the member was told one date had been rejected and believed they still held the other eleven.

A failed availability check read as "every room is free". The composable emptied both lists on error; the forms read empty as "not run yet" and fell back to the plain room list, whose entries carry no conflicts, so every room computed available and unbadged, and totalUnavailable was zero so the "Show unavailable" button vanished too. The usual trigger is the session crossing the fifteen-minute staleness line. The server still refuses a clashing write, so this was a lying picker rather than a double booking.

Erased rows could refill. A sealed session stays readable for up to thirty days after erasure, so an erased member could open /settings/notifications, flick a switch and rewrite the two columns that keep the fan-out away from a scrubbed row.

Performance: SQLite creates no index for a foreign key, so bookings.user_id and external_venue_id had none, and loading the member home page was five full scans. Two indexes added; D1 bills by rows read and bookings are only ever added, so this got worse every term.