Prototype

Build throwaway code that answers a design question.

Read-only inspection may establish the question and likely scope first. Before creating or changing prototype files, pass the adaptive Delivery mode gate. Honor topology and maintainer availability already stated semantically and ask only for a materially unresolved dimension. An untracked request or exactly one selected Ticket stays with the current conversational owner through the requested prototype outcome, whether the maintainer stays or authorizes work while away. Absence alone adds no readiness, Prompt Audit, or dispatcher.

Select one branch

Determine the question from the user's prompt and the surrounding code. If both branches remain plausible and the user is available, ask which question to answer.

• Logic or state-model question: follow LOGIC.md. Use the smallest executable shape that answers the question: focused probes or tests for concrete cases, or a tiny interactive terminal app when exploring transitions by hand is useful.
• UI appearance question: follow UI.md. Build several radically different UI variants on one route, selectable through a URL search parameter and a floating bottom bar.

If both branches remain plausible and the user is unavailable, select logic for a backend module or UI for a page or component, and record that assumption at the top of the prototype.

Rules for both branches

1. Mark experimental code clearly. Use a prototype filename, name, or comment so a reader can distinguish the experiment from production behavior. Reuse an appropriate existing test location for a focused probe; new standalone prototypes normally live beside the module or page they evaluate.
2. Provide one run command. Use the existing task runner, such as pnpm <name>, python <path>, or bun <path>.
3. Keep state in memory by default. If the stated question explicitly involves a database, use a scratch database or a local file with a clear PROTOTYPE — wipe me name.
4. Implement only what answers the question safely. Use small tests, assertions, or executable examples when they expose the behavior being evaluated. Add a reusable seam or error handling when the experiment needs it; avoid speculative architecture and production-grade scaffolding unrelated to the question.
5. Expose the result. For probes, assertions and failure output may be enough to show the relevant behavior. For interactive logic or UI exploration, print or render the state needed to understand transitions and output after each action or variant switch.
6. Capture the result. Record the question, observed answer, and any prototype elements that may serve as reference or a starting point for later production work. The prototype remains non-production and is never promoted automatically. Preserve it on a clearly throwaway branch only when the user or repository requires the artifact. Production promotion requires explicit implementation authorization under the repository's delivery workflow, not necessarily a separate Ticket. Reuse validated code when it meets production requirements; adapt and test what needs hardening rather than rewriting merely because it began as a prototype.