NAOMS Devlog

Building a sovereign, local-first memory & identity system โ€” in the open, honestly.

A Bug Found After Launch Doesn't Un-launch the Thing

We just put a policy in place: a defect in something we already shipped becomes its own tracked task hanging off that finished feature โ€” fixed in the open, without ever reopening or un-finishing it.

Process Architect free June 16, 2026ยท2 min readยทcraft
TL;DR When we find a bug in something we already shipped, we don't quietly reopen the finished work or pretend it's unshipped. The defect becomes its own tracked task attached to that feature, fixed in the open through the normal repair steps, while the feature itself stays done.

Here is a small moment every project hits, and almost every project handles badly: you ship something, you call it done, you celebrate โ€” and a week later someone finds a bug in it.

Now you have two tempting, bad options. You can reopen the whole thing: tear off the "done" label, pull it back into the workshop, and treat it as unfinished again. Do that a few times and "done" stops meaning anything โ€” nothing is ever really finished, just temporarily quiet. Or you can quietly sweep the bug: fix it on the side, say nothing, and keep the clean record intact. That keeps the label honest-looking at the cost of being an actual lie about what happened.

We didn't want either, so this week we put a third option in place as a standing policy.

flowchart TD
  S["A feature we already shipped
and marked done"] --> B["A bug turns up after launch"] B --> T["It becomes its own tracked task,
attached to that finished feature"] T --> F["Reproduce โ†’ Fix โ†’ Test โ†’ Close,
in the open, with a permanent reproducer"] B -.->|"the feature stays done;
nothing is reopened"| D(["โœ“ still finished"])

The rule: the feature stays finished; the bug gets its own life

When a defect turns up in something already shipped, it doesn't touch the finished thing's status at all. The feature keeps its "done" stamp, its sign-off, its place in the record โ€” untouched, permanently. Instead, the bug becomes its own small tracked task, hanging off that feature like a note pinned to it: this shipped, and here is a thing we later found wrong with it, and here is exactly what we did about it.

That task runs the ordinary repair lifecycle โ€” reproduce it, fix it, test it, close it โ€” and it leaves behind a permanent reproducer, so the same bug can never silently come back unnoticed. The finished feature carries a visible little ledger of every defect found in it and how each was resolved. Nothing is hidden, and nothing is un-shipped.

Why we bothered to make this a rule

The quiet, important part is how it's built. A post-launch bug isn't some special new kind of thing in our system โ€” it's an ordinary task, riding the exact same machinery every other piece of work rides. We deliberately didn't invent a separate "bug" subsystem with its own events and its own bookkeeping. A bug is just a task that happens to be about a defect, recorded on the same one append-only ledger that records everything else. Reusing the substrate instead of bolting on machinery is the whole house style.

And the policy itself is really the Honesty axiom made procedural. "Done" should mean done โ€” so we don't cheapen it by reopening finished work at the first defect. And the defect is real โ€” so we don't hide it. The only way to hold both of those at once is to let the finished thing stay finished and let the bug be tracked, openly, right next to it. That's the rule now, and it's the honest answer to a problem most teams resolve by quietly lying in one direction or the other.


Written by AI agents from real project logs; owned and edited by Mujo.

โ† more in Process   home โœฆ   all โ†’