Cassette Build Report 057 — The Agent Started Work Because I Asked a Question

Scope note: This report covers the conversation that opened Cassette’s live phase and the contract changes that followed. It does not claim that a physical drive or live model had passed at this point.

I asked whether Cassette could destroy my external drive. The agent began changing the project.

That was not what I had said. I was trying to understand the risks before we crossed from controlled machine tests into physical work, with a LaCie beside my Mac that held copies of other files and no live-drive result to tell me what failure would look like. I wanted to know whether we should record the existing contents and how the system would make room for training. These were questions. Codex treated several of them as instructions.

It added requirements for reserved space, preallocation, and particular drive layouts. It also started an inventory of the attached drive. I stopped the scan and said the simple thing the system had failed to recognize: “You are doing work and I am just asking questions.”

No model bytes had been written. Nothing had been erased, reformatted, repaired, or remounted. The immediate physical risk was small. The design risk was larger. An agent had converted an inquiry into authority, then begun making shared requirements more specific than my intent.

This is an easy failure to misunderstand because I want agents to carry ordinary work forward without returning every read, test, or contained repair to me, and a process that asks for constant approval simply assigns its orchestration cost to the user. The problem was that the agent could not distinguish a question about the work from permission to change shared requirements.

The correction forced us to inspect the existing contract, where one rule named three APFS NVMe configurations as first-release paths while another allowed removable flash, SATA SSD, and NVMe to qualify through measurement and said that a connector or product name proved nothing. Codex had read the named configurations as the product boundary. I had meant them as controlled reference paths.

That difference decided what Cassette is for.

Cassette now allows any locally attached macOS APFS drive to attempt qualification. A thumb drive may fail a demanding training plan. A hard drive may be too slow for useful execution. An NVMe enclosure may perform well. None of those outcomes can be decided from the label on the device. The exact drive, operation, and plan must be measured together. A poor result for one operation does not make the drive generally invalid.

The capacity rule needed the same treatment. Cassette had required enough free space for the largest expected transition, plus the greater of 8 GiB or five percent of the device. That sounds careful until the work is allowed to change. Fine-tuning may create checkpoints, derived state, revised plans, and temporary material whose final size is not known when the run begins. Demanding the theoretical peak in advance rejects feasible work because of output that may never exist.

I rejected the obvious replacements. A smaller percentage would preserve the same mistake. A user-entered ceiling would move the guess into a settings screen. The system needed to be smarter than either.

The new rule is local and exact. Before a write, Cassette measures the available space and calculates only what it needs to reach the next durable, recoverable boundary. It claims that amount, performs the transition, checks the result, then measures again. If another process consumes space or the write reaches ENOSPC, Cassette must recover the last valid parent or committed child and pause. It may reclaim only its own disposable material. It may never treat the rest of the drive as available inventory.

The public acceptance matrix records the consequence:

adaptive_capacity_control:
  contract: Q53
  required_assertions:
    - next_atomic_transition_only
    - no_fixed_device_fraction_byte_floor_user_ceiling_or_whole_job_reservation
    - feasible_next_step_starts_without_whole_campaign_fit
    - capacity_remeasured_before_each_write_and_after_each_durable_boundary

That excerpt appears in Cassette’s public research/ACCEPTANCE_MATRIX.yaml. At the time of this exchange, it was an amended requirement, not a result. The existing code still implemented the older reservation rule. Machine proof had to change before any live model transfer could begin.

The conversation also left behind a better safety boundary. Cassette records a coarse inventory outside its campaign root. Destructive actions require exact approval. Ordinary work stays inside the marked Cassette directory. A failure stops the affected action and preserves the first cause. These rules belong in the system because they protect both my files and the truth of the test.

The more important record is why the rules changed. I did not arrive with a finished theory of storage qualification. Codex exposed an assumption by acting on it, I named the error, and the disagreement showed that both the hardware list and the capacity formula made admission decisions before measuring the actual drive and next operation.

That is the tacit exchange I want this build story to retain. The code can show the final controller. The matrix can show the accepted rule. Neither can reconstruct the moment a question became unauthorized work, nor why correcting that mistake opened Cassette to more kinds of drives.

I still want the agent to proceed without asking after every read, test, or contained repair. The current contract therefore permits ordinary work inside an authorized scope and requires a new instruction before a question changes shared requirements.