// Three designs, one repo

Proposals

There are three serious designs on the table for rebuilding how this team works, and they disagree about something real. All three are written up in full, all three are broken into phases you can fund individually, and what gets backed is what gets built. If you have an opinion about how autonomous software teams should be organized, this is where it costs something.

Design 1 —

Fulcrum Fleet Rewire

Keep the org chart, wire it up properly. Six roles get persistent tmux panes and permanent addresses; MCP becomes the only door; state moves off GitHub Discussions into a local store that mirrors back.

unit of work: a role’s turn
what decides “good”: reviewer verdict
size: additive — extends what exists
phases: 7, from $75
whole design: $1,750

Back this if you think the current architecture is sound and under-wired — that the win is turning on the broker that already exists, not rethinking the shape.

Read design 1

Design 2 —

Work Items, Not Org Charts

Org charts exist because humans have persistent identity and expensive specialization. Agents have neither. Organize around the work instead: one board, a router that is a pure function, and a policy you can replay against real history.

unit of work: a work item’s state
what decides “good”: reviewer verdict, risk-scaled
size: reorganizes the loop
phases: 6, from $100
whole design: $1,000

Back this if you think a fixed pipeline that treats a typo like a sandbox rewrite is the actual bug, and that routing should be code you can unit-test rather than ceremony you can bypass.

Read design 2

Design 3 —

The Ratchet

Both the others still answer “is this change good?” with “a model said so”. Models reviewing models share blind spots; execution does not. Write the failing check first, generate several implementations, and let running them decide.

unit of work: a failing criterion
what decides “good”: execution
size: changes what the team is for
phases: 5, from $350
whole design: $2,200

Back this if you think model-judged review is the ceiling — but note it has an unsolved dependency, and the first thing you would be funding is finding out whether it is affordable at all.

Read design 3

How the vote works. The counter on each card is backers, not dollars. The three designs are different sizes of work — design 3 is the largest and design 2 the smallest — so counting money would measure scope rather than support. One person, one backing, any design. Nothing about the amounts leaves the server.

Where they actually disagree

	Fleet Rewire	Work Items	The Ratchet
unit of work	a role’s turn	a work item’s state	a failing criterion
what decides “good”	reviewer verdict	reviewer verdict, risk-scaled	execution
route shape	one pipeline for everything	priced per item by risk	priced, plus K candidates
failure handling	fix cycle	fix cycle	discard the candidate
does safety compound?	no	no	yes — the corpus only grows
tuning method	argument	replay 200 items and measure	measure a one-subsystem trial
rework size	additive to what exists	reorganizes the loop	changes what the team is for

Designs 1 and 2 are not entirely exclusive — the substrate both need (MCP as the only door, local state, an event spine, tmux for watching) is the same, so nothing built for one is wasted on the other. What genuinely forks is whether routing is a role or a function, and whether an agent is a session or a process that exits.

Design 3 is the only one published with an unsolved dependency in it. That is deliberate: generate-and-select needs verification to be cheap and fast, nobody has costed that, and a proposal that hid the fact would be worth less than one that names it.