prototypelisted

# Prototype ## Step 1: Define the question Before writing any code, state the design question in one sentence: > "Can [approach] handle [constraint] at [scale]?" > "Which of [option A] / [option B] produces [outcome]?" > "What does the state machine look like when [edge case] happens?" If the question can't be written in one sentence, the prototype is too broad — narrow it first. Read the relevant `.harness/engineering/features/[slug].md` to understand the full feature context, then surface the specific uncertainty that needs answering. Confirm the question with the user before proceeding. ## Step 2: Choose the approach | Question type | Approach | |---|---| | Logic / state machine / business rules | Interactive terminal app — simulate inputs, display full state after each action | | Visual / UX / layout | Multiple UI variations on one route, toggled via `?variant=a` / `?variant=b` | | Library / external integration | Minimal single-file script that exercises the specific capability | | Performance / data volume | Benchmark harness with representative data sizes | ## Step 3: Build it Rules — these are not optional: - **Mark as temporary**: name files `_prototype-[slug]` or place in a `_spike/` folder near the target location - **Single entry point**: one command to run, matching the project's existing conventions - **In-memory state**: no persistence unless the prototype specifically tests database behaviour - **Speed over quality**: no tests, no abstractions, minima