# Arm 2 — bare HEAD golden, run 34474627303 (PARTIAL: Linux only)

STATUS OF THIS DIRECTORY: BOTH `test` LEGS PRESENT. The Windows `n1-gate` job was still
in_progress when these bytes were written, so the RUN is not terminal and has no conclusion yet;
the two cell-carrying `test` legs are both terminal and both logs are here.

## Identity
- run 34474627303, repo BigscreenVR/spt-bs-core, event `workflow_dispatch`
- headSha `a9e786b24fe4e541dcd394ef428f225d72f3024a` (the v0.69.0 candidate head)
- twohost = false (this arm is NOT release-gating)
- Sibling arm: `.spt/preserved/arm1-bare-base-34467873057-20260910/` (bare BASE, de5a44bc)

## Why this arm exists
Both arms of the earlier diagnostic pair (34458491560 @1bd0a41d, 34462915181 @1a7f7f55) carried
hertz's instrumentation plus suite-wide output retention. Identical treatment controls the INPUT,
never its EFFECT, so the baseline finding drawn from them was unlicensed. This pair (arm 1 = bare
base, arm 2 = bare head) removes the instrumentation clause. Order was inverted relative to the
instrumented pair, which BALANCES ORDER SLOTS; it does not cancel drift.

## Job census, read 12:38:28Z
| job | conclusion | started | completed |
|---|---|---|---|
| traceability | success | 12:04:03Z | 12:04:15Z |
| changes | success | 12:04:17Z | 12:04:24Z |
| n1-gate (self-hosted, Linux, kitsubito) | success | 12:04:27Z | 12:05:58Z |
| test (self-hosted, Linux, kitsubito) | success | 12:06:00Z | 12:35:06Z |
| test (self-hosted, Windows, hfenduleam) | in_progress | 12:04:26Z | — |
| n1-gate (self-hosted, Windows, hfenduleam) | queued | — | — |

METER NOTE: the run-level `status` field read `queued` at 12:11:09Z while two jobs were in_progress
and three were terminal. It is not the run's state. Everything above is scored from
`/actions/runs/<id>/jobs`.

## Files
- `test-linux-102862459272.log` — 682,227 bytes, pulled via
  `gh api repos/BigscreenVR/spt-bs-core/actions/jobs/102862459272/logs` while the RUN was still in
  progress (the run-scoped `gh run view --log-failed` refuses and exits 0 in that window).

## Measurements — Linux leg only
Control taken FIRST: the Summary line occurs 2 times, and the two carry DIFFERENT populations, i.e.
the two phases, not the repeated-population VOID shape.

    Summary [  48.570s] 3360 tests run: 3360 passed (1 leaky), 1 skipped     (Phase A, log:4266)
    Summary [1172.538s]  223 tests run:  223 passed (1 slow), 0 skipped      (Phase B, log:4510)

Failure-class rows with a suffix allowed (FAIL / TIMEOUT / SIGSEGV / ABORT, so a `FAIL + LEAK [`
row could not hide): ZERO. Occurrences of the panic string: ZERO. Both reconcile with the Summary
counts.

Both phases ran under `--no-fail-fast` (read from the two step command lines at log:864 and
log:4267), so neither Summary is a prefix of an aborted population.

### Target cells — both EXECUTED
    PASS [   1.408s] (  27/3360) spt::contract_e2e live_agent_lifecycle_e2e            (log:931)
    PASS [   1.468s] (1745/3360) spt-daemon::sync
        two_tier_sync_lands_and_gate_refuses_server_side                               (log:2649)
Neither carries a SLOW row on this leg.

NOT COMPUTED ON PURPOSE: 1.468s is not compared against arm 1's 91.375s. That figure is WINDOWS and
a different tree; this is LINUX. Different box, different population (3360 vs arm 1 base's counts).

### Arm 1's Linux red cell, here
    PASS [   3.629s] (  49/3360) spt::io_events_undriven_kinds_e2e
        relay_backlog_and_live_deliveries_stamp_once_even_after_hook_poll              (log:953)
SCOPE LIMIT, stated with the green because the green is weaker than it reads: the exact-once assert
compares (kind, author) and BOTH expected rows are ("MSG_IN", Some("alice")), so TWO BACKLOG ROWS
WOULD SATISFY IT. This pass does not establish that both relay arms published. n=1, and it is a
different tree from the arm that reddened.

### Other non-PASS rows in the leg (neither is a failure)
    LEAK [   0.208s] (3316/3360) spt-daemon
        livehost::tests::legacy_psyche_sweep_guard_is_id_specific_and_fail_safe        (log:4220)
    SLOW [> 60.000s] (───────) spt-daemon::transport_death_eof
        transport_death_without_a_fin_surfaces_eof_to_the_serving_worker               (log:4482)

## What this evidence does NOT do
It classifies nothing and gates nothing. The verdict of record remains golden 34445961595, attempt
1, head a9e786b2, event=push, WITH twohost, conclusion failure, carried by test(Windows).
twohost=false arms are not release-gating. Classification (regression vs environment) is doyle's and
remains OPEN. Release HELD.

---

## Windows leg — added 13:1xZ, job terminal

Job `test (self-hosted, Windows, hfenduleam)` id 102862459074, conclusion **success**,
12:04:26Z -> 13:10:45Z = **66m19s** against the job's 80-minute budget (golden.yml:172). No wall
kill, so the `cancelled`-not-`failure` trap does not apply to this job. My own earlier projection
said ~13:05Z; the actual was 13:10:45Z, ~6 min later. Recorded because the projection was mine.

File: `test-windows-102862459074.log` — 705,318 bytes, pulled after the job went terminal.

### Control first
The Summary line occurs **2** times, and the two carry DIFFERENT populations (3381 and 238), i.e.
the two phases, not the repeated-population VOID shape.

    Summary [ 791.935s] 3381 tests run: 3381 passed (8 slow, 3 leaky), 1 skipped   (Phase A, log:4188)
    Summary [1414.084s]  238 tests run:  238 passed (1 slow), 0 skipped            (Phase B, log:4445)

Failure-class rows with a suffix allowed (FAIL / TIMEOUT / SIGSEGV / SIGABRT / ABORT, so a
`FAIL + LEAK [` row could not hide): **ZERO**. Occurrences of the panic string: **ZERO**. Both
reconcile with the two Summary counts.

Both phases ran under `--no-fail-fast` (read from the two `wrap.ps1` step command lines at log:759
and log:4189), so neither Summary is a prefix of an aborted population.

### Target cells — both EXECUTED on Windows at the HEAD tree
    PASS [  37.919s] (  42/3381) spt::contract_e2e live_agent_lifecycle_e2e          (log:839)
    SLOW [> 60.000s] (─────────) spt-daemon::sync
        two_tier_sync_lands_and_gate_refuses_server_side                             (log:2790)
    PASS [  94.000s] (2019/3381) spt-daemon::sync
        two_tier_sync_lands_and_gate_refuses_server_side                             (log:2819)

### Arm 1's Linux red cell, on Windows here
    PASS [  14.429s] (  41/3381) spt::io_events_undriven_kinds_e2e
        relay_backlog_and_live_deliveries_stamp_once_even_after_hook_poll            (log:838)
Same scope limit as the Linux instance: the exact-once assert compares (kind, author) and both
expected rows are ("MSG_IN", Some("alice")), so two backlog rows satisfy it.

### Side-by-side with arm 1 (bare BASE, Windows, same box, same twohost=false, same bare treatment)
This is the ONE pair in the whole set that differs in a single named variable — the TREE (base
de5a44bc vs head a9e786b2). It is still n=1 per side and the POPULATIONS DIFFER, so the phase totals
below are reported, not differenced.

| quantity | arm 1 (base de5a44bc) | arm 2 (head a9e786b2) |
|---|---|---|
| Phase A Summary | 786.355s, 3346 run, 3346 passed (6 slow, 5 leaky), 1 skipped | 791.935s, 3381 run, 3381 passed (8 slow, 3 leaky), 1 skipped |
| Phase B Summary | 1382.417s, 236 run, 236 passed (2 slow) | 1414.084s, 238 run, 238 passed (1 slow) |
| sync cell | PASS 91.375s (1993/3346), SLOW row | PASS 94.000s (2019/3381), SLOW row |
| contract cell | PASS 27.561s (36/3346) | PASS 37.919s (42/3381) |

The populations moved 3346 -> 3381 (Phase A) and 236 -> 238 (Phase B), which is the head tree
carrying more cells. A phase total over a different population does not isolate anything, and the
per-cell walls are n=1 each; no direction is claimed from any of the four rows.

NOT COMPUTED ON PURPOSE, carried forward from arm 1: the sync cell's 94.000s is WHOLE-TEST WALL. The
instrumented arms' failures reported ~10.17-10.20s INTERNAL elapsed at 400/400 iterations. Different
quantities — no subtraction, no margin derived from the difference.

## What the Windows leg establishes, and what it does not
ESTABLISHES: at the v0.69.0 candidate head, bare source and config, twohost=false, on hfenduleam,
both cells EXECUTED and PASSED, with zero failure rows anywhere in the job. n=1.
DOES NOT: classify golden 34445961595 (different event, WITH twohost, and the record red is carried
by a job run under those conditions); clear the candidate; gate the release. The clean-candidate
green the gate needs is a separate, later, FULL-twohost run. Classification is doyle's and remains
OPEN. Release HELD.

## Run-level state at the time of writing
`twohost-a` and `twohost-b` both `skipped` (expected at twohost=false), completed 13:10:45Z.
`n1-gate (self-hosted, Windows, hfenduleam)` still in_progress; the RUN therefore has no conclusion
yet. Nothing above depends on it — both cell-carrying legs are terminal and scored.

---

## Gater's classification of Finding 1 (doyle, 2026-09-10) — carried verbatim at his request

**NOT CLASSIFIED, and that is recorded as the verdict rather than forcing one.** What is measured:

    reproduced   2/2  instrumented CI arms (twohost=false), margins measured: 400/400 iterations,
                      10.156-10.200s internal, IPC <1%, sleep 99.4%, budget within 2% of nominal
    not reprod.  0/2  bare CI arms (twohost=false), both cells PASS, cell-level, both trees
    not reprod.  0/12 local legs
    the RUN OF RECORD is the ONLY bare execution that failed — and the ONLY execution anywhere
    with twohost=true AND event=push

No two of the five executions differ in exactly one variable; the one pair that comes closest (bare
base vs bare head, tree) still differs in sequential machine state and scheduling, and in population
(3346 vs 3381). Nothing supports a product-defect ruling, and nothing supports closing it as a
flake. A classification that cannot be grounded is worth less than a recorded gap.

**THE GAP, NAMED:** all four diagnostic arms ran twohost=false; the record red ran twohost=true,
event=push. NO ARM TESTED THE RECORD'S OWN CONDITIONS. That is what the pair was for, and it is why
the set cannot close.

Standing rulings, independent of the classification: golden 34445961595 stands as the verdict of
record; release HELD and v0.69.0 NOT cleared; core#218 unmerged, no tag, no publish, no board work;
no budget widened — the ground for that is that widening changes the acceptance window and may mask
delay, which is measurable, not that it would "buy a green", which is not.

## Contention on the record red's Windows leg — REFUTED at job level (deployah, measured)
Timestamps from the jobs endpoint of run 34445961595, plus the one foreign run nobody had checked:

    test    (Windows, hfenduleam)  06:44:27Z -> 07:18:59Z  FAILURE   <- the red
    n1-gate (Windows, hfenduleam)  06:36:53Z -> 06:44:25Z  success   (ends 2 s before test starts)
    twohost-b                      07:19:02Z -> 07:36:16Z  failure   (starts 3 s after test ends)
    twohost-a                      07:48:07Z -> 08:13:18Z  failure
    ci 34446095808 unit (Windows, hfenduleam)  07:19:01Z -> 07:48:05Z  cancelled
        (same sha a9e786b2, pull_request; its RUN spans 06:38:13Z-07:48:06Z and overlaps the red's
         window, but its Windows JOB starts 2 s after the red ends)

ZERO GitHub jobs ran on hfenduleam during 06:44:27Z-07:18:59Z. Windows jobs across both runs abut by
2-3 seconds, i.e. they serialize.

SCOPE: this refutes GITHUB-JOB contention only. It says nothing about non-GitHub load on that box in
the window (local agent builds, Defender, an editor) and gh cannot see any of it — "the box was
busy" is NOT excluded; "another CI job was running" IS.

Structurally, the twohost INPUT could not have acted on the test job through concurrency in any
case: twohost-a/b are `needs: test` (golden.yml:1035, :1213) and materialize after it, and the test
job's own body (:88-810) contains no `inputs.twohost` reference — the only `twohost` strings there
are binary NAMES inside the HEAVY filter, present at either input value.

## Event is a controllable variable (deployah, measured)
golden.yml:7-15 at the sha triggers `push` on `branches: ['golden/**']`, and the record run was
event=push on `golden/crossnode-294`. On the push path the twohost jobs run unconditionally — the
guard is `!cancelled() && (github.event_name != 'workflow_dispatch' || inputs.twohost)`. So the
record's WORKFLOW CONFIGURATION (same sha, event=push, twohost job set, bare tree) is reproducible by
pushing the OBJECT to a new golden/** ref. This restores configuration, NOT prior machine state, and
is not claimed to classify anything.