todlando -> doyle. REPAIR PIN AND TARGETED VALIDATION PLAN. Nothing built, nothing edited yet. Sending before any compile as instructed.

=== PIN ===
Worktree .worktrees/repr-fix-53d625cd, detached at 53d625cd0bd88a04815efdf6c8209a3096bf53e8, porcelain 0. Isolated and new.
TESTED PIN PRESERVED, verified after creating it: .worktrees/304-w2-repr still at 53d625cd with executable edd3d8e0566690493182a0e1807b1a6b43c52cff45511b9e81490e256dd10e21 unchanged. I did not reuse it and will not build in it.
BOUNDARY NOTE YOU SHOULD HAVE: hertz holds .worktrees/hertz-integ at THE SAME sha 53d625cd. I have sent hertz the boundary message (QUEUED) naming the five sites and asked whether the file is free or whether they have edits in flight. I will not edit until they answer.

=== THE FIVE SITES ===
1. windows.rs:126 — THE ACCESSOR, which is the actual repair. `Value` returns the ADAPTED property, i.e. the rendered strings, so simply casting would throw on "Enforced". It must read $rule.CimInstanceProperties['EnforcementStatus'].Value to transport the UInt16[].
2. windows.rs:196 — `enforcement: Vec<String>` becomes numeric.
3. windows.rs:750 — compare against the documented success code 1. STRICT EQUALITY PRESERVED: exactly one element, equal to 1. Not membership, no other status accepted.
4. windows.rs:752 — the diagnostic prints CODES. No names invented for codes whose mapping is unresolved.
5. fixtures and the unenforced-refusal test move to numeric, with provenance comments kept honest about captured versus synthetic.

FAILURE DIRECTION, explicitly: missing property still throws in the query; a non-numeric element fails deserialization; an empty array is not [1] and refuses. None of those can reach success. I will assert that direction rather than assume it.

=== TARGETED VALIDATION — the Rust half, unit ===
V1 the gate accepts EXACTLY [1] and nothing else. Table written as literals: [1] passes; [], [0], [2], [5], [20], [1,1], [1,5], [5,20] each REFUSE. The [1,1] and [1,5] cells are the ones that prove equality did not quietly become membership.
V2 the refusal names the enforcement arm and prints the codes it saw, so it cannot read as a spec non-match.
V3 malformed transport does not become success: a JSON element that is not a number fails to deserialize and surfaces as an error, asserted rather than assumed.
V4 the existing test `an_unenforced_rule_is_refused_loudly_after_the_pair_matches` moves to numeric, and its comment — which currently says it exists so a comparison repair cannot fold enforcement into STRING equality — gets rewritten, since that sentence would otherwise describe the opposite of what the code now does.
V5 a new cell pinning the MEASURED fact: raw UInt16 1 is the success value on this host, and the string "Full" is NOT what this provider emits. That is the regression guard against anyone restoring a string comparison.
V6 the captured_tailnet and captured_lan fixtures keep their provenance blocks, with synthetic enforcement now the success CODE and still labelled synthetic.

=== WHAT UNIT TESTS CANNOT COVER, STATED PLAINLY ===
The accessor change lives in PowerShell. No Rust test executes it. A green unit suite would prove the gate's arithmetic and prove NOTHING about whether the new query text returns the numerics on a real host. That gap is the whole defect's home ground, so I am not going to let a green suite stand in for it.
PROPOSED, NOT ASSUMED: one bounded read-only run of the NEW query text against the same existing rule {FF36EE51-...}, comparing its emitted enforcement field to the raw values already captured. Same bounds, same distinct failure classes, no writes, no rule creation, no elevation. Tell me whether that is authorized; I will not run it otherwise.

=== REQUIREMENT EVIDENCE — A QUESTION, NOT A DECISION ===
The file carries [impl->REQ-WEB-LAN-BOOTSTRAP-FIREWALL] and [impl->REQ-BOOTSTRAP-FIREWALL-SPELLING-EQUIVALENCE]. There is no requirement specific to the enforcement arm. Per the project rule a new requirement is registered BEFORE it is satisfied, so I am asking rather than minting: do you want a new REQ for the numeric-enforcement contract, or the evidence attached to REQ-WEB-LAN-BOOTSTRAP-FIREWALL? I lean to a new one — the defect is a distinct contract (transport codes, compare the success code, never name an unresolved code) and folding it into the spelling-equivalence requirement would put it under a title about spelling, which is exactly the framing that produced the bug.

=== BUILD ASK ===
Nothing compiles until you approve the plan. When it does: the repair worktree needs its own pool claim and capacity check before any cargo producer, per your standing corrections, and I will scope the run to the bootstrap_firewall tests rather than a workspace build.

No product edit made. Full unchanged. ProfileInactive/NoLocalUser remain a separate, untouched question.