Prototype

Answer one decision-changing question with throwaway code. Prototype code never graduates: the next production task rebuilds the selected behavior under its acceptance contract. A prototype produces evidence and a decision, not a finished feature.

1. State the question

Identify the unknown, the observation that would answer it, and the time or scope limit. Read existing code and docs first. A question already answered by those sources does not need a prototype.

Choose the smallest useful form:

1. Visual alternatives: read references/ui.md. Compare layouts on a local route with safe data.
2. Logic or state behavior that a person must explore: read references/logic.md. Use a standalone HTML demo.
3. A technical property such as integration behavior, latency, or library support: write a small local script or harness that records the relevant input, output, and measurement. Do not add a UI that cannot help answer the question.

2. Run the experiment

Keep the work isolated in a scratch location or local worktree. Name it as a prototype and give one command or file path to run it. Use in-memory or scratch data. Use real services only when that access is authorized and necessary to the question.

Skip production scaffolding and unrelated polish. Keep enough checks and error output to trust the experiment. Record actual observations and failed attempts. Stop at the agreed limit if the question remains unresolved.