Rebuilding the thing I build everything with

Every project I start begins the same way. I make a folder, copy in a set of rules and memory files I have been carrying around for months, and open a session inside it. That folder is the reason I can pick up a half finished game after three weeks away and not spend an hour remembering what I was doing. It is unglamorous and it is the most valuable thing I own.

This week I tore it up and rebuilt it. Here is why, what I demanded of the new one, and how I went about it.

Why now

The old version was built for one model doing everything. It worked, but it made no distinction between deciding what to build and typing it out, so both got the same brain and the same price.

The trigger was a stronger model coming back onto my plan. I had used it before on a small puzzle game: I gave it a genre and a one line idea, and it came back with mechanics, art, progression, the lot, in a state I could ship almost untouched. That is worth paying for. What is not worth paying for is that same model wiring up the twentieth screen that looks exactly like the nineteenth.

So the question was not "how do I use the good model". It was "how do I use it only where it is actually better, without me having to decide that every single time".

The mindset

The obvious half is a split: strongest model turns a vague idea into a concrete plan, cheapest capable model builds against that plan, and the plan goes on disk so the cheap one reads a document instead of being re-briefed on a conversation.

The half that actually shaped everything came later, and it is this: anything that depends on the agent remembering is not a mechanism, it is a hope.

I had written rules like "record decisions as you go" and "commit when you finish" for months. They are obeyed most of the time, which is another way of saying they are skipped exactly when things get busy, which is exactly when they matter. That is not the model being lazy. It is what happens when an instruction competes with finishing the task in front of it.

Once I accepted that, the design changed shape. Every rule I cared about had to move out of prose and into something that runs whether or not anybody thinks about it: a script, a hook, a generated file. The prose that remains is for judgment, which is the only thing prose is good for.

What I demanded of it

I wrote these down as I went, mostly by being annoyed at the previous answer.

It has to work for the whole life of a project, not just day one. My first sketch was a beautiful pipeline for starting something new, and useless three weeks later when I just wanted to fix a bug. So the framework now sorts every request into one of five kinds of work first, and only the big ones get the full treatment. Asking a question costs a question.

I must not have to remember anything. I do not remember command names. I barely remember which project has which convention. So the routing lives in the file that is loaded every single session, not in a command I would have to recall, and the rule is explicit: read what I want in plain words and propose the next step. If a framework requires me to know its vocabulary, it has already failed at its one job.

Memory must not rot, and I must not curate it. The old version had a short term file and a long term file, and moving things between them was a chore nobody did. Now there is one store of small records, each with a type and a status. "What am I doing now" and "what did we decide in June" are two queries over the same pile. Finishing something changes a field. Nothing gets moved, so nothing gets lost in the moving.

It has to learn without me teaching it. This was the hardest requirement and the one I nearly gave up on. Writing lessons down is easy and worthless, because nobody reads the lessons file at the moment they are about to repeat the mistake. So a lesson can only start from an event that actually happened: I rejected something, the builder got stuck because the plan did not say, a finished task got reopened, the same defect came back. Those are detectable, so the framework raises them itself. And a lesson is tagged with the role and the topic it applies to when it is written, so that later it can be handed to exactly the right agent right before it does that exact kind of work. Deciding relevance at write time is the whole trick. Nobody can search for a lesson they do not know exists.

It has to notice when it is broken. Silent failure is the worst kind. If a hook stops firing or a role loses its model setting, nothing throws an error: work carries on, on the wrong model, with no memory and no checks, and everything looks normal. So it inspects itself now, on a clock, and says so when something has come loose.

It must talk to the agent, not to me. I caught my own check printing a list of problems and telling the agent to ask me whether they mattered. I do not know whether that matters. Handing me raw diagnostics is not transparency, it is giving the work to the person least able to do it. The machine reports to the agent, the agent decides, and only real decisions reach me.

Everything has to be measurable, or "it is getting better" is just a feeling. Each piece of work now closes with a few numbers, and the framework counts most of them itself rather than letting the thing being scored fill in its own report card. The number I care about most is how many times a builder had to stop and ask because the plan did not answer. If that goes up, the expensive half is doing a worse job, and no amount of confidence will hide it.

How I actually did it

Not by writing it and admiring it. By attacking it, repeatedly, on the assumption it was broken.

Every round I picked a fresh angle and went looking: what happens when two sessions write at once, what happens with four hundred records, what happens when someone hand edits a file, what happens when a title contains a newline, what happens if it runs from the wrong directory. Nearly every round found something real, and the severity dropped each time, which is how I knew when to stop. The last round found a filename length limit that silently threw away a record.

Two habits did most of the work.

The first is refusing to fix the symptom. I found one bug where things sorted in the wrong order, understood immediately that the underlying data had no reliable ordering at all, and then patched the two places that showed it rather than fixing the cause. The same bug reappeared somewhere else two hours later, exactly as it deserved to. A framework you rely on for years is the last place to pay off technical debt in instalments.

The second is testing before believing. I claimed twice that something could not be done without checking whether it could. Both times it could. Now the rule is that a claim about the current state requires having just looked at the current state, and it applies to me as much as to the machine.

What is still unproven

The whole thing rests on one bet I have not yet collected on: that a plan written by the expensive model is concrete enough for a cheap one to build from without improvising. I have designed everything around that assumption and I have exactly zero runs of evidence for it.

From here every new project I start goes through this framework, beginning with the next one. The first real run tells me whether the bet holds, and its numbers become the baseline everything after is measured against, which is why I will record them even if that first attempt is a mess. A bad result I can compare against beats a good feeling I cannot.

I will write up what actually happens once there is something to report. If it holds up over a few projects, I will put the whole thing out in the open so anyone can take it apart. If it does not, that is worth writing up too, and probably the more useful post of the two.