design-forking
Design Forking
First ideas anchor. An agent fixates within a run, and asked for "3 options" it produces three decorations of one idea - a centroid with variants. The quality of the design you keep is governed by the best of the set, which rises with the set's variance, not just its size. So force structural variance mechanically, then converge in a separate pass. (Research behind each rule: references/evidence.md.)
0 - Gate on reversibility
Classify the decision before generating anything:
- Two-way door - reversible, cheap to change (a library behind one import, an internal helper, naming). Pick the obvious option, note the reversal path in one line, stop. Forking reversible decisions is process theatre.
- Can you buy the two-way door? A module seam, a flag, or an adapter often costs less than a deliberation. If reversibility is cheap to manufacture, buy it and downgrade the decision.
- One-way door - expensive to reverse under real uncertainty: schema shape, public API or contract, framework choice, where an invariant is enforced, anything other code or people will couple to. Fork.
Done when: one written sentence names the door type and why. The gate is never skipped because the task "looks simple" - it costs a sentence.
1 - Frame
State the decision as the capability or invariant needed, not as a choice between artefacts: "the two surfaces must never disagree", not "shared helper vs base class". Artefact framing pre-anchors the fork on one mechanism. Name the load-bearing dimensions the candidates must differ on.