UNI Universal Natural Intelligence

Wiki · Evidence & Verdicts

Receipt — THE ONE CHANGE: the off-monitor air alarm

Evidence & Verdicts · docs/receipts/air_alarm_the_one_change_2026-07-17.md @ 44baf03d5041 (gen2-runtime) — opens the published snapshot ac338733bbba

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 · viewer/hud/native/UNI.Hud.Widget Gate: air-alarm-annunciates — registered PENDING before the change.

Why

Every prior receipt and the 88-agent sweep ended on the same standing item: nothing in the studio reaches a human who is not reading pixels. The entire off-screen inventory was two systray balloons — one about an OBS dialog, one about a downed process — neither about air. A black program kills no process and opens no dialog, so if the world went dark while the operator stepped away, they found out from a viewer. The walk-away leg did not exist. This builds it — the last thing standing between "you can go live" and "you can stay live."

What it is

Built in the widget (Session-0 isolation forbids the service from playing sound or showing UI in the operator's session). The DECISION is the pure, unit-tested AlarmEngine; the widget owns the ANNUNCIATION.

  • ARM on the first fresh, MEASURED air.streaming == true. DISARM only on a fresh, measured streaming == false. Never disarm on UNKNOWN/stale — an alarm that goes quiet because it lost sight is fail-OPEN. (That is why BLIND is itself a firing code.)
  • FIRE — three codes, each a measured fact, each gated:
    • EGRESS COLLAPSE — streaming && egress.readers == 0, held 30s (readers == null never fires — a MediaMTX blip is silence, not a siren).
    • KEY REJECTED — a fanout.* health row ok:false on the D5 uniReady branch only (the row that says a platform is REJECTING while the ingest publishes — never the "YOUR KEY IS NOT IMPLICATED" no-publisher branch that is normal during ARM-before-CONFIRM).
    • BLIND — the snapshot stale (hud.stale, request-time) or the GET failed entirely.
  • ANNUNCIATE — red banner in its own always-visible grid row (cannot be scrolled away) + SystemSounds.Exclamation recurring while unacked + FlashWindowEx(FLASHW_ALL|FLASHW_TIMERNOFG) + tray balloon (once per code per episode).
  • ACK — one button per firing code: silences that code's sound for 10 min, auto-re-arms if it clears and recurs; never clears the badge, never disarms fan-out, never cuts, never acks a non-firing code. ANNUNCIATES ONLY — G-PA untouched.

Proof

The engine — 13 unit tests, rehearsed against regression

UNI.Hud.Widget.Tests (AlarmEngineTests) proves both halves. The false-alarm cases are the load-bearing ones: OffAir_IsSilent, ArmBeforeConfirm_IsSilent, ReadersNull_NeverFiresEgress, EgressCollapse_RequiresDwell, Unknown_DoesNotDisarm. The fire cases: EgressCollapse_Fires_AfterDwell, KeyRejected_Fires, Blind_Fires_WhileArmed. The ACK discipline: silences sound not badge, auto-expires, refuses a non-firing code.

Rehearsed against a deliberate regression — making a readers == null blip fire EgressCollapse:

Failed!  - Failed: 1, Passed: 34     (ReadersNull_NeverFiresEgress caught it)

restored → 35 / 35.

The wiring — LIVE, on the real widget

A mock served the widget a LIVE_LIVE, streaming=true, egress.readers=0, armed=2 snapshot (a live black push). After the 30s dwell the widget raised, at the very top, unmissable:

⚠ AIR ALARM — EGRESS COLLAPSE — live, but NOBODY is pulling the program [ ACK EgressCollapse ]

with the badge reading ● LIVE, the egress tile 0/2 · ingesting, but NOBODY is pulling it, the taskbar flashing and the tray ballooning (hud_alarm_firing.png). Restored to the real OFF-AIR service, the latch disarmed and the banner collapsed — silent when normal (hud_alarm_silent.png).

A crash I introduced and fixed (found the hard way)

Tearing down the mock restarted the real service, which serves hud.last_poll_age_ms: null before its first poll. The widget's TryPath2(...)?.GetInt64() (from the B4 footer work) only guards an ABSENT path, not a present-but-JSON-null value, so .GetInt64() threw InvalidOperationException — and in an async void timer tick that crashed the whole widget (Application event log APPCRASH, 12:15:40). The glance surface — the thing that exists to say when something is wrong — must never be the thing that dies. Fixed at source: null-safe NumL/NumI helpers over all ten numeric extractions in Refresh. Backstop: the tick is now wrapped so any future per-tick fault is swallowed-and-logged and the next tick retries. Redeployed widget stable 20s+ across the exact restart window that crashed it.

Verdict: PASS — the alarm fires on a measured dark air, stays silent off-air and through the ARM-before-CONFIRM window and a MediaMTX blip, and the surface no longer crashes on a null.

Fence / NOT VERIFIED

  • The on-REAL-air annunciation (a genuine dark platform during an actual broadcast) is exercised in WS-F — the mock proves the wiring, not a real show.
  • KEY REJECTED is an inference from a flapping pusher against a publishing ingest, not a measurement of the far end. Platform acceptance stays NOT VERIFIABLE locally.

sha256 fa3776f6e9ce75a5 — of the original file, so what was ingested stays checkable.

Plain — written for this website, not the source document

Written for this website — not the document. This is a plain-language retelling, written to help you meet the document. It is not the source, and it is not evidence. It has not yet been checked by a person. (or choose Precise in the reading-level control above)

A record of building the one thing that reaches a person who is not looking at the screen. Everything before it assumed somebody was reading pixels, so if the broadcast went dark while the operator stepped away, they would learn about it from a viewer. This adds an alarm that arms only on a measured live state, never goes quiet just because it lost sight, and fires on three measured conditions with a sound, a banner that cannot be scrolled away, and a flashing taskbar. Its gate was registered as pending before the change was made. It only raises the alarm. It never cuts, never stops anything, and never acknowledges a condition that is not firing.

Plain · written 2026-08-01 by claude-opus-5 · not yet checked by a person · about the document whose sha256 is fa3776f6e9ce75a5

Clear — written for this website, not the source document

Written for this website — not the document. This is a clearer retelling, written to help you meet the document. It is not the source, and it is not evidence. It has not yet been checked by a person. (or choose Precise in the reading-level control above)

A receipt for one change — the file recording what was run and what came out — and the page argues it is the change separating being able to go live from being able to stay live. Every earlier receipt ended on the same standing item: nothing in the studio reaches a person who is not reading pixels, and a black picture kills no process and opens no dialog.

The design splits the decision from the annunciation. The decision lives in a pure engine with unit tests; the widget owns the noise and the banner, because the background service cannot show anything in the operator's own session. The arming rule is the careful part. It arms on the first fresh, measured signal that the broadcast is live, and disarms only on a fresh, measured signal that it is not. It never disarms on a stale or unknown reading, because an alarm that goes quiet when it loses sight fails in the dangerous direction. Losing sight is itself one of the firing conditions.

Three conditions fire, each a measured fact with a guard against crying wolf. One requires the condition to hold for a dwell period, and deliberately does not fire when the reading is absent rather than zero, because a blip is silence and not a siren. Another is restricted to the branch that means a platform is refusing while the ingest is publishing, and excludes the branch that is normal in the window before the operator types the confirmation. The third is blindness itself.

Acknowledging is deliberately weak. It silences one code's sound for a while, re-arms if the condition clears and recurs, and never clears the badge, never stops the fan-out, never cuts, and never acknowledges a code that is not firing.

The proof has three parts. The engine's tests are listed by name, and the false-alarm ones are called the load-bearing cases. A deliberate regression that would let a blip fire was caught by exactly the test written for it, then restored. The wiring was exercised on the real widget against a mock serving a live-but-nobody-pulling snapshot, and after the dwell the banner, the sound, the flashing and the tray message all appeared, then went quiet when the real state returned.

Then a crash the author introduced and found the hard way. A value that was present but null threw inside a timer tick and took the whole widget down. The observation is the sharp one: the surface that exists to say when something is wrong must never be the thing that dies. It was fixed at source across every numeric read and given a backstop so that a future fault is logged and the next tick retries. The closing fence — the limit on what is claimed — names two things that are not verified. One is annunciation during a genuine broadcast. The other is that one of the three codes is an inference about the far end rather than a measurement of it.

Clear · written 2026-08-01 by claude-opus-5 · not yet checked by a person · about the document whose sha256 is fa3776f6e9ce75a5