**A7 AMENDMENT 2 — 2026-09-12 ~06:05Z.** Repairs 1–3 from doyle's review of comment 5644042784, plus one correction he required and one he did not ask for. The original quotation in that comment is untouched; this amends, it does not replace. **A7 remains NOT granted; runner availability is a separate gate.** Paths below: `W` = `C:/Users/decid/Documents/projects/spt-core/.worktrees/asm-304-w2` (the lane worktree, clean at `921aa68f`), `H` = the isolated `SPT_HOME` prepared in A3.3. Every capture **redirected to a file, never piped**. ## A3.0 Two corrections first **Required by doyle:** the phrase "candidate (b) gains" is **REMOVED** from the 554 ms diagnostic trigger. Proximity to the deadline alone cannot attribute the deficit. The trigger now reads: *if ARM B completes but lands within that spread of 3000 ms, the dropped `-Name` array form and process reuse come back on the table as options to re-examine* — with no causal attribution attached. **Not asked for, and it changes a command I already published:** A3.3 below establishes that the set-staging path builds and attests a **release** binary (`--build-current` calls `build_release_spt`). The `cargo build -p spt --bins` line in A2.2 of the previous comment would have produced a **debug** exe that no staged set attests, and the listener would have refused it by name. **The exe under test is `W/target/release/spt.exe`.** The earlier line is withdrawn. ## A3.1 Repair 1 — every outcome value and the missing row, defined The subject row is emitted to **stderr**, one per invocation: `bootstrap-firewall leg=verify-query program=powershell.exe wall_ms= outcome=` | row | source condition | counts as | |---|---|---| | `outcome=completed` | `run_bounded` returned `Ok`, deadline never fired | **The only successful completion.** The wall enters the arm's table | | `outcome=failed` | `run_bounded` returned `Err` **without** the deadline firing — a non-deadline error | **NOT a successful completion.** The wall is recorded and the error text quoted verbatim, but it is EXCLUDED from the arm's completed set. It is a distinct third state, not a slow success and not a timeout | | `outcome=killed` | the 3 s deadline (`Duration::from_secs(3)`) expired | **The failure verdict** for the populated arm | | **row absent** | no `leg=verify-query` line in that run's stderr at all | **The run is VOID and counts as neither.** It means the measured path was not reached — the listener refused by name before `report_lan_admission`, or the product exited earlier. **A missing row must never be read as "nothing went wrong"**; it is investigated before any further arm runs | **An arm is a measurement only with three `outcome=completed` rows.** Fewer is reported as partial, with each non-completed row classified by the table above. No arm is summarised by an average that silently drops a non-completed row. ## A3.2 Repair 2 — executable commands for ARM B, and the census **Census `C()` — run before and after every wall. Per-rule reads only.** ```powershell Get-NetFirewallRule -PolicyStore ActiveStore | ForEach-Object { $p = $_ | Get-NetFirewallPortFilter $a = $_ | Get-NetFirewallAddressFilter $ap = $_ | Get-NetFirewallApplicationFilter [pscustomobject]@{ Name=$_.Name; Group=$_.Group; Enabled=$_.Enabled; Dir=$_.Direction; Action=$_.Action; Proto=$p.Protocol; LocalPort=($p.LocalPort -join ','); Remote=($a.RemoteAddress -join ','); Program=$ap.Program } } | Export-Csv -NoTypeInformation "census-.csv" ``` **Two positive controls per dump, or the dump is VOID:** at least one row whose `LocalPort` covers **5470**, and at least one row whose `Program` is the installed `spt.exe`. A bare `Get-NetFirewallPortFilter` enumeration read 5470 as **zero** unelevated while the per-rule pipe read it — that is why the shape above is mandatory and why a zero from it is only trustworthy with both controls present. Subject rows: group `spt-core bootstrap TCP`, and any row covering TCP **29470**. **ARM A — empty owned set, unelevated, ×3.** No elevation; `report_lan_admission` verifies before requesting it. ```bash # C(a-pre-N) SPT_HOME=$H $W/target/release/spt.exe serve lan --bootstrap --port 29470 > a7a-N.out 2> a7a-N.err SPT_HOME=$H $W/target/release/spt.exe serve lan --stop > a7a-N.stop.out 2> a7a-N.stop.err # C(a-post-N) ``` Each ARM A run exposes 29470 on all interfaces until its `--stop`; the window is recorded per run. **ARM B setup — ONE elevated action (liam), and the mechanism that makes the arm possible.** ```powershell # ELEVATED. The pair is written by the PRODUCT'S OWN reconcile, so the rules are in the shipped # desired_specs shape. Note the LAN half now renders a LITERAL PREFIX (192.168.1.0/24) after FOLD-3, # not LocalSubnet. $env:SPT_HOME=""; & "/target/release/spt.exe" serve lan --bootstrap --port 29470 *> a7b-setup.log ``` ```bash # UNELEVATED, todlando. An unelevated --stop closes the listener and REMOVES NOTHING (measured at A3), # which is how the pair stays present while each ARM B run still starts cold. SPT_HOME=$H $W/target/release/spt.exe serve lan --stop > a7b-unelev-stop.out 2> a7b-unelev-stop.err # C(b-precondition) — the pair MUST still be present here. Asserted, not assumed; if it is gone the # arm is blocked, not adapted. ``` **ARM B measurement — ×3, unelevated, pair present.** Identical to ARM A's two lines with tag `a7b-N`, each bracketed by `C(b-pre-N)` / `C(b-post-N)`. **ARM B teardown — the second and last elevated action (liam).** ```powershell $env:SPT_HOME=""; & "/target/release/spt.exe" serve lan --stop *> a7b-teardown.log ``` **Cleanup verification, named:** `a7b-teardown.log` must carry `LAN_FIREWALL_CLEAN: no bootstrap-owned firewall resource remains`, **and** `C(final)` must show **0** rows in group `spt-core bootstrap TCP` and **0** rows covering TCP 29470, with both positive controls still present so the zero is a measured zero rather than a dead predicate. **5470 is preserved and checked by name:** the operator hand rule `spt lan-bootstrap 5470` and the blanket `spt-core daemon` rule must be present and unchanged in `C(final)` exactly as in the first census. Nothing in this experiment touches 5470; that is asserted at both ends rather than assumed. ## A3.3 Repair 3 — the APPLIED signed-set prerequisite, resolved through the supported path The listener serves only an APPLIED signed set whose host-triple artifact sha equals the running exe's, or it refuses by name. **A named refusal is a BLOCKED/VOID experiment, not A7 evidence.** So the set is prepared *before* any timed trial: ```bash # S1 — debug key (prints public_hex and seed_hex) cargo run -p xtask -- debug-keygen a7-debug-2026 > s1-keygen.out 2>&1 export SPT_DEBUG_RELEASE_SEED= # S2 — pin that key into the ISOLATED home's trust overlay ($H/identity/release-keys.json) cargo run -p xtask -- debug-pin --key-id a7-debug-2026 --public-key --home $H > s2-pin.out 2>&1 # S3 — stage a signed set that ATTESTS THE EXE UNDER TEST, into the isolated home cargo run -p xtask -- debug-rollout --key-id a7-debug-2026 --product-version 0.69.0-a7 \ --channel debug --version 1 --build-current \ --stage-dir $H/releases --state $W/target/a7-rollout-state.json > s3-rollout.out 2>&1 # --build-current builds the RELEASE spt and attests its bytes; expect # DEBUG_ROLLOUT_STAGED version=1 channel=debug platforms=x86_64-pc-windows-msvc stage_dir=$H/releases # S4 — record the applied phase in the SAME home cargo run -p xtask -- debug-mark-applied --version 1 --home $H > s4-applied.out 2>&1 # expect DEBUG_MARKED_APPLIED version=1 releases=$H/releases # S5 — binary provenance, measured independently of the product's own anchor line sha256sum $W/target/release/spt.exe > s5-provenance.out stat -c '%s %y' $W/target/release/spt.exe >> s5-provenance.out ``` **S5's hash must equal the `artifact_sha256` in the set staged at S3**, and both are retained separately from the `sha256 ` anchor the listener prints — a self-reported anchor is a claim, not independent verification. **The earlier "home not locatable" finding is downgraded and the reason matters:** even if the previous leg's home were recovered, its staged set attests the `00c4dad9` binary, not this one, so it would refuse the exe under test. **Re-staging was required regardless of whether that home exists** — locating it was never on the critical path. ## A3.4 One consequence for the window you are granting S1–S4 are `cargo run` invocations and S3 performs a **release build of `spt`**. That is real load on this box. **The exclusive window has to cover S1–S5 and both arms, not the arms alone** — otherwise the staging contends with whatever the window was meant to exclude, and ARM A's first cold wall is measured on a box still finishing a release link. ## A3.5 Ancestry, measured here, and the reported conflict dissolves doyle flagged `4f3f370f` versus `00c4dad9` as conflicting lane-base reports. Measured in this worktree — they are not rivals, they are two points on one linear chain: ``` 921aa68f FOLD-3 (the immutable test subject) ← dc8015cd rider items 1+2 (parent of 921aa68f, confirmed by rev-parse 921aa68f^) ← 4f3f370f build(xtask): debug-mark-applied ← 00c4dad9 assembly(304-w2) merge — the last ASSEMBLY commit ← 167552fe assembly merge onto main 15460d70 ← 15460d70 = merge-base(921aa68f, origin/main), the fork point ``` `git merge-base --is-ancestor` confirms all three: `4f3f370f`→`921aa68f` YES, `00c4dad9`→`921aa68f` YES, `00c4dad9`→`4f3f370f` YES. So `00c4dad9` is `4f3f370f`'s ancestor, two commits below the subject. **Neither is an accepted assembly base and I am not proposing one**: the lane forked at `15460d70` and `origin/main` has since moved to `7cdcf5da`, so a landing base is a decision about assembling onto current main, not a fact recoverable from this chain. Recorded as relationships, per doyle's earlier instruction. **And the `4f3f370f` subject line is load-bearing for A3.3:** that commit *is* `debug-mark-applied`, so the tool the set prerequisite needs is already present at `921aa68f` and no new code is required to satisfy it.