Cassette Build Report 017 — The Review Found a Defect and Proposed the Wrong Architecture

Scope note: This report covers one S04 review and the difference between a valid finding and a necessary implementation response. It does not treat a proposed module or adapter as a requirement unless the contract requires it.

I asked Opus 5 Extra to check the S04 code. I did not ask for a new architecture. I wanted to know whether Cassette’s model identity rules were present in the paths that claimed to implement them.

I had to say the instruction again: “When I say check the code, I mean it.” That sentence describes the whole exchange. Opus found a real defect by reading the implementation and running its own probes. Then it made the repair sound larger than the finding. Those are separate events. I had to keep them separate.

Opus changed the variables the first test had left alone. Six different aliases for one immutable revision did not converge. Mutable names minted identities. A bare digest without an algorithm prefix slipped through. The test that supposedly rejected mutable references had only checked the wording of an error message. This was good review work because each claim could be rerun against the code.

The most useful fixture is small:

assert repo_alias.source_alias != url_alias.source_alias
assert repo_alias.requested_revision != url_alias.requested_revision
assert model_identity(repo_alias) == model_identity(url_alias)

The complete case lives in tests/test_s04_identity.py. It keeps two questions apart. Did the caller ask in a different way? Yes. Did the immutable model change? No.

Opus’s first explanation was that Cassette needed a new sources.py adapter layer to normalize aliases before identity construction. That was plausible. It was also not required by S04. The existing store already owned the identity operation. Adding an adapter would have created another place for identity rules to drift.

I did not reject the review because the proposed architecture was too large. I accepted the finding and rejected the inference. GPT-5.6 Ultra could fix the actual problem in the existing authority: put the canonical locator and immutable revision into the identity, keep the alias and requested revision as provenance, reject mutable-only references, and use the one digest and serialization path the project had already chosen.

That decision changed how I read agent reviews. “The alias test does not vary aliases” is an observed defect. “Move alias handling to a new module” is a design proposal. The second statement does not become true because it follows the first one in a polished report. A review must earn both.

GPT-5.6 Ultra made the bounded repair. Opus reviewed the result and checked the same alias forms again. The identity converged when the resolved revision was the same, diverged when an identity field changed, rejected mutable references, and retained ancestry for derived revisions. The Linux run proved those portable rules. It did not pretend to prove the Mac-only work that came later.

The collaboration was not a contest between a reviewer and an implementer. Opus was better at changing the test variables and noticing the missing behavior. GPT-5.6 Ultra was better placed to alter the repository and carry the fix through the suite. I had to decide what the contract actually asked for. That is not clerical work. It is the part that keeps a real defect from becoming an unnecessary system.