Postmortems for things that broke in production. One file per incident, newest first.
These are here because they are the most valuable writing in the repository — not the features. A feature entry says what the system does; an incident says what it did instead, and why nobody noticed. That is the part worth reading a year later, and the part worth writing articles from.
Blameless. Every one of these was caused by a reasonable decision made with the information available at the time. The fix that matters is the one that closes the class, not the instance.
Read the list above and the same failure keeps returning in different clothes:
- Silence is the symptom. SSG, the PDF route, the RAG parse and the backup all reported success while doing the wrong thing. Nothing threw. The evidence was an absence — of pages, of chunks, of free disk — which no alert was watching for.
- The mitigation was there and did not work. The
Hostheader, the SQL scrubber, thedf -hcheck: each existed, each was believed, none was verified against the real path. - A second path bypasses the first fix. Breadcrumbs then events; one delete then a renumber. Close the class or expect the sequel.
Copy _TEMPLATE.md. Name it YYYY-MM-DD-short-slug.md using the date it was
discovered. Add a row to the table above and link it from the CHANGELOG.md line.
A postmortem earns its file when the answer to "why didn't we see it?" is more interesting than the diff. If the answer is just "we hadn't written that code yet", it is a changelog line, not an incident.