25 Sep 2026 — what “doing the vision” now means, decided:
v1.0is the claim “we do what Claude Opus does, in a different and cheaper way” made true and reproducible by any user (ADR-0093), reached rung by rung up the capability ladder inROADMAP.md. Who does each piece of work is ADR-0092 and ADR-0094: a mechanical tool where one is exact, then local models, then cheaper Claude models, then the user’s model — every rung behind the gate.
Owner’s statement, 16 Sep 2026. This is the destination. PHASES.md is the route; every phase in it
either moves towards this or is a detour that has to justify itself.
From outside, the user wants to change x, y, z in their source code, and the change gets done with the same quality Opus itself would produce. From inside, it is not just Opus — it is Opus with its local model employees.
We want to be able to do anything with the code that Opus does — the difference is the way we do it. Opus does the smart thingies, our local models do the heavy lifting. The local model can scan the code, go through several files looking for something, report back to Opus; Opus says okay, let’s do this, and so on.
Three things this settles, and the third is the one that changes what gets built next:
BACKLOG.md § The edge ideas item 1, and as of 20 Sep 2026 it
has a measured target rather than a premise: planning costs 233,500 fixed tokens on a real
project — 68 % of the total even at 41 tasks — and that fixed term is
The honest caveat, from the same measurements: a local model that returns ten confirmed locations Opus did not need has passed its gate and saved nothing. Existence is checkable by machine; relevance is not. That is why item 1 needs its own ADR before it is built, and it is a different Goodhart shape from the rest of this design.
The point is not that a 7B is good. It is that a 7B behind a mechanical gate, managed by something that is good, can be trusted with work that would otherwise cost Claude tokens — and the user never sees the difference, because the output is held to the same bar either way.
Say I want a major refactor across the whole project. Opus lists what needs to be done, in how many steps, and how many smaller local model instances each step needs. It hires them and gives each the prompt for its part — if 100 files need to change, one worker is responsible for maybe 5–10 files, grouped in a way that makes sense. Each reports back when it is finished; Opus confirms the job was done properly, and if not, gives it the prompt to fix it.
Every clause of that is a design requirement, and each one is either built, planned, or an open decision:
| clause | where it stands |
|---|---|
| Opus lists what has to be done and in how many steps | ordered steps built (ADR-0044 §2, Phase 10); the planner that writes them is Phase 12 |
| how the files are grouped, 5–10 per worker | built — ChangeTask.files, max_group_size default 10 (ADR-0044 §1); who groups them is Phase 12 |
| how many instances each step needs | see where the machine bends the picture, below — and there is no workers field, enforced |
| each reports back | built — the code-change verdict is ADR-0047 §3 |
| Opus confirms the job was done properly | the gate decides what Opus sees; Opus approves — built for both workloads (ADR-0048) |
| if not, gives it the prompt to fix it | the correction round — ADR-0044 §4, Phase 12; today the only retry is mechanical |
“How many instances” is the one clause the hardware rewrites. A 32 GB Mac hosts one or two resident 7B workers (measured, Phase 1); a 24 GB Mac one. So “hire ten workers for this step” cannot mean ten processes. It means ten tasks, queued against the workers that are up, and the run decides how many run at once from free RAM at that instant (ADR-0011, ADR-0025). Opus decides the shape of the work — how it is cut and grouped and ordered. The machine decides the process count, and nothing in the plan pretends otherwise.
The intelligence stays central and the compute moves to the machine on the desk. That is the analogy the owner reaches for and it is a fair one: what is expensive and scarce (Opus judgement) is spent on deciding, and what is cheap and local (a resident 7B, a CPU, a disk) is spent on doing. The economics only work if the deciding is much smaller than the doing — which is a constraint on the design, not a hope. See “What this rules out”.
Not every desk has the room, and sidecrew says so rather than becoming a different product. A machine with less than 24 GB cannot host a 7B beside a normal working set (ADR-0009, measured), and as of 20 Sep 2026 sidecrew refuses to run there — with the number, the floor, and the reason (ADR-0073). It used to fall back to Haiku over the API on those machines. That fallback is now an unsupported opt-in, because it was a second product — a different worker, a different cost model, and survival figures that were never measured — reached by a RAM check that most users would never see happen.
Refusing is the honest version of the same value. The failure mode of trying anyway is swapping, and ADR-0066 measured what swapping does to this gate: it manufactures false negatives indistinguishable from real defects. A stated hardware requirement is an ordinary thing for a tool that hosts a 7B to have; quietly handing someone an unmeasured second product is not.
The measure, in the owner’s words (16 Sep 2026):
All I want is to use the edge computing capacity — maybe in future with multiple agents, if it helps — to improve what happens when users use Claude Opus on its own: fewer tokens, faster, more precise.
Three goals, and how each is served — because “faster” in particular has to be said carefully:
BACKLOG.md § The edge ideas, item 1).More agents are not a goal. A role earns its place by removing Opus tokens; the design has two, and the only third one on the list is the reader in item 1.
Everything in this repo exists to make “the same quality as Opus” a checkable statement rather than a marketing one. The mechanism is always the same and it is the only real idea here:
A local model’s output is never trusted. It is admitted only by a gate that a machine can run, and Claude only ever sees what got through.
For workload #1 (unit tests) that gate is compiles ∧ passes ∧ kills ≥ 1 mutant ∧ non-tautological
(CLAUDE.md #2). Six real-world trials were spent making that gate honest, and the most important thing
any of them found was a case where it silently was not (ADR-0037): a candidate that did not compile
was scored a survivor. That is the failure mode this whole architecture has to be paranoid about, because
a gate that passes quietly turns “same quality as Opus” into a lie that nothing detects.
So the unit of progress towards this vision is not “more workloads”. It is one honest gate per workload, and a workload with no mechanical gate does not belong in sidecrew at any price.
| the work | the oracle | status | |
|---|---|---|---|
| #1 | write a unit test for an existing function | mutation testing — ADR-0016 | built and measured on real projects |
| #2a | behaviour-preserving change: type errors, lint, renames, null guards, API migrations, dead code | the project’s own test suite + tsc — free, exact, already written by the user. A bad suite does not invalidate this: #2a claims behaviour-preservation, so the oracle is asked to be unchanged and re-runnable, never to be right. What a thin suite costs is reach, not validity — ADR-0082 |
built and measured — sidecrew fix, Phase 10; Phase 11’s number, against a rule frozen first |
| #2b | behaviour-changing change: implement this, fix this bug | nothing in the repo knows the answer; Claude has to write the spec — or the worker does, ADR-0082 (proposed) | after 2a, and not cheaply — ADR-0031 options B/C, and ADR-0082 is the first candidate instrument |
The owner’s own example — “fix all the TypeScript errors in a large codebase” — is #2a, and it is the best-fitting workload in the entire design. The gate costs nothing because the user already wrote it. The planning is cheap because there are no shapes, no exemplars, no per-function specification. And it is exactly the kind of large, boring, parallel job that a resident local model should be doing while Claude does something else. A major refactor is #2a too, as long as the suite is meant to stay green through it.
When there is no oracle, Claude has to write one — which in practice means writing the tests first (the owner’s own TDD-inversion idea). Two things then go wrong at once, both already written up in ADR-0031:
if (x === 3) return 7, and that ships. The known
countermeasure is held-out tests, which doubles the expensive half.2b is in the vision. It is not the next thing, and no number from #1 or #2a will say anything about it.
Both of those objections moved on 21 Sep 2026, and neither was settled — ADR-0082 (proposed). The owner’s framing has the worker write the tests rather than Claude, which makes objection 1 an open question instead of a closed one: it is sidecrew’s own premise applied to the spec-writing step. It does not answer it, because workload #1 survives at 3/8, 4/8 and 4/10 on real projects (measured), so a manufactured oracle means generate several, keep one, and mutation testing is the most expensive stage in the system.
Objection 2 moves further. Held-out tests are what ADR-0031 proposes and they “double the expensive half” — but if the test is written by one worker invocation and the change by another, the change worker is never shown the test, and the tests are held out by construction and for free. Goodhart needs the measure to be visible. That is mitigation rather than elimination: for 2b the task description still carries the intent, so a worker can special-case toward what it infers.
And the part of 2b that no machine closes is now located rather than lamented. Does the change do what was asked is machine-checkable against a test written first. Was that the right thing to ask for is not, and never will be — but a test that states an expectation is a far cheaper thing for the user to approve than a diff spread across files. The human oracle does not disappear; it moves to the smallest artefact in the loop.
Most of the machine transfers — the contract (WorkerTask → Candidate → Verdict → BatchResult),
determinism, the zero-worker-tokens guarantee enforced in schemas.ts, the memory gate, the queue,
thermal back-off, the retry rule, the escalation queue, review routing. All of it is about outcomes
rather than about what the outcome is made of. So is six trials’ worth of knowledge about real projects:
sandboxing, monorepos, pnpm, ts-jest, module resolution.
Seven things did not. The first four were the gate side and Phase 10 built them (16 Sep 2026, ADR-0046 through ADR-0048); the next three are the management side — the half of the vision the owner’s worked example is mostly about — and they are ADR-0044. Each is left here with what it turned into, because the argument for why it did not transfer is the reason the answer looks the way it does:
ChangeVerdict says which tsc errors
are left in which file, which files gained one, which tests regressed by name, and which confinement
rule the diff broke. It is designed for a reader who arrives two phases later: ADR-0044 §4’s correction
round writes its note from the verdict and never from the candidate’s diff, which is the line
between “Opus corrects a worker” and “Opus reviews everything”.@@ hunk headers against code it is reading for the
first time fails in a way that says nothing about whether it understood the change, and it adds a whole
stage — the patch did not apply — for a verdict to represent. Deriving it buys the property the gate
needs most: confinement is decidable before a byte is written, because it is a pure function of the
task’s sources and the candidate’s. The gate then judges the change — confined, compiles, suite
still green — and the unified diff it writes to the run directory is what a reviewer reads; nothing
gates on that text, so no verdict depends on which alignment a diff algorithm happened to pick
(ADR-0048).tsc error count recorded per file so per-file
reporting costs no extra verifier run. max_group_size is a plan field with a default of 10, never a
constant, because the right number is what Phase 11 measures.ChangePlan.steps is ordered, tasks inside a
step run in parallel, and the run applies that step’s survivors and re-captures the baseline at the
boundary without waiting for Opus.escalations.jsonl and sidecrew escalate
already do. ADR-0044 §4, Phase 12.Said plainly, because a vision that rules nothing out is a slogan:
pass — candidates that compile and assert
something untrue. The product is the gate; the local model is how the gate gets fed cheaply.The owner’s call, 16 Sep 2026: sidecrew goes public when it does the vision, not before. A tool that only writes unit tests is a waypoint and would be published as a final product, which is not what it is. Later the same day, the bar in the owner’s words:
Everything should be published when what I proposed works properly and people can use it on their code base with no problem.
“Works properly” is the worked example above running end to end, with the correction round of ADR-0044 in it. “People can use it on their code base” means all of the following, and each is a definition-of-done line in Phase 14 rather than a sentiment:
doctor with its remedy, in the shape ADR-0032 set: the cause, whose fault it is, and the exact fix;Workload #2a is the first form of that sentence that is true, and it is the gate for Phase 10. Publication is Phase 14, behind Phases 10–13. Workload #2b (Phase 15) is in the vision and behind publish.