How the website is built

ace.co.nz is a static website. Every page is built into plain HTML ahead of time and served as a file, which is why it is fast and why there is very little that can break at the moment a customer visits.

The pages are built from two sources. Course listings, dates and prices come from Administrate, which stays ACE's system of record. Page wording comes from Sanity, where Tracey edits it. The site is rebuilt every morning and every night so both stay current.

The only parts that run live, at the moment somebody clicks, are the forms, the booking and payment steps, the course advisor and this portal. Everything else is a file.

ACE publish a strict DMARC policy on ace.co.nz: any mail claiming to be from ACE that cannot prove it is genuine gets rejected, not filed in junk. That is the right setting, and it means the website's own email has to prove itself properly or it simply would not arrive.

It does. All three checks pass on real delivered mail:

• SPF passes, from the record on send.send.ace.co.nz.
• DKIM passes, signed as send.ace.co.nz.
• DMARC passes, under p=reject; sp=reject with strict alignment.

Checked 16 September against the message headers of a booking notification actually delivered on 15 September, rather than against the settings screen. The sending mail is handled in Resend's Tokyo region, and the DNS records that authorise it live in the ace.co.nz zone in ACE's own Cloudflare account.

1. Wording is edited in Sanity, then Show me my changes on this portal builds the practice site so it can be checked, and Publish to ace.co.nz builds the real one. Six minutes each.
2. Code goes to the master branch on GitHub. A push builds the practice site only. The live site is built by the 9:56pm job, or on demand by pressing Publish.
3. Every build refuses to deploy a half-built site: fewer than 200 course pages and it stops. That check exists because an Administrate outage once let a nearly empty site reach the web.
4. Course dates and prices are refreshed by the build itself, so the live site is never more than a day behind Administrate.

Going back is one DNS change. The old website is still running at old.ace.co.nz on the original server, and pointing ace.co.nz back at it takes under a minute.

Clone the repo, read README.md, CLAUDE.md and NEXT-SESSION.md, then:

npm install
npx astro build        # needs adm-creds.json: {"id":"...","secret":"..."}

Without Administrate credentials the build stops on a 401, which is expected and still catches mistakes. Add a sanity-creds.json holding the project and dataset and no token, and every non-course page builds locally, because the dataset is public to read.

Run these before any deploy

node migration/verify-build.mjs                       # refuses a half-built site
node migration/search-check.mjs                       # 50 search checks
node migration/consent-check.mjs                      # nobody subscribed by accident
node migration/filter-audit.mjs                       # every filter on every topic page
node migration/verify-redirects.mjs https://ace.co.nz # all 440 old addresses
node migration/bookable-check.mjs --host https://ace.co.nz

bookable-check is the one that asks the customer's question rather than the data's: does every Book button, on every page, lead to a charge at the advertised price.

Before changing anything to do with bookings

node migration/adm-request-audit.mjs       # every request shape against Administrate
node migration/test-booking-refusal.mjs    # the refusal path, not just the happy one

The four traps that have cost the most time

• Any first: in an Administrate query without a cursor loop is a bug. One of them silently hid 169 courses, 45% of the catalogue, for weeks.
• Sanity beats the wording in the code. Edit a fallback in a file and the page will not change if Sanity fills that field.
• Cloudflare fixes settings into the site at build time. Changing a setting does nothing at all until the next build, and production and the practice site hold separate copies of every one.
• Check the page a person sees, not the markup. Several faults passed every automated structural check and were obvious in one screenshot.

The full list is in CLAUDE.md and is worth twenty minutes before touching anything.

No key is on this page, and no key is in the code. They are held in three places: Cloudflare Pages project settings for the website (14 of them on production, fewer on the practice site, which is why the practice site cannot send email or take a payment), GitHub repository secrets for the scheduled jobs, and Supabase function settings for the edge functions. Anyone with access to ACE's Cloudflare and Supabase accounts can read or replace all of them without Rove.