The Spike Clock Is an Instrument

Description and use

The spike‑clock script logs each spike phase as a JSON line, warns as the budget nears, and stops editing when the budget is spent, providing a transparent time log.

Problem

A developer’s spike often ends without recording why it ran long, leading to untracked overruns and vague feelings of delay.

Outcome

The spike-clock script turns subjective time tracking into a reproducible log, enabling developers to see exactly when a spike exceeded its budget and to document the reason for overruns.

Workflow

• 1. Create spike.yml with question, falsifier, budget, and artifacts. 2. Run ./spike-clock.sh start before writing the question. 3. Execute spike steps, calling ./spike-clock.sh step or probe as needed. 4. Run ./probe-cold-start.sh <URL> to collect three spaced hits. 5. Summarise CSV into a verdict and write to spike.yml. 6. Run ./spike-clock.sh verdict to log final outcome. 7. Review the generated JSONL log for budget compliance.

Evidence

A developer is ninety‑one minutes into a spike, and the original question … has quietly been replaced by a retry wrapper nobody asked for.

Source

The instrument is small on purpose. A heartbeat script appends one JSON line every time the operator starts a phase, finishes a step, or runs a probe, and it refuses to stay silent about the budget.

Source

The probe is where the clock earns its keep, because it converts a subjective impression of speed into three rows that either match the falsifier or do not.

Source