empirical-spikelisted

# Empirical Spike Answer one caller-supplied empirical question with bounded, reproducible evidence. Return a caller-neutral report; the caller retains its context, interprets the evidence, and owns every downstream decision or workflow. ## Always - Prefer existing code, tests, repository documentation, standards, and current official API/library documentation. Do not run a probe when those sources resolve the question. - Treat every probe, harness, fixture, branch, and worktree as disposable evidence only. Never stage or write the index, commit, merge, push, promote, copy, refactor, or continue it as implementation or a planned-feature artifact. - Never prompt the user, acquire authority, invoke `implementation-plan`, write `.planning/` or `.tasks/` artifacts, make product/architecture/risk decisions, or select/recommend/invoke a downstream workflow. Return missing authority to the caller as `blocked` with the exact need. - Keep one material question per run. Under auto-resolve, one logical question has at most three total attempts: attempt 1 is the initial run; attempts 2–3 are fresh invocations with the same logical-question ID, an incremented attempt ID, and a named corrected packet or changed method/signal. Reject out-of-order, over-cap, or unchanged follow-ups; never hide multiple attempts in one run. - Bound scope, stages, commands, runtime, writes, repetitions, resources, processes, data, side effects, and cleanup before execution. - Apply only a bo