Development history and document revisions
docs/history/CHRONICLE.md records concise, numbered actions with evidence labels. development-chronicle.csv is the canonical structured history; FIRST-100.md is a preview only. dependency-downloads.csv keeps received direct downloads and commands/ stores reference SSH commands.
The Code reference describes what files currently do; architecture describes why; User Guide describes what a customer/operator should do. Revisions of published documentation are tracked by WordPress's page revision system. The history release seal prevents silent mutation of previous journal rows.
No source-history gate can prove the accuracy of an undocumented earlier conversation. A release note must identify what was verified versus only user-reported. Do not invent missing steps to increase history count.
Four records serve different purposes
The development chronology records the order of implementation decisions, dependency transfers, generated commands, tests and packaging. The source changelog records version-relevant changes. The Code/Architecture/User documentation explains what exists and why. WordPress page revisions preserve changes to the published wording on a stable page ID. None of these should be substituted for the others; together they make an otherwise fragile solo-maintained project reproducible.
How an action becomes a history entry
A completed action gets a concise numbered entry in docs/history/development-chronicle.csv, mirrored into CHRONICLE.md. Include the date, what changed, a file/artifact/command reference and the available evidence level. Do not rewrite earlier entries to make the story cleaner. If a historical step is known only from an operator report, label it as reported; if a command was drafted but never executed, do not say it changed the server.
All saved SSH commands belong in named files under the history or recovery command directory. Each must explain the target environment and required privileges. Never store passwords, active tokens or production signing keys in the chronology. Shell commands copied from an old recovery attempt are evidence of what was proposed, not necessarily safe instructions for the present host.
Review at the release boundary
An updated source tree triggers a new chronological record and release seal. Edited functionality also triggers its Code page, architectural decision and user-flow documentation. Deployment changes trigger the single disaster-recovery review; new third-party media/dependencies trigger the licensing evidence register. The bundle generator renders canonical Markdown and checksums; the WordPress publisher updates only HSLG-owned pages through normal revisions.
What revisions do and do not preserve
A WordPress revision shows the previous published body if revisions are enabled and the underlying database survives. It does not preserve all deleted media, rebuild an Android signing identity or restore a missing MariaDB customer table. The source archive/history should be stored off-host. If a server and every independent backup are completely lost, development history may explain a rebuild but cannot recreate private customer data.
How to detect a misleading release report
Compare the reported source fingerprint to the packaged source. Check that relevant tests actually ran, not just that they exist. Distinguish local PHP mocks from staging MariaDB and browser simulations from a signed Capacitor app tested on hardware. A documentation publisher ZIP may have valid checksums yet fail to publish because of a WordPress path collision or manual edit. The release record must say 'local verified, live unverified' until the WordPress deployment has been observed.