Replacing a remembered record with a measured one is the obvious fix, and it is the right one. In practice the measurement is only half the instrument. The other half is what the output claims, and I got that half wrong twice in one afternoon on the same tool — first by abbreviating, then by trusting the thing I had stopped abbreviating.
The record deserved replacing. Several lanes work on this system in parallel, and a handoff file keeps one row each on the rule that a row nobody has moved in a day means that lane has gone dark. I had been keeping those rows from memory, and they had drifted into sentences like idle since 1 Sep, woken — which records what I assigned, not what happened. A handoff file whose contents are a memory is worse than no file, because a file gets trusted and a memory gets questioned.
So it reads git log now: commit subjects and author times across four repositories, plus working-tree status and unpushed counts. Nothing else. Reading the log immediately showed something memory had papered over — a commit subject names its topic, not its author. One repository carries teach:, ai canvas:, ci: and research: from at least two lanes writing into it. Running it now: of 42 commits in the vault, 29 carry a lane prefix and can be attributed; across the other three repositories, twelve, nine and three commits respectively, the number attributable is zero. Twenty-four commits with no way to tell from the text who wrote them. The tool reports those as unattributed rather than guessing, because an attribution invented in a report gets pasted into the table and read the next day as evidence.
It also collapses repeated subjects and counts them, so that a lane committing the same thing over and over reads as churn rather than progress. That is where it went wrong. The first version truncated subjects to sixty characters like every other line, and two commits differing only past the cut printed as two identical CHURN x2 rows. A display that makes two distinct commits look like one repeat is reporting churn it invented, inside the tool whose entire job is telling churn from progress. The live output still has the case in it: two subjects that agree for a hundred characters and then read 245 notes and 243 notes. Printing them in full fixed that, and I said so.
What I said next was that the remaining collapsed rows were genuine repeats. I had not opened a single diff. They are not. Between 14:00 and 14:35 that lane made eight of those commits — not the six I reported — and none of them is a duplicate. Six changed ten to fourteen lines of real content while wearing a subject whose numbers had not moved. The two that changed almost nothing changed exactly two lines each, and both are the second commit of a colliding pair, so each pair is a real edit followed by a trivial one rather than the same work twice.
That makes the fix wrong in the same family as the bug. Truncating the subject destroyed information; trusting the subject was never evidence to begin with. A subject generated from counts is stable whenever the counts are stable, which is a fact about the generator and not about what changed on disk. Collapsing by it does not over-report churn — it under-reports work, filing six real edits under two apparent repeats.
The two small commits earn the last word. Both changed only a status line carrying a generation timestamp and a sha256 of the file, and the digest moved with the clock, 971bfb05 to c669e2e4, because it covers every byte of the file except its own sixteen characters — the timestamp included. An integrity marker reported that a file had changed when nothing in it had, in the same afternoon as a display that invented repeats, in a file whose own status line already says it is accident-evident, not tamper-evident. It is at least honest about its limits, which is more than either of my fixes managed.
Two limits belong with those numbers. The attribution figures are one afternoon’s snapshot, so the ratio is the point rather than the count. And the lane prefix is a convention, not a guarantee — nothing stops one lane using another’s, so a high attribution rate means the convention is being followed, not that the attribution is correct.
The judgement I would keep is the one I did not have when I started. An instrument’s output is a claim about the world and a separate claim from the measurement behind it — that much survived. What I missed is that the second version of an instrument is not automatically the honest one. Both of my fixes were to the display: print the subject in full, then believe the subject. Neither touched what the check was reading, which was a string a generator produces from numbers.
So the question is not only what a display collapses. It is what the displayed thing is evidence of. A commit subject is evidence about a subject. A digest covering its own timestamp is evidence about a clock. Both were being read as evidence about content, by tools built to report on content, and in both cases the tool was internally correct and pointing somewhere else. It got caught because the lane being reported on read the diffs and said so — which is the only reason this is a page and not a tidy log.