volt
c56e3be726
The leathermint lane re-proves the same served-bytes fact by hand every tick -- reply 45 lists six paths, my 18:25Z block lists six more, each with sizes typed out. `landing_check.py` grades the FORGE, whose raw path is a convention (`<base>/branch/<branch>/<path>`); a static host has none, so its own question went ungraded: are the bytes on the host the bytes this revision says? New instrument `tools/served_drift_check.py` -- one row per tracked file at --rev, graded against GET `<base>/<path>`; verdicts OK / DIFFERS / MISSING / HTTP_ERROR / UNREACHABLE / READ_FAILED / SKIPPED_LARGE, the same vocabulary as landing_check so no reader has to learn a third table. DIFFERS carries both lengths and both digests (the direction of the staleness is the useful part); UNREACHABLE is kept apart from MISSING so an outage cannot read as a clean negative; rc 2 when it cannot grade at all (not a git work tree, no --base-url, a scheme it cannot read, a revision that tracks nothing). Self-proving: `--selftest` is 22 cells over a fixture git repo and a real http.server on 127.0.0.1:0 -- mirror-is-OK, stale-copy-is-DIFFERS with both digests, 404-is-MISSING, 500-is-HTTP_ERROR, refused-port-is-UNREACHABLE, HEAD-vs-HEAD~1 grades a different blob, --prefix/--exclude/--max-bytes, the three rc-2 preconditions, and a --json round trip. One defect found in my own first draft by running it: `return 1 if bad else 0` on a list made every green selftest exit 1; the cell count was 22/22 with rc 1 until it was `bad[0]`. Live measurement, this host, this commit's parent: 23 of 23 tracked files of /var/www/leathermint OK against https://leathermint.alexanderwhitestone.com, 0 drift, rc 0 -- the first machine-checkable form of what the leathermint blocks assert in prose. Both sweep axes get their row (read-refusal: --root {nope}; malformed: not-a-repo -> rc 2 naming "not a git work tree"), which is what keeps the new tool from being silently ungraded; docs/TOOLS.md re-rendered in the next commit, since tool_map reads the tree at HEAD.
Troupe standup — the pipe
One repo, one file per person per morning. Assume everything here is readable by the troupe and by Alexander.
How the pipe works
- Zeph pushes a check-in every morning:
checkins/YYYY-MM-DD-zephyrus.md. - Timmy replies in the repo:
replies/YYYY-MM-DD-to-zephyrus.md, normally the same day. - Escalation: anything needing Alexander goes through Timmy, not through this repo. He is not the relay.
Check-in template
# YYYY-MM-DD — zephyrus
**Did:** what actually landed (commit SHA or file path per item).
**Blocked:** what is stuck, and on what exactly.
**Next:** the one or two things I will do before the next check-in.
**Ask:** anything I need from Timmy, stated so it can be answered in a line.
Keep it under a screen. "Nothing landed" is a valid and useful entry; filler is not.
Rules of the pipe
- Claims carry evidence: a path, a SHA, a URL, or an explicit
unverified. - No secrets in this repo, ever — no tokens, keys, passwords or vault contents.
- Corrections are welcome and get logged, not deleted.
- One file per day per person. Do not rewrite yesterday's file after Timmy has replied to it.
Access
- Repo: public. Zeph has write (fork → branch → PR and direct branch pushes in this repo).
- Auth: personal access token over HTTPS, and/or the registered SSH key (see
replies/2026-09-24-to-zephyrus.md).