Loft

Cut no steel until the shape is fair. Shipwrights loft the hull's lines full-scale and fair them before a single plate is cut. Loft applies the same order to design questions: when words have run out, two plausible answers, neither falsifiable by talk, build a cheap runnable artifact, let the captain react to it, and fold that reaction into the decision.

The role contract. The crew builds the artifact; the captain's only job is to react, and that reaction is the decision. The artifact is an instrument for seeing, never a head start on the deliverable.

When to loft

• a design question stalls in prose: repeatedly rephrased, still not settleable ("how should the path page look", "does this state model feel right")
• a navigator map carries a loft ticket
• a spec discussion reaches "we would have to see it first"

Do not loft when:

• the question is answerable from repo evidence or by asking the captain (that is interviewing, not lofting)
• the destination itself is unclear (that is fog, /oh-my-claudecode:ask-navigator)
• the answer already lives in an ADR (do not re-loft settled decisions)
• the "design question" is actually a bug (that is the debugger's jurisdiction)

Choose the fork

Pick by what the question is asking. A wrong fork wastes the whole artifact.

Logic fork, is the model right?

For questions about state, business rules, data shape, or algorithms ("does unlocking regress on a retake?", "does this reducer hold at the edges?"):