technical-spikelisted

# Technical Spike **[DATA GUARD]**: Never accept "Research [X]" as a spike goal. A spike must have a binary question (e.g. "Can we support 10k concurrent users with our current DB?"). If no binary question exists, mark as `[REJECTED - NOT A SPIKE]`. ## Execution Logic 1. **The Question:** Define one technical uncertainty that blocks the `prd`. - *Bad:* "Research Web3." - *Good:* "Can we process a transaction in < 200ms using [Service X]?" 2. **The Success Signal:** What is the binary proof? (e.g. "Working prototype in Staging", "Signed-off performance log"). 3. **The Time-Box:** Standard is 1-3 days. Never exceed one sprint. 4. **The Stop Condition:** What result kills the feature? (The "Falsifiable result"). 5. **The Handoff:** Output must be a binary **Go/No-Go** for the project. ## Output Format ### Spike Design (Before Build) ```markdown ## Technical Spike: [Uncertainty Name] **Time-Box:** [Days] | **Owner:** [Lead Engineer] ### 1. The Question [Specific binary question] ### 2. Success Signal [What must be observable to mark this 'Done'] ### 3. Falsifiable Threshold "This project is a NO-GO if: [Specific technical failure or cost overrun]" ### 4. Coherent Actions [Specific steps the engineer will take] ``` ### Spike Review (After Build) ```markdown ## Spike Result: [Name] | Verdict: [GO / NO-GO / PIVOT] ### Findings - **Observed:** [Performance/Complexity/Cost results] - **Risks:** [New RAID items surfaced] ### Recommendation [Proceed to PRD / Kill Feat