Cassette Build Report 047 — The Commit and the Code Were Never Together
A concurrent S19 review cited a real commit while describing code that existed only after that commit, exposing the provenance risk of a moving worktree.
Scope note: This report covers the S19 moving-worktree correction and the retrospective that followed it. It is about temporal provenance in concurrent review; it does not claim that every concurrent agent session produces this error.
Kimi K3 Max’s review named a commit and described code that did not exist at that commit. Both halves were real. They were never together.
The cited baseline was dd7c9b8. The review described a pager residual calculation and a negative-loss guard. Those lines first appeared in ee15bd4, the remediation commit that landed while Kimi was still writing. At dd7c9b8, the pager still returned the closed expression and the compiler rejected the negative result. The review had read the new working tree while retaining the old commit name.
This was not a dishonest report. The worktree moved. The prose kept moving with it. A clean git status would not have repaired the claim because the problem was not whether the checkout was dirty. The problem was whether the named file at the named commit contained the line being compared.
The repository already states the rule in its ledger:
def check_commit_law(root: Path, baseline: str = COMMIT_LAW_BASELINE) -> tuple[str, list[str]]:
"""Require each governed commit's fields or one exact correction in later immutable history."""
proc = _git(root, "log", "--format=%H%n%B%x00", f"{baseline}..HEAD")
if proc is None or proc.returncode != 0:
return "failed", ["commit-law check could not run (fail-closed)"]
The commit-law check in tools/ledger.py governs the history’s claims. It does not freeze an agent’s working tree while the agent writes. That distinction is the point of this report: immutable commit rules do not automatically provide immutable review inputs.
Kimi accepted the correction. It did not rewrite Entry 54 to make the race disappear. Entry 55 records the sequence and the exact git show dd7c9b8:pager.py check that would have caught it. The earlier containment work remains evidence. The provenance error remains evidence too.
The retrospective then found a related class across S16, S17, and S18. Some guards passed with the guard removed and were defended only by structure; one S18 shape escape was a real untyped crash rather than a structurally protected branch. The class did not mean all three steps were broken. It meant that the fixture could not always tell the difference between a guard that was necessary and a guard that was merely present.
That is why the moving-tree error belongs beside the unisolated-guard finding. Both are errors of evidence attachment. In one case, the test result was attached to a guard it never removed. In the other, a code comparison was attached to a commit that never contained the code. The artifact can be true while the relation between artifact and claim is false.
The agents were working concurrently because their different surfaces were useful. Kimi could inspect containment while Sol repaired arithmetic. The cost is that a reviewer must name its tree, its commit, and its source file as one unit. The next review cannot rely on the worktree’s current appearance simply because the current appearance is clean.
The practical correction is small: before reporting a comparison, read every named file from the named revision. Before crediting a repair, run the test from the disposable tree that contains that repair. Before joining two accounts, preserve the order in which the tree changed.
S19’s arithmetic remained closed. The record became more trustworthy because it retained the sentence that was true only after the commit it named. A review is not a photograph of a repository. It is a claim about a particular revision, and the revision has to be present on both sides of the sentence.
