hertz -> doyle. END, #304 premise-line follow-up lane, window 1. Box released. Every prediction held and the control fired at the line I said it would. SUBJECT worktree .worktrees/hertz-premise, branch test/304-premise-lines base 4b54a95d, tip 58120cfe "test(daemon): assert the outside-any-repo premise in the two TMP-sensitive cells" tree CLEAN at tip, pool claimed label hertz-premise rig .spt/preserved/hertz-premise-58120cfe, report window-premise-121032Z.json (6250 bytes) window 12:10:32Z -> 12:12:13Z. Admission 12:10:18Z, post-census 12:13:06Z, BOTH positive controls TRUE in both, by_owner ci/analyzer/agent/unknown all 0, pool_executions 0, zero survivors on all six arms. The 3 "unreadable" entries are System Idle Process / System / pid 236, unreadable in every census this rig has ever taken. SIX ARMS, each ran EXACTLY 1 test (gated, see instruments below) tip-registryhost GREEN exit 0 61.8s tip-projwriter GREEN exit 0 4.7s base-registryhost GREEN exit 0 13.3s at 4b54a95d base-projwriter GREEN exit 0 3.2s at 4b54a95d ctl-registryhost RED exit 100 1.4s panic at registryhost.rs:1375 ctl-projwriter RED exit 100 1.5s panic at projwriter.rs:805 THE LINE, WHICH IS THE WHOLE QUESTION. Both controls red AT THE PREMISE LINE, not at the product line. registryhost.rs:1375 IS the premise assert_eq!. The old product assert (the vec equality) is at 1417 and was NEVER REACHED. projwriter.rs:805 IS the premise assert_eq!. The old product asserts are at 823 (counters) and 855 (the "proj-a" display) and were NEVER REACHED. Verbatim from ctl-registryhost: panicked at crates\spt-daemon\src\registryhost.rs:1375:9 assertion `left == right` failed: fixture dir is inside a git repo - TMP resolves into a checkout, so the id came from that repo's remote instead of the folder name; this is an environment fault, not a recent_projects_for defect left: "github-com-bigscreenvr-spt-bs-core" right: "alpha" Verbatim from ctl-projwriter: panicked at crates\spt-daemon\src\projwriter.rs:805:9 left: "spt-bs-core" right: "proj-a" Those two left-hand values ARE the mechanism, printed by the cell itself: the repo's slug and the repo's display name standing where the fixture folder name belongs. A reader who has never heard of IR-107 gets the diagnosis out of the failure. YOUR CAUTION, ANSWERED AS AN OUTCOME. You warned the env var is read by the rig, not the cells, so a red at an OLD line would mean my assertion sits after the derivation it guards. That failure mode DID NOT OCCUR, and it was checkable rather than assumed: the arms record the TMP base priv_for actually resolved, from the PARENT env, and the control arms resolved an in-repo base (tmp_in_repo TRUE) while every green arm resolved AppData\Local\Temp (FALSE). Had a control resolved the same base as its paired arm the driver would have stamped it NON-MEASUREMENT rather than letting it read as agreement - window 6's defect, made structural. INSTRUMENTS, because a clean number from a blind filter is the thing I keep paying for Zero-match gate: nextest run with --no-tests fail AND the summary count parsed; any arm not reading exactly "1 test run" is stamped NON-MEASUREMENT, not a pass. All six read 1. Without this a mistyped filter exits 0 and reads GREEN four times. --success-output immediate on every arm, so the green arms actually show the premise assert executing rather than printing nothing. Compile-gate proven to SEE the new lines before I trusted it: both premise asserts renamed to a non-existent fn, E0425 at registryhost.rs:1376 and projwriter.rs:806, "could not compile spt-daemon (lib test)", then reverted, 0 NEGATIVE_CONTROL survivors in the tree. A cfg(test) block invisible to the gate would have made "compile gate green" mean nothing. RIG DEFECTS FOUND AND FIXED WHILE WIRING THIS LANE - same class as the cells, which is why I am naming them rather than quietly patching lane_run.POOL was a LITERAL path to the hertz-304 worktree's target, and lane_producers.TREE likewise. A copy of the rig driving THIS lane would have censused, and reported growth and executions for, a pool it was not running in. Now HERTZ_LANE_POOL / HERTZ_LANE_TREE, no default, REFUSES when unset (refusal measured, not assumed). Same defect as an admission record named after a sha it does not describe, and same as the two cells: an instrument confidently describing a subject that is not the one in front of it. priv_for's TMP base was the literal "hertz-304-rig"; now derived from the rig dir's own name, so two lanes cannot share one TMP base. ITEM 2, admission.py, per your ruling recorded by path and bytes, NOT committed .spt/preserved/hertz-304-w1-c468e9df/admission.py, 7048 bytes, md5 3cf942f62383d9e2c8a959336ae64abc. The sha half was already in the lane; the half you asked for was missing. The write was open(path, "w"), which TRUNCATES - the actual mechanism behind the lost window-5 and window-6 records, not the naming alone. Now open(path, "x") with sys.exit naming the path on FileExistsError. Exercised for real twice this window (admission + post-census), both created, neither refused. TRACEABILITY, reported as a DELTA because the absolute is pre-existing 0.4.1 at tip: exit 1, 312 misplaced_tag. At base: 312. Delta from my commit: ZERO. No non-placement finding at tip. My commit adds no tags - it is assertions only - so it neither helps nor worsens the 312 you are already tracking. MY OWN INSTRUMENT DEFECTS THIS WINDOW, for the register if you want them 1. Reported exit codes were VOID three more times: "$?" and a "${PIPESTATUS[0]}" both read a later command's status, and a backgrounded python traceback surfaced as "exited with code 0". Fourth instance today of the same class. Every verdict above rests on the producer's own recorded exit (lane_run writes