hertz -> doyle. Linux lane STARTED, seam survey done, predictions filed BEFORE the first run. One thing you need to rule on is at the bottom; it does not block me. BASE WAS NOT FETCHABLE — resolved without publishing anything. 697eb398 is UNPUSHED (it is on no remote; my worktree's only remote is the dead SaberMage mirror), and neither kitsubito clone could reach it, nor 3e7eaf67 nor 0c05e722. kitsubito had origin/main 4b54a95d and e28bc27d only. Rather than push #304 work to BigscreenVR to make it fetchable — which would have broken your "HOLD, unpushed" — I moved the delta as a git bundle: 158K, 697eb398 --not 4b54a95d, scp'd, fetched into a fresh clone. Nothing was published to a shared remote. If you would rather the fold tip reach kitsubito the same way when it exists, say so and I will bundle that too; a push is your call, not mine. Clone: ~/spt-core-hertz-linux on KITSUBITO, own pool, branch test/304-linux-admission-cells at 697eb398. Nothing on HFENDULEAM. SUBJECT VERIFIED BY BLOB, not by filename: linux.rs oid 4c9ff40f1ee1cae8854e2f26258658f38c025b1c on kitsubito, byte-identical to what I read on Windows. 676 lines, 0 #[test]. kitsubito: 16 cores, 113G free, cargo/rustc 1.96.0, nextest 0.9.137 (same nextest as HFENDULEAM, so --no-tests fail is available). Toolchain is NOT on the non-interactive PATH; it needs ~/.cargo/env sourced, which is a rig detail I have already absorbed. SEAMS I CAN REACH HERMETICALLY — 7 cells, all fed fixture values, none touching the host firewall 1. marker(&Path) -> String pure; OWNER prefix + 64 lowercase hex, distinct per binder path 2. owned(&str) -> bool pure; accepts marker's own output, rejects wrong length / uppercase / non-hex / missing prefix 3. ufw_scope(&UfwRule) -> (u16,bool) pure over a constructed UfwRule; v4 Anywhere, v6 Anywhere, restricted scope, non-/tcp, port 0 4. identifier(&str) -> bool pure; empty rejected, leading digit rejected, underscore accepted, digit after index 0 accepted 5. nft_input(&[Value]) pure over fixture JSON; one inet/filter base chain accepted, multiple / device-bound / ip-or-ip6-only / unquotable identifier each refused 6. nft_owned(&[Value]) pure over fixture JSON; non-owned comments skipped, the l4proto-prefix normalisation, extra predicates and non-accept actions refused, port 0 refused, missing handle refused 7. reconcile(binder, 0) the zero-port refusal is the FIRST statement in the body and returns before backend() is ever called, so it is provably hermetic — no probe, no command, no host firewall reached. I will state that reachability argument in the cell itself, because a future edit that moves a probe above it would silently turn this cell into a host-toucher. All tagged [unit->REQ-WEB-LAN-BOOTSTRAP-FIREWALL] on the cell, never at the file top. SEAMS I CANNOT REACH — named and stopped, per your instruction; these are FOLD-1 riders for todlando, not work I will do backend() PRECEDENCE, the one you named explicitly. The UFW-before-firewalld-before-nft order is welded to its probes: `if ufw_active()? ... else if firewalld_active()? ... else if executable("nft").is_some()`. Every arm shells out or stats the filesystem, so the ORDER cannot be exercised without a host. The seam that would fix it is a pure `backend_from(ufw: bool, firewalld: bool, nft_present: bool) -> Result` with backend() reduced to probe-and-delegate. That is a product change and it is todlando's. ufw_rules(): the `ufw status numbered` PARSER — header/separator skipping, the [n] prefix, the # comment split, whitespace normalisation — is welded to command("ufw", ...) in one body. Genuinely valuable parsing, currently unreachable. Seam: split the parse into `parse_ufw_rules(text: &str)`. ufw_preflight(port): calls ufw_rules() first, so the adopt-refusal and the dedupe-by-destination decision are unreachable for the same reason. Seam: take `&[UfwRule]`. Also unreachable and not worth a rider unless you want them: unit_state, ufw_enabled, ufw_active, firewalld_active, policy_names, policy_owned, firewalld_policy, policy_snapshot, verify_ufw/firewalld/nft, clear_ufw/firewalld/nft, clear_admissions. PREDICTIONS P1. All 7 cells GREEN at my tip on kitsubito. P2. Each cell proven RED FIRST by ONE product-side mutation in linux.rs, reverted, and the revert proven by blob oid back to 4c9ff40f... plus a byte count — not by eye, and not by `git diff --quiet`, which normalises EOL and would certify a rewrite. P3. Every filtered arm carries the zero-match gate: nextest --no-tests fail AND a parsed "1 test run". An arm not reading exactly 1 is a NON-MEASUREMENT, not a pass. P4. Unfiltered `spt-daemon --lib` on kitsubito at my tip: count == `nextest list` count at the SAME sha, both reported with that sha. I expect the Linux count to DIFFER from the 988 I measured on Windows at cba18cd5 — different cfg, different tip — and I will not treat that difference as a defect without measuring it. P5. Admission census on kitsubito with a live-cargo positive control seen by the same filter that reports the zero, and a post-census after. The Windows rig's census is psutil+Windows-shaped; the kitsubito one is new code and I will prove its control TRUE before trusting any zero it reports. P6. A cell that needs root, a live nft/ufw/firewalld, or a mutated host is OUT OF SCOPE by construction — if I find I cannot write one hermetically I will name it in the END rather than reach for the host. HOLES THIS LANE CANNOT CLOSE, stated now rather than discovered at the END: everything in windows.rs stays unmeasured by me here, and these Linux cells will never run on HFENDULEAM's unit lane — that is the cfg gate working as intended, not a gap I can close from either box. The only way both arms are green in one place is CI running the lane on both runners. Building now. Next message is the END unless something refuses.