docs: log the numbered-version policy and what it changed

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

docs/history/DEVELOPMENT_LOG.md

@@ -46,6 +46,55 @@ sequence would have implied more.
 
 ## Entries
 
+### 2026-08-18 — Policy: production always runs a numbered version
+
+`_null`: *always stay on a num version.* Recorded here because it changed three
+things, and one of them was a script written an hour earlier.
+
+**What a pointer cannot do**, which is the whole argument. A stack file naming
+`:dev` says `dev` today and will still say `dev` after the image underneath it
+changes. The file records a preference, not a fact, so "what is running?" has no
+answer that survives the next push — and rollback is worse, because there is
+nothing to roll back *to*. A pointer only ever names now.
+
+**`deploy.sh`** now resolves the newest published **numbered** version from the
+registry when no `--tag` is given, and says which it picked. A floating tag is
+refused outright. `--allow-floating` is the escape hatch for the one case that
+is not a mistake — reproducing a fault on whatever a pointer currently is — and
+it warns every time.
+
+**`release.sh` stopped moving `:dev`.** It published both tags when it was
+written, because stack 58 followed the pointer. Under this policy nothing
+deploys `:dev`, so publishing it would only put something misleading in front of
+whoever reads the registry next.
+
+**`scripts/docker-push.sh` was deleted**, with its npm script. Its entire job
+was building and pushing an unnumbered `:dev` with no bump and no guards — the
+exact thing the policy exists to prevent. It had been kept a few hours earlier
+on the grounds that it was "what the muscle memory reaches for", which is a
+reason to remove it rather than a reason to keep it: a command that quietly
+violates a policy is how the policy stops being true.
+
+`:dev` and `:latest` stay in the registry, frozen rather than deleted. The
+running container was created from `:dev`, and removing the tag an existing
+deployment names is how a recreate fails to pull.
+
+**The policy is not yet true of production.** Stack 58 still pins `:dev`. The
+first deploy made under it repoints the stack at a version, and only then does
+the stack file answer the question on its own. That is also why the deploy
+default resolves a version rather than reusing whatever the stack already names
+— reusing it would have quietly perpetuated the thing being fixed.
+
+- **Closed:** none. Policy and tooling.
+- **Next action:** `npm run release` (0.9.3 → 0.9.4, publishing a numbered image
+  that contains Batch 10's accessibility fixes), then
+  `npm run deploy -- --tag v0.9.4`. That pair moves stack 58 off `:dev` and onto
+  a number, ships the a11y work, and closes #212 — the CORS trailing slash is
+  corrected in the same stack file the deploy rewrites. Both need sign-off: the
+  deploy recreates the container and takes both front doors down together.
+- **Blockers:** the deploy needs permission. Six issues remain blocked on the
+  site owner (#68, #110, #162, #213 in Batch 13; #69, #70 in Batch 14).
+
 ### 2026-08-18 — A release command, and the deploy half PrivacyLLC's deliberately omits
 
 Asked to model the release script on PrivacyLLC-Web's. Read theirs (30 KB, and