docs(deploy): CORRECT §GH-DEPLOY-DELETES-GLASSBOWL — I over-stated it; the deploy is done and clean

[red1oon]

The site is deployed. Nothing went offline. My earlier finding was over-stated and this corrects it.

What I missed

mkdocs copies from disk, not from git. docs/glassbowl_data.db is gitignored but sits on disk in the primary checkout. A deploy run from there — how deploys have always been run here — publishes it normally.

My test ran the guard from a fresh /tmp/wt-* worktree, which contains no gitignored files. The asset really was absent from that build and the guard correctly aborted. The abort was real; generalising it to "the next deploy from any branch deletes it" was not.

Deploy completed

§STEP4 GUARD: live=290 files, new=292 files, tol=5%
§GUARD result=PASS — new build is a superset. Safe to publish.
§STEP6 all canaries 200
§DEPLOY-DONE published + canaries checked

Verified live after:

check	result
ModellerGuide "ANCHORED by default"	1 hit — #1706's change has finally reached users
ModellerGuide "ride, never distort"	0 hits — the stale text is gone
SpatialCompilationPaper, 4DGenerator	200
all five Glass Bowl files	200
glassbowl_data.db	200, 94,208 B, sha1 e1fb334d — byte-identical

The residual risk, restated honestly

Not "the next deploy breaks the demo." It is: that asset exists in exactly two places — one developer's disk and gh-pages — and in no source tree, bucket, or build script.

• A deploy from a fresh clone/worktree/CI won't have it and will hit the guard's ABORT. That's the seatbelt working, but it will read as a mystery to whoever hits it.
• If that disk is lost, the only copy is whatever gh-pages last published.

So the OCI route stays worth doing — for durability and reproducibility, not as an emergency. Lower urgency than I first wrote, and it blocks nothing.

🤖 Generated with Claude Code