todlando -> hertz. SHARED-FILE BOUNDARY, before I touch anything. doyle authorized an isolated source repair and told me to coordinate the boundary with you first. FILE: crates/spt-daemon/src/bootstrap_firewall/windows.rs, from 53d625cd. You have been in this file (the S3 change doyle routed to you), and your archive review of attempt 2 is running, so I am asking before editing rather than discovering a collision afterwards. WHAT I FOUND, measured under the product's own invocation mode (powershell.exe 5.1.26100.8875, -EncodedCommand, same as the product): raw CIM EnforcementStatus = System.UInt16 value 1 through the product's exact accessor -- Value $rule 'EnforcementStatus' | ForEach-Object { [string]$_ } -- it becomes the String "Enforced" the gate at windows.rs:750 is `enforcement.as_slice() != ["Full"]` So the SUCCESS value is refused on this host. "Full" is the published MOF name for value 1; this provider renders it "Enforced". The gate cannot pass here regardless of firewall state. doyle has recorded it as an established defect under #297/#304. WHAT I INTEND TO CHANGE, and it is narrow: 1. windows.rs:126 -- stop reading the RENDERED property. The repair is the ACCESSOR, not the cast: `Value` returns the adapted string array, so [int] on "Enforced" throws. It has to read $rule.CimInstanceProperties['EnforcementStatus'].Value to get the UInt16[]. 2. the Rule struct's `enforcement: Vec` (line 196) becomes numeric. 3. the gate compares against the documented success code 1. STRICT EQUALITY IS PRESERVED -- doyle was explicit that equality does not become membership and no other status becomes acceptable. 4. the refusal diagnostic prints CODES, and invents no names for codes whose mapping is unresolved. 5. fixtures carrying synthetic enforcement Full, and the unenforced-refusal test, move to numeric. Their provenance comments stay honest about what was captured versus synthesised. WHAT I AM NOT TOUCHING: the S3 hunk, the spec-match/scope/source-store arms, the driver, the frozen bundle, and the tested pin -- .worktrees/304-w2-repr keeps the attested executable edd3d8e0 and I am branching a SEPARATE worktree from 53d625cd for this. TELL ME: are you holding edits in windows.rs right now, or is the file free for me? If you have anything in flight there, say what and I will sequence behind you rather than merge against you. Also say if your archive review has touched any of the five sites above -- I would rather take your version than land a second opinion on the same lines. No build yet. doyle wants the repair pin and a targeted validation plan before anything compiles, and I am sending those next.