The Method · v0.1

The Method

Coding agents made writing code cheap; deciding and proving it is now the bottleneck, and a fleet needs conventions the way web applications needed Rails.

The mission is every day the same. A check, a gate and an answer about the repository are identical wherever the work happens: in an agent’s worktree, on a laptop, in CI or in a release.

This page will give the principles one line each, and say what the Method is not: a framework, a vendor, or a finished answer.

  1. 01One shellEvery command runs in the one shell the repository declares.
  2. 02One agent, one worktreeEach agent works alone in its own worktree, and submits rather than merges.
  3. 03Capture at the sourceWork begins as captures, taken unattended where things happen.
  4. 04Intents and boltsWork is an intent, landed in bolts of small units.
  5. 05Two loops, one gateDesign and construction are separate loops, and a person decides where they meet.
  6. 06Order at landing, never at startWork starts at once; the merge queue orders it as it lands.
  7. 07Never prove twiceA check that passed on these inputs is not run again.
  8. 08Secrets by declarationAn agent gets a secret only through the shell, for the task at hand.
  9. 09Measure the fleetCount what lands, what it cost and what came back.

Each follows in turn, beside a diagram of its idea.

One shell

Every command, an agent's, a person's or CI's, runs inside one shell the repository declares, so the tools and their versions are the same everywhere.

Today, where it's going, and its record

How we do it today

devenv declares every tool; hooks, CI and agents enter the same shell.

Where it’s going

The shell is part of a repository’s manifest, so any platform that runs the repository knows how to enter it: devenv here, a container image or mise elsewhere.

Notes that cite it

No note cites it yet.

Changes

v0.1: introduced · reviewed 2026-10-06 · draft

One shell: every command runs in the one shell the repository declares Four places where work runs: an agent in its worktree, a laptop, CI and a release. Each sends the same command, site-check, into the one shell the repository declares. The devenv shell resolves only the tools it declares, and every place gets back the same verdict from bun 1.4.2, node 24 and vale 3.24.0 alike. Partway through, the agent tries npx vale@latest around the shell, and it is refused because it is not declared. One shell every command runs in the shell the repository declares WHERE WORK RUNS THE SHELL THE REPOSITORY DECLARES THE ANSWER agent · worktree $ site-check $ npx vale@latest laptop $ site-check CI $ site-check release $ site-check devenv devenv.nix bun 1.4.2 bun1.4.2 node 24 node24 vale 3.24.0 vale3.24.0 hooks, CI and agents enter the same shell and run only the tools it declares npx vale@latest npx vale@latest not declared site-checkpassedbun 1.4.2 · node 24 · vale 3.24.0 site-checkpassedbun 1.4.2 · node 24 · vale 3.24.0 site-checkpassedbun 1.4.2 · node 24 · vale 3.24.0 site-checkpassedbun 1.4.2 · node 24 · vale 3.24.0 the same tools and the same verdict 1Every command entersone shell. 2The repository declaresits tools and versions. 3A tool outside thedeclaration doesn’t run. 4Same tools everywhere,same answer.

One agent, one worktree

Each agent works in its own worktree with its own ports, emulator and dev servers, and submits its work to a merge queue rather than merging it, so nothing it does can disturb another.

Today, where it's going, and its record

How we do it today

Worktrunk, hashed ports, an emulator per worktree, Portless names, servers tethered to the worktree. Each session merges its own work: Worktrunk rebases, runs the gate and fast-forwards if nobody moved the line first.

Where it’s going

Worktree environments declared once and stood up from the declaration.

A session submits its head to a line and does nothing more: it never merges, never lands and never moves a line. The merge queue performs every merge and every landing (sluice statement, clauses 1 and 2).

Notes that cite it

No note cites it yet.

Changes

v0.1: introduced · reviewed 2026-10-08 · draft

Capture at the source

Work begins as captures taken where things happen, a meeting, a chat, a log, a pull request, by adapters that run unattended, so development is fed by what people and systems say rather than by tickets someone remembered to write.

A capture is one source event as recorded: a meeting, a day of a chat channel, a log run, a forwarded message. It holds where it came from, when, who captured it, and a pointer to the raw material, which stays outside version control. Capturing the same event twice yields one capture (Flywheel Next statement, clause 111).

Capture costs no more than a sentence: a forwarded message, a word on the phone, a file dropped in a folder, a key on the page (clause 112). Nobody is asked to classify what they wrote.

An adapter is what makes capture automatic. It enumerates a source’s events and writes one capture per event, unattended. Reading a capture into signals is judgment, so a session does it and nothing does it unattended (clauses 115 and 215). The adapters cover a chat forward, a meeting transcript, a log or monitor webhook, a pull-request conversation, an issue tracker and a folder drop.

Curation then moves every signal. It attaches the signal to an open intent, challenges a standing claim, joins a proposed intent, marks it answered, routes it to a chore, or drops it with a reason. An unmoved signal is never discarded (clauses 116 and 118).

Today, where it's going, and its record

How we do it today

Findings are recorded by hand with Crew’s signal command, and the first corpus of captures was written by hand from meeting transcripts.

Where it’s going

Flywheel Next’s adapters, each running on whichever host declares its source, writing captures from any machine (clause 217g). A meeting ends and its decisions are already waiting as signals beside the intents they bear on.

Notes that cite it

No note cites it yet.

Changes

v0.1: introduced · reviewed 2026-10-12 · draft

Intents and bolts

Work is an intent broken into bolts made of units, one reviewable change each. A unit merges into its bolt as it finishes, and the bolt lands on the shared line as one delivery.

Today, where it's going, and its record

How we do it today

Crew’s bolts and units, as OpenSpec changes.

Where it’s going

Flywheel Next tracks intents from capture to landed.

Notes that cite it

No note cites it yet.

Changes

v0.1: introduced · reviewed 2026-10-12 · draft

Intents and bolts: work is an intent, landed in bolts of small units An intent, one plain sentence of what someone wants, breaks into two bolts, each one delivery. Each bolt breaks into three units, one reviewable change each. As each unit finishes, it merges into its bolt's line, a short branch off the shared line, and the shared line does not move. Once all three units are in, the bolt lands on the shared line as one step; then the second bolt does the same. Below, a long-lived feature branch of 3,000 lines, which the principle rules out, keeps taking commits but never lands, and is struck through. Intents and bolts work is an intent, landed in bolts of small units AN INTENT BOLTS · EACH MADE OF UNITS A BOLT'S LINE THE SHARED LINE “Exports fail when the API rate-limits us.” Back off and retry 3 units 1 of 3 merged 2 of 3 merged 3 of 3 merged · landing landed Resume an export 3 units 1 of 3 merged 2 of 3 merged 3 of 3 merged · landing landed long-lived feature branch · 3,000 lines shared line backoff retry-after retry-test save-cursor resume resume-test 1An intent sayswhat someone wants. 2It breaks into bolts,each one delivery. 3Each unit, one change,merges into its bolt. 4The bolt lands on theshared line as one.

Two loops, one gate

Design and construction are separate loops, coupled where a human decides, and agents never approve agents; the operator's word comes before the work is tested, never between test and landing.

Today, where it's going, and its record

How we do it today

The operator approves each unit in Crew.

Where it’s going

Flywheel’s rail, with numbered decisions answerable from anywhere.

The operator’s word sits in two places: at the proposal, before construction starts, and at a channel’s promotion, before a release reaches anyone. Closing a bolt is its submission to the shared line. Landing on main is automatic once the candidate is green, and a fix after a failed landing resubmits with no new word (sluice statement, clause 4). There is never a word between a test and its landing.

Notes that cite it

No note cites it yet.

Changes

v0.1: introduced · reviewed 2026-10-08 · draft

Order at landing, never at start

Dependencies are constraints the merge queue honours when work lands, not gates that keep a session from starting; conflicts are found cheaply when work is combined, not planned around.

A unit starts at once. When it depends on another unit, it starts off that unit’s branch and names it as work to land after. The queue never lands it first (sluice statement, clauses 3 and 6), and waiting on a dependency holds back nobody else (clause 7).

The queue forms each candidate exactly as it would land: the line, plus every entry ahead of it, in order. A conflict is found when the candidate is formed, before any check runs. It removes only that entry, and the rest of the chain continues (clauses 10 to 12).

A failed candidate has exactly one culprit: the newest entry of the first candidate that failed. It is named only once everything ahead of it has a verdict, and only its session hears of it (clauses 17, 18 and 20).

Work that touches separate parts of the repository is never tested together and lands in either order (clause 8).

Today, where it's going, and its record

How we do it today

Crew orders units in its plan and starts a unit only after the units it depends on have merged into the bolt.

Where it’s going

sluice, a merge queue for agents in worktrees: one queue design with two instances. The bolt line’s queue trusts the sessions’ own runs and the local cache; the shared line’s queue trusts only the confined executor.

Notes that cite it

No note cites it yet.

Changes

v0.1: introduced · reviewed 2026-10-08 · draft

sluice: a merge queue for agents in worktrees Three agents, each in its own worktree, submit their work and never merge. sluice forms candidates line plus A, line plus A plus B, and line plus A plus B plus C, and tests them at once. Line plus A plus B fails, so B is the one culprit and only agent B is told. A lands as a merge commit; C is re-formed on the line without B, mostly replays from the cache, passes and lands. The line moves only to what passed. sluice a merge queue for agents in worktrees AGENTS · EACH IN A WORKTREE SLUICE · QUEUE OF bolt/pay entries THE LINE agent A worktree unit/auth building… submitted · waiting landed agent B worktree unit/ledger building… submitted · waiting told: pkg-x:test failed agent C worktree unit/export building… submitted · waiting landed A B C line + A testing… passed landed line + A + B testing… failed: pkg-x:test B removed: culprit line + A + B + C line + A + C testing… discarded: B is ahead re-formed · 9 of 11 replay passed landed before merge Averdict in trailers merge Cverdict in trailers bolt/pay moved only by sluice, from the revision the candidate was formed on 1Agents submit their work.None of them merges. 2Each candidate is testedexactly as it would land. 3A failure has one culprit,and only its agent is told. 4The line moves onlyto what passed.

Never prove twice

The task runner's cache, keyed by what each task reads and shared across every worktree, agent and CI run, means a check that passed on these inputs is not run again.

Today, where it's going, and its record

How we do it today

moon’s cache, with archives in the git common directory so worktrees of one repository share them. Inputs are declared per project, and a check catches a test that reads outside them.

Where it’s going

A remote cache every machine reads and only the confined executor writes. It alone holds the cache’s write credential, and that credential is the boundary, not a setting a runner inspects. A pass proven in a worktree replays when the merge queue tests the candidate it lands in. Testing the combination reruns only what the combination changed.

The cache remembers only passes. So the queue keeps a small record of every run beside it, a fail as faithfully as a pass (sluice statement, clauses 15, 16 and 19).

Notes that cite it

No note cites it yet.

Changes

v0.1: introduced · reviewed 2026-10-08 · draft

Secrets by declaration

A repository declares the secrets it needs, and an agent gets them only through the shell, resolved from a password manager for the task at hand, never pasted, stored or printed.

Today, where it's going, and its record

How we do it today

secretspec declares what each repository needs.

Where it’s going

Secrets resolved from a password manager such as 1Password at run time, scoped to the task, with each access attributable and revocable. Operations work, where agents connect to running services, depends on it.

Notes that cite it

No note cites it yet.

Changes

v0.1: introduced · reviewed 2026-10-06 · draft

Measure the fleet

A fleet that is not measured cannot be steered: count what lands, what it cost in attention and money, and what came back.

Today, where it's going, and its record

How we do it today

Collectors over Crew’s records, git and moon’s run reports, on our own repositories.

Where it’s going

A quality board, with every definition published beside its numbers.

Notes that cite it

No note cites it yet.

Changes

v0.1: introduced · reviewed 2026-10-06 · draft