# One leg in this log has a displaced `foreign_cpu`, and the smoke's verdict does not depend on it

`LEG ... m=2048 arm=fast` carries the field twice:

    ... stage2_raw='joint scheduler, m=2048, gate 8192, FALLBACK arithmetic, stripe 512w'
    foreign_cpu=BOX-BUSY-WAIT try=1 foreign_cpu=173.4 ceiling=160 at=r1-m2048-fast ts=...
    BOX-BUSY-WAIT try=2 foreign_cpu=181.2 ceiling=160 at=r1-m2048-fast ts=... 128.1
    foreign_after=45.3 errlen=1475 ts=...

`plib.ps1`'s `Require-QuietBox` both LOGGED to the output stream and RETURNED
its reading through it, so on a leg where the guard actually FIRED, PowerShell
handed the caller every line the function had printed along with the number.
Found by the `joint-factor-min-m-x86-11sep` lane and fixed at `0cf8dff14f`; the
fixed library is deployed on all three Windows boxes.

**The reading for this leg is 128.1**, the bare token before `foreign_after`.
The guard waited twice - 173.4 and 181.2 against a ceiling of 160 - and re-read
before it ran anything, so the leg itself ran under 128.1 and is sound. What is
damaged is the RECORD, in the one field a reader consults to decide whether the
box was quiet.

**Nothing the smoke concludes comes from that field.** `wall`, `cpu`, `rc`,
`restored=32/32`, `stage1=joint-whole-demand` and `stage2=joint-FALLBACK` all
sit BEFORE the corruption and are intact, and the smoke's verdict is entirely
about whether the arms engage and diverge.

**It does correct one thing I said about this run.** I described the box as
quiet throughout. It was not: this leg waited out two spikes above the ceiling
before it ran. That has no bearing on the smoke, which makes no timing claim,
and the 45-leg whole-arm round on the same box
(`zen5-whole-arm-9800x3d-2026-09-11.log`) is clean - zero waits, zero displaced
fields, so its median 48.4% / p90 79.7% / max 157.8% stand as measured.

The log is kept exactly as written. the extractor detects this shape by
REPEATED KEY rather than by checking the value, because a dict keeps the last
occurrence and the numeric check this guard started with passed the very line it
was written for.

It now also REPAIRS it, which the joint-factor-min-m-x86 lane does in their own
reducer and were right to: reporting alone leaves a recoverable number on the
floor, and worse, leaves the field reading the SPIKE. Last-wins on the repeated
key means `foreign_cpu` parsed as 181.2 - the reading that triggered the second
wait - rather than the 128.1 the leg actually ran under. That overstates the
load on exactly the legs where the guard did its job. The true value is the last
bare numeric token on the line, the one nothing claims, and the repair is
reported rather than applied silently: an edit to a record is never quiet, even
a correct one. A displacement of any OTHER shape is refused rather than guessed
at, because a corruption whose anatomy is unknown displaces an unknown number of
fields.