doyle — new INFRA finding, measured this hour, file it as an IR. Also a status note on IR-148's hold.

THE FINDING: the thin lane is structurally blind to docs drift.

cargo run -p xtask -- check appears in golden.yml ONLY, at lines 635 (Linux) and 655 (Windows). It does NOT appear anywhere in ci.yml. ci.yml's only xtask verb is brain-read-check at line 226. So a thin-lane PR can be 5/5 green while the public generated documentation is broken, and the drift is not discovered until a golden milestone run — where it lands as a red golden that comes back to me for triage, at milestone-batch cost, with the authoring lane long since context-cleared.

This is not hypothetical. I caught exactly this on W3 today: xtask check exits 1 at 66bf3c00 with three internal tracker codes leaked into docs-site/src/cli/reference.md (lines 167, 418, 1951, from clap #[arg] help at cli.rs 1464/1618/1879). W3's own PR run 36000133700 was 5/5 GREEN on both boxes at that same sha. The green was honest — the lane simply never asks the question. todlando is fixing the three lines now.

The asymmetry to state in the entry: the docs-drift gate is the one golden-only gate whose input is a THIN-LANE-sized diff. Units and clippy are already mirrored into the thin lane; this one was not, and it is cheap — it is a single xtask invocation over generated output.

Two things I want you to weigh in the entry rather than assume, because I have not measured them and I am not going to assert them:
1. Cost. xtask check needs a built spt binary, so the honest question is what it adds to a thin lane that has already built the workspace — probably little, but measure it before proposing it as unconditional.
2. Placement under IR-147. A docs-only push now skips lint and unit; if the docs-drift leg were added naively it would either run on docs-only pushes (where reference.md CAN change, so it should) or be routed off with the rest (where it must not be, since that is precisely the diff class that breaks generated docs). State which arm it belongs in. My instinct is that it follows the DOCS class, not the code class, and that is the opposite of most legs — worth saying out loud in the entry so nobody later "fixes" it by grouping it with unit.

Do NOT let this widen IR-148. File it as its own entry. IR-148's pre-registration predicts a specific classification for its own landing push and I do not want its lane's diff shape moved underneath it.

IR-148 HOLD STATUS, unchanged but with a better ETA: still hold the push. W3 is not landing as fast as I hoped — the docs-drift red means todlando pushes a fix and we take another full CI cycle on the new sha. I will tell you the moment W3 lands. Everything you have built stays valid; nothing needs rebasing yet.

One correction to something I told you earlier, since it affects how you read my gate reports: I said my W3 unit legs were running locally. I killed them. ci.yml's thin lane runs cargo nextest run --workspace -E 'kind(lib) + kind(bin)' on both boxes, so my local lib run was duplicating the authoritative instrument while competing with W3's own Windows leg for hfenduleam. CI's legs are the unit evidence; my local capacity goes to what CI does not cover, which here was the int suite and this docs-drift leg. That split is what found the red.