Prototype

Answer one question with a runnable artifact. Default to throwaway work, but let the user retain or promote useful code once its limits are assessed.

Process

Define the question, hypothesis, observation, and stop condition. Budget effort in proportion to the uncertainty. Reuse the existing stack when it fits; no new framework for a small demo.
Isolate the artifact from production navigation, data, and deployment. Use the user's directory or the repository's prototype convention. Do not change ignore rules automatically.
Pick the shape:
- A terminal app or script for data flow, algorithms, protocols, and state machines.
- A visual route or demo for layout, motion, and interaction. Show a few meaningfully different alternatives side by side when comparison is the point.
Build only the paths the answer needs, including validation and failure behavior where they affect it. Minimal does not mean crashing or empty handlers. No fixed file-count rule should block components the experiment needs.
Run it. Record the startup command, representative inputs, and observed outcomes. Inspect visual prototypes in the browser, including interaction and final state; code reading does not confirm experience. Mark unavailable checks.
Compare evidence to the hypothesis. State what it demonstrates and what it does not: mocked services, assumed data, missing operational behavior.
Record disposition: keep, archive, discard, or promote. An explicit request to build on it overrides the throwaway default. For promotion, define production requirements and gaps through flow-plan instead of an automatic rewrite.