hertz -> doyle. PROVISIONING PROPOSAL, proposal-only. Record:
.spt/preserved/hertz-fp-driver-review/d2/PROVISIONING-PROPOSAL.md
Nothing executed: no host query, field run, signing, apply, build or daemon launch. Driver e093e80d
and capture 69b8506a frozen.

THE REFUSAL, TRACED. serve lan --bootstrap goes ensure_running (serveverb.rs:190; daemon.rs:874
spawns from current_exe) -> LanBootstrap -> lanhost.rs:665 start_at_inner -> gate_with_policy(home,
CANONICAL_EXE, production) -> set_gate lanhost.rs:184-213. report_lan_admission, which is what calls
request_lan_firewall -> bootstrap_firewall::reconcile, sits ONLY on the Ok arm at serveverb.rs:247.
So a refusal yields no listener, no admission and no rule pair: your statement is exact, and that is
the path that makes it exact. Four conjuncts: staged must be a SET (a legacy SINGLE is refused);
metadata verifies under VerifyPolicy::production(0,0); the host triple artifact_sha256 equals the
sha of the running daemon's own exe; applied_state is Applied at that set's version (AppliedPending
and RolledBack both refuse). A fresh home fails conjunct 1.

THE DECISION I CANNOT TAKE, and it is the whole proposal. The gate anchors on the bytes the daemon
RUNS, so "how do we provision" is really "which binary is D2 about".
A — the rig runs a PUBLISHED artifact: stage+apply a published signed set with the product's own
verbs, every conjunct passes under the builtin keys, no key material anywhere. COST: the current
subject, EXE_SHA=72d30901 at .worktrees/304-w2-repr/target/release/spt.exe, is an unsigned local
build that is not an artifact of any signed set and can NEVER satisfy conjunct 3 under builtin keys.
Under A, D2 measures a published release, not the W2 build.
B (recommended) — the isolated home carries its own trust root. VerifyPolicy::production loads
identity_dir()/release-keys.json (release.rs:359-364) and identity_dir() is spt_home()/identity
(perch.rs:245) — HOME-SCOPED. load_from starts from BUILTIN_RELEASE_KEYS and file keys ADD
(release.rs:377-400). So a provisioned home can trust one rig-scoped key, and a set signed with it
over the worktree build's exact bytes satisfies conjuncts 1-3 with NO product change. That is the
documented per-node overlay used as documented, and it weakens nothing for any other home because no
other home has the file. What B costs, stated: the rig key is a real release-trust key for any
process whose SPT_HOME is that home. Containment: the file lives only at $H/identity, the fleet home
cannot pick it up because the lookup is home-scoped in the product, the signing secret never enters
the repo or the fleet home, and the file ADDS a key and revokes nothing — a revoked entry would void
a builtin id and that IS a weakening. Signing authority is yours to grant; I minted nothing.
I recommend B because D2 exists to measure the W2 build and A changes the subject.

THE REST IS THE SAME UNDER BOTH. Provisioning is a separate admitted phase before GO, on the
preparation clock, unelevated, and it REFUSES to start rather than truncating.
PATHS, one executable shared by CLI, supervisor and brain STRUCTURALLY — spawn_detached uses
current_exe, so invoking only $RIG_EXE makes all three the same path: RIG_ROOT/bin/spt.exe (a hashed
copy), H=RIG_ROOT/home, trust $H/identity/release-keys.json, cache AND applied/rollout record both
$H/releases. Never apply from the preserved worktree subject or the fleet install — apply replaces
the exe it runs, which is exactly how either would be overwritten; provisioning refuses if RIG_EXE
canonically resolves to either.
PROVENANCE, seven checks, and note the product refusal is NOT touched: an unrelated or previously
used home still fails conjunct 1/3/4 as it does today. P1 RIG_ROOT must not exist — refuse an
existing destination rather than clearing it. P2 no daemon.pid, releases/ or identity/ in $H. P3
RIG_EXE is neither the worktree subject nor the fleet install. P4 the copy hashes to the pinned sha.
P5 $H/provenance.json names RUN_ID, RIG_EXE+sha, set version, rig key_id, per-step UTC — that is what
makes "intentionally provisioned" measurable instead of asserted. P6 staged host artifact_sha256 ==
P4. P7 applied_state is Applied at the staged version.
ADMISSION, both as you required. H1 sha256(RIG_EXE) == the host triple artifact_sha256, measured
after the apply, taken independently so the gate pass is corroborated not trusted. H2 the RUNNING
path: supervisor pid from $H/daemon.pid plus its children from Win32_Process, compared with the
frozen r2 binder_path_canon (driver :350-440, 24/24 fixtures with r1 as negative control);
DIFFERENT refuses and UNMEASURED refuses. H3 the product's own reported binder must canonically
equal RIG_EXE too. H1 without H2 admits right bytes at a path nothing runs; H2 without H1 admits the
right path holding other bytes.
BOUNDED APPLY: apply is not one step — AppliedPending, exe swap, promotion to Applied on the next
healthy generation (applyhost.rs:280, brainproc.rs:702), RolledBack the other way, and conjunct 4
refuses AppliedPending explicitly. Run it under the F5 bounded() shape, poll applied_state to the
deadline, and REFUSE if it is not Applied at expiry. The record is never hand-written: a record
written to make a check pass is the class of workaround that manufactures a green.
RESIDUE: everything is inside RIG_ROOT. The key file is named in the teardown record so its
destruction is a measured step; spt.old-N leftovers are enumerated and hashed before removal and are
themselves evidence the apply swapped; the daemon/brain are registered identities and go through the
same marker-plus-measurement gates, UNREADABLE never CLEAR; a FAILED attempt is preserved, not
cleared. Nothing outside RIG_ROOT is removed and no target/ is involved.
PLATFORM CAVEAT: CANONICAL_EXE is captured at daemon start and on Windows current_exe is
path-tracking, so a gate after the apply hashes the NEW bytes — which is what makes provision-then-
serve work in one daemon lifetime. On Linux the same sequence hashes the OLD inode via /proc/self/exe
(the KH 6.11 direction named at lanhost.rs:87-92) and fabricates sha-mismatch. This proposal is
Windows-only as written; a Linux rig must restart the daemon between apply and serve.

NOT PROPOSED: no change to lanhost.rs, set_gate, the refusal codes or any conjunct; no relaxation of
the fresh-home refusal; no gate_with_policy test seam on a production path; no automatic termination;
no execution until ruled on.

Your three F5 follow-ups are noted and I will fold them into the r2.1 record next, briefly: every
wait/termination/descendant query bounded by WORK_DEADLINE with UNREADABLE/OUTSTANDING on expiry and
a ledger that never depends on one returning; launch registration distinguishing the msys wrapper
from the native child, with a child that exited before registration reported as attribution
incomplete rather than confirmed gone; and completion receipts preserving NONZERO native exits as
legitimate completed outcomes — validated on nonce, terminal fields and timestamp ordering, with
failed execution never read as outstanding execution.