Question
Every designer I know has a portfolio a year out of date, mine included. Not because the work stopped. Because updating it is archaeology.
You finish something, you are sick of it, you move on. Months later you want to show it and the digging starts: screenshots you never took, commits opened to see what a screen used to look like, a decision you cannot defend because you cannot remember the alternative. The work is done and the hard part is still ahead of you.
Two things never survive the dig. Why the project existed at all, and what each decision cost. The rest is recoverable: the stack is in the repo, the numbers are in the git log, the screens can be recaptured. But the reasoning lived in my head, and my head moved on.
Hand an AI my repo and ask for the story, and it writes something plausible and wrong. My home server, e-pi, catches my house's data. The first draft opened with years of patient birdwatching. Lovely, and invented. The real reason: the Mac Minis I wanted sold out, so I taught myself self-hosting instead. You will not find that in a commit.
Can a project collect its own case-study material while I build it, so publishing becomes an afternoon, not a weekend?
Experiment
Most of what I needed already existed. Anything substantial starts with brainstorming it out loud, using superpowers, and that session already writes a design doc: the origin, recorded on the day I still believed it. What was missing was everything after that moment, plus knowing while I worked which artifacts I would want later, so the screenshot gets taken while the thing is still on screen and not hunted for in March. So each gate got one fixed home.
Where each gate writes. A CLAUDE.md file at the root of my home directory holds the rules, and every project underneath inherits them. Inside any project, a dated design doc under a specs folder holds the goal, the options I killed, and what I ruled out of scope, with amendments appended to it as the plan changes. Whatever issue tracker the project uses holds one record per closed unit of work: problem, constraint, choice, tradeoff. In the portfolio repo, content/projects/<slug>/ holds the published case study alongside the media saved while the work was happening.
Only one thing in there is new work. When I close a piece of work I write four lines about it: the problem I hit, the constraint that shaped it, what I chose, and what it cost me. They go in whichever tracker the project already uses, which for me is beads, so the record sits in the repo beside the code it explains. That is the entire tax.
Those four lines are not notes to myself, and that is the part that makes it work. They are the exact fields a case study renders on this site, so a decision written at close time reaches a published page months later without being rewritten once. Capture and publication are the same object, which is why writing the page later feels less like authorship than assembly.
The obvious move is to automate it, and I spent an afternoon trying. A watcher can see every file I touch and none of the reasons I touched them; the tradeoff behind a decision has never once turned up in a diff. So the four lines stay manual, and the whole thing rests on a habit. Skip a close and that decision is gone. I would rather lose the ones I skip than collect a hundred I never meant to keep.
Then I ran it in both directions: forward on what I was actively building, and backward on older projects, rebuilding their decisions from git history and memory to see how much came back.
Learning
Backdating is where it broke, which answered the question I started with. Rebuild a decision after the fact and you get a confident guess wearing the costume of a memory. Whatever gets written has to be written at the moment, or it does not get written at all.
Writing it at the moment turned out to be necessary and not sufficient, and that part I did not see coming. What I write at a close comes out at the wrong altitude: that a spring constant read fidgety, or that a value went from six to ten. True, and worthless to anyone reading a portfolio. Three amendments and a long tail of tuning revisions on one hover effect add up to a single decision, and the decision is that a signature interaction had to feel alive without shutting out people who cannot use it. So the raising happens later, when I can see which forks actually mattered. The test I use: if the choice had gone the other way, would a person using the thing notice?
That split is what makes the whole thing survivable. Catching is not publishing. Most of what I write down will never become a page and does not need to, which is exactly why four lines is a price I can pay every time. But when something is worth showing, the material is already sitting there, and the portfolio stops being a year behind.