peltier.io/.claude/skills/peltier/references/verify.md

verify — prove a speedup in any repo

You have two things that should do the same work, one of which you think is faster. Find out. Works on any pair of shell commands, in any language.

0. Preflight

sh <skill-dir>/scripts/preflight.sh
# `sh` launcher missing ("sh: not found" — a launch failure, NOT a refusal)?
# same contract, byte-diffed against the sh version in CI:
powershell -NoProfile -ExecutionPolicy Bypass -File <skill-dir>/scripts/preflight.ps1
# installation carries no scripts/ (script-blocking harness)? run from the checkout:
sh "$PELTIER_HOME/.claude/skills/peltier/scripts/preflight.sh"

A STATUS=refuse from either entry point is final — do not run the other one looking for a different answer.

Read the key=value output; you need BENCH_RUNNER and PIN_SUPPORTED. A refusal ends the claim, not the work — report the reason verbatim and do not substitute another timing tool.

BR=<BENCH_RUNNER from preflight>

1. Config

cp <skill-dir>/assets/accept.template.toml ./peltier-accept.toml
CFG=./peltier-accept.toml

Do not loosen threshold, runs_per_side, or confidence to make a result pass. That is not measurement, it is negotiation.

Pinning is not done through this file. pin_prefix is read only by the in-repo verdict pipeline — compare, aa, and calibrate ignore it entirely (bench-runner's own fingerprint says "caller-provided (wrap cmd in taskset)"). If PIN_SUPPORTED=yes and you know a core is free, pin by wrapping both sides identically:

--baseline 'taskset -c 2 <cmd>' --candidate 'taskset -c 2 <cmd>'

An unpinned host is not disqualified. A noisy one is, and step 3 is what decides that.

2. Two immutable artifacts — not two states of one tree

The harness runs the two sides alternately, 66 times. That is impossible if "baseline" and "candidate" are the same working tree in different states. Before measuring:

• Build each side into its own location — a git worktree per side, or two separate build/output directories. Never git stash between runs.
• Pass the built artifact paths as the commands. Never pass a wrapper that can rebuild: cargo run, npm start, go run, mvn exec will happily rebuild from whatever is in the tree mid-benchmark, so you can end up timing the same binary twice — and paying build cost inside the timed window.
• Confirm the two artifacts actually differ: sha256sum <baseline> <candidate>.

Peltier learned this the hard way (phase1-verdict-smoke-001: "workspace paths get silently rebuilt from the patched tree by test runs"), which is why the in-repo pipeline rebuilds a pristine baseline from the pinned upstream commit rather than trusting the tree.

3. Equivalence — before you time anything

Capture everything each side produces, on a fixed, representative workload:

run_side() {  # $1 = tag, $2 = command
    rm -rf "out.$1"; mkdir -p "out.$1"
    ( eval "$2" ) > "out.$1/stdout" 2> "out.$1/stderr"; echo "$?" > "out.$1/exit"
}
run_side base "<baseline-cmd>"
run_side cand "<candidate-cmd>"
diff -r out.base out.cand && echo "GOLDEN PASS" || echo "DIVERGENT"

If the command's real output is a file tree (a bundler, a compiler, an image pipeline), hash that too — stdout is not the artifact:

( cd dist && find . -type f | sort | xargs sha256sum ) > out.<tag>/tree

An empty diff over empty output is a failed gate, not a passed one. If both sides wrote nothing to stdout, nothing to stderr, and you captured no artifact tree, you have compared nothing — stop and find the real output before going further. Then run the project's own test suite against the candidate; it must pass.

• Identical output + tests green → proceed.
• Divergent → stop. No speedup may be claimed from a change you cannot show is behavior-preserving. The one exception — a change that legitimately alters output, floating-point reassociation being the common case — is needs-human-review, never an auto-accept. Quantify the divergence (how many values, by how much) and hand it to a human.

4. Calibration — can this host measure this change?

The A/A self-test runs the same command on both sides. It must find nothing:

$BR --config "$CFG" aa --cmd '<baseline-cmd>'

• stdout A/A self-test passed (null verdict) → the harness is not inventing speedups. Proceed.
• Nonzero exit, with Error: A/A self-test FAILED: harness claims a speedup from identical binaries on stderr → stop. This host is too noisy to measure this change; every number it produces afterwards is fiction. Report the noise floor, then quiet the machine (pin a core, disable turbo/SMT, close everything else) or move to calibrated hardware.

For a claim anyone will act on, run the full calibration — a false-positive rate over many A/A sessions plus proof the harness can detect a known injected regression:

$BR --config "$CFG" calibrate --cmd '<baseline-cmd>' \
    --sessions 20 --slowdown 0.05 --out calibration.json

Required: <5% A/A false-positive rate and ≥95% detection of the injected 5% slowdown. A harness that cannot see a real 5% regression cannot be trusted to confirm a real 5% win. Keep calibration.json — it is the evidence that the measurement itself was sound.

Budget the runtime before you start

compare executes the workload (30 + 3) × 2 = 66 times. calibrate --sessions 20 executes it roughly 2,650 times. Size the workload to ~0.2–2 s of wall time: shorter and you measure process startup, longer and calibration takes hours. Run calibrate in the background — it will blow through a foreground command timeout.

5. Measure — interleaved A/B, bootstrap CI

$BR --config "$CFG" compare --baseline '<baseline-cmd>' --candidate '<candidate-cmd>'

Runs are interleaved (ABAB…), not blocked, so thermal drift and cache state hit both sides equally. Output:

speedup (baseline/candidate): median 1.0884, 95% CI [1.0745, 1.1001]
verdict: accepted

The ratio is baseline/candidate, so >1 means the candidate is faster.

--perf-stat (Linux) adds cycles/instructions/cache-miss medians — useful for explaining why something got faster, never part of the accept decision, and usually unavailable in VMs.

6. Risk — you are the classifier here

bench-runner emits only accepted or rejected-bench. It cannot route a dangerous change to review, because in verify mode nothing is inspecting your diff. So inspect it yourself, and override the tool:

Read the patch. If it touches any of these, the outcome is needs-human-review regardless of what compare printed:

• Concurrency — threads, locks, atomics, memory ordering, volatile, work queues, async pools, rayon/pthread/std::sync.
• Unsafe / raw memory — unsafe, pointer casts, transmute, FFI, manual allocation, uninitialized memory.
• Floating-point reassociation — reordering accumulation, -ffast-math, FP SIMD, changed summation order.

These changes can be correct on your workload and wrong in production, and a green bench says nothing about that. A byte-identical output does not clear them: a data race produces identical output right up until it doesn't.

7. Verdict — read it honestly

What you see	What it means	What you may say
verdict: accepted	CI lower bound clears the threshold.	Claim it — with the CI lower bound, the interval, and the workload.
verdict: rejected-bench, CI spans 1.0 (e.g. [0.983, 1.001])	Indistinguishable from no change.	"No shippable win." A real, complete result.
verdict: rejected-bench, CI entirely below 1.0 (e.g. [0.91, 0.96])	A measured regression.	Report it as one, with the interval. Do not call it "no win."
Any risk signal from step 6	Out of the machine's hands.	needs-human-review. Never auto-accept.

Claim the lower bound, not the median: a median of 1.088 with CI [1.074, 1.100] supports "≥7.4% faster", not "8.8% faster".

If the result is a rejection, that is the answer. Re-running until it passes is p-hacking. Two failed hypotheses on the same hot path means you need a new hypothesis, not another run.

Services (latency, not throughput)

For a server, wall-clock-per-run is the wrong instrument. Service mode is an open-loop, fixed-rate load generator that measures each request from its intended send time, so queueing delay is counted rather than hidden (coordinated omission). It reports p50/p99 with bootstrap CIs.

It is not a generic HTTP load generator. The server binary must:

• take <port> <doc> <iters> as positional argv;
• print a line beginning with READY on stdout, flushed, once listening;
• answer GET / and close the connection (Connection: close) — the client reads until EOF with no timeout, so a keep-alive server hangs the harness forever.

Point it at a stock Express or Flask app and it will either fail the READY handshake or block indefinitely. Peltier wrote a thin adapter binary (targets/cjson/service.c) for exactly this reason; you will need one too.

$BR --config "$CFG" service --baseline-bin '<bin>' --candidate-bin '<bin>' \
    --doc <workload> --rate 150 --sessions 20

Calibrate it the same way first (service-calibrate). Tail percentiles on a single-worker loopback setup are jittery — if the p99 CI is wide, do not claim p99, even when p50 is solid. Peltier's own shipped service result claims p50 (+6.2%, CI [+5.8%, +7.2%]) and explicitly declines to claim p99 (CI [0.07, 4.97]).

Record the attempt — including the failures

Outside peltier there is no ledger, so write the evidence where the next person will find it (a results file, the PR body): hypothesis, what changed, equivalence result, calibration evidence, the CI, the workload, and the verdict. Failures are the most valuable rows — they stop someone from re-running your dead end in six months.