Child of #695/#714 (plan section 4.1).
Repo github.com/cederikdotcom/hydraprobe, tag v0.1.0, CI green, published to releases.experiencenet.com (latest.json reports 0.1.0). Six platforms: linux amd64/arm64/arm(GOARM=7), darwin amd64/arm64, windows amd64.
Self-contained UDP probe engine, no external probe library; dependencies are cobra and yaml only. Reports RTT and IPDV percentiles p50/p95/p99/max, the RFC 3550 running jitter estimate (reported, never gated), upstream and downstream loss split (the reflector piggybacks its received-count so the two directions can be told apart), duplicates and late packets, max loss burst, and client pacing error from monotonic clocks so device scheduling separates from network jitter per #402. B1 and B2 profiles per PLAN 4.5. YAML output matches the PLAN 4.6 schema field for field. HMAC-SHA256 on every packet, constant-time check, UDP 2112.
Verified by real runs, not only unit tests: loopback pass (rtt p50 0.168 ms, ipdv p99 0.624 ms, loss 0); wrong-HMAC-key run correctly reports 100 percent upstream loss and verdict fail without crashing; the pacing-degraded marker fires correctly on this shared VM, which cannot hold sub-ms pacing.
One defect found and fixed during verification: a run where nothing came back scored its zeroed timings as a fast path and returned conditional. It now returns fail.
Upstream loss currently does not gate the verdict, because PLAN 4.7 deliberately scores the downstream direction the stream uses. But the head's TOUCH INPUT rides the upstream direction, and mercator-talks is touch driven, so upstream loss degrades interaction directly. Proposal: apply the same limits (0.1 percent pass, 0.5 percent conditional) to the upstream direction. This changes what qualifies a region, so it needs an owner ruling before the campaign runs. Not applied.
Loopback is done. The LAN run, the tc netem known-loss check and the pacing self-check on a real probe node remain, per docs/testbooks/g0-testbook.md in the repo.