Cover coach setup correction

• Fixed cover coach invitations and role changes being blocked after installing

the private automation scan table. The readiness check now recognises that specific table only while its ownership, RLS, lack of client access and lack of inheritance remain intact. Other cover coach restrictions are unchanged.

• SQL-only correction: run the cover-coach-private-scan-readiness preflight,

apply cover-coach-private-scan-readiness-04.sql, then run its postflight. No application deployment, environment change or feature flag is required.

CI database startup

• Reserve the disposable database ports before CI dependency and image downloads

can allocate them to temporary client connections. Existing runner port reservations are preserved, and database failures now record socket ownership and the allocation settings. This addresses the port-binding failure in PR #98; it requires no application settings or SQL changes.

Seven more automation starts

• Invoice overdue, attendance check-in, incomplete registers, course completion,

course inactivity, published grading results and effective household plan changes now publish and run. The audience preview uses their same source rules.

• Repeated scans and republishing do not resend the same occurrence. Current

eligibility is checked again after waits and immediately before delivery; transiently failed waits retain their original resume point when retried.

• Register reminders email the assigned coach and can notify configured club

administrators. Both builders show the destination clearly and filter actions that cannot safely use that source. Keep follow-ups inside these automations; child-flow enrolment is unavailable for these seven starts.

• A private, durable scan cursor makes progress across large audiences and

non-matching members. The new scheduled job appears in Admin Health.

• SQL before deployment: run automation-recipe-scan-state-00-preflight.sql,

automation-recipe-scan-state-01.sql, then automation-recipe-scan-state-02-postflight.sql. Existing settings still control delivery; no new flags are introduced. See docs/ops/automation-seven-triggers-2026-09-12.md for timing and rollout details.

Member emergency and medical details

• A member request to check details now includes each household member's

emergency contact and medical information, with a separate confirmation for each section. Members can enter corrections directly in the request.

• Corrections follow the request's existing approval setting. Unchanged details

complete immediately; review-mode corrections remain pending until an authorised reviewer approves them. Staff can compare current and requested values. Review requires request-review, profile-edit and medical-view access.

• Private staff medical notes remain separate. Stale replies cannot overwrite

newer details, and sensitive proposed values are removed after a decision.

• SQL before deployment: apply member-request-safety-details-01.sql after

its read-only preflight, then run its read-only postflight. Existing historical member-request v3 SQL is required. No new environment variables or flags.

Annual renewal reminders

• Member Status is now a selection in both automation builders. Is any of

supports Active or Paused in one condition. Existing stored values remain visible for review; legacy lists continue to require every condition.

• Annual requirement reminders offer Online renewal paid · Yes/No, scoped

to the specific member, requirement and renewal cycle. This uses portal-card renewal records; it does not claim to resolve invoice payment status.

• An unpaid reminder rechecks current status, requirement eligibility, cycle

and payment before subsequent steps and retries. Paid-pending-processing and completed renewals stop unpaid reminders. Failed reads cannot count as unpaid.

• Expires in exactly (days) supports precise 30-day and 15-day email wording.

Set the requirement renewal window to at least the first reminder offset. Exact-day sends skip missed days; within-window reminders remain available.

• Paused members receive annual reminders only when explicitly selected in an

entry Status condition. Existing unfiltered automations keep their audience.

• Paused members can start or continue online requirement renewals without

restarting membership billing. Leavers remain unable to start renewals.

• Fixed email-step condition dropdowns reverting to Status when choosing a

specific annual requirement, due date or renewal-paid condition. Changing from multiple statuses to a single status now clears the old combined value.

A clearer automation builder

• Creating a trigger, flow or recipe opens its builder and shows clear creating

and opening feedback. Creation stays locked while the editor loads, with a direct Open builder link to the saved draft and no duplicate creation.

• Choose trigger starts with category cards and counts. Browse one category

at a time, search across every category, or choose View all triggers.

• Simple setup now follows one sequence: when it starts, conditions and actions.

The trigger catalogue opens only when choosing or changing a trigger.

• Uses the app’s standard cards, buttons and header, with clearer text and a

single action list. Templates, message previews, tests and version history remain available without filling the screen.

• Incomplete checks stay visible; successful checks and the summary can be

expanded. Draft, preview and publish controls keep their existing safeguards.

• Adding an action places it before a final Stop so it can run, and opens the

new action for setup. Existing action order and saved definitions are unchanged.

AND / OR condition groups

• Fixed Current member status = Paused in plain AND annual-reminder rules.

Explicit paused selections now work consistently with grouped rules, including after waits and on retries. Current status, cycle and payment are rechecked before provider delivery; paid renewals and failed reads still block sending.

• A conditional Stop now ends the sequence only when its conditions match.

When they do not match, execution skips Stop and considers the next action, matching the audience preview. A Stop with no conditions still always stops.

• Choose Match all (AND) or Match any (OR) for entry conditions and each

action's conditions in Simple setup and the Advanced builder. Add bordered groups for mixed rules, such as (Active OR Paused) AND renewal unpaid.

• Each group has its own AND/OR choice. One group level keeps the rules readable;

empty groups can be saved as drafts but must be completed or removed to publish.

• Saved definitions, mode switches, summaries, search, simulation and audience

checks preserve the same grouping. Existing flat condition lists retain AND.

• Execution checks entry and action rules separately, including waits, retries

and final checks before sending. Historical event facts retain their original values, while current status/payment checks refresh. A failed current read blocks sending even when another OR branch would match.

• Paused annual-reminder recipients must be explicitly included by a successful

branch. Original-cycle eligibility, tenant checks, consent and duplicate-send protection continue to apply independently of the selected rules.

• Grouped runs save bounded condition facts in the existing run payload. A resumed

or retried grouped run missing its trusted version-matched snapshot fails closed. No SQL migration or new environment setting is needed. Deploy compatible code to all execution workers before publishing grouped definitions; older workers cannot execute the new definition shape.

Club recipes and current conditions

• New Trigger → Use a recipe provides fifteen editable starting points for

renewals, member requests, trials, new members, events, shop collection, attendance, invoices, registers, courses, grading and membership changes.

• Select programmes, classes, venues, plans, events, products, courses and

campaigns by name. New conditions cover current status, age, recorded attendance, trial enrolment/future bookings, event booking/payment and whether a shop order still awaits collection.

• Current-record conditions are checked before actions, after waits and again

before provider dispatch. A failed read remains retryable; a proven resolved condition suppresses the action. Older event-status conditions keep their original meaning.

• Event reminders retain the exact booking identity, including timed reminders.

Queued older reminders may resolve only an unambiguous same-club booking for the original event and member.

• Seven additional starts are local audience trials only: overdue invoice,

attendance check-in, unfinished register, published grading result, course completion/inactivity and effective household plan change. Their readers and conditions are implemented; production scheduling and publishing remain off.

Guided setup and audience review

• Four compartments guide setup: **When it starts → Conditions → Actions →

Review audience**. Return to any section without losing edits. Both builder modes retain unfinished reminder timing and visibly flag unsupported fields.

• Stronger section borders, tinted headers and coloured action icons make the

sequence easier to scan. Text-labelled Edit, Done and Continue controls replace disclosure arrows in Simple setup.

• Check audience reads current club records without sending, queuing,

publishing or saving. Campaign preparation retains the public-demo fence. Its scrollable modal lists matching members/records, intended recipients, email/SMS/Telegram channels, household/personal/staff destinations and condition results. Supporting explanation is collapsible.

• Counts describe a bounded sample of existing records, not a guaranteed send

queue. Delayed actions are checked against today's data and rechecked later. Changing the setup invalidates the old preview. No email addresses, phone numbers, credentials or action links are returned to the browser.

• Member-request push remains one initial alert per request. Email follow-up is

optional and independently checks whether the request remains unresolved.

Deployment and setup

This batch requires the member-details and recipe scan SQL listed above before deployment. No new environment keys or feature flags are introduced. The audience readers require the existing canonical schema; missing prerequisites fail as unavailable. Local Docker schema repairs and trial limits are recorded in docs/automation/16-club-recipe-local-trials.md and the QA evidence document. Existing execution/delivery gates still apply. No live automation is created or enabled. Configure Annual requirement due with a specific requirement, Active or Paused, Online renewal paid = No and an exact 30-day entry date. Add a 15-day wait and an exact 15-day condition on the second email.

Cover coach

• Owners can assign Cover coach through the existing staff settings. The role

can mark today's member and trial attendance, complete and lock registers, view health information from today's register, and file accident reports.

• Cover coaches use the same Allsorted navigation, register layout, attendance

cards, health panel and session-team controls as other staff, with only Registers and Accident Forms in navigation. They can record who coached or helped and add/remove ad-hoc catch-up attendees. The role retains a fixed permission ceiling. General member records, finances, staff settings, register unlocking and safeguarding history remain outside its duties. Custom permission denials continue to apply when custom RBAC is enabled.

• Each member's register row now opens their saved emergency contact name,

relationship and phone number, with tap-to-call. Cover coaches can use this from today's register, including after locking, without opening the full member profile. Missing contacts and unavailable reads are shown separately. This read-only addition needs no additional SQL.

• Accident drafts and submission are protected against concurrent saves. Cover

coaches can file reports without arbitrary email, Telegram or PDF download controls. Authorized safeguarding staff retain access to the saved report.

• Server and database boundaries enforce the restriction independently of the

visible navigation. Assignment fails closed until the complete SQL protection is installed and its catalogue checks pass.

Member request tracking

• A member profile's Actions → Communication & Portal → Request member action

opens the existing request dialog with that member selected. It includes the same choices, preview and advisory email/push check. Changing member or club closes the draft. Existing server permissions and request handling apply; this shortcut needs no new SQL or configuration.

• Member Requests now separates Outstanding, Completed and Archive. Outstanding

is the default; unanswered and awaiting-review work stays visible.

• Finished requests can be archived and restored without deleting their history,

cancelling changes or sending another notification. Rejected and cancelled requests keep their original outcome counts.

• Each tab is filtered before pagination. Loading failures stay distinct from

empty lists, and delayed responses cannot replace a newer tab selection.

• Apply the additive member-request-batch-archive-01.sql and its matching

postflight before deploying this follow-up. The earlier notification SQL and completed £39 accounting repair must not be replayed. See docs/database/member-request-batch-archive-2026-09-11.md.

• Live read-only diagnosis found invalid deployed push signing configuration and

no installed member-request email automations. These require separate owner configuration and activation; the archive SQL does not resolve them. See docs/ops/member-request-notification-check-2026-09-11.md.

Before creating a member request

• Check choices now includes an email and push setup summary. It distinguishes

configured, missing, paused and unavailable checks without changing whether a valid request can be created. No acknowledgement is required.

• Email advice checks published new-request automations and current sending

switches; push advice checks server signing configuration. Neither confirms recipient delivery. Contacts, automation rules, device permissions and quiet hours still apply.

• Failed or slow optional checks remain informational. This addition needs no

new SQL, flags, credentials or schedule changes.

Member portal notifications

• Invalid or mismatched push signing keys are identified before delivery work is

claimed. Platform push health now reports the configuration problem.

• An installed device using an older signing key offers an explicit repair.

Failed repair/removal shows checked registration state and safe error guidance; blocked browser permission does not retire an existing registration.

• An owned, unrevoked device's authenticated status check refreshes activity at

most daily, preventing active devices aging out solely because they have not subscribed again. Consent, preferences and revoked devices are preserved.

• Member requests send only their initial push alert, once per request batch on

each registered device. Completion, approval, rejection and overdue events no longer generate request pushes; email automation events remain unchanged. Quiet hours, consent and existing duplicate prevention still apply. This policy requires the new initial-request SQL; provider acceptance is not proof of display. Other notification categories retain their current rules.

Owner rollout

• Cover register parity follow-up — SQL FIRST: apply only the new

cover-coach-register-team-03.sql, then run its matching team postflight before deploying this follow-up. The owner already reported the original Cover authority postflight PASS; do not replay the earlier release bundles. See docs/database/cover-coach-register-parity-2026-09-11.md.

• SQL FIRST: apply cover-coach-authority-01.sql, then

cover-coach-trial-attendance-02.sql, and run cover-coach-authority-postflight.sql before deploying and assigning the role. Existing register/activity authorities and accident-report-status-01.sql are prerequisites. See docs/database/cover-coach-rollout-2026-09-11.md for the full order and hashes.

• Apply portal-notifications-activity-01.sql after the existing portal push and

member-services bundles; verify with its activity postflight. It preserves the current RPC signature and can precede the matching code deployment.

• No feature flags, signing keys, schedules or provider settings are changed by

this release. SQL application and the final fresh-request device test remain owner operations. The reported missed 18:00 notification still requires the read-only deployment/device diagnosis in docs/ops/member-push-investigation-2026-09-11.md.

• A separately reviewed owner operation can record one verified historical

renewal payment left pending before frozen checkout evidence was introduced. Its exact transaction and read-only postflight must be run by the owner; delayed payment notifications are skipped and credential processing stays in the normal staff workflow. See docs/ops/requirement-payment-owner-repair-2026-09-11.md.

Club-branded member PWA

• Signed-in member portal installs use Club name Portal and the saved club

logo, including Apple's home-screen title/icon. Logos are fitted into square PNGs without cropping, with safe padding for masked icons. Primary logos use the app's dark background so white transparent artwork stays visible. Clubs without a usable uploaded logo receive a generic portal icon.

• Push notifications use the club name/logo and a fixed category message;

member names, request answers and private details stay out of the lock screen. Consent, quiet hours, the existing app identity and subscriptions are retained.

• Apply the additive portal-notifications-branding-01.sql and run its matching

postflight before deploying for branded notifications. Existing code accepts the SQL; new code preserves generic delivery if the optional lookup is missing or unavailable. No key rotation, feature-flag change or old SQL replay.

• Existing installed icon/name updates depend on the device. If an iPhone retains

the old branding, add the portal to the home screen again after signing in and enable/repair notifications on the new installation; test using a fresh request.

Staff password setup

• New staff now receive the private password-setup email directly from Auth after

their club access is confirmed. Existing active accounts keep the ordinary sign-in invitation. Staff management never sees a recovery credential or stores it in the club's email history. Provider acceptance is labelled Setup email requested, with failures and uncertain sends shown separately.

• Password setup stays on its own page before authenticator onboarding. It

consumes each email link once, supports opening the direct invitation on another device, and preserves the correct verifier when several browser reset requests are outstanding. Missing/expired links cannot reuse another account's existing session to show the form.

• Staff who already enrolled an authenticator can verify it on the password form.

Password saves and reset-email requests resist rapid repeat submissions. Password success remains visible if the support-status update is unavailable.

• No additional onboarding SQL or flags. Auth SMTP, the exact callback allowlist

and the shared recovery email template need owner review. A ready template and Craig's recovery steps are in docs/ops/staff-onboarding-2026-09-11.md.

Installed portal hint and one request alert

• The home-screen hint stays hidden in the installed app. Already added also

hides it persistently in a browser tab; blocked browser storage does not break the portal. Safari cannot reliably discover its separate home-screen install.

• Before deploying this follow-up, apply

portal-notifications-initial-request-01.sql after the historical member notification bundles, then run its matching postflight. Do not replay older bundles afterward. See docs/database/portal-initial-request-2026-09-11.md.

• Child-only portal devices are not part of this release. Existing trusted

devices and additional email access remain household-wide.

Renewal safeguards

• An elapsed renewal link no longer automatically expires the unresolved payment

attempt and opens another collectible attempt for the same requirement cycle. Older expired attempts, including missing provider references, are held for review too.

• New attempts freeze the original Stripe account, mode, currency and request.

Concurrent offline processing blocks a stale first checkout; genuine late payment evidence still reconciles. Token and canonical ledger settle together.

• Confirmation checks the returned payment object, club, purpose, exact pence

amount and amount received. It cannot replace a different saved payment ID.

• A zero-row settlement update now requires an exact paid re-read. Pending,

expired, mismatched and unavailable rows do not produce a success message.

Shop duplicate-checkout safeguards

• Shop checkout uses a durable request key and canonical basket. Repeated

requests, tabs and lost responses resolve to the original unresolved order, rather than reserving stock or creating another payment.

• Order, line snapshots, stock reservations and key aliases commit together.

A proven stock refusal remains editable; unknown results stay held. Cancelled orders need confirmed payment/stock closure before a new purchase is allowed.

• The portal retains only opaque, contact-scoped checkout identity. Unknown,

processing, review and refund states are explicit, including after refresh; delayed card confirmation no longer claims bank authorisation. Status checks find the exact owned order even outside the latest 50 orders.

• Existing Complete payment uses the original intent/account/mode. Review,

expiry, ownership and payment-state changes are rechecked after provider waits; unresolved attempts cannot become another checkout. Explicit declines retain the existing same-intent correction path.

• This adds one reviewed SQL unit, pro-shop-checkout-claim-01.sql. Deploy the

caller, drain old checkout handlers, then apply its SQL and postflight. New checkout fails closed until that authority exists; historical order reads remain available with conservative closure status. No remote change was made.

Refund safeguards

• Older partial-refund events cannot lower cumulative invoice or shop refund

totals. The guard is on the database update itself, including concurrent calls.

• Course refund redelivery repairs a failed entitlement revocation. Revocation

is limited to the original payment and purchase source; later purchases and other sources of access are not selected. Refund-before-success delivery is retained as refunded rather than granting access on a later success event.

Payment return and status screens

• Saved enrolment and course attempts restore a read-only status instead of

restarting a blank purchase. Course returns restore the selected household member only after checking the authenticated household roster.

• Pending, review, payment received/access repair and recorded refunds have

distinct wording. Original quote/currency and a local reference are retained.

• Historical event payments without a recorded original currency no longer

acquire today's club currency or an assumed GBP quote. Their recorded payment status remains visible without inventing a monetary amount.

• Stripe redirect secrets and status hints are removed from the URL and never

used as evidence that a payment succeeded. Failed status reads do not expose another Pay button or claim a safe failure.

• Course cards with retained purchases link to payment status rather than Buy.
• Moving between payment links, invoices, courses or staff entry contexts clears

the previous checkout before the new details load, including its amount, reference and payment form. Failed reads cannot redisplay the prior checkout.

• Invoice and external-entry return screens restore collection/refund/review

state through existing authorised reads. Processing invoices do not revert to an overdue Pay screen on reload. Confirmed refunds, pending refunds and failed refunds remain distinct.

• Staff external-entry return context is checked against the session club and

effective financial capability before showing an invoice status. Old/used public credentials do not gain new permissions.

• New same-attempt continuation buttons and used-event-link financial receipts

remain paused for explicit approval. Existing first-payment actions and credential expiry/consumption rules are unchanged.

• This return batch adds no SQL or environment setting. The wider payment wave

below still needs its separately reviewed SQL rollout and provider checks.

Operational boundary

• Portal renewals distinguish processing, recorded payment and review, retaining

the member/requirement return context without treating a URL as payment proof. Renewal notification handoffs are durable, including members without email.

• Course payment/access reconciliation and exact shop stock release are atomic;

shop recovery does not automatically cancel actionable provider payments. GoCardless uses current payment observations with stale-reader protection.

• Independent cron lanes now continue despite failures elsewhere, retaining

truthful per-lane counters. Base SaaS subscription webhooks observe current provider state instead of applying obsolete event snapshots.

• Course creation uncertainty retains its pending attempt; empty provider search

is no longer treated as proof that another payment can be started.

• Course checkout now freezes its original Stripe account, mode, quote and exact

request atomically before provider creation. Exact same-key retry is bounded to 23 hours; older uncertainty remains review-only. Account changes cannot silently create a replacement charge. Failed identity attachment retains the original attempt and withholds checkout rather than cancelling or deleting it.

• Course recovery reads the original account and verifies the original charge

and refund outcomes before repairing purchased access. Existing paid/refunded local finalisers can recover without today's Stripe connection. Historical failed/deleted rows do not silently close review findings; this is not a scan of every already-paid historical purchase for missing refund events.

• Portal invoice history retains original currencies and refund labels. External

event review responses are not presented as confirmed entry success.

• Standalone invoice results distinguish full and partial refunds from paid and

zero-balance invoices; terminal invoices no longer advertise card checkout. Platform checkout returns show a neutral hint until server billing state loads.

• Event checkout freezes the original account and quote through confirmation,

invoice and refund recovery. Unknown legacy attempts remain on hold.

• Eligible GoCardless notifications now have atomic per-engine handoffs and

independent recovery. Stale queued notices are suppressed; unknown delivery attempts require review. Missing-webhook financial discovery stays silent.

• Ambiguous shop reservation responses now report unavailable rather than

incorrectly claiming that an item is out of stock.

• Enrolment processing, payment-received/finalisation and refund-review responses

now show a neutral hold instead of a retryable payment error. Further collection is blocked in the current view; explicit card/field failures remain retryable. The later return batch above restores its saved state on refresh as well.

• Waitlist checkout now distinguishes refund pending, review and confirmed

outcomes. Processing/unknown results remove Pay; a known payment can be checked again without reconfirming it. Unknown responses without a payment reference offer contact guidance only. No unsupported no-charge or automatic-refund claim.

• The owner approved retained course attempts and equivalent atomic safety

assertions in place of obsolete delete/cancel-on-uncertainty mechanics. The focused course/shop corrections are integrated. The local release checkpoint passed: 18,569 tests, three pre-existing skips, audit/types/scanners/lint/build; the critical pack passed 500 tests and the new return-browser pack passed 118 synthetic groups. Details are recorded in the payment remediation ledger. Remote CI has not run for this local correction wave. This is not closure of the full payment audit: retained legacy/provider cases, the permission-gated additions above and real provider/device checks remain.

• Eleven additive SQL units and postflights are prepared; all remote application

is pending. Nine require reviewed SQL before matching callers; event checkout and shop checkout claims instead need code-first, old-handler drain, then SQL windows. Old event links remain review-only; do not combine those two units into the pre-deployment bundle.

• Eight disposable payment rehearsals are included in CI. No new environment

setting, activation, charge, refund, cancellation or real message was performed.

• The live £39 renewal has not been modified or retried. Its current provider

outcome and webhook delivery evidence are still required from the owner.

Dependency maintenance and platform tooling

• Dependency generation now keeps the PostCSS security override aligned with its

direct version. The updated dependency tree includes Supabase compatibility fixes and reviewed Next/Sentry security expectations. Fresh production and development dependency audits report no advisories.

• Refreshed staff sessions retain all cookie chunks and cache-prevention headers

across redirects and authority errors. Authentication and MFA decisions remain unchanged. Background API audit writes use a bounded runtime lifetime.

• CI uses current pinned action releases and rejects artifact digest mismatches.

Existing test lanes and payment rehearsals are preserved. Routine action updates are grouped for review. The bundle-analysis command now uses native Turbopack analysis, and unused legacy packages have been removed.

• These changes add no SQL, environment setting or activation requirement. The

payment rollout above remains unchanged; GitHub CI and live provider checks still need their own evidence after publication. The dependency and technology report records the investigation, corrections and verification limits.

Student loading and development checks

• The student directory loads profile code when a member is selected, with a

visible loading state. Direct profile links and directory refreshes are retained.

• CI reports development-tool advisories alongside the existing production audit

gate and saves dashboard/student initial JavaScript measurements.

• Local development and CI share Node 24 and npm 11.11.0 configuration. The owner

confirmed that Vercel is configured for Node 24; no deployment setting was changed.

• Required browser checks exercise session cookie refresh and redirect retention.

The pinned Supabase installer is updated after an isolated local rehearsal, keeping the same CLI and all payment rehearsal commands.

• These improvements add no remote SQL, payment action or feature activation.

The payment rollout order and pending-renewal safeguards above remain in force.

Payment SQL handoff

• The eleven pending payment SQL units are now available as two complete SQL

editor files with verification included: nine units before deployment, then event and shop checkout after the matching code is deployed and both old handlers have drained. See docs/database/payment-reliability-bundles-2026-09-10.md.

• Each phase rolls back as a whole on failure. The first phase refuses to run

after the second so it cannot replace newer shop checkout protections.

• Payment logic and historical payment data are preserved. The owner still

applies remote SQL; no remote application or feature activation occurred.

Staff payment review and Stripe configuration

• Settings → Payments now looks up a saved requirement payment by REQ reference

or Stripe payment ID, showing the member, requirement and renewal period. Effective billing.state.view controls reads; the new auditable billing.payment.reconcile capability controls recording verified evidence.

• The recovery action checks the original frozen account, exact amount and

payment identity, charge/refund history and current renewal cycle before using existing atomic settlement. It creates no payment and does not process credentials. Legacy, conflicting, refunded or disputed attempts stay held. Existing durable follow-up work can later send ordinary notifications.

• Additive requirement-payment-reference-lookup-01.sql and its postflight must

be owner-applied before the new lookup is usable. This is a separate read RPC and two indexes; do not rerun the earlier predeploy bundle after postdeploy.

• Platform Health has an explicit super-admin-only read-only Stripe diagnostic:

account, event coverage, version and configuration gaps. Feed scope, signing secrets and actual delivery remain separately verified. Optional expected account IDs and the exact URL override are documented in the operations guide.

• A bounded requirement recovery cron runs every 15 minutes after deployment;

broad provider discovery stays daily. Fresh charge/refund proof also protects that existing recovery path. No remote SQL, deployment, provider configuration, payment, replay or notification was performed as part of the local changes.

Additional Stripe lifecycle and refund accounting safeguards

• Platform invoice payment failures and required customer actions now refresh

current subscription state through the existing ordered observer. Delayed failure events cannot directly overwrite a recovered subscription.

• Refund-created and refund-updated events wake only exact existing refund

operations. Current PI/charge/refund evidence is required before generic invoice finalization. Unknown dashboard refunds are not adopted as operations.

• A new atomic invoice observer prevents cumulative webhook totals and refund

finalization from counting the same money twice. A shared generic finalizer hold retains ambiguous historical/second-refund cases until observation succeeds. Existing external-event authority and subject cancellation policy are preserved.

• The additive generic-invoice-refund-observation-01.sql and its postflight are

SQL-first. Deploy matching code and drain old handlers before subscribing to the extra events (Connect target 12, Platform target 17). Never repeat a refund to clear an accounting hold. Existing Reconcile cannot create missing observation.

• Charge IDs are opaque, including PayByBank py_ IDs. Exact account, amount,

payment, captured and refund checks remain required for renewal recovery.

• The owner-authorised Ardent Edge Connect and Platform destinations were created

separately from local development. New secrets were owner-saved, but a later signing-secret exposure requires rotation before release; see the operator handoff. No push, deployment, remote SQL, charge, refund or real send occurred.

• Final local release verification on 2026-09-11 passed 18,965 tests with three

pre-existing skips, both TypeScript checks, zero production advisories, all scanners and production build. Lint retained zero errors/1,264 warnings. Critical verification passed 511 tests; the copied refund SQL passed 37 isolated checks. Remote CI, SQL and deployed provider verification remain separate.

Certificate design and data

• Explicit Save and current-layout PDF preview, with failure-safe drafts, guarded

modals, responsive spacing and point-size scaling that matches PDF geometry.

• Grading and course tag choices share a catalogue. Unsupported or wrong-context

placeholders block new rendering instead of appearing literally on awards.

• The legacy instructor tag is clearly labelled Club contact. Unrecorded grading

panel names are no longer fabricated in samples; existing panel slots print blank.

• Course completion dates use the existing shared club timezone (Europe/London),

independent of server timezone. Optional programme/level fields use one explicit course programme and its matching active member enrolment, never global rank pointers. Ambiguous scope is blank; these fields are not course-awarded qualifications.

• Saved layouts have bounded server validation. Invalid new background types are

rejected. Metadata-only repair of older layouts remains possible. Existing issued certificates and uploaded history are unchanged.

Reliable writes and public rendering

• Default certificate replacement uses one service-only database transaction;

failed replacements preserve the old default. Concurrent replacements serialize.

• Archive errors and zero-row updates no longer report success.
• Draft preview uses effective curriculum permissions and the demo guard. Saved

previews remain staff-readable. No new permissions, sends or feature flags.

• Public sales content no longer sits behind the global streamed loading boundary.

Existing area-specific app loading screens and authentication gates are retained.

Rollout

• SQL FIRST: apply supabase/_proposed/certificate-template-default-01.sql,

then run supabase/_verify/certificate-template-default-postflight.sql before deploying the new default-save callers. Missing authority fails closed (503).

• This is additive and re-applicable; remote application remains owner-controlled.

The original affected QA PDF/background is still required for that specific visual comparison. Synthetic sample proofs do not establish live output.

• Previous automation-template snapshot SQL remains SQL-first; paid-event

notification recovery retains its separate code-first ordering.

Dependency security correction

• Replace vulnerable Next.js, Tiptap and Sharp releases with reviewed patched

versions (16.3.3, 3.31.3 and 0.35.4). Next tooling and the complete Tiptap peer family are aligned; strict npm peer checks remain enabled.

• Patch the remaining moderate sanitizer and ZIP-parser findings with

sanitize-html 2.17.7 and fflate 0.8.3. No audit exceptions or severity changes.

• The local release checkpoint now runs the same live production dependency

audit as CI, before the longer test/build steps. An unavailable audit service fails the checkpoint rather than claiming a clean dependency tree.

• This dependency correction requires deployment, but no new SQL, flags,

environment values or provider operations. Existing SQL ordering above remains.

Register rehearsal evidence capture

• Prevent one concurrent test worker's buffered output from overwriting the

other worker's expected lock rejection. Both writers append; reused logs are cleared only after prior workers have finished. Failed runs print captured worker output before cleanup so the underlying error is visible in CI.

• Preserve every register locking, rejection and durable-state assertion.

This is test-harness-only: no application, SQL, permissions or payment change.

Clearer public sales website

• Homepage leads with club-owner outcomes, a clear trial/demo choice, shorter

feature summaries and a practical getting-started journey. Sample product data is labelled; no invented customer or time-saving claims.

• Feature and pricing copy reflects member requirements, requests/approvals,

current communication tools, course development and weekly video limits. Provider charges and specialist activation are distinguished from the published Starter guide; underlying prices and entitlements are unchanged.

• Shorter mobile club-type choices, theme-aware styling, signup-gated shared

navigation and accessible keyboard/mobile menu handling. Homepage content is server-rendered with existing motion islands; no new dependencies or queries.

• This sales batch needs a deployment, no SQL, DNS or environment change.

Prior automation authorities retain their separate SQL-first/release gates. See docs/ui/sales-website-review-2026-09-08.md for evidence and open checks.

Immutable automation wording — locally verified, rollout pending

• New automation runs capture their linked template wording before executing.

Retries and delayed steps use that content, including when the live template has been edited/deleted. Inline wording remains pinned by automation version.

• Current consent, recipient ownership, sender identity and private action-link

checks are retained. Historical runs without original evidence need review; they do not silently substitute today's template. No old sends are replayed.

• Content is deduplicated per club/revision outside frequently updated audit

payloads. Terminal-run snapshots have bounded 90-day retention; active delayed flows keep their originals. Cleanup cannot prune another club's evidence. Delivery/payment history is unchanged.

• Shared member enrichment remains once per event, while each definition gets

its own captured wording. Older automation fixtures now model the snapshot RPC with every existing assertion retained and the actual adapter under test.

• SQL first, then code: automation-template-snapshots-01.sql plus its

postflight. The local full release checkpoint passes (17,778 tests, TypeScript, security scans, lint without errors and production build); the separate SQL rehearsal passes with tenant/retention and two-session race proofs. No remote SQL, deployment or live sends performed.

Automation reliability, bounded reads and capability clarity

• Paid event reconciliation gains an atomic confirmation-notification handoff.

Recovery is separate from charging; uncertain dispatches require review rather than blind resend. No historical backfill or automatic replay of old notices.

• Automation health shows legacy/builder sending ownership, unavailable or

partial reads, and notification recovery references. Failed lookups no longer imply an all-clear; provider acceptance is not device delivery.

• Execution loads only referenced templates/flows and shares member enrichment

within one event, never across requests or clubs. Builder options have scoped server search/pagination with explicit errors and retained selections.

• Editors, compilation, publication and runtime share kind-specific action

availability. Flows support email/wait/stop; unfinished actions are labelled not yet available. Existing drafts and club flags are not rewritten.

• Deployment: this handoff requires code first, then the additive

event-paid-notifications-01.sql and its read-only postflight. Existing pending authorities keep their separately documented order. See the automation reliability runbook. No new feature flag; timezone expansion remains deferred.

Automation email links and truthful personalisation

• Trial booking, rescheduling and reminder emails resolve booking-specific

cancellation/reschedule links from existing private authorities immediately before sending. Current club/contact/state and credential hash are checked; unavailable required links fail visibly instead of sending broken content.

• Retries restore original allowlisted event facts and the saved inline message,

including preview text, while rechecking current recipient/action state. Already successful or uncertain sends keep their existing duplicate protections.

• Event payment confirmed is a distinct builder trigger with paid-invoice PDF

access. Event booked keeps its original pre-payment timing. Existing drafts are not published or rewritten; move invoice-bearing confirmations to the new trigger after reviewing club intent. No historical send replay.

• Optional unavailable renewal buttons are omitted without removing instructions.

Email skins use the same trusted unsubscribe URL as the standard footer/header. Booking buttons render as trusted markup; member values remain escaped, including single-quoted attributes. Inbox-preview tags now resolve too.

• Publication checks unsupported email action links using one batched, same-club

template read. Existing versions receive warnings; sample previews no longer promise real links are valid. Test-recipient redirects cannot expose actual member action credentials.

• Reuses the existing compiler/renderer and removes the second template lookup

during default email dispatch. Booking/invoice reads run only for used links.

• This batch requires a deployment, no new SQL or feature flag. It reuses the

existing canonical site URL configuration. Previously prepared enrolment, staff-authority and push-health SQL ordering remains unchanged. No remote SQL, provider sends, production flag changes or deployment performed here.

• Paid-event notices remain best-effort on settlement; a durable notification

handoff is separately recommended, not claimed implemented. Full coverage and live-proof limits: docs/testing/automation-email-merge-tags-remediation-2026-09-08.md.

Staff access security and six-box MFA

• Owner reports supplying the PWA VAPID values and enabling the production flag

for the next deployment. This is configuration readiness, not verified push delivery; members still opt in per device. No secret values are stored here.

• Staff grant/change/remove now uses one transactional, service-only authority.

Failed reads/writes cannot report success, resurrect removed primary-club access or delete a global staff identity. Target-club custom permissions, elevated-role and concurrent last-owner protections remain enforced.

• Club administrators no longer receive account recovery credentials or an

MFA-reset action. Invitations share the sign-in page; new staff request their own private setup email. Lost-authenticator removal requires verified support, as approved by the owner. Existing email-code sign-in remains available.

• Staff sign-in and MFA setup use six numeric boxes, keyboard/paste/autofill,

green success and a short red error shake. Reduced motion disables animation; synchronous submission guards prevent duplicate verification requests.

• SQL FIRST: apply staff-membership-authority-01.sql and its postflight

before this deployment. No new flag/environment key. Existing enrolment SQL-first work is still required; no already-applied migration was edited. See docs/database/staff-security-rollout-2026-09-08.md.

One deployment for the email correction and insurance handover

• The Creative Ways insurance cutover now has an exact-club, audited, two-stage

owner SQL procedure and independent checker. After the compatible code is deployed, link the already-copied requirement with collection paused, review old Stripe checkouts/in-flight requests, then enable canonical renewals.

• An already-issued insurance requirement token now respects the current

requirement's payment pause before any Stripe checkout is created. Missing or uncertain configuration fails closed; other requirements remain unchanged.

• The temporary pause changes the collection mode, portal renewal and linked

credential-automation setting together to respect existing constraints. Enable restores them; no automation draft is published or message sent.

• Copied expiry dates/numbers, staff corrections, historical payment references

and legacy records are preserved. Replays do not double-activate or repause a completed handover. £39, the 30-day window and staff payment-processing task stay unchanged. Red/amber requirements indicators remain in the same release.

• Post-deploy owner operation, not automatic migration: see the 8 September

insurance activation runbook. SQL cannot establish Stripe state. Defaults refuse activation until the owner supplies deployment/provider review inputs. Do not delete old payment records or the mapping to bypass a refusal.

• No additional environment variable, feature flag or second deployment is

required. The previously verified binding-table preparation remains a prerequisite; already-applied SQL/editor bundles are not rewritten.

• CI's existing requirement-renewal rehearsal now includes the disposable

insurance copy/activation proof, including an observed concurrent-enable race and unchanged financial history; no extra runner is introduced.

Owner-approved three-record exception

• Additive owner SQL can complete Creative Ways' already-linked/paused handover

without replaying the three specifically approved old attempts. All payment history and canonical member information remain intact.

• The audit records Stripe state as unverified and the owner's accepted

residual risk, not invented cancellation or in-flight-drain evidence. Genuine late provider events still follow normal reconciliation.

• Exact identity, configuration and additional-payment checks refuse changed

circumstances. The separate postflight distinguishes this exception from provider-confirmed completion. No already-applied SQL is edited, no reminders are published, and the compatible live application needs no redeployment.

• Owner instructions: docs/database/insurance-legacy-exception-runbook-2026-09-08.md.

Renewal checkout and QA corrections

• Renewal checkout resumes its stored Stripe attempt after exact identity and

amount checks, avoiding changed-parameter retries under the old key. Paid, processing or uncertain attempts do not create replacement charges.

• Portal payment fields follow light/dark theme tokens. Requirements now have

amber due-soon and red expired payment-attention counts, independent of push.

• Dashboard dates use the club calendar day. Dashboard, reports and inbox share

the same MIA window, new-member grace and club-wide attendance recency.

• Register deep-links wait for the correct day/setup data; old day rosters are

hidden during loading. Membership and public-join controls gain proper labels.

• Email domain inspection distinguishes sending-only credentials from delivery

failure without broadening provider permissions; unrelated domains are not reported as the configured sender's verified domain.

• These code corrections need a deployment, no additional migration SQL.

Push remains off until the owner supplies/activates the PWA environment settings. Those settings can be included in the same deployment.

• Existing QA certificate-layout findings still require the actual stored

template/background evidence; no issued certificate is silently regenerated. See docs/testing/qa-remediation-2026-09-08.md for coverage and remaining proof.

Enrolment checkout alignment

• Public enrolment uses the same semantic Stripe appearance, 16px hosted inputs

and guarded payment button as the renewal flow. Existing connected-account payment-method rules stay shared; wallets still depend on Stripe registration and an eligible browser/device, not PWA notification settings.

• Public/staff enrolment freezes its first exact provider request and resumes

a durably recorded Stripe attempt. Changed labels, emails or available methods cannot alter a retry under the original key. Paid, processing, cancelled, mismatched or unknown old attempts never silently become replacement charges.

• This additional enrolment work does require SQL FIRST, unlike the earlier

QA-only corrections above: apply enrollment-stripe-checkout-01.sql, then its read-only postflight, before deploying these routes. Existing preparation functions and settlement decisions are untouched; old prepared operations remain review-required, not automatically adopted. No live payment is cancelled, replayed, migrated or marked paid by the SQL.

• Reuses the existing staff-enrolment CI rehearsal, including real local JWT

denials and three observed concurrency races; no additional CI runner.

• Runbook: docs/database/enrollment-stripe-checkout-rollout-2026-09-08.md.

Staff privacy, clearer roles and portal push health

• Staff directory security details now require effective account-management

permission. Ordinary directory reads no longer call Auth or invitation history.

• Invitations offer Read-only directly and default to it; Coach / Staff wording

reflects operational access. Role and row actions follow server-calculated permissions, including demo blocking and owner-only elevated changes.

• Staff editing and removal use shared, busy-locked modals with duplicate and

Enter-key protection, retained error feedback and club-only removal wording.

• Platform health distinguishes push configuration, registered devices, recent

processing, suppression, provider acceptance, expired/rate-limited and uncertain outcomes. Keys and contacts stay private; acceptance is not device delivery.

• Apply portal-notifications-health-01.sql and its postflight for the new health

summary. No new flags or sends. Preserve the preceding staff-authority SQL-first rollout; see docs/database/staff-directory-push-health-rollout-2026-09-08.md.