hertz -- WINDOW 7 END 2026-09-11T11:27:28Z. Open 11:25:38Z, 110.8 s against a 600 s cap. ALL THREE ARMS RAN, no holes. BOX IS FREE FROM ME: post-census ci/analyzer/agent/unknown all ZERO, no survivors on any arm. Tree CLEAN, final blob == HEAD blob 2c4099f0, byte shape recorded (32145 bytes, 761 CRLF, 0 bare LF) so "clean" speaks about bytes and not only content. Admission before the START: BOTH positive controls TRUE (control_builder.seen_by_census and control_pool_exe.seen_by_filter), pool_executions 0, blind 3 by identity, 156.1 GiB free.

EVERY PREDICTION ON FILE, AGAINST ITS RESULT.

Q2 R-DROP -- CONFIRMED at the values.
  Summary: 1 test run: 0 passed, 1 failed, 987 skipped. Zero-match guard satisfied: exactly 1 selected.
  FAIL at crates\spt-daemon\src\docshost.rs:683, the cell's FINAL assert, with its own message:
      assertion `left == right` failed: dropping the guard retires the published port
        left: Some(59827)   right: None
  Filed as: RED at the final assert, left Some(<port>), right None, with (a) (b) (c) passing first. That is what happened -- the failure is at :683 and not at the gate's :671, so the earlier asserts did pass and the arm falsified the retirement half specifically. Mutation reverted immediately; revert recorded work_blob == head_blob == 2c4099f0, clean, 761 CRLF / 0 bare LF.
  Both halves of the cell are now falsifiable by a product-side mutation and each fails at its OWN line: R-GATE at :671 (left Some(56025)) in window 6, R-DROP at :683 (left Some(59827)) here. The cell is not a tautology in either direction.

Q3 ARM B -- CONFIRMED, and the negative control FIRES this time.
  Summary: 2 tests run: 0 passed, 2 failed, 986 skipped. Guard satisfied: exactly 2.
  registryhost::tests::recent_projects_for_dedups_newest_first_excludes_spt_internal
    registryhost.rs:1404, got ["github-com-bigscreenvr-spt-bs-core"], right ["alpha","beta","gamma"]
  projwriter::tests::batched_complexity_counters_hold
    projwriter.rs:842, left Some("spt-bs-core"), right Some("proj-a")
  Exactly the strings I filed. The driver recorded the bases and they DIFFER: armA reference under AppData\Local\Temp\hertz-304-rig (outside any repo), armB-real under .spt/preserved/.../temp (inside the checkout), differ TRUE -- so this arm is a measurement and not window 6's non-measurement wearing a new label.
  THE TMP MECHANISM IS NOW PROVEN TWICE OVER, by a static control and by a run: same sha, same bytes, same box, the only difference the TMP base; ARM A both PASS, ARM B both FAIL at the same two lines with remote-derived ids. Window 6's arm B PASS was the unwired switch, exactly as reported, and had I honored my own filed prediction mechanically I would have withdrawn a true finding.

Q4 -- CONFIRMED EXACTLY, both halves.
  Summary: 988 tests run: 988 passed (5 leaky), 0 skipped. Zero FAIL lines in the whole run.
  Filed: 988 run / 988 passed / 0 failed. The population half was already confirmed by complement in window 6 (1+987, 2+986); this closes the pass half. The two reds from window 5 are gone because the rig, not the product, was the cause -- and that is the same arithmetic I filed: 987 + 1 new cell - 2 TMP artifacts.

Q1 (window 6) stands: the cell GREEN, 1 test run, 1 passed.

Q5 LEAKY -- REFUTED AS A COUNT, and the refutation is the better answer. FIVE leaky, not the four I predicted:
  brainproc::tests::clear_before_spawn_defeats_exact_generation_stale_file
  brainproc::tests::ready_but_old_gen_never_drains_does_not_promote_rolls_back
  brainproc::tests::stale_generation_minus_one_ready_never_promotes
  brainproc::tests::trial_kills_alive_never_ready_candidate_before_rollback
  broker::tests::windows_session_is_zombie_sees_a_handle_held_corpse_as_dead
  livehost::tests::legacy_psyche_sweep_guard_is_id_specific_and_fail_safe did NOT leak here.
  THREE RUNS ON THE SAME BYTES NOW, which is enough to split the set: todlando 6 (brainproc x4 + broker + livehost), my window 5 4 (brainproc x4), this run 5 (brainproc x4 + broker). The brainproc FOUR leak in every run -- cell-shaped, and worth an owner's eye on a shared box. broker leaks in 2 of 3 and livehost in 1 of 3 -- RUN-shaped, ordering or load, not a property of those cells. None failing in any run. I predicted "the same four" and was wrong about the count; the characterisation is firmer than the number I filed.

Q6 POOL -- CONFIRMED: no SPT_POOL_FOREIGN, no lane-identity refusal, no survivors, growth within noise (one arm -7.8 MB as the mutated artifacts were replaced, one +10 KB).

ONE EVIDENCE-NAMING TRAP FOUND IN MY OWN RIG, reported because it is the class that hands back a previous window's verdict: admission.py writes its record to admission-61bfd85c.json -- a STALE TAG from an earlier window -- rather than to a name carrying the current sha. Today it cost nothing because I read it by content and checked its utc (11:24:39Z) and both control flags rather than trusting the filename. But a file named for a sha it does not describe is precisely how a stale read passes for a fresh one, and it is the same family as the reused .raw paths I already guard against by refusing to read them before the report carries end_utc. Not fixed in this window; named for the register and for whoever inherits this rig.

ALSO ON RECORD, an instrument slip of mine during setup: I read the admission output through `tail -8`, which showed ONE of the two required positive controls. I did not call admission clean on one control -- I went back to the record and verified both -- but a census read through a truncating filter is the same shape as every other defect I have filed today, and it nearly passed with half the evidence I require of myself.

NEXT, per your order: the comment-only follow-up on the cell as its own commit -- one sentence naming that it writes the process-global BOUND_DOCS_PORT and is sound only under process-per-test (nextest, which ci.yml:143 and golden both use), so a threaded runner is out of contract. Then the tip is yours to re-merge, re-check at 0.4.1 (I also predict zero findings: the nine misplaced tags are main's already-elided ones and REQ-WEB-URL-BOUND-PORT now has unit evidence at docshost.rs), incremental cargo check, and W1 integration closes on that sha. Understood on no golden -- #304 carries the operator question and the head is an integration head until Q1 is answered or W2/W3 fulfil the remaining members.