**A7 AMENDMENT 5 — 2026-09-12 ~06:20Z. Two-axis re-check after a context reset, superseding Amendment 4's census (A5.1/A5.2) with a current one. A7 is still NOT granted; this asks doyle for the grant, it does not take it.**

Amendment 4's census was taken at ~06:10Z. The 30-second handover measured in comment 5644026871 is precisely why a ten-minute-old idle read is not the box a first cold wall lands on, so both axes were re-read rather than carried forward.

## A6.1 Axis 1 — jobs-level CI, `BigscreenVR/spt-bs-core`

Repo confirmed by `gh repo view` before the read, because the only git remote in this checkout is the SaberMage mirror and a run list resolved against the wrong repo returns a confident empty at exit 0.

- **No run on the repo is `queued` or `in_progress`** — filtered on `.conclusion==null or .status!="completed"` over the last 15 runs; empty.
- Latest run **34676423540** (`7cdcf5da`, main), read `--json jobs`, never `--json status`: `changes` SUCCESS 05:52:40Z · `traceability` SUCCESS 05:52:30Z · `lint` SUCCESS 06:01:48Z · `unit (self-hosted, Linux, kitsubito)` SUCCESS 05:59:48Z · **`unit (self-hosted, Windows, hfenduleam)` SUCCESS 06:05:15Z**.

The Windows leg finishing at 06:05:15Z is the last work this box owed CI.

## A6.2 Axis 2 — ancestry-authenticated local census

```
Runner.Listener.exe(22712) <- RunnerService.exe(19588) <- services.exe(1644) <- wininit.exe(1532)
rustup.exe(39260)          <- claude.exe(5988)  <- claude-spt.exe(38632) <- spt.exe(4732)
rustup.exe(43280)          <- claude.exe(38220) <- claude-spt.exe(44512) <- spt.exe(4732)
```
`Runner.Worker.exe` is **absent**; the listener alone, parented through `RunnerService`/`services.exe`, is the idle waiting state. The two `rustup` shims are the same rust-analyzer LSP servers named in A5.1, parented to agent Claude sessions — a name-matching filter would report "2 build processes" and block on nothing.

## A6.3 The CPU floor, re-attributed (A5.3 bracket shape)

3-second per-process delta, all processes, >0.05 cpu-s shown:

| pid | process | cpu-s / 3 s | % of one core |
|---|---|---|---|
| 52492 | bun | 0.86 | 28.6 |
| 15856 | spt | 0.33 | 10.9 |
| 4732 | spt | 0.33 | 10.9 |
| 25032 | Everything | 0.30 | 9.9 |
| 11496 | spt | 0.22 | 7.3 |
| 35424 | chrome | 0.17 | 5.7 |
| 29268 | alchemy | 0.16 | 5.2 |
| 21584 | voicemeeterpro | 0.16 | 5.2 |
| 25272 | alchemy | 0.11 | 3.6 |
| 12424 | wallpaper64 | 0.11 | 3.6 |

**Total 3.55 cpu-seconds over 3 s wall across 16 logical cores = 7.4% of capacity. Zero `cargo`/`rustc`/`cl`/`link`/`cargo-nextest`/`msbuild` in the delta** — asserted as a count from the same delta, not from a separate filter.

**Corrected on doyle's ruling before this was posted, because Amendment 4 A5.2/A5.3 and my draft of this section both overreached:** a CPU sample is a **contextual observation taken outside the timed invocation**. Adjacent samples describe **observed load at that moment**. They cannot apportion a wall-time spread between noise and load, and one sample cannot establish a **steady-state floor** — so A5.2's "this box's steady state while agents are live" and my draft's "the floor is the agent fleet plus desktop software" are both withdrawn as characterisations. What the table supports is narrower and still useful: at 06:20Z, no build-class process consumed measurable CPU, and 3.55 cpu-s/3 s was distributed across the listed processes. The 7.4%-vs-14.8% difference between two samples is a difference between two samples, not a trend.

Binding with it: **no threshold on the bracket, no wall discarded for a busy bracket, and no replacement attempt run to improve one.**

## A6.4 Subject re-verified, unchanged

```
git -C .worktrees/asm-304-w2 rev-parse HEAD  -> 921aa68f89b2d2254087f0c832fc61ed59cf3522
git -C .worktrees/asm-304-w2 status --porcelain -> EMPTY
rev-parse HEAD:crates/spt-daemon/src/bootstrap_firewall/windows.rs -> 61841e4f6d6fe3e8c9428df2a9137252daad2eb0
```
The blob id is recorded so a later claim about what was measured is checkable against the file, not only the commit.

## A6.5 What I am asking for, and what I will not do without it

Everything in Amendments 1–4 stands as written. Nothing has been executed: **no pool claim taken, no build started, no arm run, no load added.**

The window requested covers **S1–S5 and both arms** (Amendment 2 A3.4) — S3 performs a release build of `spt` on this box, so a window scoped to the arms alone would have staging contend with what the window exists to exclude. Per Amendment 3 A4.2 item 4, the two-axis census is **refreshed again after that release build and before ARM A**; the census above authorises starting S1, not starting ARM A.

## A6.6 GRANT RECEIVED — doyle, 2026-09-12 06:10Z, quoted

> A7 window GRANTED to you on HFENDULEAM: S1–S5, both registered arms, and teardown, subject to the recorded provenance and post-build idle checks. START means actually launched; report END with cleanup evidence. If CI reoccupies the runner, pause before further trials and report it—do not stop the runner.
>
> CPU brackets accepted as contextual observations, outside the timed invocation. Correct the causal claim: adjacent CPU samples describe observed load; they cannot apportion wall-time spread or prove a steady-state floor from one sample. No threshold, discarded walls, or replacement attempts. Liam's involvement remains limited to otherwise-blocking elevated setup and teardown.

The causal correction is applied in A6.3 above rather than appended as an erratum. Four terms of the grant are carried into execution as procedure:

1. **START means actually launched.** This comment is the readiness record; a separate START report names the first command actually run.
2. **END is reported with cleanup evidence** — `LAN_FIREWALL_CLEAN` in the teardown log **and** `C(final)` showing 0 rows in group `spt-core bootstrap TCP`, 0 rows covering TCP 29470, both positive controls present, and the 5470 rules unchanged.
3. **If CI reoccupies the runner, I pause before further trials and report it. I do not stop the runner** — the post-build census (A4.2 item 4) is where that is most likely to surface.
4. **liam is asked for exactly two elevated actions**: the reconcile that creates the ARM B pair, and the teardown. Nothing else.