“The Medusa headless build I described is NOT the supermarket site.”
The correction came in while the deploy was still propagating. The web history cards had merged three minutes earlier: four cards, twelve years of professional range, all named per the site’s entity policy. The supermarket entry was one of the four. The project it described was a separate Medusa build, one I hadn’t shipped yet.
I withdrew the card. An hour later, a second correction: “Flash UI is UI Gen.”
Two corrections in one hour. On the surface they were different errors; underneath, the same problem.
The supermarket card
The card drew on a Medusa headless build I’d described in dictation: a headless e-commerce architecture I’d scoped, stacked alongside a consultancy platform, a scheduling tool, and a customer portal. A supermarket e-commerce card assembled from that description. The content was accurate for the Medusa project. The attribution was wrong.
The actual supermarket work is a different build, a named-brand client that stays off the public catalogue per the entity policy. The Medusa build is future work. The card mixed up which was which.
No README to blame here. The error came from a wrong inference from dictation: I described a Medusa project, the card landed under the supermarket category, those weren’t the same thing. The fix is to treat attribution as a distinct check, separate from whether the card’s content is accurate. Both need verifying before anything ships.
The Flash UI card
The Flash UI card pulled its name from the repo README. The README named the product Flash UI. That was the name on the card.
Flash UI was renamed to Uigen in January. Spec 029-uigen-rebrand documented the change. The README had not been updated to reflect it. By the time the card was drafted, “Flash UI” was six months obsolete and still sitting in source.
Smaller correction to ship than the supermarket withdrawal. The card stayed; only the name changed to Uigen. Same diagnostic. The most accessible source had been pulled from. The most accessible source was behind.
What both corrections had in common
Two corrections, one hour, two different sources: dictation and README. Neither is guaranteed to be current.
Dictation can misattribute. The speaker has a project in mind; the listener assembles a card from adjacent context; the attribution drifts. A README can lag. A rebrand happens, the spec gets written, the README stays unchanged for months while features ship on top of it.
What both cards were missing was a step that asked, before anything merged: is the name right, and is the attribution right? That step wasn’t in the process.
Why READMEs lag
READMEs are written at project start and updated at major milestones if you’re disciplined. When a product gets renamed, updating the README competes directly with shipping the next feature. It usually loses.
Spec 029-uigen-rebrand existed. The decision to rename Flash UI to Uigen had been made, documented, and numbered. The README hadn’t been touched since before that decision. Six months later, the card used the dead name.
Mandating README updates on every rebrand is a process rule that breaks under pressure. That’s not the fix. The fix is a source hierarchy: when a numbered spec or a named decision log exists, it takes precedence over the README. The card-drafting process didn’t check for that. It pulled from the nearest named source, which happened to be wrong.
The category refactor the same day
Earlier in the same session, I restructured the /work/ drawer. The original category groups described the site’s internal build taxonomy: standalone tools, platforms, sites, build-narrative system. Looking at the panel on my phone, the problem was clear: those groups described how the site organises things, not what a visitor reading the panel wants to know.
The result was four visitor-facing categories. The Work dropdown updated to match. An employer reading the panel should be able to answer “what kind of work?” from the category names alone, not reverse-engineer the site’s internal classification logic.
The web history cards were added in the same pass because the employer persona had flagged missing dates and range. The panel needed evidence of twelve years of professional work, not just recent builds. The corrections that followed were a separate problem from the category refactor. The structure was right. The cards were wrong.
What the check looks like
Before any work card ships, three questions:
- Attribution: does the project described actually match the client or product it’s being filed under? Accurate content attributed to the wrong project is still a wrong card.
- Current name: if the card name came from a README, does a rebrand spec, a PR, or a numbered decision log exist that supersedes it?
- Scope: is this shipped work, future work, or client work that stays unnamed?
None of this is automatable. A README check requires knowing there’s a spec to cross-reference. An attribution check requires a human read against a source I control, not just the most accessible file to hand. Three questions. Asked in that order. Before review, not after.
What ships now
The web history section of /work/ has three cards where there were four. The supermarket entry is withdrawn. The real supermarket project stays unnamed; the Medusa build gets its own card when it ships. The Flash UI card is Uigen.
A thinner catalogue is the right trade-off. A card with the wrong name or the wrong project damages the panel more than a gap does. An employer who checks the repo and finds a product called Uigen where the card says Flash UI has a legitimate question about the site’s accuracy. A gap is just a gap.
The source-of-truth check goes into the drafting process before the next batch ships. Attribution, current name, scope. Three questions, in order, before anything goes to review. That’s the lesson two corrections in one hour produced.
