Plan a time-boxed technical spike

Help me plan a technical spike so it answers a real question instead of turning into an open-ended project. What we're unsure about: [e.g. "can we replace our search with Postgres full-text", "is this vendor API fast enough"] Decision this spike will inform: [WHAT WE'LL DECIDE AFTERWARD, AND BY WHEN] Time available: [e.g. "3 days, one engineer"] Constraints and must-haves: [PERFORMANCE, COST, SECURITY, COMPATIBILITY] What we already know: [PRIOR RESEARCH, DOCS, OPINIONS] Plan: 1. Rewrite the uncertainty as 1-3 specific questions that can be answered with evidence (e.g. "Can query X return in under 200ms on 10M rows?"). 2. For each question, define what evidence counts: a benchmark, a prototype, a vendor confirmation, a test with real data. 3. Set exit criteria: what result means "go", "no-go", or "needs more investigation". 4. Lay out a day-by-day plan within the time-box, front-loading the riskiest question so we can stop early. 5. List explicit non-goals: production quality, error handling, polish. State that spike code is thrown away or rewritten. 6. Name the traps that make spikes overrun (scope creep, testing on toy data, optimizing too early) and how to avoid them. Also give me a findings template to fill in at the end: the questions, the evidence and how it was gathered, the answer to each, the recommendation, remaining risks, and an estimate for the real build.