Allocation request — no build authorization assumed; no fixture execution yet.

Minimum new compiled target: ONE diagnostic integration-test binary in spt-daemon at v0.69.0 (proposed name relay_classification_diag). Build only `cargo test -p spt-daemon --test relay_classification_diag --no-run`, not workspace/bin/test suites. The fixture hosts the real broker library with explicit hermetic NetConfig, and invokes the already-verified private RELEASED spt0.69.0 executable for caller/listener and a single coordinator. The broker is test-hosted, not a released `daemon run` process: report that distinction. Actual bind/listen calls, retained real PTY I/O and actual registry advertisement must still be exercised; no direct stamping of the classification under test. If this composition cannot reach a required public boundary, report a blocker rather than claim end-to-end coverage from helpers.

Reusable artifacts:
- Private released spt0.69.0: SHA256689503ad9fc6cfde637cbcacf21c42faf130ba465a0df6c356cf290e2adafb85, version checked. No rebuilt spt CLI is required for the all-new arm.
- Existing mock-session.exe in the released hertz-294-sync-stages pool,351,232 bytes. Its provenance/hash must be frozen before reuse. Alternatively a small explicitly versioned diagnostic terminal harness; either is a fixture, not omp-spt0.9.3 coverage.
- Completed .worktrees/hertz-294-sync-stages source tree and its own target are the warm-cache candidate, subject to a current ownership/custody check and Doyle allocation. Reuse IN THAT SOURCE TREE with a new diagnostic branch based on0.69.0; do not point the new hertz-relay-069 checkout's CARGO_TARGET_DIR at another tree's target, clone a full pool, or create a junction. Existing diagnostic commits/raws remain preserved.
- Existing analogous resume_no_control_steal_e2e binary:50,874,368 bytes exe +345,985,024 bytes PDB (~0.370GiB combined). Current spt-daemon rlib generations are354,558,532–360,675,522 bytes each (~0.330–0.336GiB). These are sizing analogues, not runnable replacements for the new scenario. Raw byte counts: artifact-sizes.json.

Additional capacity estimate (engineering estimate, NOT a measured upper bound):4–8GiB for the warm targeted build, covering recompiled project crates after the0.69.0 version change, target exe/PDB, incremental state and linker temporary files; allow a separate1GiB fixture/log/temp budget across sequential arms. Third-party dependency reuse is a prerequisite to that estimate. It does NOT apply to a cold source/target pool, changed rustc/RUSTFLAGS/profile, a missing cache, or a full workspace build. Those cases stop for re-estimation; no fallback to an uncapped cold build.
The18.6GiB free-space sample is neither the build requirement nor sufficient-headroom proof. Request allocation of9GiB additional growth PLUS the maintainer's protected free-space reserve; do not equate the sample with approval. During any authorized build/run monitor growth/free space and stop owned work at the agreed bound. No deletion or reclamation performed by hertz.

Exact isolation prerequisite:
The private RELEASED daemon-run path still constructs mDNS + real-interface networking; disabling relays and setting ephemeral advisory ports does not make it loopback-only. Avoid that path for the hermetic arm. Test-host the broker with explicit Loopback, LocalDiscovery::Off, RelayPolicy::Disabled, and an empty fixture-owned peer roster. Bind the seed/broker IPC services under a fresh SPT_HOME-derived name, choose OS-assigned advisory ports, and establish that the one released coordinator/caller connects to those exact services. Verify actual listener addresses/process provenance and retain them before proceeding. The outstanding work is composing and checking this fixture, not an assertion that private home alone isolates it. No fleet socket, identity, registry, service manager, install seat or firewall configuration may be used or changed.

Compatibility boundary:
The above target closes the all-0.69.0 hermetic internal-host/public-bind-listen hybrid. It does not prove a released0.67.1 broker process with0.69.0 coordinator. That mixed arm needs a separately pinned old broker and single-coordinator launch/isolation strategy. Available release assets were located, but none downloaded/executed; no old/new source equivalence or mixed runtime compatibility claimed. Do not widen this allocation into another cold build without a separate estimate/ruling.

Teardown/control remain as in PREFLIGHT.txt: control then replacement, separate homes, actual same-PTY fresh I/O, relay-only termination, pinned PID+birth+image, bounded success/failure/timeout cleanup and survivor census between arms. Source and fixtures remain diagnostic only; no product fix, deployment or board changes.