Change control — the pack's own release history
Summary
The pack has reversed load-bearing decisions more than once — healthy, the log says, but only if the reversals are legible in one place. Nine revisions in three days, each entry naming its trigger (almost always a one-line maintainer question: 'why do you need the vault.html file?', 'publish ./site should not be allowed'), what changed, and which numbered decisions moved. r8 is the log acting on itself: the R1 contradiction fixed by making plaintext expansion a future sgit vault expand command (decision 11), manifest entries gaining a per-object sha256 because the tabletop's keyless mirror could content-verify only 12 of 18 objects, and the visibility-downgrade warning added because a fresh CI clone resolves to bare. r9 removes publish's last copy: the output is the plaintext surface only — O(KB) for any vault — and the served root is composed at deployment (decision 12). Updating this file is now part of a developer agent's definition of done.
Key concepts
- Change control for a spec — every commit that edits a spec file adds an entry — what changed, why (the trigger), which decisions moved; a reader returning after a gap reads this file first
- Reversals made legible — decision 7 reversed (CDN default), decision 9 settled (no target), decision 2 re-settled (loader separation) — each traceable to a maintainer question and a measurement
- Findings become spec — R-numbers from the 19 Aug review and F-numbers from the executed tabletop are fixed in r8 or assigned owners — not just recorded
Key ideas
- Eight revisions in three days, almost every trigger a one-line maintainer question — the pack is a conversation with an audit trail.
- The same discipline as this site's own versions page: dated entries, newest first, reversals stated plainly.
- The keyless mirror's 12-of-18 verification gap became a manifest sha256 requirement — measurement turning into contract.