Wiki · Evidence & Verdicts
Receipt — the HUD stops being green about things it cannot see
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-17 · Track: studio · Surface: THINKER · HUD service + widget + console Origin: the operator asked "why is the HUD missing on screen for all of this? HUD is not being observed presently and that is an issue." They were right, and the answer was not what I expected.
Gates: air-level-counts-program-picture, hud-health-above-the-fold, arm-refuses-zero-endpoints,
colony-frozen-needs-dwell-not-one-sample — all registered PENDING before the code moved.
hud-renders-stale-as-stale and hud-renderer-honesty remain PENDING (not done — see §7).
0. The finding behind the finding
The HUD was never missing. Service UNI-HUD = Running, Auto, NT AUTHORITY\NetworkService,
PID 2756, 12.5h uptime, 14,999 clean polls. Widget up since 11:23, window visible, docked right
at (3232,8)-(3832,1024), 53% painted. It had been telling the truth all day.
It was missing from the WORK. An entire fan-out honesty sweep (D1–D8) was proven through curl and isolated harnesses, and the surface the operator would actually glance at was never opened once. That is the same defect being fixed everywhere else in this repo — the truth existed somewhere nobody was looking — committed by the agent, against the HUD.
Everything in §1–§5 was found in the first twenty minutes of actually looking at it.
1. Two agent claims RETRACTED (both from asserting on a partial view)
- "The per-endpoint fan-out honesty doesn't reach the HUD." FALSE. Said from a screenshot
truncated by a scrollbar, without reading
RenderHealth(MainWindow.xaml.cs:462). The live snapshot carries 13 health rows, and arming fake keys put D5's row on the HUD verbatim:[RED] fanout.youtube_1 — FLAPPING … YOUR KEY IS NOT IMPLICATED.It reaches the HUD. - "A camera show turns the badge green when the camera collapses." OVERSTATED. My first truth
table omitted
audible. With the mic still live,audible=trueholds the old code atLIVE_LIVE(red). A camera collapse alone does not turn it green; only losing camera and mic does. The verified blocker is narrower and worse — see §2.
Four partial-view errors in one session, same shape each time. Recorded here rather than quietly corrected, because the pattern is the point.
2. BLOCKER — the hero badge measured the wrong thing (gate: air-level-counts-program-picture)
visible counts CAMS — human cameras only (command_center.cjs:60). The flagship shot is
COLONY: [["cap_colony", chromeFull], ["ShowMusic"]], whose own description reads *"the hero shot.
No camera."* (studio_stage.cjs:267). So the entire colony broadcast computed visible=false, audible=false → level STREAMING → the widget painted the 32pt badge green (Ok #2ECC71).
Byte-identical whether the world was rendering or the browser source had died to black. The badge carried zero picture information for the show we actually broadcast — and the same is true of MUSIC_HOUR and both STANDBY slates. Every camera-less show sat on permanent green.
The trap (cost three tries in the stage-3 sweep; the audit warned again)
"ovl_* is not picture" is WRONG: STANDBY: [["ovl_standby", F]] and MUSIC_HOUR: [..., ["ovl_music_hero", F], ...] — the slate and the full-screen music card are ovl_ sources and
are the picture. That rule would fire the alarm through every standby and the whole music
segment. The honest line is studio_stage.cjs's own construction rule (:325-330): each scene
declares its content, then chrome is appended to every scene afterwards. Chrome is a closed,
known set. So: content = enabled program sources − chrome − audio-only.
Proven against the REAL scene table
===== streaming = true =====
scene | OLD | NEW
COLONY | STREAMING (GREEN!) | LIVE_LIVE (RED tally)
COLONY_dead | STREAMING (GREEN!) | STREAMING_DARK (RED alarm)
TRIO | LIVE_LIVE (RED) | LIVE_LIVE (RED tally)
TRIO_camdead | LIVE_LIVE (RED) | STREAMING_DARK (RED alarm)
MUSIC_HOUR | STREAMING (GREEN!) | LIVE_LIVE (RED tally)
STANDBY | STREAMING (GREEN!) | LIVE_LIVE (RED tally)
STANDBY_OFFLINE | STREAMING (GREEN!) | LIVE_LIVE (RED tally)
MUSIC_CARD | LIVE_LIVE (RED) | LIVE_LIVE (RED tally)
colony world dies OLD STREAMING->STREAMING (GREEN!) NEW LIVE_LIVE->STREAMING_DARK (RED alarm)
cameras collapse OLD LIVE_LIVE->LIVE_LIVE NEW LIVE_LIVE->STREAMING_DARK (RED alarm)
A regression I shipped and the live surface caught within a minute
The first cut keyed both branches off picture. Idle OBS sits on the STANDBY slate; the slate IS a picture; so the badge read amber REHEARSAL forever on an idle studio. That drains REHEARSAL of the meaning it has always had (talent up, air down) and paints caution permanently — an amber that is always on is not a caution. Only the streaming branch may change:
streaming -> turns on PICTURE (the defect: a dark push must never read green)
!streaming -> turns on PEOPLE (unchanged: REHEARSAL means humans up, air down)
Re-proven across both streaming states: streaming=false rows are now identical OLD vs NEW, and
idle reads OFF (grey). Live confirmation: level=OFF, pictureOnProgram=true, sources=["ovl_standby"].
FENCE — say it exactly: this is source-enablement, not pixels. pictureOnProgram means "a
picture-bearing source is enabled on program", NOT "there is a picture". A cap_colony that is
enabled but rendering black still reads true. The studio owns a real pixel classifier
(probeRenderFrac / RENDER_MIN_FRAC, command_center.cjs:642) and it is NOT wired here — a
GetSourceScreenshot on every 3s tick is a cost that needs its own measurement first. Until then
"there is a picture" stays NOT VERIFIED, and the note carried to the operator says so in words.
Verdict: PASS, with that fence.
3. The fix could have evaporated silently between two processes
SnapshotBuilder.BuildAir enumerates fields; it does not splat. A new console field is dropped
on the floor unless someone adds a line — no error, no warning. Four tests now pin the crossing, and
they were rehearsed against failure: removing the passthrough line produced
Failed! - Failed: 3, Passed: 44
and restoring it produced Passed! - 47. A test that has never failed proves nothing (c937ab4).
4. FALSE ALARM found by LOOKING — the colony was never frozen (gate: colony-frozen-needs-dwell-not-one-sample)
At 05:11 the rebuilt HUD printed, in red:
COLONY frames/s 0.0 · FROZEN — frame not advancing
The colony was fine. Its own health, probed twice 6s apart:
frame=33718 verdict=LIVE driver=producer colony_count=6
frame=33720 verdict=LIVE driver=producer colony_count=6
0.33 fps, advancing. Cause: aliasing. Rate() (PollWorker.cs:256) differences one
consecutive pair; the colony advances ~1 frame per ~3s against a 3.0s poll, so the sample
interval equals the event interval and a Δ of 0 is noise, not a frozen mind. A perfectly healthy
colony flickers into a red alarm forever — and the false-alarm leg was the one thing this HUD
had genuinely earned.
Fix: the rate is still shown (a real magnitude) but may no longer convict. FROZEN is
dwell-gated on colony.frame_stalled_ms — wall clock since the counter last actually moved — which
is immune to the tick rate. 30s ≈ 10 expected frame intervals here.
Proof, 12 samples over ~36s on the live colony:
rate= 0.67 stalled= 1806ms verdict=advancing
rate= 0.33 stalled= 2073ms verdict=advancing
... (12/12) ...
rate= 0.33 stalled= 1468ms verdict=advancing
Never FROZEN; stall never exceeded 3.0s. Verdict: PASS.
5. Fold order is a safety property (gate: hud-health-above-the-fold)
BROADCAST HEALTH — the only panel on the surface that can name a broadcast fault, and the one
carrying the per-endpoint fan-out rows — rendered fifth, behind a 14-card NOC grid and 9 Gaia
seats, ~600px below a 600×1016 dock. Nothing above the fold cued the scroll, because the badge,
ARMED (N), EGRESS and STACK: UP are all invariant to a dark platform.
Worse, the panel outranking it is static prose: predict() (door_lifecycle.cjs:145-158) is a
string lookup on (key, open, streaming). The tile promises "if killed: door_watchdog reopens it
in <=5s" and probes nothing. (Checked live: the watchdogs ARE running — PID 24204, 24128,
11080 — so the promise is true today by luck, not by measurement. If the watchdog died the tile
would keep promising a rescue nobody is coming to perform.) Unmeasured reassurance outranked
measured fault.
Health now renders directly under the mixer. Live capture confirms BROADCAST HEALTH — 11 ok · 2 failing with ✕ cam1 / ✕ cam2 in red above the fold, no scroll. Verdict: PASS.
Also fixed there: the id column was a fixed 96px and clipped — the live surface read
restrea, overloo, colonyc. A truncated identifier on the panel just promoted to prime real
estate breaks the wrap-don't-truncate law (4cb0205). Now a SharedSizeGroup sizes the column to
the longest id across rows and keeps them aligned — it grows with the data instead of guessing a
pixel count that rots when a check is added.
6. ARM could silently succeed at nothing (gate: arm-refuses-zero-endpoints)
endpoints_store.load() returns {endpoints:[]} for a missing file rather than throwing, so
startFanout() filtered to [], looped zero times, and returned {ok:true, count:0} — HTTP 200,
no error, the widget's error branch never fires, the button re-enables, and the operator believes
they armed something.
POST /api/fanout {on:true}
{"ok":false,"err":"NOT ARMED: there are no saved endpoints — nothing would push. Add your
YouTube/Twitch keys in the console (Streaming Endpoints), then arm."}
HTTP 409
Verdict: PASS. Also landed: pinOrphan/pinNote (D2's whole deliverable) were computed and
shipped by the console, rendered on the console panel, and dropped by the widget — the surface
that exists so the operator does not open the console at 02:40. It now renders red and disables
ARM, because a button whose only possible outcome is a failure seconds before air should not be
offered.
7. What is NOT done — do not read this as green
- THE ONE CHANGE (blocker #2) is NOT BUILT. There is still no air alarm anywhere in the
studio. Grep for
ShowBalloonTip|SoundPlayer|MediaPlayer|FlashWindow|Notificationacross both HUD binaries: zero hits. The entire off-screen inventory remains two balloon tips (systray_watchdog.ps1:240,265) about an OBS dialog and a downed process — neither about air. A black program kills no process and opens no dialog. Nothing reaches a human who is not reading pixels. The walk-away leg does not exist. Blocker #1 was fixed first on purpose: an alarm built on the oldvisiblewould have screamed through the entire flagship show. hud-renders-stale-as-stale— PENDING.LastOf(MainWindow.xaml.cs:246) still scans 120 slots × 3s = 6 minutes backwards for the last non-null and returns no age. A 6-minute-old colony number can still render as a confident green.hud-renderer-honesty— PENDING. The widget still has zero tests; the whole suite covers the service. Every renderer fix above lands untested. No green claim about the renderer is permitted until this gate exists.- Platform acceptance — NOT VERIFIED. Nothing local proves YouTube/Twitch took the push.
- Picture on program — NOT VERIFIED. §2's fence: source-enablement is not pixels.
- Supervisor liveness — NOT VERIFIED. The
<=5sdoor promise is design intent with a decimal point on it. commit ?in the footer — the HUD still cannot name its own bytes.- A cc restart still silently disarms the fan-out (
epMemis in-process); the HUD does not yet distinguish "you disarmed" from "the console died and dropped your arming".
8. Sweep provenance
88 agents, 6 adversarial lenses, every finding independently refuted before it counted:
37 confirmed / 43 refuted, 3 blockers. Verdict HOLD — 5 of 8 gauntlet legs FAIL. Notably
nine of the refuted claims died because their proposed fixes would have broken the false-alarm
leg — the discipline held in both directions. Workflow wf_05f618f6-7f8.
sha256 81b982932594fe9a — of the original file, so what was ingested stays checkable.
Plain — written for this website, not the source document
A record that begins by finding the operator's complaint right for a different reason than expected. The display had not been missing; it had been running all day. What was missing was anyone looking at it, and everything on this page was found in the first twenty minutes of actually looking. The main defect is that the headline badge counted human cameras. So the flagship shot, which has no camera by design, sat on permanent green whether the world was rendering or had gone black. The badge does not look at pixels at all.
Plain · written 2026-08-01 by claude-opus-5 · not yet checked by a person · about the document whose sha256 is 81b982932594fe9a
Clear — written for this website, not the source document
A receipt, the file recording what was run, that opens with the operator's question and says he was right, though not for the reason expected. The service had been running all day with a long uptime and thousands of clean polls, and the widget was visible on screen the whole time.
What was missing was the work looking at it. An entire honesty sweep had been proven through command-line probes and isolated harnesses, while the surface an operator would actually glance at was never opened once. The page names that as the same defect being fixed everywhere else in the repository: the truth existed somewhere nobody was looking. Everything that follows was found in the first twenty minutes of looking.
Two of the agent's own claims are retracted before any fix is described, both from asserting on a partial view: one from a screenshot cut off by a scrollbar, and one from a truth table that omitted a variable. The page records four such errors in one session and says the pattern is the point.
The blocker is that the headline badge measured the wrong thing. It counted human cameras, and the flagship shot has no camera, as its own description says. So the whole broadcast computed as having neither picture nor sound, which painted the badge green, byte-identical whether the world was rendering or had died to black. Every camera-less show sat on permanent green.
One trap is described because it had already cost several attempts elsewhere. The tempting rule about which sources count as picture is wrong, since a slate and a full-screen card are picture too, and using it would fire the alarm through every standby and the whole music segment. The honest line comes from the way scenes are built: each declares its content, and chrome is appended to every scene afterwards, so content is what remains once the known chrome and the audio-only sources are removed.
A table proves the new behaviour against the real scene list, showing which cases turn from a confident green into either an ordinary tally or an alarm.
Then a regression the author shipped and the live surface caught within a minute. Keying both branches off picture made an idle studio read caution forever, which drains the meaning from a state that has always meant people up and air down. The fix restricts the change to the streaming branch only, and states the principle: a caution that is always on is not a caution.
A limit is then stated exactly, and it matters. This measures whether a picture-bearing source is enabled, not whether there are pixels. A source enabled but rendering black still reads true. A real pixel classifier exists elsewhere and is deliberately not wired in here, because sampling on every tick is a cost that needs measuring first, so having a picture stays not verified.
The residuals list several things as not verified rather than green, including a renderer with no tests at all, where the page repeats its own rule that no green claim about it is permitted until that gate exists. The provenance section records that the sweep refuted more findings than it confirmed, and that several refutations survived because the proposed fixes would have broken the false-alarm case, which is the discipline holding in both directions.
Clear · written 2026-08-01 by claude-opus-5 · not yet checked by a person · about the document whose sha256 is 81b982932594fe9a