Step 1 · One small roster·A fixed role rosterPT-BR
Evidence-first model routing · Visual course

A fixed role roster

Turn model preferences into three inspectable assignments: Fable plans, Luna implements, Sol reviews.

Read first (primary source)
A Field Guide to Fable — Finding Your Unknowns

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
Start simple; open the technical layer only when useful.
1

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.

2

In one picture


Fable 5 Maxplan · max GPT-5.6 Lunaexecute · xhigh GPT-5.6 Solreview · xhigh review evidence returns to the next bounded pass
Read left to right. The dashed line is the loop, not a hidden fourth role.
3

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

4

Try it


Click each handoff. Notice that a role is complete only when its artifact is inspectable.

01

Fable 5 Max · max

Produces a bounded plan and names the unknowns that need proof.

artifact: plan
02

GPT-5.6 Luna · xhigh

Executes the one bounded unit against the real repository state.

artifact: diff + tests
03

GPT-5.6 Sol · xhigh

Reviews independently and cites concrete findings or returns a clean verdict.

artifact: review

Flip the three cards, commit a prediction, then take the check.

What is dynamic?
The run state—not the role-to-model mapping.
Who implements?
GPT-5.6 Luna at xhigh effort.
Who reviews?
GPT-5.6 Sol at xhigh effort, independently.
If a task looks harder, does this roster silently swap Luna for Sol?
No. The roster stays explicit. A deliberate code/config change is required.
Which statement matches the shipped design?
The small fixed roster is the feature: role, model, and effort are inspectable before execution.
Next: prove the path instead of trusting the roster declaration.

Sources and receipts