Cassette Build Report 051 — The Meter Was Honest; the Boundary Was Not

Scope note: This report covers the S22 review, repair, and closeout for training admission and metering. It establishes deterministic repository evidence for those boundaries; it does not establish physical-drive endurance or a live training campaign.

A training job can look careful while it spends more storage endurance than it was admitted to use. Cassette is built around a model that remains on external storage, so I needed S22 to decide before a job started whether the device had enough free space, remaining write life, time, cooling, and power for the work, then to keep checking that decision as the job ran. A number in a report was not enough. The meter had to be tied to the bytes that were actually written, and the test had to fail when a claimed limit disappeared.

Kimi K3 Max reviewed the step while it was still in progress. The machinery deserved its credit. S22 had one training-admission path, reused Cassette’s existing capacity reservation instead of creating a rival allocator, and tracked logical, read, physical-write, and elapsed counters at checkpoints. The fixture accepted an exact-fit reservation, refused a one-byte short reservation, and refused an observed physical-write total that exceeded the admitted p95 projection. It also checked forged admissions and durable records. Forty-two repository tests passed, and the ledger reported no violation.

Then Kimi removed two guards. The fixture stayed green when the eighty-percent endurance envelope became one hundred percent, and it stayed green when the monotone physical-write check disappeared. That did not mean the production guards were dead. Direct inputs still made them refuse the hostile cases they owned. It meant the fixture had named those boundaries without making them necessary to a passing result. I had seen that failure before in S21: a test can describe a protection more fully than it exercises it.

Kimi also raised a separate accounting question. trainer.py had grown to 2,570 lines, well past the repository’s threshold for an authority explanation. The ledger accepted the stated reason, one training state machine with admission, metering, durable checkpoints, restart, and publication joined together. Kimi’s concern was not that the code had become incorrect because of a line count. It was that a justified exception can become routine when nobody revisits the cost of keeping the work together.

I asked Opus 5 Max to review the same surface critically. Opus began with a useful negative result. The planned write projection and the meter were not secretly the same calculation performed twice: the fixture derived its expected values with literal arithmetic, and removing a term from that independent calculation made the test fail. The meter also counted the serialized manifest that recorded the meter, which mattered because bookkeeping bytes remain bytes.

But Opus’s first mutation control survived. The tempting explanation was a broken harness; that had happened before. Opus checked, and the harness was sound. The control was wrong. It had been chosen from a guard that Opus expected the fixture to cover, which quietly assumed the conclusion under review. Opus discarded that batch, took a control from the fixture’s own arithmetic assertion, and ran the work again. That correction narrowed the finding instead of enlarging it. Some guards were properly proved, some were not, and a repeated comparison that first looked duplicated required more reading before it could be judged.

The distinction mattered because a mutation battery is an instrument, not a verdict machine. Kimi had found real gaps. Opus had improved the method that separated a missing proof from a broken test. Neither review was a command to change code. I asked GPT-5.6 Sol Ultra to assess the reports against the current tree, decide what held, and repair the proof where it did not.

Sol reproduced the clean result and tested each disputed guard in disposable copies. The product refused a raw update one byte below its 32,768-byte floor, a device whose reported lifetime writes already exceeded its declared endurance, each endurance ceiling independently, declining cumulative counters, and a live or durable meter above the admitted estimate. That work also resolved the apparent duplicate. One identical-looking comparison checked a live observation before the next write; the other checked a meter loaded from durable cartridge state. They shared an inequality because they enforced one admitted limit, but they trusted different evidence. Removing either would open a different door.

The repair changed the fixture rather than the product. The relevant proof was frozen in b4f0cac34da265d5f049248eba2cdffc2556e060, where the test reads each material page from a scratch cartridge and compares the durable meter with those bytes plus the canonical manifest:

    material_bytes = sum(
        len(read_training_page(cartridge, checkpoint.work_root, page_digest))
        for page_digest in material_digests
    )
    assert manifest["meter"]["logical_write_bytes"] == material_bytes + len(manifest_payload)

The S22 fixture at lines 305–309 establishes that the tested durable logical meter accounts for the recorded pages and its final manifest. It does not measure a physical drive’s wear. That claim remains outside this fixture, as does any live training run.

Sol then separated the hostile cases that had previously collapsed into one generic endurance refusal. The revised Q28 test forges live and persisted counters independently. The Q74 cases drive each cumulative counter backward while the others advance, distinguish the eighty-percent lifetime ceiling from the one-fifth remaining-endurance ceiling, and require the exact early diagnosis when a device has already written beyond its declared endurance. One first run used the wrong test invocation and failed during collection; another mutation runner used zsh’s reserved status variable and stopped before it had evidence. Sol treated both as tool failures, removed the agent-created mutation tree, corrected the commands, and restarted. The final battery killed its assertion-derived control and eleven guard removals.

I kept the training state machine intact. Splitting it merely to reduce the line count would have added state plumbing and a second authority before anyone had shown a lower-cost design. The size remains recorded, and the next reviewer can challenge that decision with an actual alternative rather than the number alone.

S22 closed after the pinned arm64 macOS suite passed all forty-two tests and the ledger was clean; the closeout commit, af9b09a2fee573883fa9bc024da5cd55408adac6, bound that evidence to the completed step. The durable result is narrower and better for it. A future change now has to preserve both the training boundary and the test that makes its absence visible.