# W7 GATE RECORD — `a1f4901e`, PASSED (doyle, hfenduleam, 2026-09-24)

Lane `feat/331-w7-auto-apply` @ `a1f4901ee55d413b453af4d7b4a08b80013e4b98`, releases#336 under
#331 SEAMLESS-UPDATES. Gated from my own rig `.worktrees/gate-w7`, pool claimed
`gate-w7-a1f4901e`. **Every line below is my own measurement, not todlando's handback report.**

## Subject verified before any green

- Head `a1f4901e`, tree clean, detached in my gate worktree.
- Chain off main `9315f649`: `4d91f5d1` (REQ activation) → `54f58ede b62aa63a 3c23dcd1`
  (hertz's rig) → `21f83701` (todlando's impl) → `a1f4901e` (hertz's ORDER commit). Matches the
  handback description exactly.
- `git merge-base --is-ancestor origin/main a1f4901e` → YES, ff-able.

## Legs

| Leg | Result |
|---|---|
| `cargo build --workspace --tests` | exit 0, 11m21s |
| `traceable-reqs check` | **exit 0**, 972/972 complete, 0 findings |
| `auto_apply_e2e` (full capture) | **PASS 100.72s**, exit 0 |
| 10 pinned promotion/rollback units, BY NAME | 10/10 passed |
| `brain_respawn_rename` / `brain_survive` / `bundled_adapters_e2e` | 3/3 passed, 44.5s |

`traceable-reqs check`'s exit was captured on its own call. An earlier reading in this lane was
taken through a pipe and reported `tail`'s exit, not the tool's — the number above is the tool's.

## The ORDER observable, in my own run

    adapter move recorded in 627.28ms:
      SubjectApply { old: "0.9.0", new: "1.0.0",
                     applied_by: Some(ApplyingCore { version: "0.72.0", counter: Some(11) }) }
      with applied: Some(11) in the SAME BState read

That is A2's discrimination doing its job: the tag's claim reads "the leg ran at the promotion
this rig observed", not "some leg saw 11".

## Control pair (the rig is a real negative control, not an assumed one)

- **RED** `3c23dcd1` (doyle, this morning): exit 101, 146.15s. Failure point recovered by
  arithmetic over measured bounds, NOT read from a log — I lost the label to a `tail -40` pipe.
  `ARTIFACT_WAIT` is 600s and staging measures ~14s, so a staging failure would have burned
  600s+; the next bare `wait_for` is the apply wait at `RIG_WAIT` 120s, and setup ~12s +
  staging ~14s + 120s ≈ 146s is the only bound that fits. Recorded as an inference.
- **RED** (todlando, the ORDER assertion's own control): the adapters leg's promotion
  requirement removed → FAIL 39.268s, exit 100, label READ from the log —
  `auto_apply_e2e.rs:534`, left `(None, Some(11))` right `(Some(11), Some(11))`. The move
  happened and was performed PRE-promotion. Restored with a sha256 byte-identity assert.
- **GREEN** `21f83701` (todlando) 74.475s, **GREEN** `a1f4901e` (todlando) 71.342s,
  **GREEN** `a1f4901e` (doyle, above) 100.72s.

## Tag placement — verified by hand, not by the parser

treqs notes 5 tag-carrying files "not placement-judged". todlando flagged honestly that the
count matched `3c23dcd1` but that he had not verified it was the same SET — count equality is
not identity. I did not need the set: every W7 evidence file is `.rs` (the only non-`.rs`
tag-carrier in the range is `traceable-reqs.toml`, the registry itself), and I read the sites
directly. Spot-checked `autoapply.rs:56` (on `pub fn staged_class`), `config.rs:65` (on
`pub enum AutoClass`), `auto_apply_e2e.rs:533` (immediately above A2's
`(counter, applied) == (11, 11)` assert). None at a file top.

## Right-sizing stated, not hidden

Three swap-adjacent e2es were run, three were not: `adapter_swap_e2e` ×2 and
`live_adapt_translation_swap_e2e` are adapter-side, already exercised by `auto_apply_e2e`'s
bundle leg, and run at the milestone golden. That is a choice, recorded as one.

## Open item routed, not swallowed

**RESOLVED by hertz's RCA, same session — PRE-EXISTING, W7 not implicated.** Mechanism, in the
source at BOTH shas: the tests' Windows `long_child()` is `cmd /C ping -n 30 127.0.0.1` with only
stdout nulled, so stderr/stdin are nextest's inherited capture pipe. `Child::kill` terminates
**cmd.exe**; the grandchild `PING.EXE` is never killed and holds that handle ~29s, which nextest
reports as LEAK. That is why the A11 assert held and the leak still appeared — the assert checks
the killed pid (cmd), and the surviving handle is ping's. PROVEN on hfenduleam with a PowerShell
probe and no cargo at all: after `Stop-Process -Force` on cmd (the same `TerminateProcess` call
`Child::kill` makes), cmd dead, `PING.EXE` and conhost ALIVE. W7 exonerated by hunk: the four
`brainproc` hunks in `9315f649..a1f4901e` touch `BRAIN_EXE_ENV`/`canonical_exe`, `run_brain`,
`spawn_brain_child` and `spawn_brain_supervisor` — none touches the test module, `long_child`, or
`supervise_brain`'s kill path, and both tests drive `supervise_brain` directly with a closure
spawn.

**Labelled INFERRED, not measured:** that they also leak at base. hertz refused the base rebuild I
offered to fund, and I did not spend it either — the mechanism is in the source at both shas and
no hunk sits on the path, so a Windows base run would confirm an argument rather than
discriminate. He was also right that kitsubito is the WRONG discriminator: Linux `long_child` is a
bare `sleep 30` that the kill ends, so it returns a clean zero that answers nothing. A probe that
cannot express the hunt is not a negative result.

Filed as **IR-155** into hertz's #274 rebase (CI/test-craft debt → INFRA-REGISTER, never the
board), with the fix routed to him after: spawn PING directly so the kill hits the process holding
the handles, and null stderr/stdin there. Predicted population: the `long_child` users at
`:1529 :1953 :2227 :2271 :2313`, of which only 2 were among my pinned 10.

Original observation: `cargo nextest` reported **2 LEAK** rows among the 10 passing units:
`brainproc::tests::ready_but_old_gen_never_drains_does_not_promote_rolls_back` and
`brainproc::tests::trial_kills_alive_never_ready_candidate_before_rollback`. Both spawn
`long_child()` candidates. NOT a blocker: the A11 hazard assert itself held — the test asserts
the candidate is already dead when the rollback binary spawns, and it passed — so the kill
happened and some other handle outlived the test. Routed to hertz (test-craft lane) with the
discriminator I could not afford: does it reproduce at base `9315f649`? A rebuild at base costs
me 11 minutes in this pool and costs an idle kitsubito nearly nothing. If it leaks at base, W7
is exonerated; if only here, `brainproc`'s W7 delta is implicated and we want that before the
golden, not during it.

## Write census, read BEFORE the timing legs

Taken as a SEPARATE call and read before launching (my own IR-150 sample 7 procedural finding):
0 cargo, 0 rustc, 0 nextest, 0 Runner.Worker; only fleet `spt`/`claude-spt` adapter processes.
Free C: 39,714,869,248 B at that moment.

## Landing

**DONE.** `git push origin a1f4901ee55d...:refs/heads/main` → `9315f649..a1f4901e`, exit 0, no
force, no merge commit. `git ls-remote origin refs/heads/main` reads
`a1f4901ee55d413b453af4d7b4a08b80013e4b98`. **tested sha == merged sha.** Never a `gh pr merge`
verb, which would re-commit or mint a merge commit and break that equality.

Board: releases#336 → **acceptance** via alchemy (`cmd <op> "<tail>"` — the op is the first
argument, NOT folded into the quoted tail, which is what my first attempt got wrong).

Landing push run **36051790154** at `a1f4901e`, read separately from #274's PR run rather than
carrying that reading across (hertz's rule: the landing push is its own classification).

## Teardown owed

`.worktrees/gate-w7/target` was 72.2 GB allocated before this rebuild and is owed an IR-150
three-number teardown (apparent, allocated, escaped-per-inode) with a writer census. todlando
owes the same for `.worktrees/w7-updater/target` (14.7 GB) at lane close.

## AMENDMENT — the gate missed a real defect, found by the landing push (doyle, 20:15Z)

Landing run **36051790154** at `a1f4901e`: `changes`, `traceability`, `lint`, and BOTH unit legs
green; **`docs-drift` FAILED**. The failure is `xtask check`, and it is a genuine W7 defect:

    ... spawn a REAL `spt daemon run` or brain tree but are not in the <HEAVY> set — they will run
    in the full-parallel Phase-A pool and starve at their readiness deadlines
    (FLAKE-LEDGER: resident_service_e2e :453 PRECONDITION). Add each to BOTH <HEAVY> strings,
    alphabetically:  auto_apply_e2e

Verified at main by hand: `golden.yml:173`'s spt-package binary list runs
`attach_link_push_e2e|attach_wedge_e2e|bind_cwd_project_e2e` with no `auto_apply_e2e`, and
`.config/nextest.toml`'s `heavy-broker-pty` override has the same hole. W7 minted a new
real-daemon e2e and never registered it — HEAVY at birth under the W4 HEAVY-AT-BIRTH ruling.

**Why the gate did not see it.** The gate ran the compile leg, `traceable-reqs check`, and the
targeted suites; it never ran `cargo run -p xtask -- check`, which is what the `docs-drift` job
runs. The lane also landed by ff push from a gate worktree with **no PR run**, so `docs-drift`
spoke for the first time on the push to main. Two independent misses, one consequence.

**Standing change to my gate:** a thin lane gets `xtask check` — captured to a file, exit read on
its own call — before it is landed, whether or not it has a PR run.

Still live in the tree at `21fc9142`: the docs-only push skipped the code jobs, so nothing
re-tested it. Routed to hertz (test/CI lane) as a thin fix off `21fc9142`, with a red-then-green
pair on `xtask check` as the proof.

### Resolution — main green again at `14350a78`

hertz's PR #275, landed by me via ff push `21fc9142..14350a78` (no force, no merge commit; PR reads
auto-MERGED at the same sha). Run 36083948091 at that head: **all 6 jobs success, `docs-drift`
included**. Three files, three lines.

- `970cd45e` — `auto_apply_e2e` inserted after `attach_wedge_e2e` in BOTH `<HEAVY>` strings.
- `14350a78` — a 14-space interior run collapsed in `autoapply.rs`'s deferred message. I did not
  order this one, so I checked the premise rather than asking him to defend it:
  `xtask/src/spacerun.rs` + `main.rs:718` refuse interior space runs in operator-facing text
  (releases#74). It is a SEQUENTIAL refusal from the same predicate — `xtask check` cannot go green
  without it — and therefore **the second W7 defect this gate missed, for the same one reason.**

Two defects, one cause. The standing change above stands: `xtask check` runs in the gate, because
it refuses more than one thing and a lane landed by ff push has no PR run to speak for it.