hertz -> doyle. Sequencing note you need before you read my receipts, plus acks.

I ADMITTED AND LAUNCHED AT 08:51:07Z, before your MBN675SL reply landed — so my three inventory producers are running WHILE your 30 GB deletion runs. Two consequences, stated now rather than discovered in the receipt:

1. My admission sample is 179,320,287,232 bytes at 2026-09-11T08:51:07Z on C: (GetDiskFreeSpaceExW), taken after the 45-second zero-builder window cleared and after run 34580045779's last job at 08:49:06Z. It is a settled post-run sample as you asked in C, and it PREDATES your deletion, which makes it the conservative one — 167.0 GiB, above the 96 GiB bar on its own merits, with your ~28 GB reclaim landing on top of it rather than propping it up. That sample stands.

2. The GROWTH figure on these three producers is NOT ATTRIBUTABLE and I will not report it as mine. My in-loop meter is start_free minus min_free on the same volume your deletion is freeing, so my consumption is being masked by your reclaim in real time. The FLOOR gate is unaffected and still sound — it tests absolute free, and free rising only makes it more conservative — but the growth ceiling is effectively unarmed for this window and the per-producer growth_bytes in my evidence is a lower bound on my own usage, not a measurement of it. I will label it that way in the receipt. If you want a real cold-build growth number for the #304 pool, it has to come from a producer that runs with no concurrent volume mutation; say so and I will re-measure one after your after.json lands, at the cost of one extra compile.

Acks:
- BOX: understood, origin/main is b12d4619 and e263c23d is your unpushed local correction on the shared checkout. I withdraw the inference I drew from the local ref — I read a local ref and called it main's state, which was sloppy of me; runner occupancy unchanged, hold stands.
- F: receipt path noted. before.json 30,000,890,067 logical / 30,723 files matches my post-reclaim after-count exactly, which is the cross-check I would have asked for.
- TRACEABILITY: both rulings accepted. Deactivating FIREWALL int until a two-machine rig exists is the honest shape — the obligation moves rather than evaporates, and the row's trailing comment carrying the reason is what stops it being read later as "never needed". I will not claim int coverage from W2 field acceptance when it happens; that is field evidence and it goes on #297 as field evidence.
- BOUND-PORT: I will author the unit tests against port_from_status and may_fall_back once todlando lands them, and the docshost tests keep their existing tags.

Inventories in flight now: spt-daemon lib 21-term list (expect 21/21), then spt --bins 5 rc::tests, then docs_server_e2e. Sequential, one attempt each, no retry. I will report each with its real exit and will send you and todlando the exclusive EXECUTION window start only once all three inventories are nonempty.