project-postmortem

# Project Post-mortem Write the retrospective a project earns — grounded in what the git history and decision docs actually show, graded honestly on separate axes, reduced to the one decision that mattered most, and mined for lessons that transfer to the *next* project. The one rule everything serves: > **Ground every claim in retrieved evidence, not memory. If you can't cite it, label it as recollection.** A post-mortem written from memory is a story the team tells itself, and stories drift toward flattering the teller. A post-mortem written from the commit log, the PRs, and the decision docs is a record — and a record can teach the next project something the memory would have smoothed over. --- ## Why this exists The value of a post-mortem is almost entirely in two things: an *honest* root cause, and *transferable* lessons. Both are easy to fake and easy to get wrong: - **Memory launders failure.** By the time a project ends, everyone has a tidy narrative. The git history doesn't — it shows that the validation commit came on day four, not day one, regardless of how it felt. Cite the evidence and the real story surfaces. - **A blended grade hides the killer.** "B+ overall" averages away the fact that engineering was an A and differentiation was an F — and the F is the whole lesson. Grade dimensions *separately* or you erase the finding. - **Vanity retros teach nothing.** A retro that's all "we learned a lot and grew as a team" is a feeling, not a lesson. The test of ...