docs(site): stop three files calling a revert a rollback (#215)

Reverting the commit that added the Worker route reads like the undo
button and is the opposite of one. GitHub Pages used to sit behind that
route and was disabled and its sources deleted when the Astro site went
live, so removing the Worker now leaves the DNS record pointing at
nothing. That is an outage. docs/SITE.md has said so since the cutover,
in a paragraph three below the one telling you to revert.

Three files carried the old advice and none of them carried the
correction:

- site/wrangler.jsonc opened with "Rollback is reverting the commit that
  added this block", which is the first thing anyone reads when they go
  looking for the route under pressure.
- .github/workflows/site-deploy.yml explained its own no-branch-trigger
  design as "what makes reverting a commit a complete rollback".
- docs/SITE.md led the section with a bolded "Rolling back is git revert
  of the commit that added the route", then contradicted it further
  down. A reader skimming for the bold line got the dangerous half.

All three now say the same thing: fix a bad deploy by rolling site/
forward. The distinction that was missing everywhere is drawn
explicitly -- reverting an ordinary site/ commit is fine and is just
another way of rolling forward, because the deploy publishes whatever
main holds; it is reverting the route itself that has nothing to land
on. Deleting the route in the Cloudflare dashboard is still not a
rollback either, and all three still say that, because the weekly
scheduled deploy re-applies whatever wrangler.jsonc holds.

Comments only. No behaviour changes and no deploy is triggered by this
commit: it touches no file under site/ that the build reads, and the
workflow edit is a comment above the trigger block.

Verified: wrangler.jsonc still parses as JSONC with workers_dev false
and the route unchanged, site-deploy.yml still parses as YAML with both
jobs intact, and the site build, contrast gate, docs validator, 1333
backend tests, scripts/check.py and git diff --check all pass.

Separately confirmed live rather than assumed: www.nojoin.co.uk serves
the merged nav, and /docs/TELEMETRY, /docs/README and /docs/MCP each
still return 301 to their GitHub blob URL. That contract only runs on a
real deployment, so it cannot be checked any other way.

Author: Valtora

.github/workflows/site-deploy.yml

@@ -4,7 +4,13 @@ name: Site deploy
 # main, a published release (so the baked-in version and star count refresh),
 # a weekly schedule (same reason, without needing a release), and by hand.
 # There is deliberately no branch trigger: the workflow only ever deploys what
-# main contains, which is what makes reverting a commit a complete rollback.
+# main contains, so whatever lands there is what the public gets.
+#
+# That does NOT make reverting a complete rollback. Reverting an ordinary site/
+# commit is fine, because the deploy just publishes the earlier content. But the
+# route in site/wrangler.jsonc has nothing behind it any more — GitHub Pages was
+# disabled and deleted when this site went live — so reverting the commit that
+# added it takes www.nojoin.co.uk down instead of restoring it. Roll forward.
 on:
   push:
     branches:

docs/SITE.md

@@ -452,9 +452,16 @@ liability: `Base.astro` builds its canonical from `Astro.site` and so pointed cr
 at `www.nojoin.co.uk`, but that is mitigation rather than a reason to keep it. Reviewing an
 unmerged change is what `npm run serve` and a quick tunnel are for.
 
-**Rolling back is `git revert` of the commit that added the route, then letting CI deploy.**
-Deleting the route in the Cloudflare dashboard is not the rollback path: the weekly scheduled
-deploy from `main` re-applies whatever `wrangler.jsonc` says.
+**Fixing a bad deploy means rolling `site/` forward, not backwards.** There is no revert that
+lands on a working site, and reverting the commit that added the route takes the site down
+rather than restoring it — the reasoning is two paragraphs below, and it is the single
+easiest thing to get wrong here under pressure. Deleting the route in the Cloudflare
+dashboard is not a rollback either: the weekly scheduled deploy from `main` re-applies
+whatever `wrangler.jsonc` says.
+
+`git revert` of an ordinary `site/` commit is fine, and is just another way of rolling
+forward — the deploy publishes whatever `main` holds. What is not survivable is reverting
+the route itself.
 
 That rollback used to land on a live GitHub Pages origin. It no longer does. Pages served
 the previous Jekyll site from `main` as a `build_type: legacy` build — no workflow, just a

site/wrangler.jsonc

@@ -10,9 +10,14 @@
 // adding it intercepts traffic atomically, and removing it stops intercepting
 // just as atomically.
 //
-// Rollback is reverting the commit that added this block and letting CI deploy.
-// Deleting the route in the Cloudflare dashboard is NOT the rollback path: the
-// weekly scheduled deploy from main would silently re-add it.
+// DO NOT revert the commit that added this route to roll back. It reads like
+// the undo button and it is not one: GitHub Pages used to sit behind this route
+// and was disabled and deleted when the Astro site went live, so removing the
+// Worker now leaves the DNS record pointing at nothing. That is an outage, not
+// a rollback. Fix a bad deploy by rolling site/ forward.
+//
+// Deleting the route in the Cloudflare dashboard is not a rollback either: the
+// weekly scheduled deploy from main re-applies whatever this file says.
 //
 // workers_dev is off. It was on while the site was being built, so it could be
 // reviewed before the route existed, and it served a complete public duplicate