# Arm 1 — bare base golden, releases#294 / v0.69.0 RCA

Preserved by deployah, 2026-09-10.

## What this is
Job log for `test (self-hosted, Linux, kitsubito)`, job id 102840703764, of golden run
**34467873057** — ARM 1 of the BARE pair.

- ref: `main`, headSha `de5a44bc338d679f3c63f6d0f68826eb9e575d73` (verified at the remote via
  `git ls-remote` AND on the run object before any result was read)
- event: `workflow_dispatch`, input `twohost=false`
- NO instrumentation, NO output-retention change, budgets UNCHANGED
- uncontended: every other run in the repo was terminal at dispatch (checked, not assumed)

## Why a bare arm exists
The earlier diagnostic pair (34458491560 head @1bd0a41d, 34462915181 base @1a7f7f55) BOTH carried
hertz's instrumentation plus suite-wide output retention. That is the clause that keeps the
baseline finding unlicensed. Identical treatment across arms controls the INPUT, never its EFFECT.

## What this log contains
- exactly ONE `Summary` line (checked: `grep -c Summary` = 1), so this is NOT the two-runs-in-one-log
  VOID shape
- `Summary [40.037s] 3325 tests run: 3324 passed (2 leaky), 1 failed, 1 skipped`
- `FLOOR_END job=test runner=Linux free_bytes=57795198976 verdict=PASS` — disk floor was not the cause
- the failing cell:
  `spt::io_events_undriven_kinds_e2e relay_backlog_and_live_deliveries_stamp_once_even_after_hook_poll`
  FAIL [2.412s] (48/3325), panic at `crates/spt/tests/io_events_undriven_kinds_e2e.rs:818:9`
  `left: [("MSG_IN", Some("alice"))]`
  `right: [("MSG_IN", Some("alice")), ("MSG_IN", Some("alice"))]`

## Scope of what the log establishes — read this before citing it
MEASURED: at assertion time the receiver's log held ONE entry where two were expected; the entry
present is the offline backlog message (msg-id RLBSWUSL).
NOT ESTABLISHED, and do not restate wider:
- that the live-delivery arm "did not publish" — delayed publication is not excluded by a snapshot
  taken at assertion time (todlando's narrowing)
- that the failure is timing-insensitive — a value mismatch distinguishes the failure SITE, not its
  timing sensitivity
- any classification at all: unregistered flake, environment/timing on kitsubito, and a real
  base-present defect ALL remain compatible with this observation. n=1, one leg, one arm.

NOT a registered flake — closed by POSITIVE READ, not by a zero: `flake-registry.json` is 1469 bytes
and holds exactly two entries (`spt::endpoint_lifecycle::zombie_claim_refuses_never_attaches`
/windows, `spt::activity_link_push_e2e::activity_frames_reach_a_linked_shell_through_the_real_daemon`
/linux). Neither is this cell.

NOT the carrier of the golden RED of record: run 34445961595 had `test (Linux)` GREEN. That red is
carried by `test (Windows)`.

## Retrieval note (craft)
Run-level `gh run view --log-failed` REFUSES while a run is in progress and **exits 0**, printing
"run ... is still in progress; logs will be available when it is complete" — an empty result with a
success code. The job-scoped endpoint works mid-run and is how this was pulled (todlando's route):

    gh api repos/BigscreenVR/spt-bs-core/actions/jobs/102840703764/logs

## Added after the fact: what a GREEN on this cell does and does not establish

Established in source by doyle at `de5a44bc`, corroborated by todlando, recorded here because it
changes how this arm may be compared to the instrumented pair.

The assertion at `:818` compares `(kind, author)` pairs, and both expected rows are
`("MSG_IN", Some("alice"))` — IDENTICAL. The assertion therefore cannot tell the backlog row from
the live row, and **two backlog rows would satisfy it**. The per-message identity needed to make it
exact-once already exists and is already carried (`publish_msg_io_local` stamps
`.with_msg_id(msg_id_of(body))` — the short id `RLBSWUSL` the failure panel itself printed).

CONSEQUENCE for arm comparison: the three PASSING executions of this cell
  instrumented base linux 3.612s · instrumented head linux 2.343s · instrumented head windows 16.411s
did NOT establish that both relay arms published. They established that two rows matching
`(MSG_IN, alice)` were present at read time. A green here is a weaker fact than it reads as.
The earlier sentence "both Linux legs were green across the instrumented pair" stays TRUE — it is a
statement about the ASSERTION's outcome, not about publication — but it must not be leaned on as
evidence that the underlying behaviour was correct.

This does NOT reclassify any run, does not make the bare red more likely to be a product defect,
and does not distinguish a read-too-early race from a genuine non-publication.

## Producer-side ordering (why the race is mechanically available on this path)

`MSG_IN` has exactly two production publish sites, with OPPOSITE orderings:

- **Path A — hook poll** (`crates/spt/src/api/delivery.rs`): `poll_drain()` publishes every row
  (:757) and returns them; its only caller `cmd_poll` (:660) then emits. PUBLICATION
  happens-before PRESENTATION. An immediate log read after observed presentation is
  contract-correct here, and a bounded retry WOULD conceal a real violation. Leave Path A alone.
- **Path B — the relay** (`crates/spt/src/api/startup.rs:1057`, the `deliver` closure): `emit(...)`
  (presentation) runs, then `publish_msg_io(...)` (publication), per message, in one closure.
  PRESENTATION happens-before PUBLICATION.

The failing assertion is about the RELAY arms, so Path B governs it. The test detects presentation
by reading the listener child's stdout through a pipe, then reads the log with no wait — so the read
can legitimately land between `emit` and `publish_msg_io`. The race is MECHANICALLY AVAILABLE.
Availability is not occurrence: one observation does not distinguish the race from a genuine
non-publication, and a timeout would establish "not published within the bound", never "never
publishes". IR-92 kinship remains open.

## Arm 1 TERMINAL — final scoring (added when the run completed)

Run **34467873057** conclusion **failure**, carried by `test (Linux)` ALONE.

| job | conclusion |
|---|---|
| traceability | success |
| changes | success |
| n1-gate (Windows) | success |
| n1-gate (Linux) | success |
| **test (Windows)** | **success** |
| **test (Linux)** | **failure** |
| notify | success |
| twohost-a / twohost-b | **skipped** (twohost=false, by design) |

Note the twohost legs are SKIPPED here, not the scored-VOID situation of golden 34445961595.

### Windows log — job 102840703747, retained beside this file

`grep -c Summary` = **2**, and that is NOT the two-runs-in-one-output VOID shape. The two Summaries
are the job's two PHASES, with different populations (3346 and 236). The VOID rule fires on a
REPEATED population, not on a count of the word.

    Phase A  Summary [ 786.355s] 3346 tests run: 3346 passed (6 slow, 5 leaky), 1 skipped
    Phase B  Summary [1382.417s]  236 tests run:  236 passed (2 slow), 0 skipped

**The two cells that carry the golden RED of record both EXECUTED and PASSED:**

    PASS [  91.375s] (1993/3346) spt-daemon::sync two_tier_sync_lands_and_gate_refuses_server_side
      (also flagged: SLOW [> 60.000s])
    PASS [  27.561s] (  36/3346) spt::contract_e2e live_agent_lifecycle_e2e

Both fall in Phase A, confirmed from the job's own HEAVY filter: the spt-daemon arm does not list
`sync`, the spt arm does not list `contract_e2e`.

### Comparisons that are and are not available

AVAILABLE: bare base Windows Phase A population is **3346**, identical to instrumented base Windows
Phase A (3346). Phase A totals: bare **786.355s** vs instrumented **731.767s** — the BARE arm is
SLOWER by 54.6s (~7.5%), the OPPOSITE direction from "instrumentation adds cost". NOT EXPLAINED:
scheduling, box state and order slot are uncontrolled, n=1 each. Phase totals do not isolate
instrumentation cost (todlando).

NOT AVAILABLE, and deliberately not computed: 91.375s is WHOLE-TEST WALL TIME; the expiring
executions reported ~10.17–10.20s of INTERNAL elapsed across 400/400 iterations. Different
quantities — no subtraction, no margin read from their difference. Same for 27.561s against the 30s
poll deadline.

### Scope of the arm

One bare arm, BASE tree `de5a44bc`, twohost=false, **uninstrumented SOURCE AND CONFIG** — machine
conditions are NOT restored (later run, differently-loaded box, different order slot). n=1, against
a cell with a known intermittent history (12/12 local pass at both shas; expired at BOTH arms of the
instrumented pair). It does NOT clear the candidate, does NOT classify golden 34445961595
(event=push, WITH twohost, HEAD tree), and is NOT release-gating.

### Sibling arm
Arm 2 = golden **34474627303**, ref `assembly/v0.69.0`, headSha `a9e786b2` (verified on the run
object), twohost=false, budgets unchanged. That is the arm that speaks to the HEAD tree.

## Independent verification and two cautions on the 54.6s

doyle pulled the same Windows job log separately and every figure above reproduces exactly
(2 Summary lines, both phase totals, both cell rows, the SLOW row on the sync cell, ZERO FAIL rows
in the job). Two extractors, one number set.

**Caution 1 — the 54.6s must not acquire a load story.** The bare arm is slower in TOTAL
(786.355s vs 731.767s, same 3346 population) but has FEWER SLOW CELLS: bare 6, instrumented base 9,
instrumented head 10 (head Summary [884.008s] 3381 tests, 10 slow, 8 leaky). Those quantities point
in OPPOSITE directions. Neither a slow-cell count nor a phase duration isolates contention
(todlando), and a phase total and a tail count need not move together. NOT reconciled: scheduling,
box state and order slot uncontrolled, one execution each.

**Caution 2 — why the 91.375s is not subtracted, in source terms.** A FAIL truncates that test AT
the poll: `wait_for_stream_except` is called at `sync.rs:201`, ahead of `serve_sync`, the puller
join, and every assert after it. So 91.375s PASSING is a COMPLETE execution while 48.129s and
53.457s FAILING are TRUNCATED ones — different spans, not comparable. This prevents ATTRIBUTING the
wall-time difference; it is NOT a prediction that a pass must be slower (todlando's narrowing of
doyle's "structurally expected").