Ca Spike

$ca-spike — exploratory spike

The sanctioned lane for "I need to write code to find out." Spike code is disposable by contract:

it never merges, never PRs, and never becomes the implementation. What survives a spike is the

*answer*, written down — the code is burned.

Flow

• Name the question — a spike without a falsifiable question is just freelancing. Restate

$ARGUMENTS as the question the spike answers and the timebox (default: one session). STOP for

the user's confirmation.

• Branch — create spike/<slug> from the current branch. All spike work stays on it.
• Explore — no tdd, no plan, no review fleet. Two rules survive even here: no secret leaves

the approved store, and no irreversible operation (prod data, destructive migration) runs from a

spike.

• Exit — exactly one of:
• Answered → write the findings to <project-root>/.codearbiter/spikes/<slug>.md

(the question, what was tried, the answer, what it implies), then delete the branch. If the

answer warrants building, hand the findings to $ca-feature — the spike file seeds

brainstorming; the spike code is reference material, never the implementation.

• Timebox expired, no answer → record that too (a dead end is a finding), delete the branch.

Hard gate

MUST NOT merge or PR a spike/* branch — its only exits are a findings file and deletion. MUST NOT

copy spike code into an implementation branch wholesale; implementation re-enters through

$ca-feature and tdd. Secret-handling and irreversibility rules hold even in a spike. Commits on

a spike/* branch are exempt from commit-gate — the exemption is safe precisely because nothing

on the branch can ever land.

When NOT to use

• You already know what to build → $ca-feature.
• Diagnosing a defect → $ca-debug (investigation with a structured exit).
• A question answerable by reading code or docs → $ca-btw.