# Spike Report: [Question being investigated]

> A short record of a time-boxed technical investigation: the question, why it matters, how it was explored, what was found, and what the team should do next. A spike produces knowledge, not production code. Based on common agile engineering practice; there is no formal standard. Replace every `[bracketed]` value and every line marked *Example*. Worked examples use Brindlemark, a fictional open-source Markdown editor.

<!--
Guidance: How to use this template
- Write sections 1 and 2 before you start, and agree the time box with the team. A spike without a stop date turns into an unplanned project.
- Fill sections 3 to 5 as you go and finish section 6 on the last day, even if the answer is "we still do not know".
- If the recommendation changes the architecture, record the decision in an ADR (`dev/adr`) or a design doc (`dev/design-doc`) and link it here.
-->

| Field | Value |
|---|---|
| Spike ID | [SPIKE-NNN or ticket number] |
| Owner | [@name] |
| Time box | [*Example:* 3 working days, YYYY-MM-DD to YYYY-MM-DD] |
| Actual time spent | [*Example:* 2.5 days] |
| Status | [Planned / In progress / Done / Stopped at time box] |
| Decision needed by | YYYY-MM-DD, for [*Example:* sprint planning of the sync epic] |

## 1. Question

<!-- Guidance: One question that can be answered yes, no or "option B". Pitfall: "investigate sync", which has no end. -->

[The question this spike answers.]

*Example:* Can Brindlemark sync documents between two browsers with a CRDT library without growing stored data by more than 2 times on a 1 MB document after 1,000 edits?

## 2. Why it matters and success criteria

<!-- Guidance: Say which decision waits on the answer and what evidence would be enough. -->

[The decision this unblocks and what "answered" looks like.]

- [ ] *Example:* Measured storage size after 1,000 scripted edits for two candidate libraries.
- [ ] *Example:* Merge of concurrent edits shown working in a throwaway prototype.

## 3. Approach

<!-- Guidance: List what you tried, in order, including dead ends. Others will want to know what not to repeat. -->

1. [Step, tool or experiment]
2. [Step]

*Example:* Built a throwaway prototype in a separate branch, scripted 1,000 random edits, measured stored size with each library.

## 4. Findings

<!-- Guidance: Facts and measurements, with links to code, logs or benchmarks. Mark guesses as guesses. -->

| Finding | Evidence |
|---|---|
| *Example:* Library A stored 1.6 MB after 1,000 edits on a 1 MB document (1.6 times) | Benchmark script and output in the spike branch |
| *Example:* Library B stored 3.1 MB (3.1 times) | Same script |
| [Finding] | [Link] |

## 5. Risks and unknowns

<!-- Guidance: What the spike did not cover. These become follow-up tickets or accepted risks. -->

- [*Example:* Memory use on mobile browsers was not measured.]
- [Unknown]

## 6. Recommendation and next steps

<!-- Guidance: One clear recommendation, its confidence, and the tickets that follow. Delete the prototype code or mark it clearly as throwaway. -->

**Recommendation:** [*Example:* Use library A; confidence medium until the mobile memory test is done.]

| Next step | Owner | Ticket |
|---|---|---|
| [*Example:* Measure memory on two mobile browsers] | [@name] | [#NNN] |
| [*Example:* Write ADR for the sync library choice] | [@name] | [#NNN] |

## Standard and licence note

Based on common agile engineering practice for time-boxed technical investigations ("spikes"); no formal standard defines this format. The structure and wording are original. Brindlemark is fictional, and the figures in the examples are invented for illustration. Template licence: MIT.