hunvreus Prototype
Input
- A design, state model, UI idea, interaction, algorithm, integration, or uncertainty to explore.
- Use explicit input first; otherwise infer the question from context.
- Safest default: define the question before coding.
Workflow
- State the question. Define the single question the prototype must answer.
- Choose the shape. Use a terminal, script, fixture, route, component, or mock UI that answers the question fastest.
- Mark it throwaway. Name and place the prototype so it cannot be mistaken for production code.
- Make it runnable. Provide one command or obvious path to exercise it.
- Expose state. Print or render the relevant inputs, transitions, outputs, and edge cases.
- Capture the answer. Record what was learned in the final report, docs, issue, or follow-up plan.
- Delete or absorb. Remove the prototype or fold the validated idea into real code when the question is answered.
Output
- Question answered
- Prototype location and run command
- Findings
- What should be deleted, kept, or absorbed into production code
Guardrails
- Do not add persistence unless persistence is the question being tested.
- Do not polish beyond what is needed to learn.
- Do not let exploratory code silently become architecture.
- State what is intentionally not production-ready.