---
name: kitsubito-wifi-only-quic-seam
description: "kitsubito's only live link is WIFI (ethernet NO-CARRIER) — the whole two-host QUIC seam and every CI clone ride it, and iface counters stay at zero while it degrades"
metadata: 
  node_type: memory
  type: project
  originSessionId: 42fe48b4-6e21-4b56-bd8d-3fff633a4b40
  modified: 2026-08-03T00:02:03.162Z
---

Measured 2026-08-02 during golden run 30771155390 triage: **kitsubito's only live link is `wlp2s0` (wifi). Its ethernet `enxa0cec8f89174` is `NO-CARRIER`.** Every GitHub clone the runner does AND the entire two-host QUIC seam over tailscale ride that wifi link.

**Why:** it makes a whole class of two-host golden reds environmental rather than product. In one degraded window that run showed: an untouched `actions/checkout` step at **321s vs 1s** at the green baseline six hours earlier, bidirectional `PUMP_PEER_FAIL … submit-dial exceeded the 10s bound (peer unresponsive)` (A→B at 23:37, B→A at 23:38-23:40), and three `no-seed-holder: connect failed: timed out` pairing retries. Green baseline had **0** connect-timeouts anywhere; counts went a: 0→3, b: 8→22.

**How to apply:** `ip -s link` shows **0 errors, 0 dropped** on that interface while this is happening — the failure is throughput/latency variance, which counters structurally cannot see. So never read "no iface errors" as "the network was fine." Before blaming a two-host red on product or on your own delta, check (a) the interface actually carrying the seam, (b) an UNWRAPPED, untouched step's duration against its baseline as a load control (the checkout is ideal — it is an action, not a `run:` step, so no workflow edit can reach it). The shared-runner quiet predicate in `docs/GOLDEN-CI.md` has **no network axis** — both its axes (zero non-terminal runs, no local cargo/rustc/nextest) can pass on a box whose link is degrading. A tailscale RTT probe to the peer box is the obvious missing instrument.

Second standing load on the same box, filed as releases#125: `spt daemon run` burning **195-210% CPU instantaneous, 3w+4d of CPU time over 14d15h elapsed** on a 16-core box — load average ~2.05 *is* that one process. It is a live fleet daemon (reavus's, with omp-spt api-listen children), **not yours to reap**, and diagnosis wants the spinning state intact for a stack sample before any restart. It predates the green baseline, so it is a CONSTANT across samples, not the variable — which is why it does not block dispatching a rerun.

Kin: [[cross-machine-test-rig]], [[linux-runner-migration]], [[a2-golden-r2-specimens]], [[one-sample-is-not-a-negative]].