rdmsm4x — dev.ecs0.net recovery pushed, and reboot preparation

When: 2026-08-31 15:34–15:45 EDT · Host: rdmsm4x · Author: claude@rdmsm4x Scope: rdmsm4x. ~/dev/sites/dev.ecs0.net, ~/dev/issues. Continues the 13:15 changelog (...-ecs0-git-recovery-served-credential-and-docroot-cleanup).

Summary

Pushed the recovered dev.ecs0.net tree to its remote — deliberately without 666 agy session-doc pages — then prepared the host for a reboot: session state written, fleet warned, memories saved, and the one still-unfixed trap filed as a ticket.

1. The push — 978b5ab → backup/publish/recovery-20260831

Rich approved with "go ahead and push it to the site". Executed as the exclude option, which was the standing recommendation on TASK-20260831-03.

Why exclude on an ambiguous go-ahead: excluding is reversible in one command; publishing credential-class transcripts to GitHub is not reversible at all. The asymmetry settled it, not the wording.

A near miss worth recording. git rm --cached wiki/agy had been committed, but the 666 blobs were still reachable through 6171f75 earlier on the same branch — so pushing that branch would have published them regardless. Caught by git ls-tree -r 6171f75 -- wiki/agy → 666, run before the push. git status gave no hint.

Fix: built the push candidate with plumbing so the contaminated history was never a parent — git write-tree on the cleaned index, then git commit-tree -p a842ceb. The working tree was never touched.

Verified against the remote, not the local branch:

git ls-remote backup refs/heads/publish/recovery-20260831  -> 978b5ab (== local)
git fetch backup … && git ls-tree -r FETCH_HEAD -- wiki/agy -> 0
34,803 files, parented on a842ceb; credential scan clean across 7 patterns

Excluded and now gitignored: wiki/agy/, issues/, *.bak-[0-9]*. The agy pages remain on disk and remain served behind Cloudflare Access — only the third-party push was withheld. GitHub warned wiki/index.html is 50.7 MB (over its 50 MB recommendation); accepted, non-blocking, wants LFS if it grows.

2. Reboot preparation

• SESSION-STATE.md written and committed (516ed13) — completed work, the single open owner item, the trap list, and post-boot verification steps.
• Fleet warned via the bus (reboot-pending-rdmsm4x-checkpoint-now-20260831). 14 live sessions would have died unwarned. The message spells out what a reboot takes (sessions, /tmp, containers) versus what survives (files on disk, including uncommitted work — the risk there is losing the session that knows why).
• Left alone deliberately: open/ISSUE-20260831-04-stormguard-….md (modified) and tests/test_isolation_coverage.py (untracked) in ~/dev/issues are another agent's. Named in both the broadcast and SESSION-STATE so they are not read as drift.
• Scratchpad checked — all reproducible (a re-clonable mirror, disposable probes, derivable ID lists). Nothing needed promoting out of /tmp.

3. ISSUE-20260831-11 filed — the trap that is still live

build_site.py prints "build complete and verified" and publish_dev_ecs0.zsh logs "ok" without ever requesting a page. That green build is why an unserved /issues/ went unnoticed for days. Filed with a proposed fix rather than applied, because changing the exit semantics of the owner's build script is their call. The proposal notes the probe must send -H 'Host: dev.ecs0.net', or it would 404 permanently on the gateway catch-all and train everyone to ignore it.

4. Memories saved

• git-rm-cached-does-not-unpush — the push trap above.
• irreversible-direction-needs-explicit-call — on an ambiguous go-ahead, take the reversible branch.
• checks-that-measure-the-wrong-thing — five instances in one session of a check returning a clean result while measuring the wrong target.

State at reboot

~/dev/issues                 072f85d   (2 files dirty, both another agent's)
~/dev/sites/dev.ecs0.net     516ed13   on recovery/local-history-lost-20260831
backup remote                978b5ab   on publish/recovery-20260831, verified
store == docroot == ~/Desktop/issues/tickets ; /issues/ 200

STILL OPEN FOR RICH

TASK-20260831-02 — rotate the Google API key. Unaffected by the push and by the reboot. The shipped guard stops publication; it cannot invalidate a key that was already served, and the same shape sits in six quarantined trees (ISSUE-20260831-05).

After the reboot

OrbStack must come back before the site serves. Expect 404/connection-refused immediately post-boot — that is the stack starting, not a regression. Verify: curl -H 'Host: dev.ecs0.net' http://127.0.0.1:8788/issues/ → 200.