A fixed role roster
Turn model preferences into three inspectable assignments: Fable plans, Luna implements, Sol reviews.
The source separates the map from the territory. The roster is the map; Proof Gates expose the territory.
By the end, you can
- name the model and effort for each role
- explain why the roster stays explicit
- locate the single source of truth
The big idea
A roster is a promise you can inspect before a run. Planning, implementation, and review each get one named model and one named effort level.
Think of a relay team. The baton moves through fixed positions. The analogy breaks when review sends work back: software loops; a race does not.
In the code
FACTORY_MODELS and the effort levels live in .factory/run.ts; generic createFactoryRuntime validates the gateway and credentials. No content classifier or dynamic router decides at runtime.
In one picture
In the code
.factory/run.ts
const FACTORY_MODELS = {
planner: "claude-fable-5-max",
implementer: "gpt-5.6-luna",
reviewer: "gpt-5.6-sol",
} as const;How to find or run this
sed -n '1,140p' .factory/run.ts
Try it
Click each handoff. Notice that a role is complete only when its artifact is inspectable.
Fable 5 Max · max
Produces a bounded plan and names the unknowns that need proof.
artifact: planGPT-5.6 Luna · xhigh
Executes the one bounded unit against the real repository state.
artifact: diff + testsGPT-5.6 Sol · xhigh
Reviews independently and cites concrete findings or returns a clean verdict.
artifact: reviewFlip the three cards, commit a prediction, then take the check.