# Targeted validation for the observed-spelling regression block

hertz 2026-09-12. **NOT RUN.** Build and field holds are in force; this is the command set that runs
the moment they lift, written now so the handoff is a pinned sha plus these lines rather than
improvisation at the console. Pre-integration: todlando lands the representation repair, tells me the
tip, I rebase my block onto it, and the sha I report is the one these commands ran against.

## 0. Preconditions, each verified before the first cargo invocation

    git -C .worktrees/hertz-arm1 log --oneline -1        # must be todlando's repair tip + my block
    git -C .worktrees/hertz-arm1 status --short          # my block committed, nothing stray
    # 921aa68f unchanged and not re-pointed:
    git rev-parse 921aa68f^{commit}

Pool claim from the lane's own worktree, per AGENTS.md — the claim records the lane's GIT IDENTITY,
so it must be issued from inside the worktree that owns the lane:

    cd .worktrees/hertz-arm1
    cargo run -p xtask -- pool-claim --pool target --label hertz-304w2-regression

Free space floor before any build (the 32 GB floor; a resource red is an UNTESTED lane, not a red).

## 1. The run, and why each flag is not optional

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

- `--lib` — these are unit cells inside `src/bootstrap_firewall/windows.rs`, not an integration test.
- `-E` with an ANCHORED REGEX, not a bare substring: a bare `test(name)` is a substring match and
  would silently widen or narrow the population.
- `--success-output immediate` — **a nextest GREEN prints passing output NOWHERE.** Every assertion
  message these cells carry (the observed-vs-spec renderings) is invisible without it, and those
  strings are the evidence, not the pass count.
- Package-scoped and filtered deliberately: `spt-daemon`'s lib suite contains cells that deadlock
  against a LIVE daemon on this box. The filter keeps the run to pure functions that open no socket.
  If the filter is ever widened, that hazard comes back.

## 2. The filter's own positive control — run BEFORE trusting any green

A filter that matches nothing reports success. Two checks, both cheap:

    # a. the population is what I think it is, BY NAME, before running anything
    cargo nextest list -p spt-daemon --lib -E 'test(/^bootstrap_firewall::windows::tests::/)'
    # b. a deliberately non-matching filter must report ZERO, proving the filter can express absence
    cargo nextest list -p spt-daemon --lib -E 'test(/^bootstrap_firewall::windows::tests::hz_absent_sentinel_/)'

Then assert the COUNT, not the colour: the run must report exactly the number of tests `list`
enumerated. "1 test run" and "0 tests run" both read as success in a summary skimmed for red.

Expected members of my block (9 names, after the overlap trim; the module's pre-existing cells are
additional and run in the same invocation, which is deliberate -- a repair that breaks a sibling must
show up here):

    a_remote_that_is_narrower_or_wider_than_the_derived_prefix_does_not_satisfy_it
    malformed_remote_spellings_are_rejected_rather_than_parsed_loosely
    an_unenforced_rule_is_refused_loudly_after_the_pair_matches
    an_unrestricted_program_spelled_any_satisfies_a_spec_wanting_none
    a_profile_set_compares_by_membership_not_by_rendering
    an_ipv4_network_compares_by_value_in_prefix_or_mask_form
    the_captured_pair_decides_reconciled_once_spellings_compare_semantically
    the_write_body_renders_an_adjacent_persistentstore_pair_scoped_to_the_derived_prefix
    the_query_body_makes_one_store_pass_and_reads_no_persistent_store

The last two predate the repair: my arm-1 render cell and todlando's QUERY one-pass cell, which is
mine to land. `list` and `run` use the SAME filter, so their counts are compared against each other,
never against this list from memory.

THREE CELLS WERE DROPPED as duplicate coverage (wider-remote `Any`, hygiene failure, missing-half and
port drift) and one was reduced to its enforcement arm; the siblings that own those claims are named
in the draft's header. Their coverage does not disappear -- it is exercised by the sibling cells in
this same run, which is why the run is module-scoped rather than filtered to my nine.

## 3. Red-on-purpose controls, one per cell

Every cell gets exercised in BOTH directions: the positive it must match, and a deliberate mutation
that must turn it red. A cell that has only ever been green has not been shown to discriminate.
Procedure per cell: apply the mutation, run the SINGLE cell, record the red and the assertion text,
revert, re-run, record the green. Mutations are to the TEST or to a local copy of the predicate —
never a mutation left in the tree.

| cell | mutation that MUST turn it red |
|------|-------------------------------|
| R1 narrower/wider remote | substitute the spec's own derived prefix for each wrong value in turn: `!pair_satisfied_by` then fails -> RED |
| R2 malformed | substitute a well-formed equivalent (`192.168.1.0/24`) for one malformed string |
| R3 enforcement | set `enforcement: ["Full"]` on the perturbed rule -- the `expect_err` must then panic |
| E1 program | give the tailnet half a real program filter (`C:/other/thing.exe`) -- a genuine narrowing, so the cell must go RED |
| E2 profile | replace `Domain, Private` with `Public` -- a different set, so the cell must go RED |
| E3 network | replace the LAN mask with `192.168.2.0/255.255.255.0` -- a different network, so the cell must go RED |
| E4 whole pair | any one of the three above |
| arm-1 write body | delete one `New-NetFirewallRule` from a local copy of the render; the adjacency assertion must fire |
| QUERY one-pass | point the predicate at the COMPOSED script instead of the `QUERY` const; the counts read 3 and 1 and the cell must go RED |

A SECOND CONTROL, DISTINCT FROM RED-ON-PURPOSE, and the load-bearing one for the E cells: replace
each captured literal with the SPEC'S OWN spelling (`""`, `Private,Domain`, `/24`). The cell then
passes EVEN BEFORE THE REPAIR — which is what a fixture quietly regenerated from `RuleSpec` would
look like, and is the defect this block exists to prevent. So each E cell must be shown to do BOTH:
go red on a semantically different value (above), and go red PRE-REPAIR on its captured value while
its spec-spelled twin goes green. Only the pair of those two establishes that the cell is sensitive
to the spelling and not merely to the pair being well-formed.

## 4. Before declaring done

    cargo clippy --workspace --all-targets     # preflight, workspace-scoped
    traceable-reqs check                       # exit 1 = missing/invalid evidence, fix it, don't ship it

Every cell carries `// [unit->REQ-WEB-LAN-BOOTSTRAP-FIREWALL]` on the cell itself, not at file top.
No `cargo fmt` in this repo.

Release the pool when the lane is done:

    cargo run -p xtask -- pool-release --pool target

## 5. What gets reported back

The pinned commit sha, and for each cell BOTH runs (green and its red-on-purpose) with the
assertion text captured from `--success-output immediate` — plus the `list` count beside the run
count, so the population is a measured number rather than an inference from a green summary. A cell
whose red-on-purpose was not exercised is reported as such rather than folded into a pass count.