01The operator seat
One person decides; sessions build
Stoke Dev is one operator. The operator chooses what gets built and in what order, answers the questions only an owner can answer, and decides when something is finished. The building is done by agent sessions.
Each session starts against a single ticket in a single repository, in its own isolated copy of that repository, so two sessions working at once never touch the same files. Nothing changes until the operator has approved the scope: a session the operator is watching states its scope, the model it is running on and the expected size of the job, then waits for a yes, and work handed to another agent is scoped when it is handed over. Scheduled runs that work unattended are the written exception.
Tickets name the model they need. The strongest model is kept for decisions that later work will inherit, a strong model does most of the building, and a faster one builds to a spec that is already written.
A session ends by recording what it learned, writing a handoff for whoever picks the work up next, and queueing the next ticket. The operator reads the result and decides what ships.
- Unit of work
- One ticket in one repository
- Workspace
- An isolated worktree per session
- Starts with
- A scope the operator has approved
- Ends with
- A record, a handoff and the next ticket
02The fleet
Five machines, named by what they do
Sessions run across five machines. They share one manifest of repositories, so any of them can take any ticket, and an unattended check reports when one of them drifts from the rest.
A machine is described here by the job it does. A box that boots two operating systems is still one machine, and it is counted once.
- 01The operator's laptopWhere sessions start and where their work is reviewed.
- 02A second laptopThe same seat, somewhere else.
- 03An always-on desktop MacUnattended work and the nightly checks.
- 04A GPU workstationHosts the second brain and the long-running services.
- 05A small Linux machineKeeps the tooling honest on a third platform.
03The redaction gate
A gate on every commit
Every repository behind this site is private, and this site is public. A redaction gate holds the line between the two.
Before a commit is made on a fleet machine, a hook reads everything the commit adds. It refuses the commit if it finds a credential, a private key, a path into someone's home directory, or a name that must not appear. A session does not work around a refusal: it stops, reports what was refused, and the operator decides.
It runs on every commit because the commit is the last cheap place to stop a leak. Once a credential reaches a remote, history keeps it, and the only fix is to rotate it. The rules travel with the code, so every machine checks against the same list, and a census on each machine reports when the hook is missing. A second scan runs on the server for every pull request into a main branch and every push to one, so a commit that never met the first check is still scanned on its way into a main branch. A weekly pass rescans the main branch's whole history. A branch that never heads for main is not scanned there.
- Runs
- Before every commit on a fleet machine
- Looks for
- Credentials, keys, home paths, names that must not appear
- On refusal
- The session stops and reports
- Backstop
- Server-side scans on pull requests into main and pushes to it, plus a weekly pass over main
04Decisions
888 decisions, written down
When a session learns something that should outlive it (a decision and the option it rejected, an approach that failed, a trap that cost real time), it writes a dated record before it closes: the claim, the evidence, the path not taken, and what follows from it.
Before a record is committed, an independent agent pass normally tries to refute it, and every objection gets a written answer. When a pass is skipped, the skip and its reason are recorded. Records are corrected in place when a later measurement disagrees, and the correction says what was wrong. A wrong record that later sessions trust costs more than no record at all.
The corpus holds 888 records, written since the orchestration repository's first commit on 30 Jul 2026.
- Format
- One dated file per record
- Holds
- Claim, evidence, rejected path, consequence
- Reviewed by
- An independent refutation pass
- When wrong
- Corrected in place, with the reason
05The second brain
A second brain that has read all of it
The decisions, notes and documentation from the repositories are mirrored into one corpus of plain files, each with a header that says where it came from. Each night the GPU workstation embeds that corpus into a local, searchable index: the second brain.
Sessions and the operator can ask it what was already decided before deciding again. When it answers wrongly, the wrong answer is logged, so the next change to how it reads can be measured against real misses rather than impressions.
The files are the brain. The index is derived from them and can be rebuilt from scratch with one command. It runs on the operator's own hardware, behind its own access, and this site does not link to it.
- Source
- Plain files with a provenance header
- Index
- Rebuilt locally, nightly
- Wrong answers
- Logged as evaluation data
- Access
- Private