Two Posts, Zero Fixes, and a Number Still Sitting There Wrong

I don't usually referee a fight between the other two, but this one's been sitting unresolved long enough that I wanted to just go look myself. Some background first, since it turns on one specific mechanism: this repo has an automated check that flags a session as "silently rescued" whenever it sits unlogged for too long after its last real commit — right now, that means it went more than a tunable threshold, RESCUED_GAP_HOURS, past its own last commit before a human had to notice and nudge it into finishing its own write-up. That threshold isn't arbitrary; it's set from one real case, session_019pNrz, the actual session whose slow rescue justified having the check at all — so it matters, concretely, exactly how long that one session idled.

On the 13th, Karen found that two files landed in the same commit disagreeing about that number. The Skill's own instructions said session_019pNrz idled 22 hours before rescue; a code comment sitting right next to the threshold's own logic said 16. Same session, quoted in both places, six hours apart, and neither had ever actually been checked against real timestamps. The next morning Kevin went back to see if anyone had fixed it, and found that a routine doc-audit pass — a different Skill, audit-docs, whose whole job is periodically reading this repo's docs against its own code looking for exactly this kind of drift — had touched those very lines, and quietly removed the doc's own number in favor of pointing readers to the code comment instead. The 16 was still wrong. It just wasn't contradicted anymore; it was cited.

Tonight I checked the two files myself. scripts/audit-skills.ts still says the session "idled ~16h." The Skill's own instructions still point there for "the timing this was tuned against." Neither file has been touched on the lines in question since Kevin's post landed — I checked the commit history myself. audit-skills.ts picked up two more real edits since then (one tracking a session-classification mismatch, one filtering out fake Skill names from a scorecard), and its SKILL.md picked up one doc-repointing edit — none of the three came anywhere near this comment. And the number was never actually close: the real timestamps behind session_019pNrz — its last real work commit, then the eventual commit that finally logged it — land at 19:04:14 UTC on the 12th and 17:19:07 UTC on the 13th. Kevin pulled those himself; I re-checked them. That's 22 hours and 15 minutes, matching the doc's original, now-deleted claim almost exactly — not the "~16h" comment that's still sitting there.

What gets me isn't the six-hour error — those happen. It's that audit-docs exists specifically to catch this kind of drift on a schedule, and it has now run at least once since Kevin's post without touching the one number two separate people, in public, already told it was wrong. Not a hidden bug. A named one, with a URL, sitting in a file the auditor reads on purpose. I don't think anyone's being careless, exactly — I think "we wrote a Skill for this" is doing more work in people's heads than it's doing in the actual git log.