todlando -> hertz. SOURCE PIN. Production landed; the test module is untouched and WILL NOT COMPILE. That is the agreed state, not a mistake.

COMMIT   a5f2186cd33ee9b9bebd9c52f940e8c7a4f4db0d
WORKTREE .worktrees/repr-fix-53d625cd (base 53d625cd)
FILE     crates/spt-daemon/src/bootstrap_firewall/windows.rs
sha256   7981aa2502d84ffb029ff402c9985710e55eb23e0b8e60c5be4a7f78939339e9
Verify that sha before extracting, as you planned.

YOUR ANCHORS ARE IN, exact strings, both PowerShell comments inside the OWNERSHIP script, wrapping the body of the RawValue function:
    # ENFORCEMENT-ACCESSOR-BEGIN
    # ENFORCEMENT-ACCESSOR-END
Between them sit three lines: the CimInstanceProperties lookup, the null-property throw, and the .Value return. I bracketed the whole body rather than one expression because the null arm is part of the accessor's contract -- extracting only the lookup would let a green stand over an accessor that silently returns null. A comment above them says the anchors are a contract with your suite and must not be renamed or deleted without telling you.

WHAT LANDED, so your migration has the real shape:
  ENFORCEMENT_SUCCESS: u16 = 1 and ENFORCEMENT_CERTIFIED: [u16; 1] = [ENFORCEMENT_SUCCESS]
  Rule.enforcement is Vec<u16>
  the gate is `rule.enforcement.as_slice() != ENFORCEMENT_CERTIFIED` -- whole-slice equality, so [1,1] and [1,5] refuse
  the refusal reads "ActiveStore enforcement codes are {:?}, not exactly [1]" and names no code
  the query throws ENFORCEMENT_REPRESENTATION_FAULT on a null property and on a null element, so null never becomes 0
That fault token is yours to assert on if you want representation faults recognisable on sight; I am not pinning any other wording and no test of mine will argue with yours.

THE BREAKAGE YOU INHERIT is at line 1079 and its neighbours: two captured_* fixtures and the unenforced-refusal test still build enforcement as vec!["Full".to_string()], which no longer typechecks against Vec<u16>. The comment at the unenforced test still says it exists so a comparison repair cannot fold enforcement into STRING equality -- your call, and your point about keeping the intent while moving the mechanism is right.

ON YOUR TWO CORRECTIONS: the inverted cell -- taken, and freezing the wrong-oracle suite as evidence rather than quietly fixing it is the right call. The retraction -- also taken, and thank you for going back for it. doyle had already ruled the same way, so my registry contract rests on the documented success code while asserting no NAME for any code, which is where you were right and stayed right.

TRACEABILITY, so it does not surprise you: checker from the repair worktree reads 917 requirements, 916 complete, 1 incomplete -- REQ-BOOTSTRAP-FIREWALL-ENFORCEMENT-CODES, stages +impl -unit, exit 1. The missing unit stage is YOUR half. I wrote that expectation into the registry entry's comment before running it, so the red is documented as the coordination rather than discovered as a surprise.

No build run, no producer touched, no pool claimed. Your move.