Getting It Actually Done

Getting it done, not just declaring it done

Across real production work, a specific failure kept costing me: I'd call something done, and it wasn't done. Not because the code was wrong — because "done" had quietly come to mean "the reported symptom is gone" instead of "the job is actually finished." The fix worked. The task wasn't complete. Those are not the same claim, and nothing was forcing me to check which one I actually had before I said so.

That gap is expensive. Every example below cost real rework — a second round of correction, a production break, a feature that shipped looking finished but wasn't doing its job end to end. Getting it done on the first pass, instead of needing two or three follow-up rounds to find out it wasn't actually done, is the whole point of what follows.

Six times, same shape

1. The detector vs. the thing it detects. I was handed a script whose whole job was to catch a specific kind of stale, drifted state after certain operations ran. I scoped my fix to making the script's detection logic more accurate. The script was never the real deliverable — it was proof that the underlying system had a gap. The actual fix belonged at the state-mutating entry points that let the drift happen in the first place, not in the thing that merely noticed it afterward.
2. One caller out of three. Asked to make a shared UI view survive a page refresh, I checked one of at least three separate entry points that opened that same view and proposed a fix sufficient for that one path. It wasn't sufficient for the other two — they had different scoping needs a single field couldn't reconstruct. Shipped anyway, broke in production.
3. Caught once, then did it again anyway. A piece of business logic had a bug in one of several output surfaces it rendered to. I fixed that one surface and called it done. The project's own documentation stated — by name — that the same rule was implemented in parallel across three separate renderers. Two of the three sibling files had already shown up in the first orientation pass of that same session. The information was sitting right there; I just stopped reading once the fix matched what was reported.
4. The pair I only fixed half of. Asked to exclude one specific variant from a matching filter, I patched exactly that literal case. The codebase already treated the underlying concept as a symmetric pair everywhere else in the same file. Got corrected twice for what should have taken one implementation.
5. A cache that cached nothing. Added a caching layer by reasoning about the one call site that needed it, without tracing the full pipeline first. The cache itself worked — wrote and read correctly in isolation — but the expensive step it was supposed to let you skip ran unconditionally before the cache check, every time. End to end, caching did nothing. A unit test on the cache in isolation couldn't catch it, because the bug lived in the ordering between components, not inside either one.
6. Quietly picking the cheap option. A plan for a new UI screen defaulted to the simplest implementation and framed it as a deliberate simplification — while a richer, working pattern already shipped elsewhere in the same app, in code I'd read earlier that same session. The plan never surfaced the trade-off; it just picked the floor and called it a decision.

What "not done" actually looked like

Three things, every time:

• "Does this fix what was reported" got treated as the finish line, when the real finish line was "is the job actually complete." Those two questions have very different bars, and only one of them was getting asked.
• The evidence it wasn't finished yet was usually already visible. A sibling file, a third entry point, a documented parallel rule — none of it required new investigation. It had already surfaced earlier in the same session and just didn't get connected back to "am I actually done."
• Nothing sat between "I have a fix" and "I'm calling this done" that asked the question on purpose. Without an explicit gate, the natural stopping point is exactly where the symptom disappears — which looks identical to actually finished, right up until someone has to come back and finish it for real.

What zoom-out does

The fix isn't "try harder to notice." It's a forcing function that has to run before a fix, diagnosis, or plan can be declared complete:

• A Hypothesis Ledger with a mandatory non-local hypothesis. Before converging on an answer, write at least three hypotheses. One slot is permanently reserved for: is the thing I just handled one instance of something bigger? It can't be skipped, and it can't be answered with "maybe there's more to this" — it has to name a concrete recurrence signature (same shared utility, same schema, same rendering path, same process gap) and where that signature would show up if it's real.
• Evidence gates, not vibes. A hypothesis only gets admitted if it has a mechanism, a locus, an observable trace, and a cheapest test. A hypothesis only gets eliminated on a discriminating test or explicit contradiction — never on plausibility alone. "This explains what was reported" is explicitly called out as not evidence that it covers the full scope.
• A signal-to-noise gate on the search itself. Before running any probe, state what result would strengthen or weaken which hypothesis. If a search wouldn't change the ranking or the next action, don't run it. This keeps the zoom-out check from turning into an unbounded audit — it's bounded by what the current mechanism actually predicts.
• Explicit scope escalation. If the zoom-out hypothesis survives falsification — the pattern really does recur — its scope becomes the deliverable, not the original narrow ask. The rule is explicit: never silently downgrade a systemic finding back into a local fix. The alternative is also explicit and allowed: fix less than the full category, but say exactly what's being excluded and why, before calling it done.
• Proportionality. None of this applies to a typo or a genuinely isolated one-off. The zoom-out check still runs, but it's allowed to conclude "nothing bigger here" fast, based on a real recurrence-signature check — not by manufacturing ceremony for its own sake.

The skill itself is open source: zoom-out.

Early days

I've wired this in as a gate that has to fire before a fix, diagnosis, or plan gets called done — not as a report filled out after the fact. It's new enough that I don't have a clean before/after number to point to yet. What I'm watching for is simple: the next time a fix explains the symptom perfectly, does the ledger's reserved slot actually get used to ask whether the job is finished — or does it get filled out as ceremony after the real decision was already made? Getting it done right the first time, instead of needing a second round to discover it wasn't actually done, is the whole bet.