Document the reversible Namecheap cutover

docs/operations/cloudflare.md

@@ -86,4 +86,4 @@ The required approval provides a final gate after online acceptance testing and
 
 ## 6. Custom domains
 
-Only after [the QA checklist](qa.md) passes, add `www.lisbondatascience.org` as the production custom domain. Authoritative DNS remains at Namecheap: change the existing `www` CNAME only after Cloudflare Pages has registered the hostname, and configure Namecheap's apex URL Redirect Record as a permanent `301` to `https://www.lisbondatascience.org/`. Follow [the DNS runbook](dns.md). Do not alter mail or domain-verification records.
+Only after [the QA checklist](qa.md) passes, add `www.lisbondatascience.org` as the production custom domain. Authoritative DNS remains at Namecheap: change the existing `www` CNAME only after Cloudflare Pages has registered the hostname, and leave the existing apex forwarding unchanged. Follow [the DNS runbook](dns.md). Do not alter apex, mail or domain-verification records.

docs/operations/dns.md

@@ -6,7 +6,7 @@ This choice does not prevent a later move to Cloudflare authoritative DNS. Befor
 
 ## Captured public baseline
 
-These values were observed on 2026-10-08. Export the authoritative Namecheap zone immediately before cutover because public DNS cannot reveal every record, particularly unknown DKIM selectors.
+These values were rechecked on 2026-10-11. Export the authoritative Namecheap zone immediately before cutover because public DNS cannot reveal every record, particularly unknown DKIM selectors.
 
 | Name                           | Type  | Value                                                                  | Observed TTL |
 | ------------------------------ | ----- | ---------------------------------------------------------------------- | ------------ |
@@ -26,6 +26,15 @@ These values were observed on 2026-10-08. Export the authoritative Namecheap zon
 
 No apex AAAA or CAA response was observed.
 
+The existing Namecheap forwarding behavior was also recorded on 2026-10-11:
+
+- plain HTTP at the apex returns a temporary `302` to `https://www.lisbondatascience.org`;
+- apex paths are not preserved by the current forwarding rule;
+- HTTPS at the apex is not reliably terminated by Namecheap forwarding;
+- `www` serves the Unbounce site and returns the Unbounce page identifier `7f3394ee-2bc1-4e2a-bab8-b6f82f2f95a1`.
+
+The initial cutover preserves this existing apex behavior rather than modifying it. A later move to Cloudflare authoritative DNS should replace it with a permanent HTTPS, path-preserving redirect.
+
 ## Private backup and rollback record
 
 Immediately before cutover:
@@ -37,7 +46,8 @@ Immediately before cutover:
 5. Record the rollback values:
    - `www` CNAME: `unbouncepages.com.`
    - the two current apex A records shown above;
-   - any existing apex redirect configuration.
+   - the existing apex redirect configuration, without editing it.
+6. Keep the Unbounce account and its domain association intact. DNS rollback remains possible for as long as Unbounce continues serving that project; a suspended provider account cannot guarantee indefinite retention.
 
 ## Register the Pages hostname before changing DNS
 
@@ -59,28 +69,21 @@ In **Namecheap → Domain List → lisbondatascience.org → Manage → Advanced
    | ----- | ----- | ------------------------- | --------- |
    | CNAME | `www` | `ldsa-website.pages.dev.` | Automatic |
 
-2. Configure the apex redirect:
-
-   | Type                | Host | Value                                | Redirect type |
-   | ------------------- | ---- | ------------------------------------ | ------------- |
-   | URL Redirect Record | `@`  | `https://www.lisbondatascience.org/` | Permanent 301 |
-
-3. Remove only A, ALIAS, CNAME or URL Redirect records at host `@` that Namecheap identifies as conflicting with the new apex redirect. The observed apex A records are website/forwarding records, but compare them with the private zone export before removing them.
-4. Do not edit MX, SPF, DKIM, DMARC, CAA, SRV or verification records.
-5. Save the changes. Namecheap states that URL redirects normally begin working within about 30 minutes; resolver caches may take longer.
-6. Wait for Cloudflare Pages to show `www.lisbondatascience.org` as active and for its TLS certificate to become valid.
+2. Leave the existing apex forwarding configuration and its Namecheap-managed A records unchanged.
+3. Do not edit MX, SPF, DKIM, DMARC, CAA, SRV or verification records.
+4. Save the `www` change and allow for its 60-second DNS TTL plus resolver caches.
+5. Wait for Cloudflare Pages to show `www.lisbondatascience.org` as active and for its TLS certificate to become valid.
 
 ## Production verification
 
 Verify from at least two networks or public resolvers:
 
 1. `www.lisbondatascience.org` resolves through the Pages CNAME and serves the accepted commit over HTTPS.
-2. `lisbondatascience.org` returns a permanent redirect to `https://www.lisbondatascience.org/`.
-3. Deep apex URLs preserve their path when redirected. If Namecheap does not preserve paths as required, stop and replace the forwarding method before accepting cutover.
-4. All maintained routes, legacy redirects, the custom 404, assets, headers, canonical URLs, `robots.txt` and the sitemap pass.
-5. Flodesk submits a controlled production subscription successfully.
-6. Google Workspace sends and receives controlled messages, including a reply from an external mailbox.
-7. The protected `dev` alias remains separate and private.
+2. The existing apex forwarding still sends HTTP requests to `https://www.lisbondatascience.org`; record the inherited HTTPS and path-preservation limitations as accepted until the future Cloudflare DNS migration.
+3. All maintained routes, legacy redirects, the custom 404, assets, headers, canonical URLs, `robots.txt` and the sitemap pass.
+4. Flodesk submits a controlled production subscription successfully.
+5. Google Workspace sends and receives controlled messages, including a reply from an external mailbox.
+6. The protected `dev` alias remains separate and private.
 
 After the hostname is active, configure production-only Web Analytics using the Cloudflare runbook.
 
@@ -89,9 +92,10 @@ After the hostname is active, configure production-only Web Analytics using the
 If production has a material failure:
 
 1. Restore the `www` CNAME to `unbouncepages.com.`.
-2. Remove the new apex URL Redirect Record and restore the prior apex website records or forwarding configuration from the private backup.
-3. Leave all mail and verification records untouched.
-4. Verify the old public site and email before investigating the failed cutover.
+2. Leave the unchanged apex forwarding, mail and verification records untouched.
+3. Verify the old public site and email before investigating the failed cutover.
+
+This rollback changes routing only. It does not recreate an Unbounce project that Unbounce has removed, so retain the account, project, custom-domain association and any required provider access while rollback remains a business requirement.
 
 ## Future move to Cloudflare DNS
 
@@ -103,5 +107,6 @@ A future authoritative-DNS migration remains fully supported:
 4. Validate the staged Cloudflare zone against the private export.
 5. Replace the Namecheap nameservers with the two nameservers assigned by Cloudflare.
 6. Verify website, email and domain-verification services throughout propagation.
+7. Replace the inherited apex forwarding with a Cloudflare `301` redirect that preserves the path and query string over HTTPS.
 
 The registrar can remain Namecheap even when Cloudflare becomes the authoritative DNS provider.

docs/operations/qa.md

@@ -79,7 +79,7 @@ HTTP checks prove that the public Flodesk scripts and POST endpoints exist, but
 
 ## Production cutover checks
 
-- [ ] `https://lisbondatascience.org/` redirects to the canonical `www` HTTPS hostname.
+- [ ] Existing apex forwarding still sends plain-HTTP requests to the canonical `www` HTTPS hostname; its inherited HTTPS and path-preservation limitations are recorded for the future Cloudflare DNS migration.
 - [ ] `https://www.lisbondatascience.org/` serves the expected commit.
 - [ ] Canonical and Open Graph URLs use the production hostname.
 - [ ] `robots.txt` and `sitemap-index.xml` return 200.

docs/operations/release-acceptance.md

@@ -23,13 +23,22 @@ No subscriber addresses or other personal data are stored in this repository.
 - `main` is the production branch and `dev` is the private integration branch.
 - Production DNS remains authoritative at Namecheap.
 - `www.lisbondatascience.org` will point to `ldsa-website.pages.dev` only after the custom hostname is registered in the Pages dashboard.
-- Namecheap will provide a permanent apex-to-`www` redirect.
+- The existing Namecheap apex-to-`www` forwarding remains unchanged during the initial cutover.
 - Browser Web Analytics will be enabled only for production after the final hostname is active.
 - The existing Unbounce-hosted public site remains available until the DNS cutover.
+- Unbounce will be retained as a rollback target after cutover; the migration does not cancel or delete its account, project or domain association.
+
+## Production candidate
+
+- Accepted production commit: `2dfa88d460235d97e1ab4ed982c70b15a2e4c7a5`
+- Production workflow: <https://github.com/LDSSA/website/actions/runs/38138514741>
+- Result: passed on 2026-10-11
+- Public staging hostname: `https://ldsa-website.pages.dev/`
+
+The public Pages hostname returns `200`, is not protected by Access and does not send `noindex`. Immutable deployment URLs remain private and send `noindex`.
 
 ## Remaining acceptance gates
 
-- Promote the release-preparation changes from `dev` to `main` and verify the public Pages production hostname.
 - Export the complete Namecheap zone privately and record rollback values.
 - Attach `www`, complete the Namecheap cutover and verify email.
 - Enable and verify production-only Web Analytics.