# Combined gate plan — 304-w2-repr, after an agreed source handoff

hertz 2026-09-12. **NOTHING EXECUTED.** No checkout change, no cargo launch, no pool claim. Written
under doyle's constraints: the gate runs in `.worktrees/304-w2-repr` (which holds the WARM target),
no cold target is created in `.worktrees/hertz-integ`, and no `CARGO_TARGET_DIR` is pointed at
another worktree's pool.

## 0. The two pins, and why the handoff loses neither

    fix/304-w2-representation-compare -> 10d18b7f   (todlando's repair; his 23/23 evidence)
    test/304-w2-observed-spelling-cells -> 53d625cd (my eight cells; uncompiled, untested)

`10d18b7f` is an ANCESTOR of `53d625cd` — measured, `git merge-base --is-ancestor` exits 0 — so the
handoff is a strict fast-forward with no rebase, no merge and no conflict to resolve. Both refs
already exist and neither needs to move: the handoff switches which ref `304-w2-repr` has checked
out, it does not repoint either branch.

## 1. The handoff, as commands, for todlando to run or to agree I run

Git refuses one branch in two worktrees, so my side releases the branch FIRST:

    # hertz, in .worktrees/hertz-integ — releases the branch, keeps the commit reachable
    git switch --detach 53d625cd

    # todlando, in .worktrees/304-w2-repr — takes my branch; his own branch stays at 10d18b7f
    git status --short                     # must be clean before anything moves
    git switch test/304-w2-observed-spelling-cells
    git log --oneline -2                   # expect 53d625cd then 10d18b7f
    git rev-parse fix/304-w2-representation-compare   # must still read 10d18b7f

After this the warm target sits beside a tree whose HEAD is `53d625cd` and whose parent commit is
the exact tree his 23/23 ran against.

## 2. Pool claim, from the lane's own worktree

The claim records the LANE'S GIT IDENTITY, and claiming another worktree's pool from outside it exits
2 without writing, so this is issued from inside `304-w2-repr` and nowhere else:

    cd .worktrees/304-w2-repr
    cargo run -p xtask -- pool-claim --pool target --label 304w2-combined-gate

His lane is FINISHED and his pool RELEASED, so this is a sequential takeover, which is the supported
case. No `--foreign-pool`. The first build is what speaks to lane identity, not the claim verb.

## 3. The combined module selection — listed before it is run

    cargo nextest list -p spt-daemon --lib -E 'test(/^bootstrap_firewall::/)'

Recorded BY NAME and BY COUNT. His run at the parent reported 23; my block adds 8; so the expected
combined count is 31 — stated here as an EXPECTATION TO BE MEASURED, not a claim. If the list reads
anything else, that discrepancy is the finding and the run does not proceed as if it were noise.

Filter competence, in the same session, because a filter matching nothing reports success:

    cargo nextest list -p spt-daemon --lib -E 'test(/^bootstrap_firewall::hz_absent_sentinel_/)'
    # must list ZERO — the filter can express absence

## 4. The run

    cargo nextest run -p spt-daemon --lib -E 'test(/^bootstrap_firewall::/)' --success-output immediate

- `--success-output immediate` is not optional: a nextest GREEN prints passing output nowhere, and
  these cells' assertion messages (observed-vs-spec renderings) are the evidence, not the count.
- Module-scoped rather than filtered to my eight, deliberately: the three claims I dropped as
  duplicates now ride on sibling cells, and **coverage preservation becomes measured only when those
  siblings are seen in this list and seen passing in this run.** Until then it stays a source audit.
- The run count must equal the list count from §3. "1 test run" and "0 tests run" both read as
  success in a skimmed summary.
- `spt-daemon`'s lib suite contains cells that deadlock against a live daemon; the anchored
  `bootstrap_firewall::` filter keeps this to pure functions that open no socket. Widening it brings
  that hazard back.

## 5. The controls — TWO BATTERIES, and the distinction is the point

doyle, 2026-09-12: changing a test's INPUTS to force an assertion proves that assertion EXECUTES; it
does not prove the cell is sensitive to a BROKEN PRODUCT COMPARISON. My first draft had only the
weaker kind and labelled it "red on purpose". Both are run, separately, and reported separately.

Common rules for every control in both batteries: ONE mutation at a time, applied to the pinned
content, never stacked; the intended red is the cell's OWN ASSERTION firing with its message -- a
COMPILE FAILURE IS NOT THE INTENDED RED and makes the control VOID, to be reworked rather than
counted; after each, `git diff --quiet` exits 0 and `git rev-parse HEAD` still reads `53d625cd`.
(That the registered mutations compile is an EXPECTATION, not a measurement, until each one is run.)

### 5a. ASSERTION CONTROLS — the test's inputs move, the product does not

Proves the assertion is reached and can fail. Labelled as such in the report, and NOT cited as
regression sensitivity.

| cell | input mutation |
|------|----------------|
| H1 scope at the verdict | substitute the derived prefix for each wrong value in turn |
| H2 enforcement | set `enforcement: ["Full"]` on the perturbed rule -- the `expect_err` must panic |
| E1 program | give the tailnet half a real program filter (`C:/other/thing.exe`) |
| E2 profile | replace `Domain, Private` with `Public` |
| E3 network | replace the LAN mask with `192.168.2.0/255.255.255.0` |
| E4 whole pair | any one of the three above |
| arm-1 write body | delete one `New-NetFirewallRule` from a local copy of the render |
| QUERY one-pass | point the predicate at the COMPOSED script instead of the `QUERY` const |

### 5b. REGRESSION-SENSITIVITY CONTROLS — the PRODUCT breaks, the test is UNTOUCHED

The cells are left exactly as pinned; one production behaviour is reverted or bypassed, and the
UNCHANGED cell must fail AT ITS INTENDED ASSERTION. This is the battery that shows these cells would
have caught the defect they were written for.

The pre-fix comparison is not invented: it exists verbatim at `921aa68f`, so each restoration is
`git show 921aa68f:crates/spt-daemon/src/bootstrap_firewall/windows.rs` copied back at that site.

| production mutation | cells that MUST fail, at their own assertion |
|---------------------|----------------------------------------------|
| restore `observed.program.is_empty()` in place of `program_unrestricted` | E1, E4 |
| restore exact-string `observed.profile != want.profile` in place of `profile_set` | E2, E4 |
| restore the lowercased-sort string-set compare in place of `remote_set`/`wanted_networks` | E3, E4 |
| delete the remotes comparison from `spec_satisfied_by` entirely (a normalizer that widens) | H1 |
| delete the `enforcement != ["Full"]` loop from `decide` | H2 |
| interleave a statement between the two `New-NetFirewallRule` calls in `render_writes`; and separately switch one `-PolicyStore PersistentStore` to `ActiveStore` | arm-1 write body |
| add a second `Named-Rules 'PersistentStore'` pass to the `QUERY` const | QUERY one-pass |

EXPECTED NON-REACTIONS ARE PART OF THE RESULT, not omissions: H1 and H2 are NOT expected to fail
under the three comparison restorations (a raw string compare still rejects a different scope, and
enforcement is decided on a field the normalizers never see). Recording that they stay green under
those mutations is what shows the two batteries are measuring different things -- and each of H1/H2
has its own production mutation above precisely because the comparison restorations cannot reach it.

### 5c. The spelling-sensitivity twin, kept from the earlier draft

Replace each captured literal with the SPEC'S OWN spelling (`""`, `Private,Domain`, `/24`). Those
twins must PASS. Their significance is that they would have passed BEFORE FOLD-4 too, which is what
distinguishes a cell sensitive to the captured spelling from one that merely needs a well-formed
pair. Reported beside 5b, never as a substitute for it.

## 6. Closing

THE BATTERY ENDS ON THE CLEAN CANDIDATE, so the last thing recorded is the pinned tree passing, not
a mutated one:

    git diff --quiet && git rev-parse HEAD          # clean, and still 53d625cd
    cargo nextest run -p spt-daemon --lib -E 'test(/^bootstrap_firewall::/)' --success-output immediate
    cargo clippy --workspace --all-targets
    traceable-reqs check                      # exit 1 = missing/invalid evidence; fix, do not ship
    cargo run -p xtask -- pool-release --pool target

No `cargo fmt` in this repo.

## 7. What the result may claim, and what it may not

- A green combined run covers **every test selected at `53d625cd`** -- the inherited 23 as well as my
  eight -- because they all ran, at that SHA, in that invocation. (Corrected by doyle 2026-09-12; my
  first draft understated it as "my eight only".) What it does NOT do is rewrite or invalidate the
  separate `10d18b7f` receipt, which stands on its own as todlando's evidence at his pin. Two
  receipts at two SHAs, neither consuming the other.
- Coverage preservation is claimable only if the named sibling owners (:945, :968, :856, :912, :1136
  and FOLD-4(a)/(b)) appear in the §3 list and pass in the §4 run.
- Regression sensitivity is claimable only per cell that actually got its §5 control exercised. Any
  cell whose control was not run is reported as such, never folded into a pass count.
- Nothing here speaks to field admission. That is a separate gate and still held.