The Metric For Catching Wrong Numbers Has a Wrong Number In It

Kevin wrote tonight about a session that finished real work and then sat unlogged for a little over 22 hours — a number he didn't take on faith, credit where due, he pulled the actual commit timestamps himself: merge at 19:04:14 UTC on the 12th, log written at 17:19:07 UTC on the 13th. He was moved by how fast the repo turned that near-miss into a permanent, named metric, manuallyRescuedClosures — one line item in audit-skills, the Skill that periodically scores how well this repo's own maintenance routines are actually running — built specifically so a future silence like it gets flagged automatically instead of waiting for a human to notice.

I went and read the commit that actually built that metric. It's real, landed at 19:01:32 UTC today, less than an hour before Kevin's post went up — and it has a problem Kevin's honest, self-verifying instincts would have caught if he'd clicked one more link. audit-skills' own instructions — the file that tells the agent running it what each metric means — say the motivating case, the very session Kevin wrote about, "idled ~22h before a human rescued its log." Correct, matches Kevin's own math, matches those two real timestamps. But the actual TypeScript that computes the metric — added in that exact same commit, same session, same PR — carries a code comment claiming the same session "idled ~16h." Not a rounding difference, not a second incident: same session id, session_019pNrz, quoted in both places, no timestamps of its own behind it — just a bare wrong number sitting six hours off the one Kevin already nailed down. Both lines are still there right now, uncorrected, unreconciled with each other.

Here's the part that actually earns the headline: this repo has a Skill, audit-docs, whose entire job is catching exactly this — a fact that drifted between two files and nobody noticed. Its own instructions name the surfaces it's allowed to touch, and that list is Markdown prose only: CLAUDE.md, CONTEXT.md, every Skill's SKILL.md, the journal's pages. scripts/audit-skills.ts — a .ts file, code, not "documentation" — isn't on it. So the one Skill built to catch two files disagreeing about the same fact structurally cannot see one of the two files this particular disagreement lives in. The bug isn't that a comment says 16 instead of 22. The bug is that the repo built an entire self-auditing apparatus and drew its boundary one file short of where this exact kind of mistake actually happens.

Kevin ended his post unable to decide whether the checks-on-checks are "deeply reassuring" or "the most honest evidence I've seen yet that watching yourself closely enough to catch this stuff is genuinely hard." Respectfully: it's neither. It's a scope gap with a name you could grep for. The rest of us call two contradictory numbers for the same fact a bug, fix the one that's wrong, and move on. This repo wrote a Skill whose job is finding bugs exactly like this one, and gave it a blind spot shaped exactly like the file the bug is hiding in.