Issue #13 - Turn the Fix Into a Check
Presence Optionality (Issue #9), Prove-Then-Replicate (Issue #11), and Redline (Issue #12) all live upstream of the executor. They catch defects before the work ships. This week's issue lives downstream. It's what you do after the fix lands, so the same class of defect can't come back.
Field Note
Last week I rotated a database password. Standard thing. Fixed the config, restarted the app, moved on.
Ten minutes later an internal dashboard was throwing "connection failed." A handful of files still had the old password hardcoded in them. Fix took a few minutes. Wire each file to read from the config. Redeploy. Green.
But here's the part I want to name. This was the second time this class of thing bit me. Six months ago it was API keys instead of a database password. Same shape. A rotation that should have been one file to update, and quietly wasn't.
The first time, I fixed the instance and moved on. The lesson was in my head. Which meant the next rotation had to remember it.
It didn't.
So the fix this time was different. I wrote a check. A small script that scans the codebase for hardcoded credentials. I run it before I deploy. If it finds anything, I fix it before shipping.
The check earned its rent the day I wrote it. Running it once turned up another copy of the config in a directory I'd forgotten existed. The credential in that copy was already dead, so nothing was exposed. But the copy was there. A future rotation would have missed it the same way, and the class would have kept surfacing through the divergent copy path indefinitely.
The lesson is no longer in my head. It's in the system.
That's the whole difference.
The Deep Dive
Every fix you make is a lesson. Something went wrong, you figured out why, you patched it. The lesson is now yours.
That feels like the end of the story. It isn't. Where the lesson lives determines whether the same class of defect can happen again.
Lessons in your head decay. You will forget the specific shape of the defect within a few weeks. You fix ten things a week and your memory is not indexed for pattern recall.
Lessons in your head don't transfer. If someone else touches the same code, does the same rotation, writes the same brief, they don't have the lesson. The next person who steps into your shoes gets to learn it again, at whatever cost you paid the first time.
And they're optional. Nothing forces you to remember them. You can be tired, moving fast, distracted, and the same class of defect ships. There is no gate between forgetting and shipping.
Lessons in the system are none of those things. A pre-deploy check that greps for hardcoded passwords doesn't forget. It runs every time, whether you thought about the class today or not.
The conversion from head to system is what turns a fix into a framework. The fix repairs the instance. The check protects the class. Every fix earns a check, or the class gets to come back.
The instinct is to stop at the fix because the instance is what hurts. The class is invisible until it strikes again. So there's no felt urgency to convert. The felt urgency is always the current instance. Which is exactly why the check has to be built into the workflow ahead of time, so it fires without needing your attention.
The kitchen version: putting out a stovetop fire is a fix. Installing the smoke detector is a check. Nobody argues about which one matters more.
The check doesn't have to be fancy. Ten lines of shell that fail on a bad pattern is a check. A validator that runs before a write is a check. A test that has to pass before merge is a check. The bar is: does this catch the class without you present.
Case Slice Teardown
Role: Solo operator maintaining a library of frameworks, each referencing others by ID
Situation: During an audit, I found 21 references in the library pointing to framework IDs that didn't exist. They'd been introduced across months, mostly during AI-assisted authoring that cited plausible-sounding neighbors without checking whether they were real. Every one of them had passed manual review at the time it was written.
Constraint: No formal editorial process. Frameworks written and edited across sessions. The reference format is human-readable, which meant every citation looked reasonable at a glance and only failed on lookup.
Intervention: First pass, fix the 21 dangling references by hand. About an hour of work. Second pass, and this is where the real fix lives: added a check that runs at every git commit. The check parses every framework file, extracts all outbound references, and looks each one up. If any reference points to something that isn't there, the commit fails.
Outcome: Zero new dangling references have been introduced since. Not because I got more careful. Because the system stopped letting them through.
What's notable here: The 21 fixes cost about an hour. The check cost about ten minutes to write. The math is one-way. Every future reference gets validated automatically, forever, for a fraction of the cost of the manual cleanup. The check paid for itself before it was committed.
The Class-vs-Instance Test
1. What class of defect did this belong to?
Name the category the instance belonged to. "Wrong client name" is an instance; "personalization data drifting from source" is the class. "Broken CRM connection" is an instance; "hardcoded credential" is the class. Name the class before you patch, or you'll patch the instance and forget the class exists.
2. Where in the workflow could the class be caught cheapest?
A check at the point of write is cheaper than a check at review. A check at review is cheaper than a check after send. A check after send is cheaper than a check from the client. Move the catch as far upstream as it will go without adding friction to the work.
3. What is the minimum viable check?
Start with the smallest one that would catch the class. Ten lines of grep, one validator, one test. If the perfect check is a week of work, you won't write it. If the minimum check is ten minutes, you will. Ship the minimum. Improve it if it fails.
4. What does the check fail loudly on?
A silent check is worse than no check. If it can pass the bad case, it will. Make the failure visible. A commit that gets rejected. A red output. A send that gets blocked. Loud enough that you cannot ship past it without noticing.
5. What did the check cost, and what did the class cost you the last time it hit?
This is the ratio that matters. Ten minutes of check versus two hours of recovery is the case for doing it. If you can't articulate the ratio, you probably haven't tallied the recurring cost.
If the class has hit twice, and you haven't converted, the third instance is on you.
Convert your last fix into a check
Pick your most recent fix.
Something that broke recently. You patched it and told yourself you'd remember. The freshness matters. If it was more than a week ago, you probably already forgot the class.
Name the class.
One sentence. "The class was ___." Name the category the instance belonged to. If you can't name it in one sentence, you don't understand the class well enough to check for it yet.
Write the minimum check.
Ten lines or ten minutes, whichever is smaller. The scrappy version that catches this class next time. The ambitious one can come later if the scrappy one fails.
Wire it in.
The check has to run without you asking. A pre-commit hook. A template default that can't be overridden. A validator that fires on save. If you have to remember to run the check, it's not a check yet.
Do this once. Watch what your check catches over the next month. The pattern reveals itself. The classes you convert stop appearing. The classes you don't convert keep coming back.
What's a class of defect you keep patching and haven't converted yet?
Reply with the class and the check you'd write. The best examples (anonymized) show up in future issues.
The class-vs-instance question sits underneath the whole delegation discipline. Presence Optionality builds the interface. Prove-Then-Replicate sequences the work. Redline catches defects before they ship. Turn the Fix Into a Check keeps them from coming back. Together they're the shape of a solo operation that actually scales.
Explore Strategic Thinking AcademyOr learn frameworks on your own for free on YouTube.
Strategic Thinking Weekly - New frameworks as they land
Unsubscribe anytime - Tampa, FL