PRODUCT-PATH TRACE - `LAN_BOOTSTRAP_REFUSED:unsigned-exe`. Read-only: source at pinned 85f84d73 (.worktrees/304-w2-repr) plus saved run evidence and file hashes. No product invocation, no daemon action, no edit, no bypass. THE OBSERVED REFUSAL run 20260913T071131Z, handoff/003-setup-command.err, both lines: DAEMON_AUTOSTART: no daemon and no standing operator stop — starting one LAN_BOOTSTRAP_REFUSED:unsigned-exe EMISSION SITE AND ROUTE The string is `lanhost::REFUSED_UNSIGNED_EXE` (spt-daemon/src/lanhost.rs:74). It is produced by the SET GATE, daemon-side: serveverb.rs:179-190 `serve lan --bootstrap` -> ServeRequest::LanBootstrap serveverb.rs:191 ensure_running() <- this is the DAEMON_AUTOSTART line above servehost call -> lanhost::start_at_inner (lanhost.rs:665) :677 exe = canonical_exe() -- the DAEMON'S OWN exe, captured at daemon boot (daemon.rs:282) :679 gate_with_policy(home, &exe, VerifyPolicy::production(0,0)) The refusal arrives back as ServeResult::LanRefused and is printed by the CLI. WHICH CONJUNCT FIRED - ESTABLISHED, NOT INFERRED gate_with_policy (:252) reads the exe bytes, opens ReleaseCache at `/releases`, and calls set_gate (:184) with staged_update() / applied_state(). set_gate's FIRST arm: `let Some(StagedUpdate::Set(signed)) = staged else { return Err(REFUSED_UNSIGNED_EXE) }` (:194-196). relcache.rs:330 staged_update() reads `release_path()` and returns None via `.ok()?` when that file is absent. MEASURED: the isolated home `…/bundle-r5/fp-home-d2-a2` contains brain.ready, daemon-effects.log, daemon-spawn.lock, daemon.pid, identity/, index/, logs/, serve/ — and NO `releases/` directory at all. So the staged read returned None and the gate refused at its first conjunct. The exe was read fine (branch 1 needs a read failure); nothing reached signature verification, triple lookup, sha comparison or the applied check. THIS IS THE GATE WORKING. `unsigned-exe` here does not mean "this binary failed a signature check" — it means "this home holds no signed SET to attribute the binary to". The code name is broader than the English reading, which is worth knowing before anyone hunts a signing defect. THE UNMET PREREQUISITE, IN FULL (all six must hold for the listener to come up) 1. `/releases/release.json` exists and parses as an UpdateSet (a legacy SINGLE also refuses unsigned-exe, deliberately — lanhost.rs:191-196). 2. An artifact file exists for at least one platform in that set (`releases/artifacts/.bin`), or staged_update() returns None anyway (relcache.rs:334-345). 3. The metadata verifies under VerifyPolicy::production — the ADR-0015 keys compiled into the binary plus the node key file. 4. The set names this host triple (`current_platform()`). 5. That triple's `artifact_sha256` EQUALS the sha256 of the DAEMON'S canonical exe. Not the CLI's — the gate anchors on the daemon process's own binary. 6. applied_state() == Applied{version} with version == the set's version. AppliedPending or RolledBack refuse as `set-not-applied`. WHY THIS ARM OF D2 CANNOT SUCCEED AS CONFIGURED - and the measurement that says so The subject binary is r10's cargo build: 72d309011415b419aabfdb0b4065df1183bfd0069a9f95b5779da62e43349b10. It is not an artifact of any signed set on this box. Measured on the resident fleet home `%LOCALAPPDATA%\spt-core\releases`: applied-state.json = {"phase":"applied","version":105}; release.json metadata names x86_64-pc-windows-msvc with artifact_sha256 689503ad9fc6cfde637cbcacf21c42faf130ba465a0df6c356cf290e2adafb85; `releases/artifacts/x86_64-pc-windows-msvc.bin` is present; and the installed `%LOCALAPPDATA%\spt-core\bin\spt.exe` hashes to exactly 689503ad… So the ONLY binary on this box that can satisfy conjunct 5 is the installed fleet one, against a home holding that applied set. Seeding a copy of that cache into the isolated home would satisfy 1-4 and 6 and then refuse at conjunct 5 with a DIFFERENT code — `sha-mismatch` — because the daemon would still be the dev build. That difference is a clean prediction if anyone wants to test this reading rather than take it. CONSEQUENCE FOR THE EXPERIMENT'S SUBJECT The firewall admission call is on the SUCCESS arm only: serveverb.rs:247 `report_lan_admission(...)` sits inside the `ServeResult::LanUp` match arm; `LanRefused` returns without it. So while the gate refuses there is no listener, and with no listener `reconcile_lan_firewall` is never called and the bootstrap-owned TCP pair is never created. This is consistent with the earlier finding that no product-created NON-SERVING path to that pair exists — `bootstrap_firewall::reconcile` is reachable only from `reconcile_lan_firewall`, whose binder and port come from a live listener. PROPOSED NARROW CORRECTIONS - nothing executed, nothing edited PRODUCT: none. The refusal is correct behavior and I found no defect on this path. I am not proposing a bypass, and the `gate_with_policy` policy seam is a test seam — using it in a field run would make the run prove nothing about the shipped gate. EXPERIMENT (yours and hertz's to rule, not mine to take): the subject binary has to BE a signed, applied artifact for this path to be reachable at all. That means either running the arm with the installed fleet binary and a home carrying that applied set — which changes the subject from r10's build and moves the run next to live fleet state, so it needs your ruling and hertz's rig design — or re-scoping this arm as unreachable with a dev build and recording it as such. ONE DOCUMENTATION POINT, if you want it filed: the code name `unsigned-exe` covers four distinct causes, only one of which is about signing. The run record should say which conjunct fired, because "unsigned-exe" alone will send the next reader hunting a signature problem that is not there. WHAT I DID NOT ESTABLISH I did not verify conjunct 3 against the production keys for any binary (no invocation), and I did not read the full VerifyPolicy chain. I did not attempt to determine whether seeding the cache is safe or advisable — process disposition and rig shape are hertz's. Nothing of mine ran the product.