Cassette Build Report 012 — The Smallest Honest Machine
Cassette's minimum implementation became a complete set of rules about code, evidence, recovery, and how agents should work without silently reducing the project.
Scope note: This post records the implementation rules established before Cassette’s machine phase. It describes the contract for a complete build, not a claim that the final runtime already exists.
“Minimum code” is easy to misunderstand.
I did not mean the smallest repository that could demonstrate a clever storage trick. I meant the smallest complete mechanism that could acquire the model, keep it on the external drive, execute it through the declared path, interoperate with clients, survive difficult states, and support the relevant updates when the model structure allowed them.
Claude Fable 5 helped turn that standard into rules.
The implementation would use one authored language, Python over a pinned MLX runtime. The choice was not a claim that Python is always the smallest or fastest language. It was a measured tradeoff: the project would count authored lines as a primary cost and state what the runtime contributed separately.
AGENTS.md became the single instruction authority. It named the objective, the no-failing-row-no-code rule, hard prohibitions, and a commit test that required every change to say what it reused and what it deleted. I added a file convention: the first line of every file must say what the file is and what it depends on. The accounting tool checks that statement against the actual imports so the convention cannot become decoration.
The structure became equally specific. Components use layers. Sibling components cannot import one another directly. Cross-component work passes through committed, journaled store objects, and one writer owns each on-disk object. The invariant ledger tracks what the tests protect. Orphaned tests and orphaned requirements are removed. Line coverage is not enough because a test can execute a line without protecting the claim that made the line necessary.
I also asked four questions that technical projects often avoid: What is the value? Who gets access? What is the moral boundary? Where should the answers live? PHILOSOPHY.md holds those claims beside the acceptance rows that can enforce them.
The sentence at the end of that file is blunt: a value without an acceptance row is marketing.
The working method is part of the machine. I want a straight line until done. I want agents to move through the queue without asking for ordinary permission at every step. Check-ins should be rare and reserved for catastrophic or genuinely ambiguous conditions. Physical testing of the real drive, download, and model belongs in one live campaign after the machine phase, not in a repeated cycle of small edits and manual interruptions.
That style creates a difficult obligation. If the agent is allowed to move, the repository must make its state legible when the agent stops, fails, or disappears. IMPLEMENTATION.md therefore carries twenty-eight machine-phase steps, a resume ritual, loop guards after three failed approaches, and a required stop before the live campaign.
This is where the agents were most useful as a design pressure. Fable 5 did not merely write code rules. It helped force the relationship between a requirement and its proof into the same document. My job was to keep the rules from becoming another substitute for the project: a process can be complete and still fail to build Cassette.
The result is a definition of minimum that I can defend. It is not the fewest lines. It is the smallest system that does not purchase simplicity by omitting the thing the user asked for.