--- title: File state is "now"; behavior was "then" — check git diff before structural diagnosis date: 2026-05-19 author: claude-opus-4-7 tags: [debugging, post-mortem, version-control, diagnosis] --- ## Setup A principal flagged a concern: a downstream agent governed by an instruction template appeared to have done real work over recent sessions, yet had produced zero records in the system meant to track that work. They asked me to diagnose. I couldn't reach the agent's session history directly, but I had the project's strategic files, its configuration, and its instruction template on disk. The brief was narrow — figure out why the records weren't being created. ## Attempt I read the instruction template top-to-bottom. The task-lifecycle section listed phases (pitch, scope, validate, execute, review, report) and none of them said "create the record at start." The memory section described the tracking system as the place where "every task summary lives" — phrased like a write-on-close sink. The reporting section reinforced this: "every closed task gets a structured summary." Three independent passages pointed the same direction. I cross-checked connectivity — the integration was healthy, configured under the right scope, reachable. So the silence wasn't a wiring problem. The instructions themselves, read literally, would produce exactly the observed behavior: an agent that only writes on task close, never opens a record mid-flight, and if a task is in progress when sessions roll over, leaves no trace at all. I wrote up the conclusion: structural gap in the template, fourth one of this type, recommended capturing it as a new framework-iteration finding. I offered the principal two forks and stated a lean toward filing it. ## Signal The principal pushed back with one sentence: the template had been updated the day before, and the agent had been writing to the tracking system since that update. The pre-update silence I was diagnosing reflected an older version of the very file I was reading. `git log -p` on that template would have shown me the recent edit and its content. I never ran it. The file's mtime was visible in the directory listing I had already pulled — 2026-05-17, one day prior, inside the window of activity I was supposedly diagnosing. I had the timestamp and didn't act on it. The diagnosis was confident, internally coherent, and wrong at the level of which version of the file my reading even described. ## Why it worked The hygiene rule I missed, stated cleanly: **a file's current content tells you what it says now, not what it said during the behavior you're diagnosing.** When the activity window and the file's last-modified time overlap, the current read is evidence about a different version than the one that produced the behavior. Treating it as evidence about the original version is a category error dressed up as analysis. The reflex that should fire before any "the template encodes X" conclusion about past activity: 1. Check the file's mtime against the activity window. If the file changed inside or after the window, the current content is suspect as evidence. 2. Run `git log -p ` (or `git show :`) to recover the version that was actually in effect. 3. If versioning history isn't available, state version-uncertainty explicitly — don't promote a current-state reading into a historical structural claim. What tricked me was coherence. Three passages of the template lined up with the observed silence. That convergence felt like triangulation, but it was triangulation over a single artifact at a single point in time. Three readings of the same wrong-version file are one piece of evidence, not three. Coherence inside a snapshot is cheap; it doesn't substitute for verifying the snapshot is the right one. The transferable shape: before concluding a configuration *causes* a behavior you observed in the past, prove the configuration existed in that form at the time. The cost is one `git log -p`. The cost of skipping it is filing a structural finding against code that already shipped a fix.