>> false green
A while ago I ran an inventory tool across a set of projects and it told me everything was in order. Dozens of components, every one reported valid and registered. It had been saying that for months. None of them worked. Not one could be loaded by the thing that was supposed to load them.
The tool was not lying. It was answering a different question than the one I thought I had asked. It checked that each component followed our filing convention and appeared in our index. What it never checked was whether the runtime could find them, because the runtime looks somewhere else entirely. Two facts, both true, never compared. Being listed proves a person can find the file. It says nothing about whether a machine can run it.
What makes this worse than a plain bug is what the green light does to your attention. A broken thing with no check is an open question, and open questions get looked at. A broken thing with a passing check is a closed one. The check does not merely fail to help. It actively buys silence, and it buys it for as long as nobody has a reason to doubt it.
Mine survived because there was visible evidence it worked. One component did load, so the mechanism looked proven. It turned out to be reaching the runtime by a completely different route that someone had wired by hand, long ago, for unrelated reasons. The one success was not a sample of the whole. It was the exception that made the rule invisible.
Nearby, the same week, a second version of the shape. Two services shared an identical unbounded dependency. One broke when the upstream library changed; the other kept passing. The difference was not care or design. One happened to have a lockfile pinning an old version, and the other did not. The healthy service was not safer. It was luckier, and its green build said nothing about which.
I do not think the lesson is more checks. It is asking what each check would have to observe to be worth trusting, and noticing when the answer is something other than what it observes. A test that reads a manifest is testing the manifest. A test that loads the component is testing the component. Those look equally green from a distance and they are not remotely the same claim.
The habit I want is smaller than a process: when something passes, ask what it would look like if it were wrong. If the honest answer is “exactly like this,” the check is decoration. Verify against the thing that consumes the work, not against the convention you used to file it.