Launch & cutover

A runbook, in the order you do it. Each step says where you are, what to do, and how you know it worked. Steps marked OWNER need you at a keyboard on someone else's website; CLAUDE steps are done in a session — ask, and they happen. A Done chip means it is finished, with the date on the step.

Open now — start here

The cutover is finished: every numbered step below is done, the last (step 24, cancelling InMotion) on 2026-09-25. What is left sits here, yours first. The rest of the page is the historical checklist of how the move was made, kept in order and with its numbers, because the manual’s other pages point at those steps by number.

Yours, numbered

Five left, as of 11 November 2026. Numbered so you can name one in a session (“open item 2”); the numbers belong to this list and are not the cutover’s step numbers below. The fifth, the faster Publish, was added last so the other four keep their numbers; it is ready whenever you are.

1. OWNER Check the signed-in phone page, then say “stage two”. The Cloudflare sign-in is on (done 9 Oct — see Done along the way). Of the three checks, two passed: door-check said ON, and the admin’s bar named your address. The third, the phone page, answered not found; the fix went live with the Publish of 9 October (build b6c1a86b), along with the smaller rail buttons. On the phone, open www.traveller.org/admin/api/m/: it should open straight on the albums, no passphrase screen, the gold bar reading signed in with Cloudflare. If it does, add it to the home screen in place of the old icon and tell a session it works. Stage two then follows, done by Claude: the passphrase comes off the web pages altogether — the test site’s admin points you to www (your choice: live site only), the old upload addresses forward to the new ones, and the Unlock the live site path retires. The iPhone Shortcut keeps its passphrase (your choice); it never used these pages. Until then the passphrase still works on the old addresses and on the test site.
2. OWNER DMARC off p=none — unblocked since step 24. Cancelling InMotion removed the last sender that failed authentication; the DMARC reports now decide when p=quarantine is safe. Ask a session to read the reports; it says when, and then the change is one TXT record in the Cloudflare zone (DNS records, select the zone first).
3. OWNER When you choose — not today (your call, 2026-09-25). Re-upload the Philippines 2016 photographs the site does not have. The old server had three Philippines 2016 albums the crawl never reached. Matched by filename against the site today: Cebu, 19 photographs, 2 on the site — the album is effectively missing; Boracay, 71, of which 39 are on the site; Palawan (the El Nido album), 210, of which 189 are. You said you can re-upload them yourself; do it as any upload. Until then every old Philippines page already answers (see Done along the way): Cebu’s land on the Philippines page, and a re-upload named 2016/cebu is picked up by the next redirect build on its own.
4. OWNER Optional. Add brarob100.github.io to the Turnstile widget’s hostnames (Turnstile → the widget → Hostname Management), only if you want the contact form’s robot check to draw on the test site. The live site does not need it.
5. OWNERDone 11 Nov Built 2026-11-10 and left switched off, at your word (“Build it, off until I act”). Switched on by you on the night of 11 November 2026; the first fast Publish went live at 04:53 UTC and passed every check below. Switch on the faster Publish. Today Publish moves the production branch and Cloudflare clones the repository and builds it: a median of 4.4 minutes to the live site, sometimes twenty. The faster path builds on GitHub and hands Cloudflare the finished site. Do the parts in order; do C and D one straight after the other.
   1. Done 11 Nov Give the deploy token permission for Pages. Open your Cloudflare API tokens. This page belongs to your profile (the person icon), not to the account and not to the domain, which is why it is not in either of those menus. Find the token that the Worker deploy uses: it is named traveller-worker-deploy, and its editor shows two policies, a Zone policy (all zones, Workers Routes Write) and an Account policy (Workers Scripts Write). On its row press ⋯ and then Edit. Press the pencil on the Account policy and add Cloudflare Pages set to Write (Cloudflare now says Write where older screens said Edit; Add new policy → Account policy does the same job). Save the policy, then save the token.
      Done 11 November 2026, by you. The token has no DNS permission, and never needed one: an earlier version of this step said it had DNS: Edit, which was a September inference from a green deploy, never read off this screen. Your screenshot settled it.
      Do not roll or re-create the token: editing keeps the same secret value, so nothing on GitHub needs touching.
      Done when: the token lists three permissions: Workers Routes Write, Workers Scripts Write and Cloudflare Pages Write.
   2. Done 11 Nov Tell the session: “run the fast publish trial”. It starts the workflow with trial chosen. That builds the commit the live site is on, compares nine pages byte for byte with www, and uploads the result to a preview address only: fast-publish-trial.traveller-org.pages.dev. The live site is not touched. It takes a few minutes.
      Done when: the session reports all nine pages same and the upload green.
      Stop here if any page is different, or the upload is refused. A refusal naming authentication or permission means part A did not take; look at the token again. Nothing has changed yet, so stopping costs nothing.
      Done 11 November 2026, run 1 of the workflow. It built 2770e8e, the commit www was serving, in 17 seconds; all nine pages came out same; the upload was accepted on the first try (of 3,635 files Cloudflare already held 3,634 byte for byte, which is the same finding seen from Cloudflare’s side). The preview address answers with that commit at /build.json, and its /admin/ sends a stranger to sign in.
   3. Done 11 Nov Stop Cloudflare building on its own. Open the Pages project’s settings (this is under the account, in Workers & Pages, project traveller-org). Cloudflare’s own instructions, as of 11 November 2026, read: Build → edit Branch control → turn off “Enable automatic production branch deployments”. Save. Leave the preview-branch setting as it is.
      A session cannot see this screen, so if the words differ, the setting you want is the one that stops a push to production from starting a build.
      From this moment Publish moves the branch and nothing builds it, until part D is done. Go straight on.
      Done 11 November 2026, by you. The words matched: the Branch control panel, production branch production, the box “Enable automatic production branch deployments” unticked, preview branch left on “All non-Production branches”.
   4. Done 11 Nov Set the switch. Open the repository’s Actions variables (this is under the repository: Settings, Secrets and variables, Actions, and then the Variables tab, not Secrets). Press New repository variable. Name: FAST_PUBLISH. Value: on. Add it.
      Done when: the Variables tab lists FAST_PUBLISH with the value on.
      Done 11 November 2026, by you. The next Publish ran the fast job, which it skips unless the variable reads on: that is the proof it took.
   5. Done 11 Nov Tell the session: “publish it”. There need not be anything new waiting: the first fast Publish can send the commit that is already live, which is the safest first run, since the workflow compares its build with www before it uploads and refuses if they differ. The session then checks, on www itself: the commit named at /build.json; that an unlisted album still sends a stranger to the friends’ sign-in; that /admin/ still asks you to sign in; and that the contact form still draws its check.
      Done when: the session reports all four, and the Publish page says Live within a couple of minutes of the button.
      This is the first real proof that the project’s settings (the friends’ password, the sign-in values) apply to a site uploaded this way. The trial in part B cannot show it, because a preview address uses the project’s preview settings, not the live ones.
      Done 11 November 2026, Publish run 42962048441. First an ordinary Publish (Cloudflare building, 2½ minutes) brought www level with the trunk at 7539cd8, so this one sent the commit already live. The whole run took 80 seconds: the branch moved, the build matched www on all nine pages, Cloudflare already held all 3,635 files, and www answered with the commit at once. Then, on www: /build.json names 7539cd8; the unlisted album /countries/unitedkingdom/1991/ and the friends’ shelf both send a stranger to the friends’ sign-in; a wrong friends’ password is refused (bad=1), which it can only be if the server has the password, so the live settings apply; /admin/ sends a stranger to the Cloudflare Access sign-in; the contact page carries the Turnstile widget with its live site key. The session could not watch the check draw, because its sandbox cannot reach Cloudflare’s challenge server; the next time you open the contact page is the last word on that. The Publish page’s Live is yours to see too: it is behind your sign-in.
   6. If anything is wrong, put it back, in this order: in the Pages project, open Deployments, find the last deployment from before tonight and choose Rollback (the live site is back at once); delete the FAST_PUBLISH variable; turn automatic production branch deployments back on. Then tell the session what you saw. Publish is then exactly what it was this morning.
   Afterwards (done 11 November): this item marked done, the “today” line on the manual’s front page moved, and the first run recorded in addendum 438. How the pieces work is on the pipeline page.

Still open, and not blocking anything

Claude’s when you ask, or deliberately waiting.

• CLAUDE Noted 2026-11-11, when the faster Publish went on. The Publish page still describes the old path. Its status line says “the branch moves in under a minute, then Cloudflare builds the live site” and “Cloudflare is building the live site (it usually takes a few minutes)”. Since 11 November the build runs on GitHub and the site is live in one to two minutes. The words are loose rather than wrong, and the page’s Live chip still works the same way (it reads /build.json). A session rewords them with the page’s test when you ask.
• CLAUDE Reviewed 2026-11-10; you said “take all actions listed” the same day. All six batches published. The review of 10 November. A full pass over the admin, the public site and the pipeline, with the iPhone and iPad in mind. The whole list, how sure each finding is and where it lives in the code, is docs/2026-11-10-review.md in the repository. It is being worked through in six batches, each published when tested: (1) the faults — done; (2) phone and iPad polish — done; (3) a “done” signal for background runs — done; (4) public-site speed, touch and navigation — done; the 1200px photograph size for phones was built on 11 November at your word (addendum 437), and its one-off fill for photographs already on the site was run the same day: 30,846 of 30,932 have their copy (the numbers). The owner’s photo controls came off the album pages the same day (addendum 439). Still open: moving the admin’s styles out of the public stylesheet. It was measured and tried on 11 November and not done: 244 rules, about 26 KB of the stylesheet’s 142 KB, match nothing on a public page and could move, but the check built to prove the move changes nothing on any admin page gave different answers for the same build twice, so nothing was moved (addendum 442); (5) pipeline efficiency — done; the faster Publish was built off and switched on by you on 11 November (the steps, all done). Built since, on 11 November: caption saves leave in batches; Album cleanup reads captions from the repository without waiting for a rebuild; a covers or journal-photo save that GitHub drops sends itself again (addenda 435, 436). The build’s Node version is pinned to 22 in .nvmrc (addendum 440). Album cleanup’s order and friends-only marks are read from the repository too, and the test runner times every suite (addendum 441; a full run is about 700 seconds, and running 52 suites side by side saves about 31 of them). Still open from this batch: Cards & strips, Journal photos and Banknote pages reading saved changes the same way; sharing builds between the browser suites, which is where the suite’s time goes; the IndexNow run’s wait after a Publish, which should now be short and has not been looked at since the faster Publish went on; the guide-sync runs that fire for nothing (the cause is in the app repositories); (6) Delete for films and letters, and one vocabulary — done. The eight controls left from batch 6 were built on 11 November (addenda 434 and 435): captions in Album cleanup; Unlisted and “Publish to www too” when the phone uploads into an existing album; old albums in Album cleanup’s phone list, with Delete; a Friends button that says which way it goes; a card to name banknote photographs the reader could not; Bring them back for photographs held as near-duplicates; one rule for confirming what cannot be undone. One is yours to decide: the Remember-passphrase default, which is off at a desk and on on the phone; say which way both should go. Caption saves now leave in batches too. A session picking this up reads that file and the decision log from addendum 426 on.
• OWNER Found 2026-11-11. 86 photographs the site lists have no file in storage. The fill for the phone’s size could not make a copy of 86 photographs, and the reason is that there is nothing to copy: for each, images.traveller.org answers 404 for the full-size file, for the thumbnail, and for every rotation name of it. 72 are in Turkey 2022, 13 in Siem Reap 2009 and 1 in Belgium 2016. The albums’ records still name them, so each album page draws a tile whose picture cannot load, on the test site and on www. Nothing done on 11 November could have removed them: that work wrote and deleted files under mid/ only. Not known: when they went, or why. The names are in docs/2026-11-11-missing-photographs.txt. Yours to decide: a sync run on each of the three albums removes the 86 empty tiles (the records then match storage); getting the photographs back means uploading them again. Say “sync the three albums” in a session, or upload the photographs to those albums first.
• OWNER Clarity went live 2026-10-31; this was deferred the same day, at your word: “update any privacy policy or TOC later — I need this live immediately”. Say on the site what Analytics and Clarity collect. Microsoft Clarity records how visitors scroll, click and move on the public pages (heatmaps and session recordings), alongside Google Analytics’ page counts. The site has no privacy or terms page today, so there was nothing to update. When you want one, ask a session to draft it from the stack table’s Google and Clarity rows, which say exactly which pages each runs on, and to check Microsoft’s and Google’s own terms for what they require a site to tell its visitors.
• OWNER Built 2026-10-14; the four settings added the same day. Waiting on a Publish. See the insights dashboards fill in. After the Publish that carries them, open Search & indexing and Traffic & AI on www. Every card should fill within a few seconds; press Check a sample once for Google’s index verdicts. A card reading Not configured yet names a setting the Pages project is missing (add it, then Retry deployment); a Google card saying the key file is not valid JSON means it was not pasted whole on one line. Say in a session what you see and this closes.
• OWNER Baseline laid and all 792 pages announced, 2026-10-13; Bing seen acting on it, 2026-10-14. Ready to check. See IndexNow arrive in Bing. The Publish of 2026-10-13 put the key file and the page fingerprints on www and, as designed, sent nothing. From the next Publish, each one sends the pages it changed. After that Publish, open Bing Webmaster Tools, go to its IndexNow page, and look for the URLs. Its exact address is not recorded yet; add it to the stack table’s Bing row once you have it. The matching IndexNow run lists the same pages. If Bing shows nothing after a day and the run is green, say so in a session. You do not have to wait for that Publish: the same night a session announced every page once, so that Bing re-reads the new descriptions sooner than its own schedule. The run marked all sent 792 URLs at 23:52 UTC and IndexNow answered 200, so those should already be on Bing’s IndexNow page. That was a one-off. It is not to be repeated, because IndexNow asks for changes, not the back catalogue. Bing has already acted on it (a session, through Bing’s Webmaster API, 2026-10-14): it re-read the home page, Australia and Cuba within 31 seconds of IndexNow’s 200, and by 00:45 UTC 6 of the 18 pages checked. A second read later that day got no further: Bing was still refusing page lookups (ThrottleHost), so 6 of 18 is the last count a session has. What is left for you is Bing’s own IndexNow page: send its address in a session and it goes into the stack table, and this item closes.
• CLAUDE Waiting for Google’s numbers, from about 2026-10-23. Did the new descriptions move anything in Google? On 2026-10-14 Search Console’s data reached only 2026-10-13, the day of the Publish itself, and Analytics had no day after it either, so there was nothing to compare. The “before” is recorded: 28 days of Search Console, by page type, in addendum 395 of the decision log. Once a week of “after” is final, which is about 2026-10-23, ask a session to compare impressions and click-through by page type against it. Google has to re-read a page before its new description can show, and it does not take IndexNow, so the change arrives on Google’s own schedule. Where Google’s reading stood on 2026-10-14: its sitemap report holds the sitemap under its old name, http://www.traveller.org/sitemap.xml (submitted 2009; the new one kept the filename), last downloaded 2026-10-04 — nine days before the Publish. So Google had not yet read the new sitemap, let alone the pages. The session doing the comparison should read that date first: if it has still not passed 2026-10-13, there is nothing to compare yet, whatever the calendar says.
• CLAUDE Deferred by you, 2026-09-24. Two GitHub Actions savings, for when minutes matter. Your plan includes 3,000 minutes a month, shared by every private repository, at $0.006 a minute beyond that (August: 6,533 minutes, $21.18 billed; September to the 24th: 2,731). You chose to leave these until development slows, since the minutes will fall on their own. When wanted, each is a small edit: (1) docs-guard.yml — run it on the trunk only, and check out without the photographs (filter: blob:none, sparse to .github); it only compares two lists of file names, yet was the largest single consumer (661 minutes in September, 2,797 in August), about 500 minutes a month saved. (2) cutover-checks.yml — run it on the trunk only, not on every session branch as well; roughly 100 minutes a month. Already done: the retired-file sweep runs daily rather than hourly (about 720 minutes a month avoided). Keep the $35 Actions budget as an alert without Stop usage: a stopping budget would halt photo imports, the test site and Publish until the month resets.
• 53 journal photographs vanished from the old server years ago. Seven of them turned up in the InMotion backup (2026-09-25); you chose to leave those seven behind in the migration rather than extract them, so the letters stay as they are. Each of the 53 is listed with its entry in migration/journal-missing-images.csv in case a scan turns up.
• A pre-flight for iCloud links — “12 in this link, 5 already in San Andrés: fetch the 7 new / replace all 12” before anything starts (planned and set aside by you on 2026-09-13: “save for future”, then “record it”). Today the link intake decides overlap by rule on the runner, after the button is pressed — an original already in the album at its size is kept, a different photograph with a taken name is numbered, the pixel-hash check holds near-duplicates — and the page shows no count and offers no choice, because it never opens the link. The drag-in and phone paths do pre-flight names and ask skip / replace. The plan: a Worker route that resolves and lists the link itself (the fetch’s first two calls, small JSON, no downloads), plans names by the same rule as the run, compares them with the album folder, and answers new / same / differs / movie counts plus the link’s expiry; both pages show the sentence and two buttons (fetch the new is the dark one; replace all rides the dispatch as direction: replace, which the fetch honours by overwriting a taken name); the phone reuses its existing duplicates sheet. Tests pin the classification’s parity with the Python, both pages’ POSTs, and the replace flag. About half a day of session time. Reuse points: icloudGuid and the destination handling on /dispatch, the /photos listing, master_name / plan_names in icloud_fetch.py, the #dupsheet on /m. Nothing is built until you say so.
• Cloudflare Pages is in maintenance mode — a move to Workers is on the table, and deliberately not taken yet (checked and deferred 2026-09-09, your call: “no dev”). Cloudflare has put all new investment into Workers; Pages still runs, still builds, and has no announced shutdown date, so nothing is broken and nothing is urgent. Two things here sit on Pages: this site (built from production, with five Pages Functions) and the Spec Intake form (two functions, on spec-intake.pages.dev). The four Workers — upload, contact, email and the recipe pipeline — are already Workers and are unaffected, as are Netlify (Expense Tracker) and Railway (the Amapas 353 ChatGPT app).
  What a move would cost: _redirects, _headers, custom domains, environment variables and secrets all carry over, and Git builds become Workers Builds — but the functions/ folder is not supported natively and must be compiled or rewritten. On this site that folder is the 301 layer answering every old address plus the friends door, which is the machinery least safe to disturb while the Search Console reports are still draining.
  When it is wanted: do Spec Intake first as the rehearsal — two functions, no custom domain, no Access door, and a broken deploy costs a form rather than the live site. Only then this site.
• The Amapas 353 Website & Admin guide is written and held back (your call, 2026-09-10: “hold on the amapas353.com documentation until we get that site completed. it’s changing too much”). Six pages covering the booking site and every admin screen exist in that app’s own repository under docs/guides-site/; they are not on the shelf. The reason is worth keeping: the guide went stale between being drafted and being pushed — the Rates screen was redesigned, promo codes went from two kinds to three, and a Reviews screen appeared, all in the hours it took to write. To bring it back: delete the hold line from that app’s row in src/data/guides.json, then run the Sync app guides workflow. Before you do, have that repository’s session re-read the six pages against the finished site — the sentence most likely to be wrong by then is the one saying the permanent web address is not switched on yet.
• Decap CMS at /admin is not built. Editing is by session or by editing JSON on GitHub. The Journal editor (2026-08-18) now covers the letters — prose, inline photographs, the pull-quote — which was the largest piece of what a CMS was for.
• No film is flagged for the home page or its country page, so the home page's film row renders empty. The Films manager sets those flags.

The cutover, as it was done — the historical checklist

Every step here is finished. Read top to bottom, it is the order the move had to happen in, and each step records when it was done and anything that surprised us.

The order is a dependency chain, not a suggestion. Every step can be started the moment the one above it is finished, and none can be started before — so working top to bottom never leaves you stuck. If a step ever tells you it must wait for a later one, that is a bug in this page: say so and it gets moved.

Stage 1 — Now (before anything moves)

Nothing here touches the live site. Do it whenever; it can all sit finished for weeks.

1. OWNERDone 18 Aug Create the Cloudflare Pages project.
   Cloudflare → Pages → Connect to Git — that link goes straight there, which is the reliable way in (see the warning below). Pick brarob100/traveller.org → Begin setup.
   On Set up builds and deployments (verified against the dashboard 2026-08-18): Project name traveller-org — keep exactly this, it is the name step 2's redirect table was built against; Production branch production — the one field that must not be left at its default; Framework preset None; Build command npm run build; Build output directory dist. Preset None leaves the last two blank — type them, rather than picking the Astro preset and trusting what it fills in.
   
   If you navigate by hand, the dashboard will put you in Workers instead — twice over. Cloudflare has demoted Pages to a footnote, so Workers & Pages → Create application lands on a "Create a Worker" panel whose step rail reads Select a method → Select a repository → Create and deploy. It will happily let you choose this repository and go on to a form headed "Set up your application — Configure your Worker project" with a Deploy command box reading npx wrangler deploy.
   Two tells, either one decisive: Pages never says "Worker" anywhere, and Pages has no Deploy command box at all. If you are on the Worker panel, the way out is the grey line under the method list — "Looking to deploy Pages? Get started" — or just use the link above.
   Why it matters, not just which button: that deploy command would read this repo's root wrangler.toml, which belongs to the upload Worker, and deploy that instead of the site — a second deploy path fighting the one GitHub already runs. Worse, the Workers form pins no branch, so it would build the working branch: every commit straight to the live site, which is the one thing this project exists to prevent. It also never asks for the output directory or the five variables below, both of which Pages does.
   Open Environment variables (advanced) on that same screen and set exactly these five (the field truncates long values on screen — click into PUBLIC_R2_BASE and check it ends .r2.dev):
   • SITE_URL = https://www.traveller.org
   • SITE_BASE = a single forward slash
   • PUBLIC_R2_BASE = https://pub-d86b555b7dd7462abd871c743192bcd6.r2.dev — the bucket's own address, for now. It becomes https://images.traveller.org at step 14, which cannot happen until the nameservers move at step 13. Setting the custom name before it resolves builds a site on which every photograph is broken.
   • PUBLIC_LEGACY_IMAGES = off
   • PUBLIC_UPLOAD_URL = https://traveller-upload.brarob.workers.dev
   Done when: the build finishes green, traveller-org.pages.dev shows the site, and a session confirms the build is correctly shaped — green is not the finish line, because it is green either way. Write that address down — step 2 needs it.
   Done 2026-08-18. traveller-org.pages.dev, production branch production, all five variables verified from a session against the deployed site — see the checklist below for what that means and how to ask for it again after a redeploy.
   Expect a site a little behind staging. Pages builds the production branch, which moves only when you press Publish — so this first build shows whatever was last published, not the newest staging. A missing recent change here is the gate working, not a broken build: open the Publish page, check the waiting list, and publish once to bring the two level.
   Then have a session check the shape of the build, because a Pages build succeeds and looks identical from Cloudflare's success screen whether those five variables took effect or not. Ask for it — do not read view-source yourself. traveller-org.pages.dev was added to the sandbox's allowlist and a session verified all five from this side on 2026-08-18, so the check is one sentence to Claude ("verify the deployed Pages site") rather than five things to find in a browser. What it looks at, and which variable each proves:
   • photographs on a real album page come from pub-….r2.dev and the objects fetch 200 image/jpeg — PUBLIC_R2_BASE reached the build, and its truncated ending survived the paste
   • /robots.txt does not say Disallow: / and names a sitemap — SITE_URL reached it
   • rel="canonical" on the home page says www.traveller.org with no sub-path — SITE_URL and SITE_BASE both landed, so the build is production-shaped
   • /sitemap.xml exists, every URL in it names www.traveller.org, and none is under /admin/
   • an album still on the old server 404s and is absent from the sitemap — PUBLIC_LEGACY_IMAGES=off reached it
   • the Publish page carries the Worker address — PUBLIC_UPLOAD_URL reached it
   Any one of these failing is a variable in the Pages project, fixed at the dashboard and a redeploy — not a code problem. A session can tell you which one and what to set it to, but it cannot set it: Pages environment variables are yours alone.
   Why production and not the working branch: every commit reaches staging (the test site) by itself, but the live site must only change when you press Publish on the Publish page — that button is what moves the production branch, and this Pages project rebuilds from it. Connect the working branch instead and every half-reviewed commit goes straight to traveller.org.
   Why these five: the first two make links, canonical tags, robots.txt, the sitemap and the llms.txt files all say www.traveller.org instead of the test address; PUBLIC_R2_BASE points every photograph at the image host; PUBLIC_LEGACY_IMAGES=off withholds the 0 albums whose photographs are not migrated yet (), so the site never shows a broken frame.
2. CLAUDEDone 18 Aug Generate the redirect table against the real Pages address.
   NEW_HOST=https://traveller-org.pages.dev python3 migration/build_redirects.py
   This is not optional because the file already exists. The committed migration/htaccess-redirects.txt was generated against a guessed address, traveller-org.pages.dev. If Cloudflare gives the project any other name, every one of its 327 redirects points at a host that does not exist — and it is pasted into the live server at step 6.
   Done when: migration/htaccess-redirects.txt names your Pages address, and both checks pass: python3 migration/verify_redirects.py and python3 migration/test_htaccess.py.
   Done 2026-08-18, and it was a confirmation. Cloudflare assigned traveller-org.pages.dev — the very address the committed table had been generated against from a guess — so regenerating produced a byte-identical file and git diff came back empty. That empty diff is the whole result: it proves the 393 rules about to be pasted into the live server point at a host that exists. Had Cloudflare named the project anything else, the diff would have been the work.
3. CLAUDEDone 18 Aug Run the cutover audit.
   SITE_URL=https://www.traveller.org SITE_BASE=/ PUBLIC_LEGACY_IMAGES=off PUBLIC_R2_BASE=https://images.traveller.org npx astro build then python3 migration/verify_cutover.py.
   All four variables, not two. Leave SITE_URL and SITE_BASE off and the build still calls itself production — but its canonical tags name the staging address, so the redirect check reports STAGING and refuses to make the strong claim this step exists to obtain, and the audit's own headline passes for the wrong reason (see the note below).
   Then, on that same production build, re-run python3 migration/verify_redirects.py.
   Done when: the audit prints nothing on the public site addresses www.traveller.org, and the redirect check prints checked against a PRODUCTION build with every target found. If the audit prints anything else, stop — those are images that break the moment DNS changes.
   Why the redirect check runs again here, having already passed at step 2: it only ever checked the build sitting in dist/, and at step 2 that is normally a staging build. Production sets PUBLIC_LEGACY_IMAGES=off and withholds the legacy albums, so a redirect aimed at one would pass at step 2 and 404 on the live site. The check now prints which shape it read and says so when the weaker claim is all it can make.
   And why the command grew from two variables to four, 2026-08-18. With only PUBLIC_LEGACY_IMAGES and PUBLIC_R2_BASE set, the audit printed self-references the new site serves: 0 and then nothing on the public site addresses www.traveller.org — safe to cut over. Both lines were true and together they meant nothing: with SITE_URL unset there were no www.traveller.org references in the build at all, so the audit passed by having nothing to look at. Adding the two missing variables gives 1130 self-references and the same pass — which is the pass that means something. That is `tests/README.md`'s second trap ("a passing test can be measuring nothing") landing on the runbook for the second time in one day.
   Run 2026-08-18 with all four: audit clean at 1130 self-references, redirect check checked against a PRODUCTION build, 278/278 targets present, so no redirect depends on a withheld album.
4. CLAUDEDone 18 Aug Verify the sitemap and structured data. Built 2026-08-18 (same day this step was added for their absence): the sitemap (@astrojs/sitemap, /admin/ excluded, named by production robots.txt), canonical tags and og:url/og:image on every page, and schema.org JSON-LD (WebSite + Person on the home page, ImageGallery on galleries, BlogPosting on journal entries). tests/seo.test.mjs holds it all green.
   Done when: ./tests/run.sh passes — the SEO suite asserts the sitemap exists, leaks no admin page, and robots.txt names it.
   Note that run.sh builds a staging-shaped site, so for the production claim run the step-4 build command above and then node tests/seo.test.mjs against it. Done 2026-08-18 that way: 21 assertions green, 563 sitemap URLs, no /admin/ page listed — and the same three facts confirmed independently against the deployed site at traveller-org.pages.dev, which is the stronger check because it reads what Cloudflare actually served.
   This step began life as "build the sitemap" — the manual had promised one on three pages while nothing generated it. It stays as a verification step because the promise has been broken once already, and a re-check costs one suite run.

Stage 2 — At InMotion (old site still live)

This is the only stage that edits the old server. It sends visitors to the new site before DNS moves, so no old link is dead in the meantime. The old site keeps working for anyone typing the address.

5. OWNERDone 18 Aug Back up the current .htaccess.
   cPanel → File Manager → public_html → Settings → tick Show Hidden Files → select .htaccess → Download.
   Done when: the file is on your machine somewhere you can find it in a hurry. This is the undo button for the whole stage.
   Done 2026-08-18, on the owner's report — this is the one step in the runbook a session cannot confirm, because the evidence is a file on his own machine. Its contents were pasted into a session the same day and are now a fixture in migration/test_htaccess.py, which is the next best thing: the file can be reconstructed from the repo if the download is ever lost.
6. OWNERDone 18 Aug Paste the redirect block in.
   Yes, there is somewhere to send the traffic — already. Every one of the 393 rules points at traveller-org.pages.dev, not at www.traveller.org, and that host has been live since step 1. This is the whole reason Stage 2 comes before the DNS flip: visitors and search engines start reaching the new site now, and nothing about it waits for step 13. Verified 2026-08-18: all three of step 8's targets answer 200 on the Pages site. If you would rather see that for yourself before editing anything, open https://traveller-org.pages.dev/currency/thailand-20/ in a browser — that is exactly where the third test URL will land.
   Right-click .htaccess → Edit. Open migration/htaccess-redirects.txt on GitHub, click Raw, copy everything, and paste it in at the bottom, below everything already there. Save.
   Done when: the file still begins with the #spamming site lines and ends with the redirect block.
   Done 2026-08-18, verified live from a session. The block is in effect: the catch-all answers 301 → traveller-org.pages.dev on an invented URL, which it can only do if the rules are being read.
   The generated table grew after you uploaded (same day) — your copy on the server does not need updating. Nine rules were added for seven albums in the crawl's oldest, pre-content/ layout, which the generator had missed. Every URL they cover already falls through your uploaded catch-all to the new host, where the new machinery catches it — verified live on /luxembourg/1998/. Re-pasting would only shorten a two-hop redirect to one, and the whole file stops mattering at step 13, when this server stops seeing traffic for the domain.
   Confirmed against the real file 2026-08-18 — the owner pasted it into a session and it is now a fixture in migration/test_htaccess.py. It holds only two things, a user-agent block and a PHP handler, and neither one catches URLs, so the redirects can safely run last. Pasting below them means the user-agent block keeps first refusal on the agent it bans; everyone else falls through to the 301s.
   Pasting ABOVE is not merely untidy, it is wrong, and the suite now proves it: a redirect would match first and carry [L], so the banned agent escapes the block entirely and gets a 301 like everyone else. Bottom of the file, every time.
7. OWNERDone 18 Aug Optional: fix the spam block while you are in there.
   The blocking rule already in the file has never matched anything, and that is now verified rather than argued (2026-08-18, against the file itself). Its pattern is the raw browser string, and Apache reads a RewriteCond pattern as a regular expression — so the parentheses in (Windows NT 10.0; WOW64) and (KHTML, like Gecko) are capture groups, not literal brackets. The rule therefore hunts for a version of the user-agent with its brackets stripped, which no browser sends. If you want the block to work, replace its RewriteCond line with:
   RewriteCond %{HTTP_USER_AGENT} "Chrome/51\.0\.2704\.103" [NC]
   Done when: saved — or skipped. The old site retires in weeks either way, so this is tidiness, not necessity.
   Done 2026-08-18, and it works now. A request carrying that exact user-agent gets 503 from the live server — the first time this rule has ever fired. A normal browser is unaffected, and the redirects below it are untouched.
   Skipping costs the redirects nothing. The suite runs the cutover both ways against the real file: unrepaired, readers get their 301s exactly as before and the banned agent simply gets redirected along with everyone else. It is the block that is broken, never the redirects.
   Leave the AddHandler line alone while you are tidying. The old WordPress site still runs on it until InMotion is cancelled, and the 301s living in this file have to keep working until then. (Its comment says PHP53 and the directive says php56 — the comment is what is wrong, and neither is worth touching.)
8. OWNERDone 18 Aug Test three redirects.
   This step runs now, not at cutover. The redirects target traveller-org.pages.dev, which is live, so they work the moment step 6 is saved — the old site being still on InMotion changes nothing.
   In a browser, open each and confirm you land on the new site:
   • www.traveller.org/journal/?p=15 → Climbing the Pyramids
   • www.traveller.org/cuba/1996/varadero/ → the Cuba gallery
   • www.traveller.org/currency/thai-notes-20.html → the Thai 20 note
   Done when: all three land correctly. If any 500s, restore the backup from step 5 and say so — the old site is back instantly.
   Done 2026-08-18, verified from a session — and well beyond three. All three test URLs 301 to the right target and finish 200 on the Pages site. Then 14 more were sampled, two from each of the seven redirect categories (banknote, banknote-without-a-record, country, gallery, split-or-retired gallery, journal post, root page): every Location header matched the redirect map exactly, and every target answered 200 on the deployed site rather than merely existing in a local build.
   Reading a failure. Three outcomes, and only one of them is a broken rule:

   • 500 — the block has a syntax error Apache will not accept. Restore the backup; nothing else in this stage matters until it is back.
   • 200, showing the old page — the block is not in effect at all. Not a rule problem: the file was not saved, or it went into the wrong .htaccess (it must be the one in public_html, the same file step 5 downloaded).
   • The right new page — done.

   The one-URL version of that check: open www.traveller.org/definitely-not-a-real-page.html. With the block live, the catch-all rule 301s anything unmatched to the new site. If instead you get a 302 to missing.shtml, that is the old site's own 404 handler answering, which means no rewrite rule ran — the block is not active. Confirmed as the pre-paste signature on 2026-08-18, when the live server was probed from a session and answered exactly that.

Stage 3 — Before you flip DNS

Last look. Still nothing irreversible. Start with the TTL, because it is the only step here with a wait attached — set it first and the other three happen while the clock runs.

9. OWNERDone 18 Aug Lower the DNS TTL.
   At Porkbun — still the DNS host at this point — set the TTL on the traveller.org records to 600 seconds. Then wait for the old TTL to expire (whatever it was set to — often a day) before step 13.
   
   600, not 300 — and 300 will be rejected when you press save. Porkbun enforces a minimum TTL of 600 seconds, because Porkbun runs its own DNS on Cloudflare and Cloudflare caps TTLs at 600 for records on its network. Established 2026-08-18, from Porkbun's support desk, after the runbook asked for 300 and the save failed.
   Nothing is lost by it. The point of this step is that a rollback does not have to wait out a day-long cache, and 600 seconds is ten minutes — the difference between 300 and 600 does not change any decision on cutover day.
   Done when: the records show a 600-second TTL, and the old value's worth of time has passed.
   Set 2026-08-18, on the owner's report — a session cannot read Porkbun, and DNS-over-HTTPS is blocked from the sandbox, so this one cannot be confirmed from a session either way. Check the records read 600 before starting step 13c. The wait is the part that matters: do not start step 13 until the previous TTL's worth of time has gone by.
   This is what makes step 13 reversible in minutes rather than hours. Skip it and a rollback is stuck waiting for caches to expire worldwide.
   Why this is the first step of the stage and not the last (moved 2026-08-18): it is the one step whose cost is waiting, and the three after it are reading and checking. Set the TTL, then walk the site and run the checks while the old value ages out — otherwise you finish Stage 3 in an hour and then sit for a day before you can flip.
10. OWNERDone 18 Aug Walk the Pages site.
    Open each of these on traveller-org.pages.dev — one of every kind of page the site builds:
    • home — photographs, not blank frames
    • a country page
    • a gallery
    • a banknote
    • a journal entry
    • the contact page — it shows its picture
    • a gallery whose filenames contain spaces and brackets — the shape most likely to break a URL
    Done when: nothing is a broken image.
    This one is genuinely yours, and the page used to claim otherwise. It said a session could drive it in a browser and report. It cannot: Chromium in the sandbox has no outbound network at all — every host, proxied or not, answers ERR_CONNECTION_RESET — which is why the committed browser suites run against a local server with photographs stubbed. Corrected 2026-08-18, after trying it.
    What a session can do, and did: fetch every page above and every distinct image URL on them over HTTP. On 2026-08-18 that was 213 image URLs, all answering 200 image/jpeg from the bucket, including the four whose filenames carry spaces and brackets. So the addresses are right and the objects exist.
    What that does not prove is what you are looking at. `CLAUDE.md` has this exact warning for a reason: numeric assertions have passed on pages that were visibly broken. A correct URL that renders behind a mis-sized container is still a bad page. Your eyes are the check here; ask a session first if you want the URL-level sweep re-run against a fresh deploy.
11. OWNERDone 18 Aug Decide about the withheld albums.
    There are none left to decide about. Every album this site knows about is publishable: 195 serve their photographs from the image host, and one — luxembourg/1998 — ships its 23 photographs with the site itself.
    Done when: you have decided — or, as here, there is nothing left to decide.
    Resolved 2026-08-18 rather than decided. This step was written when the number was 32 albums and 4,395 photographs. Thirty-one of those were the deprecated 800px albums, deleted outright at the owner's request (see Done along the way). The last one, luxembourg/1998, was moved onto the new site the same day: its 23 photographs now ship with the build under /legacy-media/, so it is published like any other album and is not marked deprecated — nothing supersedes it, it is simply the best copy that exists.
    It had to move, not merely deserve to. That album's photographs were hotlinked to www.traveller.org, and step 6's redirects made every such URL 301 to the new site, where they did not exist. The moment the redirect block went live, the album's images broke. Shipping them with the site is what makes the old server switchable-off, which is the whole point of stage 5.
    The counts above are derived from the gallery data at build time, so this step cannot overstate itself again.
12. CLAUDEDone 18 Aug Final re-run of both checks, in case a gallery imported or a page changed since step 3.
    Done when: verify_redirects.py and verify_cutover.py both pass against a fresh production build.
    Run 2026-08-18, on a production build made the same hour that luxembourg/1998 moved onto the site:
    • verify_cutover.py — 574 pages serve photographs from the image host, 1,133 self-references to www.traveller.org, and 0 references to the moving hostname the new site does not serve. Nothing on the public site addresses www.traveller.org — safe to cut over.
    • verify_redirects.py — checked against a PRODUCTION build, 327 redirects to 278 distinct targets, 278/278 present.
    You do not have to ask for this any more (2026-08-18). Both checks now run on every push that touches the site, the data or the redirect table, as the Cutover checks job in the repository — against a production-shaped build of that exact commit. It is red on failure, not a warning like Docs guard: a redirect aimed at a page that does not exist is not a matter of taste, and it gets pasted into a live server at step 6.
    The job also guards the two ways these checks have already been fooled. If the build is not production-shaped, verify_redirects.py says STAGING and exits 0 — so the job greps for the word PRODUCTION and fails without it. And the audit's headline passes trivially on a build containing no www.traveller.org references at all, which is what happens when SITE_URL is unset — so the job also fails if the self-reference count comes back near zero, where a real build has over a thousand. Both failure modes were reproduced deliberately before the job was trusted.
    What is left for you: nothing, unless it goes red. If it does, the run summary prints both scripts' full output, and the fix belongs in the repository rather than the dashboard.

Stage 4 — Cutover day

13. OWNERDone 19 Aug Point the domain at Cloudflare.
    
    Nameservers are hostnames, not IP addresses, and Porkbun's nameserver field takes hostnames. If you are looking at a box that wants an IP, you are in the A-record or glue-record screen — back out. Nothing in this step types an IP address anywhere.
    And no one can print the pair here in advance, including a session. Cloudflare assigns two nameservers per zone, drawn from a large pool, at the moment the domain is added — they look like amy.ns.cloudflare.com and bob.ns.cloudflare.com but the two words are yours alone. Copying a pair from any documentation, including this page, sends the domain to nameservers that are not authoritative for it and the site goes dark. Step 13a is where yours appears; use those two and nothing else.
    Before any of it: press Publish and let the Pages build finish. The live host serves the production branch, and the post-cutover redirect machinery (step 18) only exists on it after a publish — the 100-rule discovery of 2026-08-18 was made on the deployed site, and the fix reaches it the same way. Then ask a session to re-verify the three legacy URLs on traveller-org.pages.dev before 13c; they must 301 or forward, not 404.
    This step is five screens, in this order. The first is the one the runbook used to skip, which is why "the pair Cloudflare gives you" had nowhere to come from:
    
    1. 13a — Add the domain to Cloudflare. Cloudflare → Add a domain → type traveller.org → choose the Free plan. Cloudflare then scans Porkbun's existing DNS and imports what it finds. This changes nothing yet — the domain keeps resolving through Porkbun until 13c.
    2. 13b — Check the imported records before you go further. On the DNS screen Cloudflare shows what it copied. The MX records are the ones that matter: mail follows DNS, and between this step and step 15 your email must keep flowing to InMotion exactly as it does now. If the scan missed them, add them by hand from Porkbun's DNS page before continuing. A missing A or CNAME costs a page; a missing MX costs mail.
    3. 13c — Copy the two nameservers Cloudflare shows you, then at Porkbun → Domain Management → traveller.org → Authoritative Nameservers (some accounts label it NS) → replace both existing entries with Cloudflare's two → Save. This is the moment the switch is thrown.
    4. 13d — Tell Cloudflare to look. Back on the Cloudflare overview, press Check nameservers now. The zone flips from Pending to Active when the change has propagated — usually minutes, occasionally an hour or two.
    5. 13e — Point the site at the domain. Only once the zone is Active: Cloudflare → Workers & Pages → traveller-org → Custom domains → add www.traveller.org, then add traveller.org. Cloudflare creates the records and issues the certificates itself.
    Why nameservers and not just an A record at the new IP? Because there is no "the new IP". traveller-org.pages.dev answers on 172.66.44.108 and 172.66.47.148, and those are Cloudflare's shared edge, not this site's address. The edge decides what to serve from the hostname, not the IP — so an A record pointing at it serves your visitors nothing until Cloudflare has been told that hostname belongs to this project, and the only place to tell it is the Custom domains panel above, which needs the zone in the account.
    Demonstrated 2026-08-18, not assumed. One TLS connection to that exact address, asked twice, differing only in the hostname:

    • traveller-org.pages.dev → 200, the site
    • www.traveller.org → 403 Forbidden, from server: cloudflare

    That 403 is what every visitor would get. Three more reasons stack on top: the apex cannot be a CNAME (DNS forbids it alongside the zone's own SOA and NS records — Cloudflare only gets away with traveller.org by flattening it, which requires hosting the zone); no certificate — Cloudflare issues the padlock for a custom domain once it is attached, so an A record alone fails TLS before it ever reaches the 403; and those addresses are Cloudflare's to change, so a hand-copied A record is a bomb on a timer.
    And even if all of that were solved, the cutover would stall one step later: steps 14, 15, 16 and 20 need the zone in the Cloudflare account regardless of how the website itself is reached.
    Done when: the Cloudflare zone reads Active, both custom domains are attached, and https://www.traveller.org shows the new site with a valid padlock. Certificates can take a few minutes.
    A session can confirm it in one probe — ask, and it fetches www.traveller.org and reads the response headers. Server: cloudflare with a CF-RAY means the request is being answered by Cloudflare; Server: Apache means it is still InMotion and the change has not landed yet. That is exactly how the pre-cutover state was established on 2026-08-18. What a session cannot do is read the nameserver records themselves: cloudflare-dns.com and dns.google both answer 403 on CONNECT from the sandbox, so the authoritative check on the NS pair is Cloudflare's own Active badge.
    This is the irreversible-feeling step, and it is not — but the fast way back is not the obvious one.
    To roll back, edit the records in Cloudflare, do not revert the nameservers. Once the zone is Active, Cloudflare answers every query for traveller.org, so pointing www and the apex back at InMotion's address (216.194.165.246, the value they resolve to today) takes effect within the record TTL — minutes: Cloudflare serves proxied records with a ~5-minute TTL of its own, and the records its scan imported carry the 600 seconds set in step 9. Reverting the nameservers at Porkbun instead means waiting on the .org registry's delegation TTL, which is not yours to set and is commonly a day: resolvers that have cached the delegation keep asking Cloudflare regardless of what Porkbun now says. Same intent, two very different clocks.
    Step 9's 600-second TTL is what keeps the record clock short, which is the one you control.
    This is also the step that unlocks the rest of the day. Everything from here needs the zone to be in the Cloudflare account, and nothing could be done before it: the R2 custom domain (step 14), Email Routing (15), Resend's records for Gmail send-as (16) and Zero Trust on /admin/ (20) all require it.
    What actually happened, 2026-08-19. The zone went Active and both custom domains attached without trouble; www.traveller.org answered server: cloudflare with a CF-RAY, serving the new site, and the live home page counted the same 60 countries as the data. One thing broke, and it was not the website.
    The import at 13b copied the MX record and Cloudflare orange-clouded what it pointed at. The apex MX read traveller.org MX 0 traveller.org — aimed at the apex, which is proxied — and the orange cloud carries HTTP and HTTPS only. A proxied name resolves to Cloudflare's edge, which does not speak SMTP, so inbound mail had nowhere to land. Nothing in the dashboard says so; the record looks fine.
    The repair, applied the same day: an A record mail → 216.194.165.246 set DNS only (grey cloud), the apex MX re-pointed at mail.traveller.org, and cpanel and ftp greyed for the same reason. Confirmed from a session: mail.traveller.org answers server: Apache with no CF-RAY — the grey cloud is working — while www answers as Cloudflare.
    The rule to carry forward: anything that is not a web page must be grey. Mail, cPanel, FTP, SSH. 13b's advice to check the MX records was right and not enough — it is not whether they were imported, it is whether their target is proxied.
14. OWNERDone 19 Aug Give R2 a custom domain.
    
    Set, but not yet visible on the live site (2026-08-19). images.traveller.org is attached to the bucket and works, and the owner reports PUBLIC_R2_BASE changed — but the live build still asks for every photograph from pub-….r2.dev. A variable is read at build time only, so the site keeps the old value until a build runs having seen the new one. The same symptom sits on step 18's Turnstile keys, from the same cause — which is what makes this one build problem rather than two variable problems. Nothing is broken meanwhile: both addresses serve the same bucket.
    Needs step 13 done first — R2 attaches a custom domain only for a zone already in this Cloudflare account, which traveller.org's becomes the moment the nameservers move. Confirm it in one click before starting: left sidebar → Domains must list traveller.org. (Until then + Add has nothing to offer you — which is why this step is here and not up in Stage 1.)
    Not urgent, and nothing is broken while it waits. The site keeps serving every photograph from the pub-….r2.dev address set in step 1. If mail needs attention first, do step 15 and come back — the two do not depend on each other.
    Cloudflare → R2 Object Storage → traveller-images → Settings → Custom Domains → + Add → images.traveller.org. It is the first panel on the Settings page, above the fold, and while it is empty it reads "There is no custom domain assigned to this bucket."
    
    Do not confuse it with "Public Development URL", the panel directly below — and do not press Disable there. That panel holds https://pub-d86b555b7dd7462abd871c743192bcd6.r2.dev, which is the value PUBLIC_R2_BASE is set to right now, so disabling it breaks every photograph on the site the moment it is clicked. Searching the page for "public" lands on that panel and not on the one you want. Cloudflare's own warning under it — rate-limited, not recommended for production, Access and Caching unavailable — is the whole reason this step exists. It stays enabled until PUBLIC_R2_BASE has been switched over and a redeploy has proved the new name works.
    Done when: a photograph opens over that name, e.g. https://images.traveller.org/thumbs/vietnam/2009/halong-bay/…any file listed in the bucket — and Pages → traveller-org → Settings → Environment variables has PUBLIC_R2_BASE changed from the pub-….r2.dev address to https://images.traveller.org, with a redeploy so the build picks it up.
    Change PUBLIC_R2_BASE after the custom domain resolves, never in the same sitting as adding it — between the two, every photograph on the site is being served from a name that may not have propagated, and the Pages build cannot tell you that. Add the domain, open a photograph over it in a browser, and only then edit the variable and redeploy.
    Dashboard wording, verified 2026-08-18: this used to say Public access → Connect Domain. There is no "Public access" section on the Settings page today; the control is Custom Domains → + Add, and "public" now names the development URL that must be left alone. Cloudflare renames these panels — if what you see disagrees with this step, that is a bug in this page, and saying so in a session gets it fixed in the same push.
    This step used to be number 2, sitting in Stage 1 — Now among things that can be done today, with a warning that it could not actually be started for another twelve steps. The owner called that wrong and asked for it to be moved (2026-08-18): a runbook whose order is not the order you do things in is not a runbook. It now sits directly after the step that unlocks it.
15. OWNERDone 19 Aug Move the email forwarders to Cloudflare.
    
    “Existing non-Cloudflare MX records conflict with Email Routing.” This is the error the first attempt got (2026-08-19), and it is worth knowing what it means before you start, because the obvious suspect is the wrong one.
    It is not Resend. Email Routing manages the MX for the apex and nothing else. Resend's MX lives on send.traveller.org — a different hostname, which Email Routing neither reads nor cares about. Do not delete it: it is Resend's bounce and complaint return path, and removing it breaks sending, which is the half you are keeping.
    The conflicting record is the apex MX 0 mail.traveller.org — the one written at step 13 to repair inbound mail while it was pointed at a proxied name. That was right then and it is exactly what Email Routing replaces now. Delete the apex MX, then press Activate; Cloudflare writes its own three route1/2/3.mx.cloudflare.net. Leave the mail A record alone — it is not an MX, and it is how you reach cPanel and webmail afterwards.
    Do not let the wizard replace your SPF record. Onboarding offers v=spf1 include:_spf.mx.cloudflare.net ~all for the apex. You already have an apex SPF covering InMotion's sending; accept the offer as written and InMotion's mail stops passing SPF. Merge the two into one apex TXT — every include you have plus Cloudflare's, one ~all at the end — and edit the record by hand afterwards if the wizard has overwritten it. The InMotion include comes back out at step 24, when that plan is cancelled.
    Two more records on the apex are inert and can stay or go: a v=DMARC1 TXT (DMARC is only ever read at _dmarc.traveller.org) and a v=DKIM1 TXT (DKIM is only ever read at <selector>._domainkey). Neither does anything where it sits. That the DMARC one is inert is lucky rather than fine: it asks for strict alignment, which Resend's send. return path would fail if anything ever read it.
    Today InMotion forwards eight @traveller.org addresses to Gmail. The moment the nameservers change, mail follows DNS — so this step happens the same day, right after step 13. Cloudflare → the traveller.org zone → Email → Email Routing → Get started:
    • Add both destination addresses — brarob@gmail.com and reynaldh@gmail.com. Cloudflare emails each one a verification link; both must be clicked before any rule can point at them.
    • Recreate the forwarders as custom addresses: brarob, brobinson, dns, hiole, privacy, support, theboys → brarob@gmail.com, and reynald → reynaldh@gmail.com. Add dmarc → brarob@gmail.com alongside them — it is not one of InMotion's eight, but step 17's reports are sent to it and bounce without it.
    • theboys@ goes to both inboxes today, and a Cloudflare rule forwards to one destination only — so its rule is different: set the action to Send to a Worker → traveller-email. That Email Worker is already written and deploys itself (cloudflare/email-worker.js); it hands the same message to both Gmail inboxes. It still needs both destinations verified first.
      Where the two addresses actually are, since the routing rule does not show them. The rule says only “hand it to traveller-email”; the Worker decides where it goes, from a list in its own code:
      • To read them: Workers & Pages → traveller-email → the code view. The line reads const INBOXES = […], near the top.
      • To change them: edit cloudflare/email-worker.js in the repository and push — it redeploys itself. Not in the dashboard editor: that works until the next auto-deploy overwrites it. Asking in a session is the short way.
      • The one screen that does list them: Email Routing → Destination addresses. Both must read Verified — forward() refuses an unverified destination, so an unverified inbox means theboys@ quietly reaches one person instead of two. Check it here before activating.
    • Set the catch-all to brarob@gmail.com, so an address missing from this list still lands somewhere instead of bouncing.
    • When Cloudflare offers to replace the MX records, accept — that is the moment mail stops flowing through InMotion.
    Done when: a test email sent from an outside account to each address arrives in the right Gmail inbox — and a test to theboys@ arrives in both.
    Why here and not Porkbun or Resend: Porkbun's free forwarding only works while the domain uses Porkbun's nameservers, which it no longer does after step 13; Resend only sends mail, it cannot receive or forward it. Email Routing is free, unlimited, and lives in the dashboard the DNS just moved to. Sending from the domain is the next step.
16. OWNERDone 19 Aug Keep sending as @traveller.org from Gmail.
    Replying as brobinson@traveller.org (or any address on the domain) must not depend on InMotion's mail server. Resend takes over as the outgoing relay — the domain is already verified there, because the import emails send from pipeline@traveller.org:
    • First confirm the move of DNS carried Resend's records: resend.com → Domains must still show traveller.org as Verified. If it does not, add the DNS records it lists to the Cloudflare zone — they came from InMotion's DNS and Cloudflare's import usually copies them across.
    • Create a second API key at resend.com → API Keys, named something like gmail-smtp. Do not reuse the pipeline's key — separate keys mean rolling one never breaks the other.
    • Gmail → Settings → Accounts and Import → Send mail as → Add another email address. Name as you like, address brobinson@traveller.org. SMTP server smtp.resend.com, port 587, username resend, password = the new API key, TLS.
    • Gmail emails a confirmation code to brobinson@traveller.org — it arrives in brarob@gmail.com through the forwarding set up in step 15, which is why this step comes after it.
    • Repeat the “Send mail as” entry for any other identity wanted (brarob@traveller.org, support@…) — the same SMTP credential serves them all.
    Done when: a mail sent from Gmail with the From set to brobinson@traveller.org arrives showing that address — not “via gmail.com” — and lands in the inbox, not spam.
    “Why not just use smtp.gmail.com for all of them?” (owner, 2026-08-19 — the honest answer is longer than the old one here, which is why the question kept coming back.)
    It sends. The mail leaves, arrives, and looks right in your Sent folder. What it does not do is prove it came from traveller.org. Sent through Google's servers, the mail is signed d=gmail.com and its bounce address is your gmail.com account — so SPF and DKIM both authenticate gmail.com, while the From line says traveller.org. DMARC's whole test is whether those two agree, and here nothing authenticates the domain in the From line. Through Resend the message is DKIM-signed d=traveller.org, which is the same thing said properly.
    Three consequences, in the order you would notice them:

    • Gmail recipients see “brobinson@traveller.org via gmail.com” in the header. For a domain whose whole point is that the mail is from you and not from a free account, that line undoes it.
    • Strangers' filters treat it worse over time. Nothing rejects it outright today, because traveller.org publishes no enforcing DMARC policy. Outlook, Yahoo and corporate filters weight an unauthenticated From-domain heavily, and the direction of travel since 2024 has been one way.
    • It forecloses the next step. Publish the DMARC record in step 17 and Gmail-sent mail claiming to be traveller.org starts failing your own published policy. You would be choosing, permanently, between protecting the domain and sending from it.

    It may not even be offered: the “Send through Gmail” option is a Workspace feature, and a free Gmail account adding an address on a domain it does not host is generally sent straight to the SMTP form. Resend costs one paste of an API key, and the domain is already verified there because the pipeline sends from pipeline@traveller.org. Free tier: 100 emails a day, shared with the import notices — plenty.
    If one address sends and another does not, with “the same settings” (owner, 2026-08-19: theboys@ and hiole@ worked, brobinson@ did not) — Gmail stores the SMTP server per address, not once per account. The screen that lists them shows only the address, so three entries can look identical and be pointed at three different servers. An address you set up years ago against InMotion keeps InMotion's server and password until you change it, and mail.traveller.org still resolves, so the failure is a credential error rather than an obvious one.
    Check it: Gmail → Settings → Accounts and Import → Send mail as → edit info beside the failing address → Next → read the SMTP Server box. Anything that is not smtp.resend.com on port 587 with username resend is the bug; retype it and re-send. If it already says Resend, the next suspects are an address showing (unverified) in that list — Gmail will not send as an address whose confirmation code was never clicked — and an API key created with sending access scoped to one domain.
17. OWNERDone 19 Aug Publish a DMARC record — monitor only.
    With Email Routing receiving and Resend sending, the domain finally has a settled list of who is allowed to send as it. DMARC is the record that says so, and tells you who else is trying. One TXT record in the Cloudflare zone:

    Type	Name	Content	TTL
    TXT	_dmarc	v=DMARC1; p=none; rua=mailto:dmarc@traveller.org; fo=1	Auto

    • p=none is deliberate. It changes what happens to nobody's mail; it only asks receivers to report what they saw. Read a few weeks of reports, confirm everything legitimate passes, and only then consider p=quarantine. Starting at enforcement is how a forgotten sender — a booking site, an old form, a mailing list — disappears into spam with no warning.
    • Leave the alignment flags off. Omitted, they default to relaxed, which is what this domain needs: Resend's return path is on send.traveller.org, a subdomain, and relaxed alignment accepts that while strict would fail it. The old apex record carried adkim=s; aspf=s — do not copy them across.
    • Delete the old apex v=DMARC1 TXT at the same time. DMARC is only ever read at _dmarc, so the apex copy has never done anything; leaving it there invites a future tidy-up that copies its strict flags onto the real record.
    • dmarc@traveller.org has to exist, or the reports bounce. Add it as a custom address in step 15's list, forwarding to brarob@gmail.com. Keep the address on traveller.org — pointing rua at a gmail.com address instead requires Gmail to publish an authorisation record for this domain, which it does not, so most senders would silently refuse to report at all.
    • Expect volume, and do not read them by hand. Daily XML from Google, Microsoft, Yahoo and anyone else who received mail. A filter into its own label is enough; the reports matter in aggregate, not one by one.
    Done when: _dmarc.traveller.org answers with the record (any DNS lookup tool), the apex copy is gone, and within a few days a report has arrived at dmarc@.
    Why now and not at the start: DMARC is a claim about who may send as the domain, and until step 15 and step 16 were done that list was still changing. Publishing it earlier would have been publishing a claim that was about to become wrong — and it is the record that makes the Gmail-SMTP shortcut in step 16 permanently unusable, so it is placed after the decision it forecloses rather than before it.
18. OWNERDone 20 Aug Switch the contact form on.
    
    Done 2026-08-20. The live page carries the real data-sitekey, the Turnstile script and the live endpoint, and the contact Worker answers past its own secret check. It came right a day after it looked broken, and the reason is worth keeping: the page the owner was testing was staging, whose build carried neither key and therefore drew the display-only form — a grey “Test build” line and a picture of a checkbox — while the live site had been sending all along. Staging now builds with both keys too, so the two agree.
    If it ever looks dead again, the checks below still apply, and the first of them is now: which site am I on?
    The one-line check, from any browser: open https://www.traveller.org/contact/, view source, search for data-sitekey. Empty means the build had no key, whatever the dashboard shows. Then, in order:

    • Is the panel showing Production? Variables are kept per environment and the panel has a Production/Preview switch at the top. A variable added under Preview is invisible to the live site and looks entirely present.
    • Is the name exactly PUBLIC_TURNSTILE_KEY? Case-sensitive, no trailing space. Astro only substitutes a variable whose name starts with PUBLIC_, and an unrecognised name is not an error — it is an empty string.
    • Did the newest deployment succeed? On a failed build Cloudflare keeps serving the last good one, so the site looks unchanged and healthy. Deployments → the top entry should be green and newer than the moment you added the variables.
    • Was it a redeploy or a rollback? Retry deployment builds again and reads the variables; Rollback re-serves an old build and does not.

    The same symptom is on step 14's PUBLIC_R2_BASE, which is the useful clue: two unrelated variables both missing points at the build, not at either variable.
    The form and its CAPTCHA are built and deployed; they are dormant until these keys exist.
    • Cloudflare → Turnstile → Add widget. Name it traveller.org contact, hostnames traveller.org and www.traveller.org, widget mode Managed. It gives you two keys.
      Add brarob100.github.io to that list as well (the widget → Settings → Hostname Management → Add). The staging site builds with the same public key since 2026-08-20, so the form works there too — but Turnstile renders only on hostnames the widget names, and on any other it draws nothing at all. That empty space is indistinguishable from a broken key, and it is neither.
    • The site key is public: it goes on the Pages project as an environment variable. Add PUBLIC_TURNSTILE_KEY, and alongside it PUBLIC_CONTACT_URL = https://traveller-contact.brarob.workers.dev. Then redeploy — a variable on its own changes nothing until a build reads it.
      “Where is the Pages area?” (owner, 2026-08-19). There is no menu item called Pages on its own, which is what makes it hard to find: Pages projects and Workers share one list. Use the link, not the sidebar — dash.cloudflare.com → Workers & Pages resolves to that list whatever the nav happens to be called this month (it has been Workers & Pages, and Compute with the projects inside it). traveller-org is the entry tagged Pages, not the traveller- Workers beside it.
      From there: Settings → the variables panel — labelled Variables and secrets or Environment variables depending on the week. Two things to get right on that screen:

      • Add them under Production, not Preview. The panel keeps a separate set for each, and a variable added to Preview is invisible to the live site while looking entirely present.
      • Nothing happens until a build runs. Variables are read at build time, so the live site keeps the old values until you go to Deployments, open the three-dot menu on the most recent production deployment, and choose Retry deployment. Pressing Publish also works when there is something new to publish; retrying does not need there to be.

      While you are on that screen, step 14's other half is the same panel: change PUBLIC_R2_BASE from the pub-….r2.dev address to https://images.traveller.org and one redeploy finishes both.
    • The secret key is not: Cloudflare → Workers & Pages → traveller-contact → Settings → Variables → add TURNSTILE_SECRET (encrypted), and RESEND_API_KEY — a third Resend key, its own, so rolling it touches neither the pipeline nor Gmail.
    Done when: you send yourself a message from https://www.traveller.org/contact/ and it arrives in your inbox — and hitting Reply addresses it back to the address you typed, not to the form.
    Two ways to test this and get a wrong answer.
    Wait for the build before testing at all. Setting the variables does nothing to the live site; Cloudflare's own note (“active on next deploy”) is telling you it will not happen by itself. The signal that the build has landed is on the page: the grey line “Test build: the form is display-only” under the form disappears, and a CAPTCHA box appears. While that line is still there, nothing you type is being sent anywhere and the failure means nothing.
    Test on a hostname the widget lists — www.traveller.org or brarob100.github.io, not traveller-org.pages.dev. The Turnstile widget is bound to the hostnames in its Hostname Management. On any other name it refuses to render — which looks exactly like a broken key, and is not.
    And check which site you are on. Staging carried no contact keys at all until 2026-08-20, so its form was display-only while the live site's was working: the owner met the grey “Test build” line and an unclickable checkbox on brarob100.github.io and reasonably read it as a broken CAPTCHA on a form that was, on the live domain, already sending.
    Until both halves are set the form stays visibly display-only rather than pretending to send, and the Worker refuses with a message that never says which key is missing — a form that says "your message was sent" into a void is the one failure nobody would ever notice.
19. OWNERDone 19 Aug Check the three redirects again, now that the name points somewhere new. Same three URLs as step 8, but the machinery serving them is the new host's now, not InMotion's — and it is three different mechanisms, which is why all three URLs are worth re-opening rather than trusting one:
    • /journal/?p=15 — the journal index resolves the WordPress post id with a script, because Pages redirects cannot see a query string.
    • /cuba/1996/varadero/ — a pre-rendered forwarding page at the old address, one of 172 the build writes for every exact old URL.
    • /currency/thai-notes-20.html — a forwarding page too; the wildcard rules in _redirects cover only the ~4,600 photo wrapper pages, whose filenames cannot be enumerated.
    Done when: all three land on the right page.
    Why forwarding pages and not one _redirects file (2026-08-18): the deployed Pages host was observed honoring exactly the first 100 rules of that file and silently dropping the other 125 — rule 100 fired, rule 101 did not, bisected live against traveller-org.pages.dev, with no bad byte at the boundary. Every plain gallery URL was in the dropped half, so they would have 404ed the moment DNS moved, with every build green. Cloudflare's documentation permits far more; the site is built to the limit that was observed, with a guard in build_redirects.py that refuses to emit more than 100 rules and a suite (tests/redirect-stubs.test.mjs, also in the Cutover checks job) holding every exact old URL to having its forwarding page.
20. OWNERDone 19 Aug Confirm search and answer engines are switched on.
    Open https://www.traveller.org/robots.txt, then https://www.traveller.org/llms.txt.
    Done when: robots.txt does not say Disallow: /, and every link in llms.txt names www.traveller.org, not the old test address. The staging site blocks indexing and writes test-host links; a production build drops both automatically. If either survives, the build did not pick up SITE_URL.
    The pair travels together because one variable drives both: robots.txt is what lets Google in, and llms.txt / llms-full.txt are what AI answer engines read. AI crawlers are deliberately not blocked — the Pipeline page has the whole LLM-and-search inventory, including what is deliberately not built.
21. OWNERDone 20 Aug Lock the admin door.
    In the Zero Trust dashboard: Access controls → Applications → Add an application → Self-hosted. That opens Create new self-hosted application, which is four things on one long page.
    1. Destinations → Public hostnames. Three boxes: Subdomain, Domain, Path. Put www in Subdomain, choose traveller.org as the Domain, and type admin in Path.
       The Subdomain box is the one that catches people. Left empty it protects traveller.org/admin and not www.traveller.org/admin — and www is where the site actually lives, so the door would look configured and guard an address nobody uses. Add a second public hostname with the Subdomain empty if you want the apex covered too; it costs nothing and closes the back way in.
    2. Access policies — the panel that says No policy associated. This is the step that cannot be skipped: without a policy the application protects nothing. Create new policy → name it something like Owner only → Action Allow → under Include choose the selector Emails → save. Back on the application, the policy now appears in the list.
       More than one person. Three ways, and which to use depends on how often the list will change:

       1. Several addresses in the one selector. The value field takes more than one: type an address, press Enter (or a comma) and it becomes a chip, then type the next.
       2. Several Include rows. If that field will only hold one, press + Add include and add a second Emails selector. The effect is identical.
       3. A reusable list, once the names outlast the afternoon: Reusable components → Lists → create one of type Emails and put everyone in it, then point the policy's Include at the list instead of naming addresses. After that, adding or removing somebody is one edit in one place, and the next application you protect can reuse it.

       The shape, which outlasts the labels: Include rows are ORed, and so are the values inside one of them — any address that appears anywhere in Include gets in. If the wording on your screen differs from the wording here, that sentence is what you are looking for.
       Two things before you add anybody. Every address on the list has to be a real inbox somebody reads — Cloudflare mails the one-time PIN to whatever is typed at the login screen, and the code only works if that address is on the list.
       And this is not a read-only door: it opens the whole of /admin/, including Publish and the upload pages. Anyone you add can put the site live. Keep the list to people you would give the repository to.
    3. Authentication — leave Accept all available identity providers switched on and add nothing. With no identity provider configured, Cloudflare falls back to its built-in one-time PIN: the visitor types their email, Cloudflare sends a code, and the code lets them in if the address is on the list. That is the login this step promises, and it needs no setup at all.
    4. Details — the Name box auto-fills to traveller.org; change it to something you will recognise in a list, like traveller.org admin. Session Duration 24 hours is fine. Then Create.
    Done when: an incognito window at https://www.traveller.org/admin/docs/ asks for an email and a code before showing this manual — and your own browser, already signed in, still opens it normally. Both held on 2026-08-20: an anonymous request is 302'd to the one-time-PIN login, the JSON feeds the pages read stay public, and the owner signed in with the code the same day.
    Decided 2026-08-18 (this used to say "optional"): the admin pages and this manual hold no secrets, but there is no reason for them to be public on the live domain when one free login screen closes them. Two boundaries this deliberately does not move: staging stays public-but-unlisted on github.io — a GitHub Pages site cannot take a login, and moving staging behind one was offered and declined; and Access covers only this hostname, not the Worker's own address at traveller-upload.brarob.workers.dev — nor www.traveller.org/api/*, where the same Worker is routed (since 2026-08-20) so the admin pages can call it on their own domain. Putting Access in front of either breaks every interactive admin page, which is the fault this route was added to end (2026-08-20). Its door is the passphrase — which is why that gate rate-limits failed attempts (about ten wrong tries a minute, then a one-minute wait; the Pipeline page has the details). Remember that robots.txt and noindex keep pages out of searches, not away from visitors — they are politeness, not locks.
    This step used to be three lines — "add an application covering www.traveller.org/admin* with an email allow-list of one" — which describes the outcome and not the screen. The owner reached the create form and could not get past it (2026-08-19): the form asks for a subdomain, a domain and a path as three separate boxes, and the policy that does the actual work sits in a panel further down that reads No policy associated and is easy to read as a status rather than a task. Both are written out above now. Same lesson as the Pages panel and the Shortcuts variable strip: name where the control is, not just what it achieves. It was still short an hour later: the rewrite said “add any others on separate lines”, describing a text area the form does not have, and the owner asked how to list more than one address. The lesson generalises past labels — describe the semantics a reader can verify on whatever screen they have, which here is that Include rows are ORed.

Stage 5 — After

22. OWNERDone 22 Sept Tell Google the site moved.
    Search Console → add https://www.traveller.org as a property if it is not already → submit https://www.traveller.org/sitemap.xml.
    Needs step 4 done first — until the sitemap is built, that address 404s and this step cannot be completed.
    Done when: the sitemap reads as Success.
    The old site's sitemap lived at exactly this address, so Google already knows it — the new one is served under the same filename and gets discovered on its own. Submitting is confirmation, not introduction.
    Marked complete by the owner, 2026-09-22 (“Item 22 complete”). The Search Console side is theirs to see; the crawler probe and the indexing report on the pipeline page are what a session can check.
23. OWNERDone 22 Sept Leave InMotion alone for a month.
    Nothing depends on it any more — every image it once served has been copied into the repository, and email moved to Cloudflare in step 15 — but the 301s living there still catch anyone reaching the old server directly by IP or an old hostname.
    Done when: a month has passed, search traffic looks normal, and forwarded email has been arriving all the while.
    Marked complete by the owner, 2026-09-22 (“Item 23 looks good. mark as complete”) — a month and three days after the 2026-08-19 cutover, with search traffic and forwarded mail both normal on their side. Step 24, cancelling the plan, is the next one and stays open until they say so.
24. OWNERDone 25 Sept Cancel the InMotion plan.
    Before you do, take a full backup (cPanel → Backup → Download a Full Account Backup) and keep it. The repository already holds the crawl, but the backup has the WordPress database, which the crawl does not. Email is already off InMotion (step 15), so cancelling ends only the old web server.
    Three things come out with it, none of them automatic:
    • The InMotion include in the apex SPF record — step 17 left it in deliberately and named this step as where it goes. A cancelled host that is still authorised to send is the worst of both.
    • The DNS records that point at it: mail and cpanel are grey-clouded A records in the Cloudflare zone aimed at InMotion's server, and they are the reason those two names still hold a certificate. Once the plan ends they aim at nothing.
    • The 393 redirects stop, because they live in that server's .htaccess. That is the whole of what “the redirect overlap” means; decide it is over before pressing cancel, not after.
    Done when: the backup is downloaded, the plan is cancelled, and the SPF include and the two DNS records are gone.
    Cleared to go, 2026-09-24 (you asked “can I now cancel the plan?”). Yes: step 23’s month is done, step 25 is done, and nothing on the site reads from InMotion any more. The order is the one above — backup first, then cancel, then the DNS clean-up at the zone’s DNS records (the zone, not the account). One correction to the list: the “Where the domain stands today” table records three grey-clouded records at InMotion’s address — mail, cpanel and ftp — so delete all three, and edit the apex SPF TXT to drop only the InMotion include, keeping Cloudflare’s. This session cannot read public DNS, so it could not check the live records for you; the zone’s own list is the one to believe. Say when it is done and the step, the table and DMARC’s next move get updated together.
    Marked complete by the owner, 2026-09-25 (“Runbook Item 24 is complete. I have the site backup”): the full account backup is downloaded and kept, the plan is cancelled, and with it the last step of the cutover. The backup’s database is the only remaining copy of the two letters that resisted migration — see the open list at the top. This session cannot read public DNS, so the removal of the three records and the SPF include is recorded on the owner’s word.
    The two journal entries that resisted migration are only recoverable from that database, so this backup is the last chance at them.
    Until this is done the host is not merely idle — it is still sending mail as the domain. Step 29 stopped the stream of it; only cancelling ends the capability. That is also the precondition for moving DMARC off p=none, which is why the two are written down together.
25. OWNERDone 24 Sept Raise the DNS TTL back to an hour or a day, now that nothing is going to change suddenly.
    In Cloudflare, not at Porkbun — the zone moved at step 13, so Porkbun's DNS panel no longer feeds anything. Cloudflare → the traveller.org zone → DNS → Records. (Records left Proxied show TTL as Auto and need no change; the setting only applies to unproxied records.)
    Done when: Cloudflare shows the longer TTL. This is housekeeping; nothing breaks if it is forgotten.
    Marked complete by the owner, 2026-09-24 (“runbook step 25 complete”).
26. OWNERDone 24 Sept Open every tier of Cloudflare’s crawler controls — Search, Training and Agent all Allow (your call, 2026-09-16: “lean into being indexed”).
    Cloudflare → select the traveller.org zone first (the controls are per-domain; the account page does not have them) → Security → Settings, the page Cloudflare’s 2026-09-15 email calls Security Settings. The page is headed Security — Manage how AI crawlers access your content, and there are two layers on it, both of which have to say Allow (you walked this on 2026-09-16):
    (a) The policy. Configure AI bot policies opens a sheet with three drop-downs — Search, Agent, Training — set each to Allow (do not block) and Save. Leave Enable Bot Preference Sync off: it prepends Cloudflare’s own directives to the site’s robots.txt, and the probe below treats any such line as a refusal. (Done 2026-09-16 — the probe run straight after showed Meta-ExternalAgent and PetalBot, blocked before the save, getting through.)
    (b) The per-crawler toggles. Below the policy is a table of every crawler Cloudflare has seen (tick Show inactive crawlers to see them all), each row ending in a Block Crawler switch. These are separate blocks layered on top of the policy — the policy saying Allow does not turn them off, and the probe run after the policy save still found GPTBot, ClaudeBot, CCBot, Amazonbot and Bytespider refused with every row’s switch still on. Switch off every one that is on. If a switch will not move and says it is controlled by the policy, reload the page: the policy has just changed.
    Done when: the Crawler probe workflow (Run workflow, then open the run’s summary) reads every identity is let in with a 200 on every row. It runs itself every Monday morning after that, and goes red if the setting drifts again.
    Done, 2026-09-24. You marked (a) complete and could not find the (b) table in your dashboard. It no longer matters: the probe was run from a session the same day and every identity — the five training crawlers the table used to block included — read 200 on both paths, with robots.txt the site’s own. That is this step’s whole test, so whatever switches that table held are no longer refusing anyone. Where Cloudflare now keeps the table, this session cannot say — it cannot see the dashboard, and the page has changed since you walked it on 2026-09-16. If the Monday probe ever goes red, that is the moment to look, starting from the same zone Security settings page.
    Found 2026-09-16, the day Cloudflare’s email announced the new controls: the edge was already refusing the whole training tier — GPTBot, ClaudeBot, CCBot, Amazonbot, Bytespider — with a bare 403, while every search-tier crawler got through. The manual had said no crawler was blocked since step 20, and that sentence was honest about what it had checked: robots.txt, which the repository builds and which was clean. Cloudflare decides before robots.txt is read, by user agent, and nothing in the repository can see that setting. Two consequences follow. Answer engines (ChatGPT search, Claude, Perplexity) were never affected — the search tier was open. Model training was: a page GPTBot cannot fetch is a page no future model simply knows, which is the half of “indexed in LLMs” the block was costing. The probe exists so the edge is asked, not assumed.
27. OWNERDone 22 Sept Add albums.traveller.org as a custom domain on the Pages project — the friends’ albums site (built 2026-09-22; your ask: every unlisted album in one place, behind the friends password).
    Workers & Pages → traveller-org → Custom domains → Set up a custom domain → albums.traveller.org. Cloudflare creates the DNS record and issues the certificate itself, exactly as it did for www and the apex at 13e; you type nothing at Porkbun and add no record by hand. No Cloudflare Access application is needed — there is no admin on this host, and the friends door is the Pages Function, which is already in front of it.
    Done when: https://albums.traveller.org/ answers with the friends sign-in (a 302 to /friends/, server: cloudflare); signed in as a friend, an unlisted album opens there by both spellings — /countries/<country>/<album> and with the trailing slash — and its country page and the home list it; and https://www.traveller.org/albums/ forwards to the albums host. Nothing changes before this step: the site’s pages carry the nav item and the tree from the first Publish after 2026-09-22, and the hostname simply does not answer until the domain is attached.
    One build, one Pages project, one Publish, one password — the albums site is the tree under /albums/ served on a second hostname by the same Function that guards www, with the door in front of everything on that host. A second Pages project (two deploys, two Publish flows, one set of data) was the alternative, and the reason it lost is in Addendum 364.
    What actually happened, 2026-09-22. You added the domain at 15:35 UTC and the panel opened a Verifying — Complete DNS setup sheet asking for a CNAME albums → traveller-org.pages.dev at “your DNS provider”, which read as a to-do. It was not one: the zone is at Cloudflare, so Cloudflare had already written the record itself — the certificate for albums.traveller.org was issued in the same minute and the edge answered on the hostname before the sheet closed. The sheet is what the panel shows for the minute or two before its own check catches up; nothing is typed at Porkbun, ever. Then you published, and the live site did not change for 27 minutes: the branch moved in seconds, Cloudflare’s build of it took the rest. That is the same publish that always took “about two minutes” before — so a Publish that has not landed after five minutes is slow, not broken, until the deployment list at Workers & Pages → traveller-org says otherwise. Verified from outside once it landed: / and an album path both 302 to /friends/, robots.txt is the tree’s (Disallow: /), www.traveller.org/albums/ 301s to the host, the friends’ data answers 401 without a cookie, and www’s nav carries the item.
28. OWNERDone 24 Sept Switch on asking-for-access at the friends door — two settings on the Pages project and one on the Turnstile widget (built 2026-09-22; your ask: “people that have forgotten their access can enter their name and email and request access from Bradley. I receive an email and can click approve, then the requestor gets an email with a button to open the friends site”).
    (a) Workers & Pages → traveller-org → Settings → Variables and secrets, environment Production, beside the FRIEND_KEY you set at the door’s launch — add two, both encrypted:
      RESEND_API_KEY — a new key made at resend.com → API Keys, the fourth on the domain (pipeline, contact Worker, DMARC Worker, and now the door), so this one can be rolled or revoked without touching the others.
      TURNSTILE_SECRET — the same secret the contact form uses (the traveller-contact Worker’s copy): the door’s card draws the contact form’s widget, whose site key already rides in the build as PUBLIC_TURNSTILE_KEY. Copy it from Cloudflare → Turnstile → the widget → its secret key (the Worker’s settings page does not show a secret back). This is not a second Turnstile key on the list: PUBLIC_TURNSTILE_KEY, already there, is the widget’s public half (the page draws the check with it) and stays as it is; TURNSTILE_SECRET is the same widget’s secret half (the Function verifies the check with it). One widget, two halves, both on the list — you asked exactly this on 2026-09-22 with both already added, so (a) was done.
    (b) On that same Turnstile widget → Hostname Management → add albums.traveller.org. The widget draws nothing on a hostname it was not told about, which reads as a broken card rather than a missing hostname; www.traveller.org is already listed from the contact form.
    (c) Press Publish (or say so in a session): Pages settings take effect on the next deploy, not when they are saved.
    Where it stands: (a) and (b) were done by the owner on 2026-09-22 — both secrets on the project, albums.traveller.org on the widget beside www and the apex (three hostnames, ten allowed). (c) is the next Publish; until it lands the card answers not switched on yet.
    Done when: www.traveller.org/friends/ and albums.traveller.org/friends/ both show the Need access? Ask Bradley line under the password form, which opens to a short form with the robot check drawn inside it; asking from it with your own name lands an email in your inbox headed … is asking for friends access; its button opens a page naming you; pressing Approve sends a second email whose button opens the site signed in. Until (a) is done the card answers “Asking for access is not switched on yet” — it never pretends to have sent.
    Why the Pages project holds copies rather than the door calling the contact Worker: the second email — the one to the friend — must be sent by the code that mints the enter link, and that link is sealed under FRIEND_KEY, which only the Pages Function has. Two secrets on the project is the whole cost; the alternatives are in Addendum 365.
    Tested and marked complete by the owner, 2026-09-24 (“runbook item 28 tested and functional. complete”): the whole round trip — ask, the email to you, Approve, the email to the friend, signed in by its button.
29. OWNERDone 22 Sept Stop the retired host emailing as the domain — exclude the dead names from AutoSSL.
    From 20 September 2026 the InMotion cPanel account began sending a notification every few hours, from cpanel@traveller.org, that could prove neither DKIM nor SPF. Gmail refused each one (550-5.7.26 … sender is unauthenticated), the bounces piled into your spam folder, and the DMARC Worker raised the alarm on each day's report. Nothing was spoofing the domain — it was our own half-retired host.
    The cause, in cPanel's own words (SSL/TLS → Status):
    DNS DCV: No local authority: “traveller.org”; HTTP DCV: The system queried for a temporary file at “http://www.traveller.org/.well-known/acme-challenge/…”, … responded with the following error: 404 (Not Found). … The domain “traveller.org” resolved to an IP address “104.21.2.180” that does not exist on this server.
    AutoSSL proves control by fetching a challenge file over HTTP at each name. Since cutover those names answer from Cloudflare, so the fetch never reaches InMotion, the renewal can never succeed, and cPanel reports the shortfall — forever, on a timer. It is not fixable in place: the only way to make the check pass is to point the domain back at InMotion, which is the thing cutover undid.
    What to do — cPanel → SSL/TLS → Status (reach cPanel at biz292.inmotionhosting.com/cpanel — mail.traveller.org is no longer a working way in, even though the name still resolves and still holds a certificate). Tick the eight failing rows and press Exclude Domains from AutoSSL: traveller.org, www, webmail, webdisk, cpcontacts, cpcalendars, autodiscover, autoconfig. Leave mail and cpanel included — they still resolve to InMotion, so they still validate, and they are the names the certificate is actually for. Then press Run AutoSSL once, rather than waiting for the next scheduled run to notice.
    Done when: the error blocks are gone, the excluded rows read a flat “The installed certificate does not cover this domain”, and mail/cpanel show a new expiry date — a reissued certificate, not a silenced warning. Then: no new bounces in spam within a day, and the DMARC alerts stop within two (the reports cover a window that has already closed, so one more alert after the fix is expected and is not a failure).
    Why exclude rather than repair. Two of the eight fail for a second reason worth knowing: webmail, webdisk, cpcontacts, cpcalendars, autodiscover and autoconfig do not resolve at all — those records were never recreated in the Cloudflare zone. Excluding them costs nothing, because no traffic for any of the eight has reached this server since 19 August.
    This stops the noise, not the capability. The host can still send mail as traveller.org that proves nothing; any other cPanel notification would fail identically. Only step 24 ends that — and until it does, the DMARC policy stays at p=none, because enforcement would fall on our own sender first. The reasoning is on the Pipeline page.

Done along the way

Work that finished outside the numbered steps, kept as the record.

• CLAUDEDone 13 Oct The admin on iPhone and iPad. The review fixed the clear defects first: edge margins, fields that made iOS zoom in, unstyled buttons, small tap targets, the menu opening the passphrase uploader, and the iPad uploader’s destination list. Of the six larger proposals you chose 1, 2, 3, 4 and 6 (“5 works on the iphone”): (1) the gold band is the phone’s account control, with no block repeating it; (2) admin pages on a phone drop the site’s section links from the header; (3, 4) an iPad uses the side menu at any angle, so the account block always sits in it and the tool starts near the top; (6) the phone’s menu offers only the phone uploader. What changed for you is on the phone manual page.
• OWNERCLAUDEDone 9 Oct Switch the admin from the passphrase to the Cloudflare sign-in (you asked, 2026-10-08, for brarob@gmail.com and reynaldh@gmail.com). Done 9 October: you confirmed reynaldh@gmail.com is in the traveller admin access group the admin application’s policy includes, added ACCESS_AUD_ADMIN and UPLOAD_KEY, and the Publish of 9 October (build 1acfa470) put the site’s half live. door-check said ON and the admin’s bar named your address. The phone page answered not found at first; that was fixed and published the same day (build b6c1a86b) and is open item 1’s check. Stage two is open item 1 too. What follows is the item as you worked it. On www.traveller.org, every admin page, the upload pages and the photo controls ask Cloudflare who you are instead of asking for the passphrase. Three settings turn it on, all in Cloudflare, and until they are in nothing changes — the passphrase keeps working everywhere, so there is no order in which this can lock you out.
  1. Reynald on the admin’s list. In the Zero Trust dashboard (account level — not inside a zone): Access controls → Applications, open the admin application (the one on www.traveller.org/admin, not the guides one) and its policy. If reynaldh@gmail.com is not under Include already, add it there the way you added your own address at step 21 (Include rows are ORed — any address anywhere in Include gets in). The guides application already lists him (14 Sept); this repository does not record whether the admin one does. Remember what the list opens: the whole admin, Publish included.
  2. The admin application’s audience tag. In the same application: Configure → Additional settings → copy Application Audience (AUD) Tag — the path you walked for the guides on 3 Oct. Then on the Pages project’s settings → Variables and secrets → Add, environment Production: name ACCESS_AUD_ADMIN, type Text, value the tag. This also switches on the admin’s second lock, which the guides have had since 3 Oct.
  3. The passphrase, given to the site once. Same page, Add again, environment Production: name UPLOAD_KEY, type Secret, value the upload passphrase you use today — the same value the Worker holds. The site adds it to each call on your behalf; no page ever sees it again.
  4. Publish (or, if nothing is waiting, Retry deployment on the newest Production deployment at the Pages project’s deployments — a setting is read only by a new build).
  5. Check it: open www.traveller.org/admin/. The bar at the foot of the menu reads Signed in with Cloudflare as your address, and no page asks for the passphrase. The upload pages have new addresses behind the same sign-in: www.traveller.org/admin/api/ on a computer and www.traveller.org/admin/api/m/ on the phone — add the phone one to the home screen in place of the old icon. www.traveller.org/admin/door-check/ says ON and whose pass it checked. Tell a session what you see.
  If it shuts you out (a wrong tag makes the admin pages answer “This page is behind a sign-in”): delete ACCESS_AUD_ADMIN on the same settings page and Retry deployment, as for the guides. Until stage two, the test site’s admin still takes the passphrase, so Publish is reachable there throughout. Stage two, once you say it works: the passphrase comes off the web pages altogether — the test site’s admin points you to www (your choice: live site only), the old upload addresses forward to the new ones, and the Unlock the live site path retires. The iPhone Shortcut keeps its passphrase (your choice); it never used these pages.
• OWNERDone 9 Oct Store FRIEND_KEY as a secret (your report, 2026-10-09). It had been typed Text on the Pages project’s Variables and secrets, so its value showed on screen; you re-added it as Secret with the same value, so no friend was signed out and no link sent was voided.
• CLAUDEDone 9 Oct Zip records retired (you asked, 2026-10-09: “delete all zip files”; film originals: “keep nothing”). Imports and film conversions make no zips; the Zip records page and its nav entry are gone; the delete-zips run emptied zips/ in the bucket and the old zip addresses answer 404. Published 9 October (build b6c1a86b). How it works is on the Pipeline page.
• CLAUDEDone 25 Sept Give the old site’s uncrawled pages a target (you asked, 2026-09-25). The backup held 739 pages in the travel folders that the crawl never captured — 193 of them answering 404 that day, and all 316 of Philippines 2016. Every one now has a target, chosen by the same rules as the crawled pages: 270 photograph pages reach the album that holds that photograph by filename (191 old Palawan pages the El Nido album, 76 Peru 2010 highlights the Inca Trail), whole old albums reach their album or their country (Boracay its album; Cebu, not on the site yet, the Philippines page), Greece 1998’s wrappers the 1998 Mykonos album, and the Africa pages the country each is named for. The list is migration/backup-pages.txt; how it was made and how the rules work are on the Pipeline page. Folders that were never the travel site (portfolio, hiole, winequest, ebay, insurance, staging and a few small ones) stay 404, as decided. Live: it was on the site by the Publish of 1 October.
• CLAUDEDone 25 Sept Read the InMotion backup’s databases and file list. Both WordPress databases — the live journal (trave127_wrdp1) and its old staging copy (trave127_wp14) — hold 161 published letters, and every one is on the site, matched by id, each within 15% of its original length, with no longer earlier revision anywhere; the two letters this page once said had resisted migration are not missing. Also there: a 2024 draft page for an Almar Resort studio rental, two 2012 reader comments, and 24 media uploads the letters never used. The file list (184,383 entries) holds the old website and 124,340 files of old mailboxes — keep the backup for those alone. What it found is in the open list above.
• OWNERCLAUDEDone 25 Sept Move the photographs to images.traveller.org, and only then switch the r2.dev address off. The custom domain is attached and Active (your screenshot, 2026-09-24), but the live site still asks the bucket’s pub-…r2.dev address for every photograph, because PUBLIC_R2_BASE on the Pages project still names it — step 14’s unfinished half. Do not press Disable on the Public Development URL yet: it would break every photograph on the live site, and five admin pages, the staging workflow and the pipeline also have that address written in. The order: (1) a session moves those hard-coded addresses to images.traveller.org (ask for it); (2) you change PUBLIC_R2_BASE to https://images.traveller.org at Workers & Pages → traveller-org → Settings → Variables and secrets, Production; (3) Publish; (4) a session checks that the live pages ask for images.traveller.org and nothing asks for r2.dev; (5) then Disable, at R2 → traveller-images → Settings → Public Development URL.
  Where it stands: (1) done 2026-09-24 — the five admin pages, the staging build and the pipeline now ask images.traveller.org, checked first to serve the same bytes, the same etag and the same year-long cache rule as r2.dev. (2) and (3) done by you, 2026-09-25 — PUBLIC_R2_BASE changed and published. (4) done the same night, once Cloudflare’s build landed (00:42 UTC): the home page, an album, the country index, a country, the journal, the banknotes, the films and both friends doors ask images.traveller.org and nothing asks r2.dev; a sample photograph loads from the new host. (5) done by you, 2026-09-25: the Public Development URL is off — the old address now answers 401 while images.traveller.org serves photographs and thumbnails 200, checked the same hour. Step 14 is finished at last.
• OWNERDone 24 Sept Publish. Two things wait on it: the 21 photographs broken on the live site since this afternoon’s Rotate and Remove presses (Washington D.C. 1989, both Beijing albums — the files are gone and the live record still names them; a Publish drops them), and the live site’s /build.json, without which the new retired-file sweep deletes nothing (Addendum 375). From now on a Remove or Rotate leaves the live album as it was until you publish — never broken.
• Done 14 Sept The uploader has a plain address: upload.traveller.org (your call, 2026-09-14). Declared as a Worker custom domain in wrangler.toml and created by the deploy that already runs on every push — no dashboard, no hand-written DNS record, no credential in the conversation. Nothing was clicked, which is the point: the dashboard cannot do this. Adding it there puts you in Cloudflare’s Connect your domain flow — add-a-new-zone onboarding, which will not register a subdomain of a zone it already hosts — and it spins on “processing” and gives up silently, which is exactly what happened on 2026-08-20.
  Verified the minute it deployed: the name resolves to Cloudflare, / and /m both serve the uploader carrying that deploy’s own build stamp, /galleries answers 403 with no passphrase (the Worker itself talking), and the certificate verifies. The run was green on the first push, so nothing had to be added to the token. (Corrected 2026-11-11: this used to say the token “already carried” a DNS · Edit row. It does not — read off the token’s own editor that day, it holds Workers Routes and Workers Scripts only. The deploy created the custom domain without DNS permission.)
  All three addresses are live and none replaced another. www.traveller.org/api/ is still what the admin login should read, because it is the only same-origin one; traveller-upload.brarob.workers.dev still carries the iPhone Shortcut, so the Shortcut needs no change.
• Done 13 Sept A guide that publishes itself is now checked against a build first (found 2026-09-12, closed 2026-09-13: the sync rebuilds the site before it commits, and pushes nothing if the build fails, so a broken guide reaches neither the test site nor the live one). The history, kept because the failure was invisible rather than loud: When an app pushes only guide pages, the sync copies them in and publishes them without anyone looking. It asks whether anything else is waiting — it does not ask whether the site still builds. On 2026-09-12 one app wrote a date without quotation marks, the build failed, and because Cloudflare keeps serving the last good version, everything reported success while the new page answered “not found” for hours. The two causes are fixed (the reader is tolerant now, and the copy quotes as it goes), but the gap itself stands: the sync should build the site before it publishes, and hold if the build fails. It needs a fuller checkout than the sync currently takes, which is why it is a deliberate job rather than a quick patch. Until it is done, a broken guide page shows up as a page that 404s on the live site while every record says published.
• Done 14 Sept The guides shelf has its door — a second Access application on www.traveller.org/guides*, allow-list of two (you and Reynald), one-time PIN, created by you on 2026-09-14 and verified from outside the same day: the shelf and every page under it answer with the login, the public site is unaffected. The app addresses went onto the cards in the same change, which the door is what makes safe. The history, kept because the ordering mattered (deferred by you on 2026-09-05: the shelf went live open, unlinked and unindexed but readable by anyone with the address, and every guide is written as if public). The door is a Cloudflare Access application, and it locks the shelf with no change to the site. In the Zero Trust dashboard, Access → Applications → Add → Self-hosted: domain www.traveller.org, path guides (covers /guides/ and everything under it), one policy Allow with an email allow-list of just your address, one-time PIN as the login method — a second application, not a new path on the admin one, so its list can later take an app’s users without opening the admin to them (owner’s choice: just you for now, widen later). Then check that a private window asking for www.traveller.org/guides/ is answered with the PIN login, not the shelf. That rule — nothing private on the shelf until the door exists — held until 2026-09-14, and is why the addresses waited.) Separately, and not waiting on the door: the sync’s read token exists — you created it on 2026-09-05, under your own name for it, CENTRAL_DOCS_GIT_TOKEN (credentials table on the pipeline page) — so the nightly sync can read the app repositories.
• OWNER Give the guides door its second lock: the audience tag — steps 1–3 done by you, 3 Oct: the tag you copied matches the one Cloudflare puts in the guides sign-in redirect (checked from outside), and the shelf opens for you signed in. Only step 4’s proof page is left, after the next Publish. (Asked for 2026-10-01: “use the cloudflare authentication used on amapas353.com/admin on these traveller guides”). Why: the Access door stands on the address www.traveller.org, and the site also answers at its own Pages address, traveller-org.pages.dev, where no door stands — on 2026-10-01 traveller-org.pages.dev/guides/ served the shelf to anyone, every app address on it. Already closed, with nothing for you to do: from the next Publish, a request for /guides or /admin on any address but www is sent to www, where the door is. The second lock is the amapas353.com one: the site itself checks the signed pass that Access hands every visitor it lets in, so even a request that found another way round is refused. It switches on when the site is told the guides door’s audience tag — one value, copied from Cloudflare.
  1. Copy the tag. In the Zero Trust dashboard (account level — not inside a zone): Access controls → Applications, open the guides application (the one on www.traveller.org/guides, not the admin one) → Configure → the Additional settings tab → copy Application Audience (AUD) Tag. This is the path you walked for amapas353.com’s admin on 25 September (its Launch Book step 14). It is a long string of letters and digits; it is not a secret.
  2. Give it to the site. The Pages project’s settings → Variables and secrets → Add, environment Production: name ACCESS_AUD_GUIDES, type Text, value the tag.
  3. Make the site read it: on the Pages project’s deployments, Retry deployment on the newest Production one. A Pages setting takes effect only on a new build, and Publish starts one only when something new is waiting — with nothing new it moves production to the commit it is already on, and no build happens. Retry deployment always builds, and reads the variables; Rollback does not.
  4. Check it: open www.traveller.org/guides/door-check/ and sign in if asked. It says ON and names the email whose pass it just checked, or OFF if this deployment has no tag. Read it there and not on the shelf itself: the shelf looks exactly the same either way, which is why this page exists (3 Oct — your “Behind Cloudflare login” and the shelf appearing were both true and still could not tell on from off). A page reading “This page is behind a sign-in” instead means the lock refused you; its last line says why. Tell a session what it says.
  If it shuts you out: delete ACCESS_AUD_GUIDES on the same settings page, then on the Pages project’s deployments use Retry deployment on the newest one — it builds again and reads the variables; Rollback does not. The shelf goes back to the edge door alone, which is where it is today. Publish keeps working throughout: the admin has its own door and its own switch.
  The admin can have the same lock, and it is off by your choice to make: the code is in place for it (ACCESS_AUD_ADMIN, the admin application’s tag, same steps). It is not part of this item because a mistake there locks the Publish button too, and the way back is then only the dashboard’s Retry deployment. Worth doing once the guides lock has run cleanly for a while, or not at all: the admin’s pages are already visible on the test site, so its second lock protects less than the shelf’s does.
  Left open, and what would settle it: every past deployment keeps its own preview address (<something>.traveller-org.pages.dev), serving the code it was built with — so deployments from before this change still serve their shelf openly to anyone who has that exact address. They are not listed anywhere public and the names are random, but they exist. A session cannot list them (the Cloudflare token in GitHub cannot read Pages). Settling it is a look at the deployments list: either delete the old preview deployments, or put an Access application over the preview addresses. Not urgent; say which you prefer and a session will write the steps.
• The friends door is ON — built 2026-08-27, and you set FRIEND_KEY on the Pages project and deployed on 2026-08-28. Rotating the password (which signs every friend out) is one edit to that same setting followed by a deploy; the manual’s Friends section says what to send people.
• The 31 deprecated 800px albums were deleted on 2026-08-18 at your request — their records, repo thumbnails and home-page references are gone, and every old link 301s to the replacement gallery where one exists, else the country page. Their photographs still await re-scanning (the full-size scans stay on the old server and your drives); each future import recreates its album from scratch, exactly as before. One album remains as-is: luxembourg/1998, whose country has no high-res batch yet.
• The Home page manager shipped on 2026-08-18 — the hero carousel is now managed at the top of Cards & strips: drag to reorder, caption each slide, remove, add from any gallery, per the approved design (screen 4, Home page manager). The manual's Updating the site page walks it through.