Prototype
A prototype is disposable code that answers one explicit question. The question determines the shape, fidelity, and stopping point.
Choose the branch
- For business rules, state transitions, data shape, or API feel, read LOGIC.md.
- For layout, hierarchy, interaction, or visual direction, read UI.md.
If the branch is genuinely ambiguous and quick repository context does not resolve it, ask one question before editing.
Shared workflow
- Write the question and the evidence that would answer it.
- Locate the prototype near the target area and mark its route, filename, and visible UI clearly as a prototype.
- Use the project's existing runtime, task runner, components, and styling. Add no new dependency unless the experiment itself requires it.
- Keep state in memory and side effects stubbed unless persistence or integration is the question being tested.
- Implement only enough realism for a trustworthy answer. Skip production abstractions, exhaustive error handling, and unrelated polish.
- Make the relevant state, differences, and trade-offs visible while the prototype runs.
- Run the prototype and report how to access it, what to try, and which observations would settle the question.
- Once the user chooses, carry the validated decision into production code deliberately. Remove or retain the prototype only with the user's direction; do not create branches, issues, commits, or external records without explicit authorisation.
The prototype is complete when it can distinguish the plausible answers to its stated question. It is not complete merely because it runs.
1---2name: prototype3description: Build disposable code to answer one design question. Use when the user wants to test whether logic or a state model feels right, or compare materially different UI directions before production implementation.4license: MIT5---67# Prototype89A prototype is disposable code that answers one explicit question. The question determines the shape, fidelity, and stopping point.1011## Choose the branch1213- For business rules, state transitions, data shape, or API feel, read [LOGIC.md](LOGIC.md).14- For layout, hierarchy, interaction, or visual direction, read [UI.md](UI.md).1516If the branch is genuinely ambiguous and quick repository context does not resolve it, ask one question before editing.1718## Shared workflow19201. Write the question and the evidence that would answer it.212. Locate the prototype near the target area and mark its route, filename, and visible UI clearly as a prototype.223. Use the project's existing runtime, task runner, components, and styling. Add no new dependency unless the experiment itself requires it.234. Keep state in memory and side effects stubbed unless persistence or integration is the question being tested.245. Implement only enough realism for a trustworthy answer. Skip production abstractions, exhaustive error handling, and unrelated polish.256. Make the relevant state, differences, and trade-offs visible while the prototype runs.267. Run the prototype and report how to access it, what to try, and which observations would settle the question.278. Once the user chooses, carry the validated decision into production code deliberately. Remove or retain the prototype only with the user's direction; do not create branches, issues, commits, or external records without explicit authorisation.2829The prototype is complete when it can distinguish the plausible answers to its stated question. It is not complete merely because it runs.
timmo001