autotune

Use when running autotune — the autonomous, metric-driven code-tuning CLI (assumed already installed) — on a project to improve a measurable metric such as benchmark speed, test coverage, binary size, or model accuracy (e.g. "use autotune to speed up X", "tune this project with autotune", "have autotune improve my benchmark/coverage"). Also use when an autotune run misbehaves (crashes, hangs, banks no real improvement, scores real wins as noise) or lacks a config option / adaptor / behavior your project needs.

Use when hardening the autotune CLI by running it end-to-end against a real target repo — i.e. "try autotune on <project> and fix what breaks", "run autotune against X and watch for malfunctions", "can autotune actually improve X", or any dogfooding/shakedown of the tune loop. Dogfooding has two goals: (1) robustness — the loop doesn't crash, hang, orphan processes, fill the disk, or record the wrong outcome; and (2) efficacy — autotune produces meaningful, correct improvements (good hypotheses, real wins that clear the noise envelope, not gamed/overfit). Covers launching a traced unattended run, watching the trace/logs/ledger, diagnosing via trace `phase.decision`, fixing bugs OR improving autotune itself (research prompts, scoring, specialization) with a failing-test-first discipline, and rerunning until N iterations complete cleanly and the wins are judged real. Not for plain unit changes — just run nextest.