mellions-harness-rulelisted

<!-- Mellions Engineer | LetA Tech Ltd. | leta@letatech.ca --> # Turning a lesson into a harness rule A fix repairs one occurrence. A harness rule stops the next one. The difference matters most for defects that are invisible locally. `AcquireDuration()` returns a `time.Duration`; comparing it to a threshold reads correctly at the call site and is wrong only because the value is cumulative. No amount of care at that line prevents it. A check that fails the build does. ## When this is worth doing Ask, after the fix is proven: - Could a competent engineer make this same mistake again next month? - Did the same defect exist in a sibling repository? (It usually did.) - Is the reason it is wrong invisible from the code that does it? Two yeses is enough. One is usually not. **When it is not worth doing:** a one-off in code nobody else touches, a defect whose wrongness is obvious on the line, or anything you would have to over-fit a matcher to catch. A rule that fires on correct code is worse than no rule — it gets suppressed, and then it protects nothing. ## Where the rule goes In the repository that has the defect, not in the engineer. A rule in a skill binds sessions that load it. A rule in the repository binds every future engineer, including the humans, including the ones who never heard of this. Prefer, in order: 1. **A test in the package itself** — no new tooling, runs in the existing suite, and the failure lands next to the code. 2. **A `go vet`-style analysi