prototype

Build a small interactive terminal app around a pure reducer or state machine, with keyboard shortcuts that dispatch actions and re-render the full state after each one. This lets you push the model through edge cases by hand and spot invalid transitions early.

Render each variant as a separate component on the same route, gated by a ?variant= URL search param, with a floating bottom bar to cycle between them. Keep existing data fetching intact so variants are judged against real content and layout density.

No. Prototypes should keep state in memory unless the question being answered is specifically about persistence. Wiring to a real database adds setup cost and failure modes that distract from the design question the prototype exists to answer.

Use a terminal prototype when the question is about logic, state transitions, or data shape. Use a UI prototype when the question is what something should look like. Choosing the wrong branch wastes the prototype, since the two produce very different artifacts.

Capture the answer in a commit message, ADR, or NOTES.md, then delete the prototype or fold the validated logic module into real code. The pure logic module can be lifted out; the terminal shell and losing UI variants should be removed.