Estate

Twenty-four drifts, and the worst of them are on air right now. The single highest-blast finding is that viewer/channels.json — the contract obs_stage.cjs binds OBS window-capture sources against — declares THREE capture windows and only ONE exists: ch_glass (Chrome PID 49868) is alive, ch_colony and ch_overlook are gone, and zero chrome.exe on this box carries --remote-debugging-port. Every OBS scene that captures the colony or the overlook is bound to a window title that no longer exists, and a window capture of a missing window renders black with no error anywhere. Second: the colony camera's health check is TCP-connect-only (door_healer.cjs:69) against a socat forwarder that the lab measured accepting a client per second, logging "successfully connected", then EOFing both directions in the same journal second with zero bytes moved — the greenest possible probe over the emptiest possible pipe. Third: two live servers are running bytes older than the commits that changed them — publisher.cjs (PID 40356, started 01:40:10; last commit f67a5d7 at 09:05:22, ~7h25m behind) owns the LAN-wide HTTPS gateway [redacted: port], and track_server.cjs (PID 30176, started 09:29:47; last commit e0163b8 at 09:39:33) is the operator surface. The gate written for exactly this, build-identity, is ci:true and was not run. Fourth, and public: the committed and deployed content/generated/live_status.json still says "The operator has not declared a watch URL, so none is published" while he is live on YouTube and Twitch; the fix exists only in an uncommitted working-tree file. I also verified what is NOT drifting, because that matters: gates.ndjson is exactly 207 rows at sha256 1daac9124c0ce483…4ee1, the control-plane ledger is 32 entries with anchor head b90b7498… length 32 in agreement, the plan is 7 stages / 43 steps / 31 DONE / 1 IN_PROGRESS / 1 BLOCKED / 8 PLANNED / 2 OPERATOR, next_act is CHECKPOINT-E, and the Checkpoint-E surface is genuinely live and correct — /lab/l6 returns 9005 bytes and the two shots return 3371 and 3375 bytes exactly as the banner claims. Only the gates block is stale, by one: 36 registered / 33 ci:true measured against a generated block that says 35 / 32, in all three declared copies. Two corrections to my own working hypotheses, said before the findings that survived them: /hud returning 404 on [redacted: port] is BY DESIGN (launcher.cjs:342 says so explicitly — the HUD is a native WPF widget, not a webpage), and voice_server.cjs IS running (PID 28628 on [redacted: internal address][redacted: port], /healthz 200) — my first process filter missed it because it was launched with cwd=viewer and no path prefix. Nothing was started, stopped, killed or edited; no file outside the evidence path was written.

minecraft 1 repo

flagellum 3 repos

public 1 repo

architect 10 repos

builder-and-rest 4 repos

studio-box (this Windows 11 Pro 10.0.26200 box; hostname not separately measured) reachable

uni-lab ([redacted: internal address], mesh id "uni-lab", self/local box for the uni-lab MCP; hostname reported "uni-lab") reachable

fleet-peers (probed from uni-lab / [redacted: internal address], the router box, via mcp__uni-lab__*) not reachable

channels.json declares three capture windows; one exists — the colony and overlook OBS sources are bound to windows that are gone silent A · probed

Kind: file-claims-launch-but-not-running

Claim. viewer/channels.json (mtime 2026-08-02T10:30:00) = {"colony":"Prismarine Viewer","glass":"UNI Glass Cockpit","overlook":"Stratified Palimpsest — Overlooker"}. obs_stage.cjs:17 reads this file and targets OBS window-capture sources by those EXACT titles. studio_channels.ps1:53-59 launches all three (ch_colony with --remote-debugging-port=9220, ch_glass, ch_overlook with --remote-debugging-port=9221).

Reality. Only ch_glass exists — chrome.exe PID 49868, --app=[redacted: internal host].local/glass/ --user-data-dir=...\Temp\ch_glass. No process carries user-data-dir ch_colony or ch_overlook. Measured: (Get-CimInstance Win32_Process -Filter "Name='chrome.exe'" | Where CommandLine -match 'remote-debugging-port').Count = 0. CDP 9220 and 9221 therefore have no listener, consistent with the earlier netstat finding that 9220 is DOWN.

What breaks. Every OBS scene whose source is a window capture of the colony or the overlook — COLONY, COLONY_SIDE, COLONY_SIDE_MUSIC, OVERLOOK, DUAL_WORLD and any composite that includes them (37 scenes exist; the program scene was TRIO earlier and is CAM_A now). Cutting to any of them puts a black or frozen frame on a live stream that has pushed 8.12 GB. Also kills throttle_colony.cjs, which needs CDP 9220 to cap the colony render loop.

[redacted: local path] ; [redacted: local path] ; [redacted: local path]

The colony camera's liveness check is TCP-connect-only against a forwarder that accepts and immediately EOFs silent A · probed

Kind: healthy-report-empty-payload

Claim. viewer/door_healer.cjs:69 — `const [colonyCam, phoenix, producer] = await Promise.all([tcp(COLONY_NAME, 3020, 2000), tcp(COLONY_NAME, 4000, 2000), tcp(COLONY_NAME, 4200, 2000)]);` — a bare TCP connect decides whether the colony camera is healthy. door_healer.cjs:112 only raises a gap when the connect itself fails.

Reality. On the lab, host [redacted: port] is a rootless podman publish into container uni-viewer-cam-fwd running socat. Its journal shows, per client and roughly once a second: 'successfully connected' to uni-producer:3020, then 'socket 1 (fd 6) is at EOF', 'socket 2 (fd 5) is at EOF', 'exiting with status 0' — all inside the same journal second, zero bytes transferred. `ss -tnp state established` for sport/dport [redacted: port] returned an EMPTY table: no connection survives long enough to be caught. The upstream producer is restart-looping (container-uni-producer.service NRestarts=24, fresh pid 2945038 born 16:34:58.965Z replacing 2935417 which no longer exists), and each incarnation needs ~3-5 s from container start to '[director] spawned; camera on [redacted: port]'.

What breaks. The Door ([redacted: port] /api/status — the call CLAUDE.md declares binding for any agent's state question) and every downstream surface report the colony camera healthy while it delivers nothing to any client. A TCP probe against socat cannot ever go red. Two independent measurements of the same port disagree (see the S7 stop), and neither the Door nor Gaia can express that.

[redacted: local path],112 ; lab unit container-uni-viewer-cam-fwd.service ; lab unit container-uni-producer.service

Two live servers are executing bytes older than the commits that changed them — including the LAN-wide HTTPS gateway and the operator surface silent A · probed

Kind: stale-running-image

Claim. viewer/gate_registry.json registers `build-identity` -> viewer/verify_build_identity.cjs, ci:true, gate_row=boot-identity — 'running bytes match committed bytes'. Both files are clean in git status, i.e. disk == HEAD.

Reality. publisher.cjs: PID 40356 started 2026-08-02 01:40:10; the last commit touching viewer/publisher.cjs is f67a5d7 at 2026-08-02T09:05:22-05:00, and the file mtime is 08:54:45 — the running process loaded its source about 7h25m before the source last changed. track_server.cjs: PID 30176 started 2026-08-02 09:29:47; last commit e0163b8 at 2026-08-02T09:39:33-05:00, mtime 09:35:17 — running ~10 minutes behind. `git diff --stat HEAD` on both is empty, so disk matches HEAD and only the loaded image is behind. The build-identity gate was NOT run (ground rules forbid it).

What breaks. publisher.cjs owns the LAN/tailnet-reachable HTTPS source gateway on [redacted: internal address][redacted: port] (36,197 bytes served) and the loopback registration endpoint [redacted: port] — a security- or routing-relevant change committed at 09:05 is not in effect. track_server.cjs is UNI TRACK, the operator's persistent surface that renders phase9_plan.json live; the operator is reading a build from before its last fix. Anyone reading TRACK believes they are reading the committed instrument.

[redacted: local path] (PID 40356, [redacted: port] + [redacted: internal address][redacted: port]) ; [redacted: local path] (PID 30176, [redacted: internal address][redacted: port]) ; [redacted: local path]

The committed studio launcher starts and supervises a file that exists in no commit silent A · probed

Kind: launcher-references-untracked-file

Claim. viewer/studio_up.ps1 is CLEAN at commit 0257e0e (2026-08-02T11:42:40-05:00, 'the agent's voice becomes a real broadcast source — no Windows audio device anywhere'). Line 382: `Start-NodeHidden 'UNI VOICE' 'voice_server.cjs'`. voice_server.cjs also appears in the -Stop reap list (line 80), the -Status list (line 192) and the -Watch restart loop (lines 474, 476).

Reality. git status: `?? viewer/voice_server.cjs`, `?? viewer/claudespeak_source.cjs`, `?? production/overlays/voice.html`, `M viewer/music_director.cjs`. The service does run on THIS box only — PID 28628, cmdline `node.exe voice_server.cjs`, listening [redacted: internal address][redacted: port], /healthz -> 200 (66 bytes). Its source is in no commit and the branch is already 10 ahead of origin/gen2-runtime and unpushed. Compounding it: music_director.cjs:55 now sets `const DESKTOP_VOICE_DUCK = false;` with the note at line 114 'voice_server.cjs owns the voice duck now', so task #31 (auto-duck under hot mic, marked completed) has been moved entirely into untracked code.

What breaks. A clean clone of gen2-runtime cannot bring the studio up: Start-NodeHidden fails, -Watch restart-loops a missing file forever, and the agent's broadcast voice plus the mic auto-duck simply do not exist. The whole voice subsystem — server, Piper source, and the OBS overlay page — lives in one working tree on one box with no remote copy.

[redacted: local path],192,382,474,476 ; [redacted: local path] (untracked, PID 28628, [redacted: port]) ; [redacted: local path],114

The Checkpoint-E surface — the plan's declared NEXT ACT — runs with no supervisor of any kind silent A · probed

Kind: declared-watchdog-not-running

Claim. viewer/track/track_watchdog.ps1 and viewer/track/track_boot_install.ps1 exist and declare TRACK boot-install plus watchdog. phase9_plan.json next_act = CHECKPOINT-E, owner OPERATOR, 'Two images side by side at [redacted: internal address]

Reality. Exactly three watchdogs are running: door_watchdog.ps1 (PID 22368), gaia_watchdog.ps1 (PID 22520) and systray_watchdog.ps1 (PID 6608). track_watchdog.ps1 is NOT running. hud_watchdog.ps1 is NOT running. lab_server.cjs has no watchdog file at all — repo-wide it is referenced only by viewer/lab/desk.cjs and the lab-L0..L6 verifiers, i.e. it is launched by gates, not supervised by anything. systray_watchdog.ps1 only covers the eight names in studio_up.ps1's list, which include neither TRACK nor the lab. The surface is genuinely working right now: /lab/l6 -> 200 (9005 bytes), /api/lab/shot?swap=0 -> 200 (3371 bytes), ?swap=1 -> 200 (3375 bytes).

What breaks. If lab_server (PID 54448) dies, /lab/l6 vanishes and CHECKPOINT-E — the operator's eye, the one act the whole plan is currently waiting on, in progress on air as task #32 — cannot be performed, with nothing to restart it and nothing to say so. If track_server dies, the operator loses his persistent surface and its declared watchdog is not there to notice.

[redacted: local path] (PID 54448, [redacted: internal address][redacted: port]) ; [redacted: local path] (not running) ; [redacted: local path] next_act

The running stack was not produced by studio_up.ps1, and studio_up's own -Status and -Stop are blind to six of the fourteen live services silent A · probed

Kind: launcher-status-incomplete

Claim. studio_up.ps1 line 1: 'ONE command that brings the whole UNI broadcast studio up, in order, with... -Status report what's up / down (incl. zombies)... -Stop tear EVERYTHING down, verified'. Step 1 launches Minecraft (paper.jar, [redacted: port]); step 2 launches ONE Phoenix node (elixir --sname uni, [redacted: port]).

Reality. Fourteen UNI node processes with start times spread across twenty hours — launcher.cjs and door_healer.cjs from 2026-08-01 15:53, then 01:40, 06:49, 07:13, 08:44, 09:17, 09:29, 09:38, 10:09, 11:40, 11:41 — not one bring-up. -Status (line 192) reports on eight names only; launcher.cjs, door_healer.cjs, lab_server.cjs, track_server.cjs, gaia_server.cjs and capture_minds_loop.cjs appear in neither the -Status nor the -Stop list, so -Stop would report EVERYTHING torn down while the Door, Gaia, TRACK and the LAB kept serving. And the two things it launches first are absent: Get-NetTCPConnection on 4000, 25565 and 25575 returns nothing, and Get-Process for beam.smp, erl, java, werl returns nothing. Separately, music_director changed identity mid-audit — PID 41312 (started 11:05:56) was replaced by PID 52188 (started 11:41:28).

What breaks. The one command documented as the authoritative bring-up/teardown/status for the studio cannot see or stop nearly half of it. An operator running -Stop before a reboot believes the box is quiet when four servers, two of them bound to [redacted: internal address], are still live. -Status is used to decide whether it is safe to go live.

[redacted: local path],80,192,238,243,249,289,474

Two implementations claim port 8100; the live one reports git_commit null and had restarted 58 seconds before the probe silent A · probed

Kind: duplicate-implementation-and-unknowable-boot-identity

Claim. viewer/hud/hud_server.cjs:3 — 'Binds [redacted: internal address][redacted: port] (LAN-visible; reachable at [redacted: internal host][redacted: port]).' viewer/hud/hud_watchdog.ps1 exists to keep it up; hud_boot_install.ps1:95 promises 'the HUD OPENS ON ITS OWN once [redacted: port] answers'. Registry gate `build-identity` claims running-vs-committed identity across the bodies.

Reality. [redacted: port] is owned by PID 4 (System / http.sys) on both :: and [redacted: internal address] — not node. hud_server.cjs is not running and hud_watchdog.ps1 is not running. GET /api/hud/health -> 200: {"server":"uni-hud","instrument":"UNI.Hud.Service@0.2","git_commit":null,...,"result":{"hud":{"version":"UNI.Hud.Service@0.2","port"[redacted: port],"bind":"[redacted: internal address]","uptime_ms"[redacted: port]}}}. So the live [redacted: port] is the native .NET service, bound loopback-only, reporting NO git commit, and it had restarted 58 seconds earlier — mid-broadcast — while the Door's /api/status reported hud {open:true, locked:false, circle_ok:true}. CORRECTION TO MY OWN FIRST READING: /hud returning 404 is BY DESIGN and not a drift — launcher.cjs:342 states 'there is NO /hud page — it 404s; the HUD is a native WPF widget, not a webpage'. The drift is the duplicate and the null identity, not the 404.

What breaks. Two servers claim one port with opposite bind policies — if hud_watchdog.ps1 were ever started it would either collide with the http.sys reservation or succeed and expose the HUD LAN-wide, which hud_server.cjs's own header advertises and the live service deliberately does not do. git_commit null means boot identity for this body cannot be established at all, so the build-identity gate cannot cover it. The `hud` gate is one of the three that never runs (ci:false).

[redacted: local path] ; [redacted: local path] (not running) ; [redacted: local path],342 ; probe [redacted: internal address]

The Phase-2 metabolism collector and the topology unit are both failed, and no operator surface says so silent A · probed

Kind: declared-service-failed

Claim. uni-collector-metab.service is the Phase-2 metabolism RED collector (one tick); uni-topo.service is a declared rootless unit. Both are installed in uid 1000's user manager.

Reality. `systemctl --user -M uni@ list-units --type=service` returns five units total, of which uni-collector-metab.service is 'loaded failed failed' and uni-topo.service is 'loaded failed failed'. Only container-uni-viewer-cam-fwd and dbus are cleanly running; container-uni-producer is the stuck one. No science tick is being collected.

What breaks. The science road is already blocked at runs/pureworld_qa_gate.exs (still raising @scaffold), and the collector that would feed the metabolism evidence is dead on top of it. Nothing on the Door, Gaia or TRACK reports a failed lab unit, so the failure is invisible from every operator surface on the Windows box.

lab uni-lab: uni-collector-metab.service, uni-topo.service (rootless, uid 1000)

The limb registry marks both remote limbs "active" while both are unreachable in two different ways, and the registry disagrees with itself about its own path silent A · probed

Kind: static-registry-field-read-as-health

Claim. /etc/uni/limbs.json (sha256 c24589a3f9a3a712308cb9ee7ade782cf7b06b144b7c9d8ded5cc3c118b18cbf, 729 bytes) lists three limbs and marks both remote ones "status":"active". limbs_list's own tool text cites /etc/uni-limbs/limbs.json; /etc/uni/fleet-extra-peers is a two-line deprecation stub pointing at /etc/uni-limbs/limbs.json.

Reality. uni-lab-79740c (node2) -> '[Errno 113] No route to host' (EHOSTUNREACH — the mesh route is gone). uni-tab-arm-1 -> '[Errno 111] Connection refused' (ECONNREFUSED — a TCP RST came back, so the path carries packets and nothing is listening on [redacted: port]). Both reproduced twice with different tools 19 s apart. The two failures are materially different and the registry says the same word for both. Only uni-lab itself answers.

What breaks. Anything reading "status":"active" as liveness reports a wish. It also masks the distinction that matters most tonight: node2 being off the MESH says nothing about node2 on its LAN address [redacted: internal address], which is the path the off-box witness actually uses.

lab uni-lab: /etc/uni/limbs.json ; /etc/uni/fleet-extra-peers ; mcp__uni-lab__limbs_list

Producer port 4200 is documented in eight places and has no observed listener anywhere silent A · probed

Kind: documented-port-with-no-listener

Claim. viewer/infra_registry.json declares producer at port 4200 with probe [redacted: internal host][redacted: port]/producer/health. launcher.cjs:95 and :128, command_center.cjs:800 and :902, door_healer.cjs:69 and :112, door_lifecycle.cjs:127-129 and :159, gaia/caps.cjs:218 and gaia/collectors.cjs:420,481 all address [redacted: port]. viewer/discovery.cjs:41 records the history in its own words: 'producer was ALSO declared on port 4000; the registry says 4200. A hand-copied address goes stale, and a hand-copied port was simply never right.'

Reality. On the lab, the producer's Phoenix/Bandit endpoint binds [redacted: internal address][redacted: port] inside the container namespace ('[info] Running SpUiWeb.Endpoint with Bandit 1.11.1 at [redacted: internal address][redacted: port] (http)'), and host [redacted: port] is an orphan forwarder. Nothing was observed listening on 4200 on either box. NOT DEFINITIVE: the lab's `ss -lptn` output came back truncated, so the port census is a floor, not a census, and no HTTP probe of 4200 was possible (curl and wget are outside the os_exec allowlist, ssh to localhost was refused at auth, and the Windows box is off the mesh — ping [redacted: internal address] is 100% loss).

What breaks. The Door's colony panel, the command centre's colony poller, Gaia's caps and the overlook capture window are all pointed at a health route on a port that was never observed answering. The overlook channel window is one of the two that is missing entirely, which is consistent with it having failed to load its URL.

[redacted: local path] ; viewer/launcher.cjs:95,128 ; viewer/door_healer.cjs:69,112 ; viewer/discovery.cjs:41 ; viewer/studio_channels.ps1:58 (ch_overlook -> [redacted: port]/stream)

mediamtx declares eleven ingest paths; seven have never carried a byte and one is READY while dropping thousands of frames silent A · probed

Kind: declared-path-never-ready

Claim. viewer/mediamtx_local.yml declares eleven paths, presented through the [redacted: port] control API as the camera inventory.

Reality. GET /v3/paths/list -> 200 (4784 bytes): four READY — uni (rtmpConn, 1920x1080 H264+AAC, 8.17 GB in / 16.34 GB out to two readers), cam1 (webRTCSession, 960x576, 73.47 MB), cam2 (webRTCSession, 1280x720 H264+Opus, 7.44 GB in / 5.29 GB out, 4,412 inbound frames IN ERROR), cam5 (722x442, 157.3 MB, 9 frames in error). NOT ready with zero bytes: cam3, cam4, cam6, cam7, cam8, cam9, cam10.

What breaks. An operator reading the config or the API sees eleven cameras and has four. cam2 is the busiest camera on the show and is READY while discarding 4,412 inbound frames — a 'ready' flag that says nothing about picture quality. Ranked below the channel-window drift because the API does report readiness honestly if anyone looks.

[redacted: local path] ; probe [redacted: internal address] (PID 7580 mediamtx.exe)

The OBS WebSocket is unauthenticated on all interfaces and the risk acceptance rests on a network condition nothing monitors silent A · probed

Kind: documented-exposure-with-no-detector

Claim. docs/control-plane/LIMITATIONS.md `f31.obs-unauthenticated`, line 75: 'the operator's studio configuration, S2. RISK ACCEPTED BY THE OPERATOR 2026-07-29 on the stated basis that no other party is presently on the LAN or the tailnet. That is an ACCEPTANCE, not a mitigation: the port is still open and unauthenticated, and the acceptance rests on a network condition that can change without anything here noticing.'

Reality. Confirmed exactly, including the correction the doc itself carries: obs64.exe PID 48960 binds [redacted: internal address][redacted: port] (all interfaces, not [redacted: internal address]), and the Hello frame carried NO authentication challenge — authRequired=false. Anything that can reach this host on 4455 can change the program scene or stop the stream mid-broadcast. Six ports bind wide: 4455, 8090, 8096, 8097, 8102, 8443. The doc and the runtime AGREE; what is missing is any detector for the precondition.

What breaks. The whole broadcast. This is the only finding here where an outsider, not a bug, is the failure mode. It is listed as a drift not because doc and runtime disagree — they match, which is to the project's credit — but because the acceptance names a condition ('no other party is on the LAN or the tailnet') that no gate, probe or alarm re-checks, and the box also carries Intel AMT/ME on [redacted: internal address]:623 and [redacted: port].

[redacted: local path] ; obs64.exe PID 48960 on [redacted: internal address][redacted: port]

Two voice-connector processes listen on the same transcript port silent A · probed

Kind: duplicate-supervisor

Claim. The operator's transcript surface is documented as a single service at [redacted: internal address], rendered live in UNI TRACK.

Reality. netstat shows TWO distinct PIDs on [redacted: internal address][redacted: port] — 15024 and 38720 — both python.exe running '-u -m claude_voice_connector.stdio_main'. One is presumably a stale duplicate. Which one owns the accept queue was not determined and nothing was touched (that would be a mutation). Separately there is now a SECOND, unrelated TTS path: viewer/voice_server.cjs on [redacted: internal address][redacted: port] renders Piper for broadcast audio — a different job, but it means two Piper-driven subsystems now exist with only one of them tracked in git.

What breaks. Low in isolation — the port answers 200 with 6,029 bytes. It matters because the transcript is the operator's record of every spoken finding, and if the two instances write the same log they can interleave or one can silently swallow lines.

[redacted: internal address][redacted: port] PIDs 15024 and 38720 (claude_voice_connector.stdio_main) ; [redacted: local path] PID 28628 on [redacted: internal address][redacted: port]

The public /live page tells the world no watch URL is declared, while the operator is live on two platforms silent B · documented

Kind: doc-contradicts-runtime

Claim. Deployed and committed: `git show HEAD:content/generated/live_status.json` -> distribution = {"declared": false, "note": "The operator has not declared a watch URL, so none is published. A guessed link would be a fabrication."}. The built static export out/live/index.html carries the same refusal prose.

Reality. OBS reports outputActive true with 8,116,318,842 bytes pushed over 04:19:43 at the earlier probe, and [redacted: internal address] returns {"level":"LIVE_LIVE","streaming":true,"visible":true,"audible":true,"program":"CAM_A"} right now. The corrected file — declared:true with the YouTube (@ORCHESTRATEMaster) and Twitch (mregenerativearchitect) links — exists only as the single dirty file in the UNI.Public working tree and has been neither committed nor redeployed.

What breaks. Everyone who reaches universalnaturalintelligence.com/live during the broadcast is told, in confident and well-reasoned prose, that there is nothing to watch. The refusal is honest-looking, which is exactly why nobody will question it.

[redacted: local path] (working tree M) ; [redacted: local path] ; probe [redacted: internal address]

The generated gates block is stale by one gate, identically, in all three declared copies of the contract silent B · documented

Kind: generated-block-not-regenerated

Claim. CLAUDE.md:726 — 'Gates: 35 registered, of which 32 ci:true and 3 ci:false (colony, hud, overlays...). 7 lab gates.' The block is wrapped in 'BEGIN GENERATED uni.state.gates ... DO NOT EDIT. node viewer/generate_state_blocks.cjs' and the banner above it exists specifically because hand-written counts drift.

Reality. viewer/gate_registry.json parsed directly: 36 gates, 33 ci:true, 3 ci:false. The 36th is `obs-fence` -> viewer/verify_obs_fence.cjs, gate_row=obs-supervisor-refuses-to-kill-a-live-encoder. The string '35 registered' appears on two lines in each of the three declared documents. The lab-gate count of 7 is correct. Every OTHER generated block verified exact: gates.ndjson is 207 rows at sha256 1daac9124c0ce48360244f7feb8b219a130be7a89b50bb1b92dce400e8bd4ee1; control_plane/ledger.ndjson is 32 lines and anchor.json declares head b90b74980f47b93aea1c0f2efc548fd6fb707ec4a61bee38924a127d466dafc0 length 32; the plan is 7 stages / 43 steps / DONE 31, BLOCKED 1, IN_PROGRESS 1, PLANNED 8, OPERATOR 2; next_act is CHECKPOINT-E.

What breaks. Narrow in magnitude, exact in kind: this is the fourth recurrence of the failure mode the banner was rewritten to end, one layer up. The numbers are generated but nobody ran the generator after obs-fence landed, so 'generated' is now itself a claim with a half-life. Any agent or public page deriving a gate count (UNI.Public gates.json also carries 35) inherits the undercount.

[redacted: local path] ; [redacted: local path] ; [redacted: local path] ; [redacted: local path]

The retired channel launcher refuses to run for a reason that is no longer true of the file it defers to silent B · documented

Kind: doc-instructs-superseded-or-false-rationale

Claim. viewer/launch_channels.ps1:4-6 (retired at commit 5861784, 'retire the superseded channel launcher — the thing most likely to bite the next bring-up'): 'studio_channels.ps1 is a strict superset: the same three PLUS the WEB channel (CDP [redacted: port]) and the CLIP channel ([redacted: port]), and BOTH write the same viewer/channels.json. So running this one after the real bring-up... OVERWRITES channels.json with the three-window subset and strands WEB and CLIP.' The refusal text at lines 27-28 repeats it.

Reality. studio_channels.ps1's $channels array (lines 53-59) has exactly THREE entries — colony (9220), glass, overlook (9221). There is no 9223 and no 9224 anywhere in the file; its own comment at lines 50-52 says 'web / clip stay OBS BROWSER SOURCES (2D, no WebGL) on the NVIDIA'. The two files launch the same three channels, so the superset claim and the stranding rationale are both false as written. channels.json on disk holds exactly those three keys and is therefore NOT stranded — I checked and my first hypothesis was wrong.

What breaks. An agent or operator reading the refusal believes WEB and CLIP are CDP channel windows that a wrong bring-up could strand, and will go hunting for CDP listeners on 9223/9224 that the live path never creates. That is exactly what happened: the runtime brief handed to this vector listed 9223 and 9224 as DOWN Chrome CDP channels. They are not down — they were retired into OBS browser sources and the doc was not brought along.

[redacted: local path],27-28 ; [redacted: local path]

The three declared copies of the governing contract are three different documents, and the one an agent reads first is missing a governing section silent B · documented

Kind: doc-copies-diverged

Claim. viewer/state_blocks.cjs:50,364 declares three document roots — REPO, FLAG and OUT_OF_TREE (path.resolve(REPO, '..', 'UNI-Flagellum'), 'tracked by no repo') — so all three CLAUDE.md copies carry the six generated blocks and drift under verify_claims.cjs. The banner asserts the third copy is now inside the reckoning.

Reality. Three distinct md5s and three distinct lengths: UNI.Minecraft/CLAUDE.md 7c3904694484e5f19f3787bd1a5d71c1, 833 lines; UNI-Flagellum/UNI-FLAGELLUM/CLAUDE.md 7bdcad662da039fd6cf53bfb9198b67e, 556 lines; UNI-Flagellum/CLAUDE.md f471c4fb8cc3b0e168b866d21a4a3b96, 393 lines. The 393-line untracked copy — the first file an agent starting in Documents/UNI-Flagellum reads — contains ZERO occurrences of 'parity ladder is the spine'; the tracked 556-line copy contains it. All three carry the stale '35 registered' string on two lines each. A fourth copy exists at UNI-FLAGELLUM-math-workbench with no RESUME POINT banner and none of the six blocks at all.

What breaks. The parity ladder (P0..P8) is how the project states its own maturity honestly. An agent that starts in the container directory — which is where the resume instructions point — never sees it, and is tracked by no git repository, so no diff and no CI run can catch the divergence. Only the gate can, and only when someone runs it.

[redacted: local path] ; [redacted: local path] ; [redacted: local path] ; [redacted: local path],364

UNI.Public's README understates its deploy chain, and the gate that declares itself fail-closed is not in that chain silent B · documented

Kind: doc-contradicts-config

Claim. README.md: 'there is no CI here — the deploy runs `next build` and nothing else.' safety/verify_publish_safe.cjs header: 'NOTHING SHIPS UNTIL THIS PASSES, AND IT FAILS CLOSED.'

Reality. vercel.json:4 buildCommand runs four things: `node generators/verify_public_consistency.cjs && next build && node generators/verify_a11y.cjs && node generators/verify_lenses.cjs` — all three verifiers WITHOUT --prove, so the mutation suites never run on deploy. Neither safety/verify_publish_safe.cjs nor safety/verify_coverage.cjs appears in the buildCommand; both run only via `npm run gate` / `prepublish:check`, i.e. only when a human remembers, on the one box that has the gitignored safety/patterns.local.json and generators/roots.local.json.

What breaks. The gate standing between the private estate and the public internet is not on the path that publishes to the public internet. It fails closed only when invoked, and the deploy does not invoke it. Deploys from any box other than this one, or by anyone who does not run `npm run gate` first, ship unguarded.

[redacted: local path] ; [redacted: local path] ; [redacted: local path] ; [redacted: local path]

Three registered gates never run, and they cover exactly the three surfaces where live drift was found silent B · documented

Kind: coverage-hole-aligned-with-failures

Claim. viewer/gate_registry.json marks `hud` (verify_hud.cjs, gate_row=hud-suite), `overlays` (verify_overlays.cjs, gate_row=overlay-proof) and `colony` (verify_colony.cjs, gate_row=colony-count-consistency) as ci:false — listed, never run, never a fabricated pass.

Reality. All three verifier files exist on disk and none is in the runner's CI path. The three surfaces they cover are precisely where this vector found live drift: the HUD ([redacted: port] duplicate implementation, git_commit null, 58-second uptime), the overlays (overlay_server 404s every path tried; production/overlays/voice.html is untracked yet served at 200 with 6,293 bytes), and the colony (camera delivering an empty pipe, capture window absent, producer restart-looping).

What breaks. Not a dishonesty — declaring them ci:false is the right call over a fabricated pass — but it means the three most operator-visible surfaces have no automated check, and the failures found tonight are in all three. The alignment is the finding.

[redacted: local path] ; viewer/hud/verify_hud.cjs ; viewer/verify_overlays.cjs ; viewer/verify_colony.cjs

Five verifiers exist in the estate that the gate registry does not know about silent B · documented

Kind: verifier-outside-registry

Claim. viewer/gate_registry.json is treated throughout the docs as the set of gates the project claims, and gate_row.schema.json says every gate the project claims must be represented in evidence/gates.ndjson.

Reality. production/run-of-show/verify_rundown.cjs, production/verify_p1.sh, production/verify_p1_v2.sh, production/verify_python_gates.py and production/mixer/verify_scenes.py all exist and none appears in viewer/gate_registry.json. The registry is the complete set the runner knows about, not the complete set of checks in the repo — and nothing states that distinction.

What breaks. verify_rundown.cjs validates the rundown against first-show.rundown.json and the weekly grid — the artifact whose last defect commit reads '98 minutes of airtime were invisible'. It is not in the registry, so no run of the gate runner exercises it and no ledger row can represent it.

[redacted: local path] ; production/verify_p1.sh ; production/verify_p1_v2.sh ; production/verify_python_gates.py ; production/mixer/verify_scenes.py

A 4.85 MB BEAM crash dump has sat at the repository root for six days and no Erlang node is running silent B · documented

Kind: uncleared-crash-artifact

Claim. studio_up.ps1 step 2 launches ONE Phoenix node (elixir --sname uni --cookie sp -S mix phx.server) and guards hard against zombies and duplicates: 'ABORT: a Phoenix process is already running but [redacted: port] is not responding -- ZOMBIE.'

Reality. erl_crash.dump, 4,852,467 bytes, dated 2026-07-27 21:40, at the UNI.Minecraft root — untracked by git status, so gitignored, and never cleared. Right now there is no beam.smp, erl, werl or java process on the box and nothing listening on 4000, 25565 or 25575. epmd is alive (PID 3960 on 4369) with no node behind it. The dump was not opened (read-only, and it is large).

What breaks. Six days of unread evidence about how the BEAM died, on a box whose Elixir core is the pure-science substrate. The zombie guard in studio_up is well built and would have caught a half-dead node — but nothing brought the node back, and nothing surfaces its absence, because -Status does not check it either.

[redacted: local path] ; [redacted: local path]

The lab's producer unit points its PIDFile at a container that no longer exists, and host [redacted: port] is held by an eighteen-day-old orphan from a dead podman scope loud A · probed

Kind: orphan-listener-and-unconvergeable-unit

Claim. [redacted: local path], generated by the deprecated podman-generate-systemd(1): Type=forking with PIDFile=[redacted: local path], ExecStart=/usr/bin/podman start uni-producer. The registry and the Windows-side surfaces address the producer at [redacted: port] or [redacted: port].

Reality. ExecStart exits 0/SUCCESS and systemd never converges: ActiveState=deactivating, SubState=stop-sigterm, Result=timeout, NRestarts=24, Active-since 2026-07-19T03:23:06Z — stuck two weeks — with a queued start Job 1206849. The conmon actually in the unit's cgroup was for container d5f4c8defe16a029…, a DIFFERENT id from the PIDFile's. Podman also logged the container carrying restart policy 'unless-stopped', fighting systemd's own restart. Meanwhile host [redacted: port] is held by rootlessport pid 89839 born 2026-07-15T16:43:54Z in cgroup podman-89795.scope — a bare podman scope, not the unit — whose parent 89795 no longer exists; the live producer binds [redacted: internal address][redacted: port] inside a different, churning namespace.

What breaks. The producer never signals ready, so anything gated on the unit converging waits forever; the restart loop gives every camera client a 3-5 second dead window per incarnation; and a client on host [redacted: port] most likely gets a TCP accept from an eighteen-day-old forwarder with nothing behind it (that last clause is inference, not measurement). This is the mechanism behind the empty colony camera.

lab uni-lab ([redacted: internal address]): [redacted: local path] ; rootlessport pid 89839 ; container-uni-producer.service

The off-box witness capture is 168 hours past its own one-hour fence, and the contract states its contents as a present-tense fact loud B · documented

Kind: stale-capture-stated-as-current

Claim. CLAUDE.md, 'Four things that must not be softened', item 1, present tense: 'The off-box witness is COMPROMISED — node2 accepts the writer's key, independent_custodians: 0.' viewer/gaia/verify_capture_age_fence.cjs declares the bound: CAPTURE_MAX_AGE_S = 3600, inherited from SP.ControlPlane.Witness, with the pre-registered falsifier 'a capture past its max age rendered as a value'. witness.json's own claim_note calls the refusal 'a CURRENT CONFIGURATION FACT... which is why it is re-measured on every capture'.

Reality. viewer/gaia/witness.json mtime 2026-07-26T12:05:09, captured_at 2026-07-26T17:05:09Z — 168 hours old today, 168x its own max age. It has not been re-measured in a week. It cannot currently be re-measured by the mesh path either: node2 (uni-lab-79740c) returns [Errno 113] No route to host from the router box, reproduced by two different tools 19s apart. Its LAN address [redacted: internal address] — the address witness.json actually addresses it by, and a different path from the dead mesh — was not probed.

What breaks. The single load-bearing security claim of the whole control plane. Gaia's fence withholds the stale value (that half works), but the CLAUDE.md prose is not fenced and every agent reads it as current. 'We measured this and it is so' and 'we have not looked in a week and cannot look now' are different states, and only the first is in the contract.

[redacted: local path] ; [redacted: local path] ; [redacted: local path] and the two sibling copies

The architect master plan declares all three target repositories unreachable and 146 of 147 tasks blocked, while all three sit cloned and clean on this disk loud B · documented

Kind: doc-contradicts-runtime

Claim. UNI_Three_Repo_DDD_TDD_Master_Plan_v1.0.0.json, generated_at_utc 2026-07-16T14:35:06+00:00, status 'implementation_ready_with_phase_0_access_gate': current_truth 'All three supplied URLs returned public HTTP 404 during discovery', only_ready_task 'P00-T001', all_other_tasks 'blocked by dependency', and every entry in repository_registry carries default_branch: null, commit: null, license 'unknown_until_phase_0'.

Reality. All three are cloned in [redacted: local path] right now with working origin remotes, resolved branches (UNI-Encyclopedia-Cookbook main, UNI.DDNA.OS main, UNI.OS os-only) and clean trees. The plan is seventeen days stale against its own targets. It also exists as three uncoordinated versions in three directories — v1.0.0 at the architect root (the only one with a .sha256 sidecar), v2.0.0 in work/, v3.0.0 in outputs/ — and it names three target repos while the folder holds seven, including two third-party research clones and a second copy of UNI-FLAGELLUM it does not mention.

What breaks. executive_handoff.first_action instructs an agent to 'Execute P00-T001 only: authenticate and resolve the three target repository identities. Do not begin implementation against guessed repository contents.' An agent obeying it would re-run a phase that has clearly already been cleared, against a plan that is a single point-in-time JSON with no generator keeping it honest — the exact hand-written-claim-with-a-half-life pattern the FLAGELLUM contract had to fix with generated blocks.

[redacted: local path] ; [redacted: local path] (v2.0.0) ; [redacted: local path] (v3.0.0)