Fixed Once Is Not Fixed Forever

One system check turned up several problems. The same agent-skill name appeared in different loading sources, and the error log already contained load failures. Configuration copies that should have matched had diverged. Obsolete workspace directories were still confusing name resolution. None of these brought the whole system down at once, but together they made the next run less predictable.

What worried me most was not a directory left behind. It was the earlier record saying the issue was “fixed.” That record may have been true on the day it was written. Tools get upgraded, directories move, and loading sources change. A sentence about the past cannot establish the state of the system today.

Fixing something is an action. Remaining fixed is a separate claim.

From a completion record to a checkable condition

I had plenty of notes that said “resolved.” They were missing the important half: how would I know if the problem returned? For duplicate skill names, I turned the conclusion into a condition evaluated against the current loading sources. Active skills must not have unapproved namesakes that could make loading ambiguous. A failure identifies both definitions. An approved exception applies only to specified files; adding a third copy does not inherit that exception. An old note saying “done” cannot make the check pass.

This is different from waiting for someone to report that a skill has stopped working again. A load failure is the outcome; the name collision is a condition that can be seen earlier. Leftover workspace directories work the same way: they look like harmless housekeeping until they enter a loading source and give the resolver multiple candidates. If I watch only errors, I have to wait for each failure to recur. If I watch the condition, I can see the risk before the next use.

I made another “resolved” claim checkable too. Where configuration copies were still in use, files that existed on both sides and were meant to be synchronized could not silently drift from the master. Matching on the day of repair says nothing about the next one-sided edit. The check only reads and compares shared files, reporting where they differ. It cannot prove that missing files were synchronized, and it does not overwrite anything. Automatic repair might erase a change worth keeping. After an alert, a person still has to choose whether to synchronize, preserve a difference or change the architecture.

The checker also needs correction

The first version of a check was not perfect. It flagged a situation that was actually allowed. A red result was not a verdict: I had to inspect the directories and loading behavior to decide whether the system was broken or the condition was too broad. I corrected the check. If false alarms become routine, they bury the regressions the check was meant to catch.

Later the operating setup changed again: I consolidated it and no longer kept multiple copies that needed synchronization. A daily comparison of those copies had become obsolete. Rather than report a pass for copies that no longer existed, I disabled that check and recorded why. A safeguard does not stay right forever just because it was once written as a rule.

These two corrections changed how I think about repeated verification. The checker is not an infallible extra layer of automation. Its logic must answer to observed facts, and its own assumptions have an expiry date.

What deserves a recurring check?

I do not turn every work note into a daily job. A state is worth guarding when it can regress unnoticed, the regression can affect later actions, and the present condition can be checked from real state at modest cost. Skill names, loading sources and configuration consistency met that test. Whether a discussion reached genuine agreement, or a user was satisfied, is not something a script can decide for people.

For a critical state, a “done” record should retain at least four things: what was verified then, how to verify it again now, what evidence a failure should expose, and when changed assumptions should retire the check. Without those, the completion record is only an archive. With them, it can be tested against reality before the next use.

I still write “fixed.” I just no longer treat that word as a promise about every day that follows.