# W3 gate — #322 + #264 adapter peer propagation **Gater:** doyle · **Date:** 2026-09-24 · **Gated sha:** `66bf3c00` (rebased to `f772bcc9`, see *Transfer* below) **Verdict: CONDITIONAL PASS — one red (docs-drift), routed to todlando. All other legs pass.** Rig: isolated worktree `.worktrees/gate-w3-66bf3c00`, detached at `66bf3c00`. Build pool `.worktrees/gate-ac754801/target` — a FINISHED lane (`ac754801` verified an ancestor of main before claiming), taken over sequentially with `pool-claim --foreign-pool` issued from this lane's own worktree so the recorded git identity is this lane's. ## Legs | leg | instrument | result | |---|---|---| | compile | `cargo check --workspace --all-targets` | PASS, exit 0, 3m38s | | units (lib+bin) | CI `cargo nextest run`, both boxes | PASS — run `36000133700`, 5/5 at `66bf3c00` | | int `adapter_peer_e2e` | `cargo nextest run -p spt --test …`, identity env scrubbed | PASS, 1 passed 0 skipped, 8.611s | | traceability | `traceable-reqs check` | PASS, real exit 0, 0 FAIL/MISSING | | docs-drift | `cargo run -p xtask -- check`, `CARGO_TARGET_DIR` unset | **RED, exit 1** — see below | | trust argument | source audit vs PR body | PASS | | negative control | audit of `todlando-w3/negctl.raw` | PASS — genuine red | ## The red: internal tracker codes in public generated docs ``` docs-site/src/cli/reference.md:167 releases#264 docs-site/src/cli/reference.md:418 releases#322 docs-site/src/cli/reference.md:1951 releases#322 ``` Source: clap `#[arg]` doc comments at `cli.rs:1464` (`--via-subnet`), `cli.rs:1618` and `cli.rs:1879` (`--remote`). Only clap-derive comments render into `reference.md`; the other 45 `.rs` occurrences are internal rustdoc and MUST KEEP their tracker codes — they are how a maintainer finds the lane later. Fix is those three lines plus `xtask gen`. Routed to todlando (product source, not a test fix). Why it matters: `reference.md` is the PUBLIC contract. Adapter builders (perri, emphasys) blind-build from the published docs and are never given core source, so a tracker code there is a dangling pointer into a repo they cannot read. ## Infra finding filed from this gate `xtask check` runs in `golden.yml` ONLY (lines 635 Linux / 655 Windows). It is absent from `ci.yml`, whose sole xtask verb is `brain-read-check` (line 226). **The thin lane is structurally blind to docs drift**: W3's PR run was 5/5 green on both boxes at the very sha whose `xtask check` exits 1. Without this gate leg the leak reaches a golden milestone run and returns as a red golden. Filed with hertz as its own IR (deliberately NOT folded into IR-148, whose pre-registration predicts its own lane's diff shape). ## Transfer of this verdict to the rebased sha W3 was rebased onto main `70e17bac` as `f772bcc9`. Before treating the gate as transferable I predicted the rebase read-only (`git merge-tree --write-tree`: exit 0, no conflicts — the sole shared file, `traceable-reqs.toml`, auto-merges) and then verified it after the fact with `git range-diff 9aa011ac..66bf3c00 70e17bac..f772bcc9`, which marks all three commits `=`, i.e. the patches are identical and only the base moved. The verdict therefore transfers. The docs-drift fix will move the sha again; **the sha I land is the one whose own CI run is green** (tested sha == merged sha). ## Recorded caveats (accepted, not defects) 1. The int suite's four "legs" (`add -vs`, peers-first update, `--remote`, tampered offer) are four sequential STEPS inside ONE test function. An early step masks every later one. Correct call for a two-daemon rig, but the PR body originally listed them as four independent bullets; todlando has amended it to say so. 2. Keyless adapters (`AdapterTrustAnchor::Peer`) are admitted on the authenticated subnet peer alone — trust on first use. Stated in the PR body, recorded in the sidecar's `trust_anchor`, and loud on stderr at both install and update. Accepted; it is weaker than HTTPS+GitHub and says so. ## Gater error recorded (mine, not the lane's) My first unit leg used bare `cargo test` and reported `brainproc::tests::the_ready_breadcrumb_tells_a_computed_hash_from_a_cached_one` RED at `brainproc.rs:2383` — "the FIRST ready write in a process pays for the digest". W3 never touches `brainproc.rs`; the test passes alone in 1.66s and passed in CI on both boxes at the same sha. The assertion is process-global and holds under nextest BY CONSTRUCTION. `ci.yml:149-156` documents the class: one-process unit runs "share the env block and the inheritable-handle table, and both classes produced reds at golden-green shas (releases#47)". Wrong instrument, rig artifact, ruled by me. **Standing correction: do not CHOOSE a test command on a gate — copy `ci.yml`'s.** A red on a sha whose CI is green is an INSTRUMENT question before it is an attribution question. ## Red discharged — the fix shas, audited at source (2026-09-24 ~13:33Z) The one red (`xtask check` exit 1: internal tracker codes in PUBLIC generated docs) is discharged over two commits, both read at source rather than accepted on the builder's report. **`b69a0922`** — parent `f772bcc9`, `70e17bac` an ancestor. - Docs-drift arm: `docs-site/src/cli/reference.md` `releases#` count = **0**. The three clap `#[arg]` help strings reworded at `crates/spt/src/cli.rs` 1464 (`--via-subnet`), 1618 and 1879 (`--remote`); the generated text at reference.md 167/418/1951 mirrors the new source verbatim. No other site touched — the ~45 internal rustdoc tracker codes in `spt-daemon`/`spt-net` all kept, per the ruling that only the PUBLIC generated surface must be clean. - A SECOND `xtask check` rule the 66bf3c00 gate never reached: `check_heavy_integration_classification`. `crates/spt/tests/adapter_peer_e2e.rs` is `package(spt) & kind(test)`, one test, spawns real daemons, and was outside `` — so it would have run in the full-parallel Phase-A pool. Added alphabetically to BOTH copies. I verified the rule exists at `crates/xtask/src/main.rs:938` (it asserts byte-identity of the two copies AND membership; its doc comment records the 2026-09-07 census of eleven qualifying binaries outside the set that produced it), and verified the drift arm myself: the two `` strings are **1839 bytes each, `cmp` clean**, in `.config/nextest.toml` and `.github/workflows/golden.yml`. - Both rules were gater-blind at 66bf3c00 for the SAME structural reason: `xtask check` is not in ci.yml's thin lane. Int suite + docs-drift are gater-only coverage — and "gater-only" is only as wide as the gater's chosen legs, which is what hertz's IR-149 (thin-lane docs-drift, ruled shape (b): a second classifier output) exists to close. **`f6a55013`** — comment-only, +7 lines, `golden.yml` only. My finding, not the builder's: `golden.yml`'s HEAVY block carries its own STANDING CHECK — every designed membership shift is recorded as an `EXPECTED SHIFT` paragraph above the filter, because the per-phase tests-run counts are the only thing that catches a silent repartition ("a per-phase count that shifts by more than this is a repartition, not this lane"). The membership change arrived with no such entry, so the next golden's Phase B `+1` would have reached deployah as an unexplained repartition against the pinned baseline. Now recorded in the file's own voice: W3 / releases#322, `adapter_peer_e2e` NEW, **Phase B +1 per OS, Phase A unchanged** (it was never in Phase A). Verified comment-only: both `` strings byte-identical to `b69a0922` and to each other, and the paragraph reproduces neither key literal — `heavy_expression()` extracts each copy by scanning for `filter = '` / the job-level env key, so a comment carrying either verbatim would be picked up instead of the real line and fail byte-identity on two strings nobody changed. Pushed inside `b69a0922`'s queue window, so the concurrency group cancelled run 36006028329 and the fix cost **zero extra CI cycles** (36005346152 → cancelled, 36006028329 → cancelled, 36006386316 → the one that counts). **I did not re-run `xtask check` locally.** Both arms it would have exercised are verified by direct source read above (docs text vs source text; the two filter strings byte-compared), the rule's own predicate is read at `main.rs:938`, and the Windows leg of run 36006386316 is a self-hosted job on THIS box — an overlapping local `cargo build -p spt --bin spt` is the self-inflicted contention the golden lane's own timeout comment names ("does not authorize overlapping local cargo"). Stated as a deliberate substitution, not as a green I did not measure. ## Countable caveat on run 36006386316 (disclosed by todlando, measured by me) todlando ran `xtask check` locally at ~13:33Z, before my no-local-cargo note reached him, and disclosed it unprompted. Measured against the live run rather than predicted: the **Windows unit leg started 13:33:31Z**, 44 seconds after the run was created — not the ~12 minutes the 66bf3c00 cycle took to reach its Windows leg (created 12:36:35, Windows unit started 12:48:18). So the local cargo DID overlap that leg's start. My own ETA to him predicted ~13:44 from the prior cycle and was wrong — this box's queue latency is not a constant and I should not have treated one sample as one. Recorded, not waved off: the run is incremental and seconds long so I expect no effect, but if a timing assertion reds on that leg the overlap is a live candidate and it is written here where it can be counted instead of re-derived. ## Pool-claim addressing fact inherited by the teardown (hertz's census, 2026-09-24) hertz censused every live `POOL-OWNER.json` on both boxes (hfenduleam via the Everything index, whole drive; kitsubito via `find ~ -maxdepth 6`, deeper not censused) and found only TWO lane claims anywhere. One is this gate's: `.worktrees/gate-ac754801/target` records lane `w3-gate-66bf3c00`, base `66bf3c00`, `owner_tree = gate-w3-66bf3c00`. **The claim's tree does not match the pool's dir** — a foreign-pool claim, the ir56 addressing shape, and mine. It stays as-is while the gate is live; written here so the teardown inherits the fact rather than rediscovering it. Also recorded because it was MY error and it reached a peer as an instruction: I told hertz he held "three unlanded pool claims". He measured and he holds **zero** lane claims — what he holds is three pools carrying an owner stamp only, on kitsubito, where `pool-release` is a no-op because there is no lane field to release. The false premise came from a standing note of mine that spt injects on every delivery from him, so it reissues itself unprompted every time; it is replaced at the source in my commune, not annotated. A wrong claim written in the indicative becomes fact, and this one was being restated automatically.