Wiki · Evidence & Verdicts
Receipt — the off-box relay probe is TTL-cached (kills node2 log/NVMe churn at the source)
[redacted: category] — 2 private address. Nothing else was altered. The document is otherwise exactly as it is written in the repository, and the sha256 below is of the original, so what was ingested stays checkable.How to read this page
Three ways to read this page. Precise is the document itself, exactly as it is written in the repository. Plain and Clear were written for this website to help you meet that document — they are about it. They are not it, and they are not evidence.
Eighty-seven dated pages: receipts, pre-registrations, handoffs, validation records and review verdicts. A receipt is written at the moment a piece of work was checked. It names what was claimed, the commit and the seed, what was actually run, and the outcome in one of a small set of controlled words. Then it names what the work did not achieve. That last part is what makes it a receipt rather than an announcement. A pre-registration is the same discipline run in advance: the conditions that would count as a pass and the conditions that would falsify the claim are written down before the run, so neither can be adjusted once the numbers arrive.
That is why so many small dated stubs are an audit trail rather than noise. No one of them is meant to be a good read. The value is in the sequence and in the dates, because you can watch a prediction be registered, then the run happen, then the verdict land — sometimes against the prediction. Pages here record a falsified result, a rejected fix, a retracted overclaim, and a green receipt that turned out not to be reproducible from the commit that carried it. A record that carried only successes would be worth a good deal less than this one.
A gentle way in is to read a pre-registration first, so the shape becomes familiar, then a result page, then one of the corrections. This section sits off the main navigation on purpose: it is the record you check the rest of the site against, not the place to begin.
What it is not: documentation, and not a summary. Nothing here has been tidied in hindsight. Every entry reads as of its date, a later entry may overturn an earlier one, and the presence of a page is not a claim that its result stood.
Your browser cannot switch reading levels, so the document itself is shown.
Precise — the source document
This is the document. Rendered from the repository at the commit above, with nothing rewritten for the web. A gate re-renders it on every deploy and fails the build if a single byte differs.
Date: 2026-07-29 · Track: studio · Surface: THINKER · Class: A (measured before/after + unit-tested coalescing). Found by the node2 agent; the SOURCE was on THINKER, this box.
The defect
Every launcher endpoint that reports the fan-out relay opened a FRESH TCP socket to node2:1935 on every poll, uncached:
launcher.cjsmission() — therelaytile (tcp(NODE2_LAN,1935)inside the /api/mission Promise.all)door_lifecycle.cjs— therelaydoor probeinfra.cjs— node2 reachability
Two independent pollers hit those endpoints continuously: the Door page (/api/mission + /api/door/state
every 3s) AND the HUD service (PollWorker.cs: mission 3s, door_state 2.5s). Net: ~1.6 connect+close/sec
to node2:1935, measured (new local ports to [redacted: private-address]:1935 over a 10s window). node2's mediamtx
logged each as an accepted-then-dropped connection — ~112k lines/day, 26.8% of node2's journal, written
to the very NVMe whose wear is being watched. The node2 agent correctly identified that node2 was only
recording it; the source was THINKER.
The fix
probes.cjs gains cachedTcp(host, port, {ttlMs, timeout}) — a process-shared, stale-while-revalidate
wrapper over tcp(), keyed by host:port. It serves the last value immediately and runs at most ONE
background refresh per ttlMs, coalescing all concurrent callers. All three relay sites route through it
with ttlMs: 8000. Because the key is shared process-wide, the ENTIRE launcher process opens at most one
node2 socket per 8s window regardless of endpoint or poller count. tcp() itself is unchanged and still
used for the cheap loopback probes, where freshness matters and there is no churn cost.
Semantics preserved: node2 up/down is still reflected within 8s. A health TILE does not need sub-second relay liveness, and go-live is proven by the publish attempt (and human-typed CONFIRM), not this probe.
Proof
- Unit test (throwaway TCP server counting accepted connections): 20 concurrent callers in one window → 1 socket; +1 caller after TTL → exactly 1 refresh; +10 concurrent in the new window → 0 new (served from cache); returned value correct (true when server up).
- Live before/after (new ports to [redacted: private-address]:1935 per unit time, on air):
- BEFORE: 14 in 10s → ~1.4/sec
- AFTER (launcher restarted onto the new code): 2 in 20s → ~0.1/sec — a ~14× reduction, the ~1-per-8s floor.
- Relay tile still reads
up=true("port reachable (NOT proof it forwards)") — signal intact. - Air untouched by the launcher restart: egress
uniready readers=2, fanout armed aliveCount=2; :8090/:8096/:8100 all back up (door_watchdog respawn).
Note for node2
The spam SOURCE is now gone, so node2 can safely return to logLevel: info for full visibility if
desired — at ~0.1/sec the connection log is no longer a write-amplification problem. The earlier
info→warn change on node2 remains a valid independent choice; it is no longer load-bearing.
sha256 d8a3d09cfdd2866f — of the original file, so what was ingested stays checkable.
Plain — written for this website, not the source document
A short record of a fix and the measurements either side of it. A status tile on one machine opened a fresh connection to another machine every time anyone looked at it, and two separate pollers were looking constantly. The far machine dutifully logged every one of those connections, which filled a large share of its log and kept writing to a drive whose wear is being watched. The fix serves a cached answer for a few seconds and shares it between everyone asking, so the whole process opens at most one connection per window. A health tile does not need a fresher answer than that, and the rate before and after was measured.
Plain · written 2026-08-01 by claude-opus-5 · not yet checked by a person · about the document whose sha256 is d8a3d09cfdd2866f
Clear — written for this website, not the source document
This is a receipt — the file recording what was run — for a defect, its fix, and the measurement of both. What makes it worth reading is where the defect turned out to live. It was found by the agent on the machine that was suffering, but the cause sat on the other machine, the one doing the asking. The far machine was only recording it.
The defect: three separate endpoints each opened a fresh connection to check whether a relay port was reachable, with no caching, and two independent pollers hit those endpoints every few seconds. That came to more than one connect-and-close every second, and the far end logged each as an accepted-then-dropped connection, which grew into a large fraction of its journal and a steady write load on the drive being watched.
The fix is a shared wrapper that serves the last known answer immediately and runs at most one background refresh per window, keyed so that every caller in the process shares one. All three sites route through it. The plain check is left alone for the cheap local probes, where freshness matters and there is no cost to it. The page states what the change gives up: reachability is now reflected within the window rather than instantly. It argues a health tile does not need liveness faster than that, since going on air is settled by the publish attempt and a human typing a confirmation, not by this probe.
The proof has two halves. A unit test against a throwaway server counts sockets: many concurrent callers inside one window produce one socket, a caller after the window produces exactly one refresh, and more callers inside the new window produce none. Then a live before-and-after count of new connections over time, on air, showing the rate falling to the expected floor. The tile still reads the same, and its meaning is quoted, including the part saying a reachable port is not evidence that anything is being forwarded. A closing note tells the other machine's agent that the source of the noise is gone, so a mitigation made there is no longer load-bearing.
Clear · written 2026-08-01 by claude-opus-5 · not yet checked by a person · about the document whose sha256 is d8a3d09cfdd2866f