CLEANUP END. Residual cleared, all four verifications done, and one precision correction to my own earlier wording about 5470.

IDENTITY REVALIDATED IMMEDIATELY BEFORE TERMINATION, all four fields, and only then:
  pid 49768 == expected 49768
  CreationDate 2026-09-12T10:38:36Z == expected
  ExecutablePath C:\Users\decid\Documents\projects\spt-core\.worktrees\304-w2-repr\target\release\spt.exe == expected, exact string
  CommandLine contains 'daemon run --detached' == true
  ALL FOUR MATCH, so I proceeded. Had any differed I would have stopped and reported instead.
  Terminated by Stop-Process -Id 49768 - that pid ONLY. No tree kill, no name-based match, no broad daemon-stop verb, and OWL_SESSION_ID untouched.

VERIFICATION AFTER, each measured rather than assumed:
  1. PROCESS ABSENT: pid 49768 absent on a re-read. Broader sweep as a second arm - NO spt.exe anywhere with an ExecutablePath under 304-w2-repr is running. The lane's built binary has nothing holding it now.
  2. 29470 CLEAR: no listener.
  3. THE NODE'S OWN DAEMON IS UNTOUCHED, which is the thing a careless kill would have taken: pid 4732 ALIVE, path C:\Users\decid\AppData\Local\spt-core\bin\spt.exe - the INSTALLED binary, not the built one - started 2026-09-11T04:17:53Z, i.e. long before this run and unchanged by it.
  4. 5470 UNCHANGED: captured now with the same frozen portfields instrument the guard used, and it is byte-identical to the driver's final-post-cleanup capture excluding timestamps. The driver's own guard-final-post-cleanup.diff is ZERO LINES.

A PRECISION CORRECTION TO MY OWN EARLIER WORDING, because "5470 listener identity identical" overstates what was compared. All three 5470 captures - guard-baseline, post-build, final-post-cleanup - and mine now read LISTENER_STATE NONE and LISTENERS 0, with MATCHING_RULES 1 and the same single rule {FF36EE51-2837-46D8-9AB8-2441D9070633} (Inbound/Allow/TCP/5470/Private, RemoteAddress 192.168.1.0/255.255.255.0, Program=Any). An independent live read confirms 5470 is NOT BOUND right now.
  So what the guard actually established is: 5470 had NO LISTENER AT BASELINE, still has none, and its one matching rule is unchanged field for field. It is two absences compared, not two listeners compared. The protection claim that matters - this run did not disturb 5470's rule set and did not take a listener away from it - holds either way; I just should not have said "listener identity identical" when the identity on both sides was absence.
  Related, stated as a measurement and not a recommendation since you have ruled the banner a standing notice: the LAN-EXPOSED line in my environment signal claims this node serves its binary on 192.168.1.81:5470, and 5470 has no listener. I am not acting on that.

PRESERVATION, as you framed it: the a-1 wall, its captures and its outcome are preserved in the run evidence as an INSTRUMENT-ABORTED ATTEMPT - not a product failure and not a completed registered trial. The evidence dir is intact and nothing in it was rewritten after the fact; a-1.out, a-1.err, the portfields and census captures, cpu brackets, findings, exits and cleanup-failures all stand as written.

BOUNDARY ACCEPTED on the build figure: 9m05s is an OBSERVED INTERVAL between two evidence files' mtimes (capacity-rollout-build.out 10:27:08Z to s3-rollout.out 10:36:13Z). It is not a measured compiler duration - it includes whatever else ran inside run_cmd in that span, and I have no per-phase timing from cargo. I will quote it with that qualifier attached or not at all.

No rerun, no rebuild, nothing retried. Pool remains released. Awaiting your word on whether the line-925 revision is authorized and who writes it - hertz tells me you have given them the harness repair, and they have asked me for the executed artifact, the real captured portfields file and a path for their revision, which I am sending them now.