todlando -- W-2a PARTIAL END, 2026-09-11T12:08Z. STOPPED AT THE GATE YOU SET, NOT WORKED AROUND.

**NEEDS-OPERATOR: I DO NOT HAVE ELEVATION, MEASURED TWO WAYS BEFORE ANY ARM RAN.**
  token:      IsInRole(Administrator) = FALSE, user HFENDULEAM\decid.
  functional: `netsh advfirewall firewall add rule name="spt-w2a-elevation-probe" dir=in action=allow protocol=TCP localport=59999 enable=no`
              -> exit 1, "The requested operation requires elevation (Run as administrator)."
              -> re-probe by name: present_after_add = 0. The rule was never written, so nothing of mine is on that box from this attempt.
  I ran the functional probe rather than trusting the token bit, because a token check says what Windows thinks and an add says what actually happens. Both agree.
  Arms B and C cannot run. I am not seeking a workaround (no UAC prompt spawn, no service, no scheduled task) -- your word was that this is a NEEDS-OPERATOR line.

WHAT I DID RUN, because neither needs elevation, and both are yours anyway:

ARM A -- BASELINE, 12:07:09Z. No throwaway rule present (census below).
  kitsubito -> http://100.68.35.65:5470/install : http_code=000, connect=0.000000, total=8.002732, curl (28) timed out after 8002 ms.
  loopback control at the same moment: http_code=200, size=322.
  BLOCKED, as predicted, and the control proves the listener was answering while the peer could not reach it. This is not a repeat of W-0: W-0's TCP arms were at 11:33Z, this is a fresh reading 34 minutes later with the same verdict.

CENSUS, by name, before the arms (read-only, works unelevated):
  blocks mentioning 5470 or spt-w2a: ONE.
    Rule Name: spt lan-bootstrap 5470 | Enabled: Yes | Profiles: Private | RemoteIP: 192.168.1.0/24 | Protocol: TCP | LocalPort: 5470 | Action: Allow
  spt-w2a-* rules on this box: ZERO. No contamination from me, before or after the elevation probe.
  NOTE for the B/C reading when they run: that hand rule is LAN-scoped (192.168.1.0/24) and cannot match 100.98.197.12, so it does not confound either arm.

ARM D is not meaningful without B and C -- it is the after-delete control for rules that were never added. Not run, not claimed.

PREDICTIONS FOR B AND C, FILED NOW, BEFORE ANY netsh THAT WRITES ANYTHING, with reasons:
  B (program-scoped: localport=5470, program=<installed spt.exe>, profile=any, NO remoteip) -- PREDICT BLOCKED.
    Reason: at W-0 the rule "spt-core daemon" (Private, Protocol ANY, RemoteIP Any, Program = that exact spt.exe) was present and enabled, the Tailscale interface measured Private, and the TCP fetch to 5470 still timed out. B is that shape widened to all profiles. If B is ADMITTED, then profile was the missing piece all along and my "program scope admits nothing over the tailnet" reading is too broad -- I would be wrong, and it would mean W1's effector shape works and only its scope breadth is at issue.
  C (two rules, one throwaway name: profile=any remoteip=100.64.0.0/10, and profile=private,domain remoteip=LocalSubnet, both localport=5470, no program) -- PREDICT ADMITTED.
    Reason: the only inbound path from kitsubito this box has ever demonstrably accepted is the port+remote-scoped UDP rule for 7460-7499, and C is that shape on TCP.
  THE OUTCOME THAT WOULD REFUTE US BOTH: B and C BOTH BLOCKED. That puts the block at the tailnet ACL for TCP -- which my W-0 END named as explicitly unexcluded -- and it would mean NEITHER amendment's rule shape can be validated on this pair, making the #297 Windows-rule question unanswerable here rather than answered wrongly. If that is the result, the next step is an ACL question for the operator, not a third rule shape.

THE EXACT ELEVATED COMMANDS, so the operator runs what was specified and nothing else. Throwaway names, never the product's:
  ARM B:
    netsh advfirewall firewall add rule name="spt-w2a-B" dir=in action=allow protocol=TCP localport=5470 profile=any program="C:\Users\decid\AppData\Local\spt-core\bin\spt.exe"
    (then tell me, I fetch, then:)
    netsh advfirewall firewall delete rule name="spt-w2a-B"
  ARM C:
    netsh advfirewall firewall add rule name="spt-w2a-C" dir=in action=allow protocol=TCP localport=5470 profile=any remoteip=100.64.0.0/10
    netsh advfirewall firewall add rule name="spt-w2a-C" dir=in action=allow protocol=TCP localport=5470 profile=private,domain remoteip=LocalSubnet
    (then tell me, I fetch, then:)
    netsh advfirewall firewall delete rule name="spt-w2a-C"
  Neither touches "spt lan-bootstrap 5470", "spt-core daemon", "spt-core inbound UDP" or any rig rule. I will census by name before and after each and report both.

YOUR CORRECTION, TAKEN, AND IT SHARPENS MY FINDING RATHER THAN SOFTENING IT: six unit cells DO carry REQ-WEB-LAN-BOOTSTRAP-FIREWALL at 7b098cc2 (opt-out gating x2, argument guards, binder-path text, UTF-16LE round-trip), so the id reads +doc +impl +unit at asm-304. None of the six touches profile, remoteip or program. So the id is COVERED at the checker and its SCOPE POLICY -- the one thing W-0 measured as decisive and the one thing the two amendments disagree about -- is untested at every sha. A green coverage gate over an untested scope policy is exactly the shape that let two contradictory amendments coexist without anything going red.

Holding: no W-2 build, no kitsubito clone, no fold or renumber. Standing by for elevation or for a different instruction.