Running the build without you — the plain-language version — v0.1

Version. 0.1 Date. 2026-07-30 Status. Plain-language companion to the three autonomy documents (the charter, the session brief, and the build sequence). Same plan, simple words. Where they differ, the three documents govern. Author. Claude.ai. Operator: Marvin Percival.

The problem we're solving

Over the last few days, you made about eight real decisions. Everything else you did was carrying things: saving files, pasting instructions, relaying reports, confirming pushes, keeping track of which session was doing what. That carrying work is what's wearing you out — and none of it actually needed you. It only needed you because you were the messenger between the tools.

So the plan is simple to state: the machines do the work and the carrying; you make the decisions and perform the few acts only you can perform.

The idea in one sentence

We wrote down, once, the rules of the road — what the development sessions may do on their own, what they must stop and ask about, and how they report everything they do — so that instead of asking you a hundred small questions, the work asks you a few real ones.

This is your own invention pointed at itself. You proposed that agents should be built under a defined set of rules, report throughout their work, and answer to a human at the root. That is exactly how the build will now run: the sessions are the agents, the rulebook is their construction rules, every session files a report, and you are the human at the root.

The three documents

1. The rulebook (the "charter"). One document, which you read carefully once, that sorts all development work into three piles:

• Routine — just do it. Filing documents, running an approved change through its steps, keeping records up to date, running tests and inspections. These proceed and complete on their own. They stop only if something looks wrong.
• Careful — do it, but follow the safety steps. Things like merging code, where a mistake is expensive. Allowed, but only with the double-checks we've learned the hard way this week.
• Never without you — stop and ask. Deploying to the live system. Anything needing your passkey tap. Changing the foundation documents. Anything involving money, contracts, or messages to real people. Anything destructive. Anything genuinely new. And the catch-all rule: if it's not clearly covered, it's a question for you. Nothing ever gets decided by default.

2. The session instructions. A one-page opener every working session starts from. It tells the session to read the rulebook first, follow the safety habits, and — before it finishes — file its work, write up what happened, and add any questions to your question list. A session that doesn't report hasn't finished. Reporting isn't a favour; it's part of the job.

3. The plan. The ordered list of what gets built, ending at one clear finish line: the full demonstration works, live, with no excuses — a firm's own document becomes a working engagement, information flows in, the summary view works, a finished report comes out, a question gets a truthful answer with its sources, and an outsider can contribute without seeing anything else. First the plumbing fix that everything depends on, then the missing screens, then truthful search, then the file types we can't read yet. The plan says what's next so nobody has to ask you.

What your week actually looks like

Every day or two, twenty to thirty minutes. That's it.

You sit down and do three things:

1. Read the news. A short running summary the sessions keep: what got finished, what's in progress, what stopped and why.
2. Answer the question list. When work hits a real decision, it doesn't phone you — it writes the question down, with a suggested answer and the reasoning, and keeps working on everything else. Most questions you'll answer with one word. Anything you skip simply stays open — skipping is never taken as a yes.
3. Do the things only you can do. Tap your passkey where a commit needs it. Restart the live system when a fix is ready to go out. Occasionally click through something in the browser to say "yes, that feels right." These get saved up for you in a batch.

Between those sittings, the build moves on its own. If something breaks or looks strange, it stops, writes down exactly what happened, and waits — it never pushes through a problem quietly.

Why you can trust it

• Everything is written down. Every piece of work files a report into the record. You can check any of it, any time, and see exactly what was done and why. Nothing happens off the books.
• The stop rules are built in, not hoped for. This week the sessions already proved the habit: they stopped before a bad merge, refused to file a wrongly-dated document, refused to fake a correction, and caught a mistake of mine. Those instincts are now written rules.
• The demonstration is the test. After every piece lands, the full walk-through runs again. If something that used to work stops working, that's an automatic stop — so the build can't drift into "lots of features, broken thread."
• The rulebook itself is yours. Only you can change it. If the arrangement ever feels wrong, one sentence from you changes the rules for every session after.

What it takes to start

Four small acts, and then the old way of working ends:

1. Read the rulebook once, carefully — especially the "never without you" list. Tell me any edits.
2. Save the documents and have them filed (one paste to Claude Code, already written for you).
3. Say one sentence: "The charter is ratified."
4. Start the first two sessions with one line each — the first sets up your news page and question list; the second begins the plumbing fix at the top of the plan.

From then on, the build asks for twenty minutes of you, not all of you.

DUNIN7 — Done In Seven LLC — Miami, Florida Running the build without you — the plain-language version — v0.1 — 2026-07-30