AlpineClubBookingsNZ v0.10.0

Tag: v0.10.0 · Previous: v0.9.0 (2026-06-27) · Merge commit: 0182cd7ea.

What this release is

A large quality-and-hardening wave layered on top of the public booking,
membership, and finance capabilities, followed by a remediation wave
(epic #1348) that closed the post-wave audit findings and a live-feedback
admin-UX wave (epic #1438). The public deployment shape is unchanged.

Downstream forks: read docs/UPGRADING.md and the Migration/deployment notes
in CHANGELOG.md before deploying, and back up your database first. This
release contains two destructive/behaviour migrations and other hot-table
migrations.

Post-upgrade actions you must take

These are the actions a fork operator has to take after upgrading. Full detail
and the exact migration names are in docs/UPGRADING.md (v0.9.0 → v0.10.0).

(a) Re-enable your capability modules — some features switch OFF on upgrade

Migration 20260627120000_core_module_defaults_off changes the default for the
high-risk capability modules — kiosk, chores, finance dashboard, waitlist,
Xero integration, bed allocation, and Internet Banking payments — to off,
and switches them off on any fork whose Admin > Modules row was never saved
by an admin (the untouched singleton default row). If you never opened and saved
Module settings, these features will turn off on upgrade.

Action: after upgrading, open Admin > Modules and re-enable the modules
you use once their provider/setup is ready. Rows an admin already saved are
preserved; general-purpose modules stay on.

(b) Complete or export in-flight inductions first — unfinished ones are deleted

Migration 20260702100000_induction_workflow_types moves inductions to a
single-Pass flow and, doing so, deletes in-flight (DRAFT/IN_PROGRESS)
per-item induction results and clears their self-assessment answers. Completed
historical inductions are kept.

Action: before upgrading, finish or export any inductions a member has
started but not completed. There is no recovery after the migration runs.

(c) Audit membership access roles only if you ran intermediate main

The contract migration 20260630120000_rename_member_role_to_user collapses
the legacy Member.role values (MEMBER/ASSOCIATE/LIFE) into USER and
recreates the role enum. It assumes no live deployment used the intermediate
Access-Roles window.

Action: if your fork deployed a main build between 2026-06-28 and
2026-06-30, run npm run db:audit-access-role-cleanup after upgrading and
resolve anything it flags. Forks that upgraded straight from the v0.9.0 tag
never entered that window and can skip this.

(d) The three verified-safe migration items — you do NOT need to re-audit

These are already recorded as blue/green-safe in
docs/BLUE_GREEN_MIGRATION_SAFETY.tsv; no fork action required:

• ClubTheme sub-AA gold theme bump is conditional — it only rewrites a
  persisted theme still on the old sub-AA default; a theme you have customised is
  left as-is.
• BookingGuestNight backfill is automatic — it runs during migration and
  old code ignores the table.
• Access-role backfills are old-code-compatible — old code keeps reading
  Member.role/financeAccessLevel while the new access-role tables are added.

(e) AgeTier NOT_APPLICABLE — deploy in a quiet window, or defer the backfill

Migrations 20260707000000_add_age_tier_not_applicable (enum add) and
20260707000100_backfill_org_age_tier_not_applicable (backfill) introduce a
NOT_APPLICABLE age tier for organisation-type members. The backfill is
old_code_compatible=no: a pre-v0.10.0 app color cannot read the new enum
value, so old-color reads of the flipped rows can error while both colors are
live (the classic blue/green enum-backfill hazard).

Action (per the owner decision on epic #1438, 2026-07-07): deploy both
migrations in a quiet window and cut over promptly, or defer the backfill
migration until the old color has fully drained, then run it (the UPDATE is
idempotent and safe to run late). The enum-add migration is a plain expand and is
safe either way. Detail and the ledger caveat are in docs/UPGRADING.md and
docs/BLUE_GREEN_MIGRATION_SAFETY.tsv.

Behaviour changes to note

• Capability modules default off (see (a)).
• Booking Officer / on-behalf booking scope widened — Booking Officers can
  open booking detail; bookings:edit holders can create and quote on behalf of
  members; an admin's own bookings still go through normal member payment paths.
• Email preferences enforced on reminder and chores sends.
• Non-member hold policy is admin-toggleable.
• Cancellation policy — tiered credit restore (owner decision D7). A member
  who paid entirely with account credit and cancels inside the 0%-refund tier now
  gets nothing back, the same as a card payer; a captured-but-partially-refunded
  cancel is tiered on the remaining value (#1493). See the committee heads-up
  draft (docs/releases/v0.10.0-committee-headsup-draft.md) — brief your
  committee before wider rollout.

Removed / changed routes

• The standalone POST /api/bookings/cancel route was removed earlier in the
  line; cancellation goes through the consolidated cancel path. Forks calling it
  directly should move to the current booking cancel flow.

Validation evidence (fill in at tag time)

• npm ci — clean install on the release commit.
• npm run lint — result.
• npm run typecheck — result.
• npm test / build / Playwright E2E — from the release PR's green CI run.
• npm run db:check-drift against a shadow database — in sync.
• Migration-drift and static-analysis gates — green on the release PR.

Deferred to post-approval (owner-gated)

• Create the annotated v0.10.0 tag on the merged commit and publish this
  GitHub release (checklist step 6).
• Image names / commit SHA / GHCR references — record at tag time.
• Non-blocking maintainability follow-ups — carry the current
  docs/MAINTENANCE.md known-hotspots list.