MasterMind: Prototype

Tight feedback loops beat big plans when the path is unclear (~/.mastermind/engineering/core/agent-loop.md, mindset.md → design it twice). A prototype buys knowledge cheaply: the discipline is keeping it knowledge, not product.

Method

1. Name the question: the ONE risky unknown this prototype will answer ("can the Worker stream a >20 MB file?", "does this library handle X?"). One named question is the entry price, find it first.
2. Build the smallest thing that answers it: hard-code, skip error handling, skip tests, skip polish. Speed over quality; it's throwaway.
3. Extract the learning: what did reality teach? Write down the answer and any surprises.
4. Throw it away and rebuild to standard: the real version gets the full loop (design, rigor, tests, review). Ship the rebuild; the prototype gets discarded.

Rules

Time-box: 5 build-and-run attempts, roughly 30 minutes: one question needs a handful of tries, not a day; proportionality over ceremony. An attempt is one edit → run → observe cycle against the named question; count them out loud as you go, so the box is observable and not a vibe. Attempt 5 finished without an answer = the box is spent, whatever the clock says.

When it expires, stop. That's a result, not a failure. Report: what you learned, what is still unknown, and one recommendation: proceed (answer is yes, build it properly) / different approach (this path is wrong, here's the next one) / needs more investigation (name what a second prototype would target). Then discard the code: it stays throwaway and does not ship, same as a prototype that succeeded.

Extending the box is a decision, not drift. Only extend when the attempts narrowed the question rather than wandering: say so explicitly, state the new bound (e.g. "3 more attempts"), and stop there.

Keep it isolated (a scratch branch/dir) so it can't leak into production. The deliverable is the learning, not the code.

Output

The answer to the question + the surprises, and a clear "now build it properly" recommendation (or a "don't build it, here's why"). When the prototype served a feature in specs/, record the question and the answer in that feature's research.md, so blueprint builds on it instead of re-asking it.