Wiki · Evidence & Verdicts
Receipt — the overlay gate is scene-aware (stops crying wolf on music scenes)
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-19 · Track: studio · Surface: THINKER · Class: A (independently reproduced,
failure rehearsed both directions on the live program)
Gate: overlays-up — behaviour corrected, not loosened.
The defect
viewer/verify_overlays.cjs hard-coded ONE expected list:
const REQUIRED = ["ovl_lower3rd", "ovl_ticker", "ovl_caption", "ovl_onair"];
and asserted it against whatever scene was on program. But the stage does not put the same chrome on
every template (viewer/studio_stage.cjs): music scenes deliberately DROP the duplicate now-playing
chrome (hero card + lower-third + corner chip all said the same track), STANDBY carries only its
slate, and MUSIC_CARD has a bespoke set. So on 2026-07-19, live on air, the gate reported:
OVERLAY PROOF: FAIL — source 'ovl_lower3rd' is NOT in program scene 'COLONY_SIDE_MUSIC'
— stage never built (run studio_stage.cjs)
The stage was built correctly and the overlays were airing correctly. The gate was wrong, and its advice ("run studio_stage.cjs") would have rebuilt every scene and cut program to COLONY mid-show. A gate that cries wolf on a healthy system is worse than no gate: it trains the operator to ignore it, and here it also pointed at a destructive remedy.
The fix
The expectation now comes from the module that BUILDS the scenes, so the two cannot drift:
studio_stage.cjsexportsexpectedOverlaysFor(sceneName), derived from the BUILTSCENESobject (so appended music chrome and voice anchors are accounted for). Items declareddisabled: trueare excluded —ovl_lyricsis created intentionally dark onMUSIC_HOURand must not be demanded.- Unknown scene returns
nulland the gate FAILS honestly rather than silently passing. verify_overlays.cjsasks for the current scene's declared set and verifies present + enabled + pointing at127.0.0.1:8099.- Overlays enabled but NOT declared for the scene are reported as a NOTE, not a failure —
ovl_lyricsis a documented per-segment operator choice. Surfaced anyway, because a stale lower-third bleeding onto a music scene is a defect this project has shipped before.
Load-bearing safety detail: studio_stage.cjs ran its OBS-mutating half unguarded at require
time — connecting to OBS, rebuilding every scene, and ending with
SetCurrentProgramScene {sceneName:"COLONY"}. Requiring it for its policy would have cut the live
program. It is now guarded by a top-level if (require.main !== module) return; (legal in CommonJS,
smallest possible guard, no reindentation, no behaviour change when run directly).
Proof
Resolution is correct per scene type (require returned in 284 ms; a real build takes many seconds):
COLONY_SIDE_MUSIC -> ["ovl_music_card","ovl_watermark","ovl_onair"]
COLONY -> ["ovl_watermark","ovl_musicbug","ovl_nowplaying","ovl_lower3rd","ovl_caption","ovl_ticker","ovl_onair"]
MUSIC_HOUR -> ["ovl_music_hero","ovl_watermark","ovl_onair"] (ovl_lyrics excluded: declared disabled)
MUSIC_CARD -> ["ovl_music_card","ovl_watermark","ovl_lower3rd","ovl_onair"]
STANDBY -> ["ovl_standby"]
NO_SUCH_SCENE -> null (gate fails honestly)
Guard proven inert: program scene read BEFORE require = COLONY_SIDE_MUSIC; AFTER require =
COLONY_SIDE_MUSIC. No rebuild, no cut.
Gate on the exact case that falsely failed — now PASS:
OVERLAY PROOF: PASS — scene 'COLONY_SIDE_MUSIC' carries ovl_music_card/ovl_watermark/ovl_onair
(enabled, -> 127.0.0.1:8099); state.json updatedUtc=2026-07-19T07:13:22.975Z
It also wrote a REAL 576,066-byte proof, replacing a 22,289-byte near-blank failed capture.
Failure rehearsed BOTH directions on the live program (a test that never failed proves nothing):
disable ovl_watermark -> OVERLAY PROOF: FAIL — source 'ovl_watermark' present but DISABLED
in 'COLONY_SIDE_MUSIC' exit=1
re-enable -> OVERLAY PROOF: PASS exit=0
Air unaffected throughout: uni ready, readers=2.
Honest scope
This corrects the gate's EXPECTATION, it does not weaken it. Every previously-checked property is
still checked (present, enabled, URL points at the overlay server, state.json parses, screenshot
written) — they are simply checked against the set the scene actually declares. A scene that drops a
declared overlay still fails, as rehearsed above.
sha256 d186a143ef381080 — of the original file, so what was ingested stays checkable.
Plain — written for this website, not the source document
A record of a check that failed while nothing was actually wrong. It demanded the same four overlays on every scene, but the stage deliberately puts different chrome on different scenes, so a music scene made it cry wolf while the show was on air. Worse, the advice it printed would have rebuilt every scene and cut the live programme. The fix has the expectation derived from the module that builds the scenes, so the two cannot drift apart. The page is careful to say the check was corrected rather than loosened, and it rehearses the failure in both directions.
Plain · written 2026-08-01 by claude-opus-5 · not yet checked by a person · about the document whose sha256 is d186a143ef381080
Clear — written for this website, not the source document
A receipt — the file recording what was run — about a check that was wrong while the system was right, which the page argues is worse than having no check at all. It teaches the operator to ignore the check, and in this case the remedy it suggested was destructive.
The defect is small and clear. One hard-coded list of expected overlays was asserted against whatever scene happened to be on air, but the stage deliberately drops duplicate chrome on music scenes, gives one scene only its slate, and gives another a bespoke set. So on air the check reported a missing source and advised rebuilding the stage, which would have rebuilt every scene and cut the programme to a different one mid-show.
The fix moves the expectation into the module that builds the scenes, so that the two cannot drift. That module now reports the expected set for a given scene, derived from what it actually built, and excludes items it deliberately creates dark. An unknown scene returns nothing and the check fails honestly rather than passing by accident. Overlays that are on but not declared for the scene are reported as a note rather than a failure. The page explains why they are surfaced at all: a stale overlay bleeding onto a music scene is a defect this project has shipped before.
One safety detail is called load-bearing and earns it. The module being imported for its policy also ran its live-mutating half at import time, ending by switching the programme scene. Importing it would have cut the show. It is now behind the smallest possible guard, and the receipt records the programme scene before and after the import to show the guard is inert.
The proof lists the resolved set per scene type, shows the previously failing case now passing, and notes that a real capture replaced a near-blank one. The failure is then rehearsed in both directions on the live programme, disabling an overlay to get a red result and re-enabling it to get a green one, with the air unaffected throughout. The closing scope is explicit: every property checked before is still checked, only now against the set the scene declares.
Clear · written 2026-08-01 by claude-opus-5 · not yet checked by a person · about the document whose sha256 is d186a143ef381080