## What this is

Two commits on `b0b67aaa`: the pump instrument, and the IR-84 entry that explains why it was needed. Filed in the lane rather than after it.

## The defect this closes is a DIAGNOSTIC one

`two_host_web_helper_role_a` takes **61.956–69.096 s** across five runs while its siblings in the same binary take **0.135–0.753 s**. Every ladder rig — win-onebox, linux-onebox, cross-box — logs **exactly one** `PUMP_PEER_FAIL:<node>:peer reply-read: no progress within budget` on B before completing. 3/3, one each, never on A.

That line is emitted from the `Err(e)` arm of `peer_leg_outcome`, and at `b0b67aaa` it read `emit_line_err!("PUMP_PEER_FAIL:{peer_hex}:{e}")` — **no timestamp**.

Measured at that sha, not recalled: `pump/mod.rs` carries **four** `PUMP_PEER_FAIL` emit sites, **three** already stamped `wall_ms=… mono_ms=…` (submit arm, no-route arm, `PRESENCE_DIAL_FAILED` arm), and this was **the only unstamped one left**. It is also the arm the rigs actually fire — a `PEER_REPLY_READ_BUDGET` expiry reclassified out of `TimedOut` by `brain::reclassify_peer_reply_err` so it drops one peer rather than poisoning the round.

**The single arm a reader most needs to time was the single arm that could not be timed.**

## The arithmetic stays open, and the entry says so

`PUMP_PEER_IO_TIMEOUT` 30 s (`:118`) + `SUPERVISE_BACKOFF_BASE` 5 s (`:121`) = **35 s accounted** against **61.956–69.096 s observed**. ~27–34 s unaccounted — itself close to another 30, the coincidence the design doc warns against — and the count of *exactly one* fail forbids reading it as two deadlines elapsed.

Three candidates named and **deliberately not ranked**: a first ~30 s burned before the deadline's clock starts; a second budget stacking; the restart's re-prime costing more than its 5 s floor. Separating them needs the deadline's own timestamps against the fail line — exactly what the log did not carry.

## What this does NOT claim

The instrument does not explain the stall, does not shorten it, and **changes no product behaviour**: same peer dropped at the same instant with the same backoff. It makes the stall answerable from a log that already contains the failure, instead of requiring a rebuild to learn when the budget started.

## Recorded as a recurrence, which is the part worth keeping

This is the **second** unstamped `PUMP_PEER_FAIL` to cost a hunt. The `PRESENCE_DIAL_FAILED` arm already carries a comment naming the *"2026-07-14 PUMP_PEER_FAIL-unstamped seed"*, and **`REQ-PUMP-STAGE-TRUTH`** already requires every peer failure "stamped (wall+mono) and peer-attributed", explicitly subsuming that seed.

So the contract was written, three of four sites complied, and the fourth stayed silent for eight weeks — a convention enforced by no mechanism degrades one arm at a time, and every reader of a complying arm reports the convention as held. The site is now tagged `[impl->REQ-PUMP-STAGE-TRUTH]`.

The sibling reference in the comment is named **by arm, not by line number** — a sibling's line is wrong the next time anyone edits the file, and a stale pointer in a comment is the same defect class the stamp exists to fix.

## Verification

- `traceable-reqs check` → **exit 0**; `REQ-PUMP-STAGE-TRUTH` now carries this site as impl evidence.
- `now_ms()` (`:1607`) and `mono_ms()` (`:1555`) are module-level fns in this same file, in scope from `peer_leg_outcome` — checked rather than assumed.
- Register sequence IR-83 → IR-84 → IR-85 intact.
- **Not compiled locally**, deliberately: a push to main was running unit on both self-hosted runners during this lane's window, and a local Windows build competes with it. CI is the compile gate here.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

https://claude.ai/code/session_01WAw9XAcTR8oSwzYPsqZoY2