Prototype

For a direct invocation, use shared/references/model-preview.md to choose the branch first. Coordinator work and deterministic commands proceed within invocation authority. An actual worker branch uses one approved route snapshot. Nested calls reuse it without route selection or added workers.

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 decision: read references/ui.md. Start with one fixture or static screen for one question. When a comparison can change the decision, use two alternatives. An explicit user request for a different bounded set controls. Use a host page or switcher only when real app context changes the observation.
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 safe memory backed or scratch data. Use real services only when that access is authorized and necessary to the question.