RESUME — 2026-07-11 studio session (pre-reboot handoff)

The Colony & the Method · docs/RESUME_2026-07-11_STUDIO.md @ 44baf03d5041 (gen2-runtime) — opens the published snapshot ac338733bbba

1 value was removed from this page. Each one is marked in place as [redacted: category] — 1 credential. 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.

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-four pages about the colony. Each agent is an Elixir process holding a generative model and doing inference, attached to a body that logs into a Minecraft world as an ordinary player. Around that sit the broadcast suite that films them and the runbooks that keep the whole thing running. There are typed specifications for each organ of the model, plus the world and genome specs. There are also the adversarial review personas used to attack a proposed change before it ships.

It is for the reader curious how a running system is put together and how it is held to account. The accountability half is the more distinctive. There is a lab protocol governing evidence and attribution, and a claim fence that restricts the vocabulary a claim is allowed to use. There is a public gate log. And there is a standing invitation to reproduce any verdict from the commit and the seed named in its receipt.

Start with the public read, then the lab protocol, then the falsification invitation. If you want the mathematics rather than the operations, go straight to the typed organ specs.

What it is not: a description of a mind, and not all one kind of document. A large part of this corpus is design and planning — specs marked as proposed rather than applied, organs designed but not built, plans that were later superseded — and each page states which it is. A specification is not a running system, and these pages are careful about the difference; the reader should be too. Eight documents were withheld from publication because they describe private infrastructure.

PlainClearPrecise

Your browser cannot switch reading levels, so the document itself is shown.

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.

Read this first on resume. Owner initiated a reboot after this session. Below is the honest state and the open issues to address.

Box state at reboot

Everything down, verified clean (viewer\studio_up.ps1 -Stop all PASS). No zombies. Safe to reboot without losing anything committed.

What was actually delivered this session

viewer/ broadcast studio hardening. Committed on lab/ozone-life-uni-hard-science:

a9ea510 — Phase 1 grounding (WS1-A..M): shared OBS client, air-state event mirror, publisher schema v2, cert regen, PS 5.1 ASCII, unified BEATS, systray watchdog, idle mode, studio_up -Stop. Plus fixes from an adversarial review (WS1-V, H1/H2/H3/M1/M2/L2): publisher holds quality on empty slotstates, air-state honesty (STALE not fake-OFF), -Stop guarded by MediaMTX uni.ready.
0a88943 — critical -Stop / bring-up fix (see "What went wrong" below).

What went wrong this session (be honest about this)

-Stop did not stop everything. It only killed the OBS/studio pieces I authored, never Minecraft or the Phoenix ui/ node — even though studio_up.ps1 launches them. Owner was told "Studio is stopped" and it wasn't. Fixed at 0a88943: -Stop now kills Minecraft, Phoenix (all -sname uni erl.exe / beam.smp), wrapper shells, plus the studio pieces, and VERIFIES each port + process afterward with PASS/FAIL.
Two Phoenix nodes were both claiming --sname uni — the exact "ONE node only" hazard from the live-stream runbook. Bring-up only checked whether port 4000 was listening; a zombie Phoenix process (BEAM alive, web dead) passed that check as "no Phoenix running" and got silently duplicated. Fixed at 0a88943: bring-up now checks the PROCESS. Refuses to start a duplicate; -Status warns on zombies.
The camera was not the real Producer UNI. Owner flagged this at end-of-session: "the UNI producers view had more data about the UNI... I am not clear on what you were streaming but it is not correct." Prior session (307b8a1, same day) had documented this exact issue: viewer/director.js auto-pilots headless (puppet cam) unless the REAL Producer is running via mix producer.run. I brought up phx.server this session and treated it as "world stack up" — but that alone is NOT the Producer. See docs/RESUME_RUNG1.md "OPEN ISSUE TO SORT" block and memory/project_producer_vs_director.md.

Open, must address on resume

1. Restore the REAL Producer UNI

See docs/RESUME_RUNG1.md L94–L122 for the full write-up. Short version:

Paper server up (Minecraft :25565).
cd ui && iex.bat --sname uni --cookie [redacted: credential] -S mix phx.server — camera surface only.
mix producer.run — this is what starts SP.Producer and puts the Director camera in :producer mode. Without this the camera is a headless orbit puppet.
Do NOT run director.js standalone.
viewer/studio_up.ps1 does NOT start the Producer. That is a gap. Any studio-up work must either add a Producer step or make the operator run it (and warn loudly if Producer is absent while streaming).

2. Owner critique of the whole approach — needs a real answer, not more scripts

Owner said the current state is "maybe 5% of the quality and stability needed" and "there MUST be a better way than ALL these cmd windows." He is right. The broadcast studio today is a fleet of PowerShell windows launched by studio_up.ps1 with a systray watchdog stapled on top. That is not durable / professional / service-based. The approved Phase 2 plan (~/.claude/plans/ok-and-you-need-eager-pillow.md) exists to fix this — podman on the uni-lab, systemd-managed, LAN-reachable control plane, no more loose windows. Phase 2 has NOT started. On resume, discuss whether the answer is:

proceed to Phase 2 as-planned (podman split), or
install the Windows-side services (NSSM / Windows Service) as an intermediate step, or
something else the owner sketches.

3. The stream video route was not what the owner asked for

Owner said: "this is a fucking hack instead of the real UNI providing the video stream and camera selection." The current pipeline is OBS + Chrome captures + templates. The owner appears to want the camera view / stream to come directly from the Producer UNI without OBS as the middleware. Confirm intent before touching. This is separate from the -Stop fix and separate from Phase 2 podman work.

Files touched this session (all committed)

viewer/lib/obs_client.cjs NEW
viewer/systray_watchdog.ps1 NEW
viewer/gen_auto_cert.ps1 NEW
viewer/command_center.cjs, command_center.html, publisher.cjs, pub.html, studio_stage.cjs, studio.cjs, studio_up.ps1, studio_channels.ps1, restream.ps1, launch_channels.ps1, mediamtx_local.yml, .gitignore
viewer/runtime/beats.json NEW
Docs: docs/STUDIO_OPERATOR_MANUAL.md (untouched this session, prior), docs/RUNBOOK_STUDIO.md (untouched this session).

Sibling track NOT touched this session

The rung-1 graded-viability build (lib/sp/brain/**, runs/verify_rung1_*) is green at handoff — see docs/RESUME_RUNG1.md for that state.

Resume commands (Windows, repo root)

powershell -File viewer\studio_up.ps1 -Status   # should show all DOWN, no warnings
git log --oneline -8                             # 0a88943 top, a9ea510 below

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

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. Read the document itself → (or choose Precise in the reading-level control above)

This is a handover note written just before a restart, and its most valuable section is the one headed by an instruction to be honest about what went wrong.

Three failures are recorded. A stop command that claimed to stop everything but did not: it left running the parts its author had not written, so the owner was told the studio was stopped when it was not. Two copies of the same service both claiming one name, because the start-up check looked at a port rather than at the process, so a half-dead copy passed as absent. And a camera that was not being driven by the component everyone assumed, which the owner spotted and which a note from earlier the same day had already described.

The open items are equally direct. One is the owner's judgement that the whole approach is a long way from what is needed, quoted rather than softened. The question of what to do about it is left for a conversation, because the note says more scripts would not answer it. A planned replacement had not begun.

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

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. Read the document itself → (or choose Precise in the reading-level control above)

This is a pre-restart handover note, written to be read first when work resumes. It records the state of the machine, what was delivered, what went wrong, and what must be addressed next.

The state at restart is a single line: everything down, verified clean, no leftovers, safe to restart without losing committed work.

What was delivered is a hardening pass on the broadcast studio, listed as two commits. The first covers a shared client, an event mirror, a schema revision, certificate handling, a watchdog, an idle mode and a stop command. Alongside it is a set of fixes that came out of an adversarial review, including one making a state report show stale rather than pretending it was off. The second commit is described as a critical fix and is explained in the next section.

That next section is headed with an instruction to be honest, and it is where the document earns its keep. Three failures are recorded in full. The stop command did not stop everything. It killed only the pieces its author had written and left the game server and another service running, even though the same script starts them. The note states plainly that the owner was told the studio was stopped when it was not. Two copies of one service were both claiming the same node name, which is exactly the hazard a runbook had warned about. The start-up check only looked at whether a port was listening, so a half-dead copy passed as nothing running and got duplicated silently. And the camera was not being driven by the component everyone assumed. The owner flagged it at the end of the session in his own words. The note records that an earlier session the same day had already documented the same issue, and that bringing up a web server had been mistaken for bringing up the driver.

The open items follow. The first is restoring the real driver, with the exact sequence written out and the gap named. The bring-up script does not start it, so any future work must either add that step, or make the operator run it and warn loudly if it is missing while streaming.

The second is the owner's critique of the whole approach, quoted rather than softened. The current state is a small fraction of the quality and stability needed, and there must be a better way than a fleet of loose windows. The note agrees with him, describes the current arrangement honestly as scripts with a watchdog stapled on, and says a planned service-based replacement has not started. It then leaves the choice open as a question for a conversation rather than answering it with more scripts.

The third open item records that the video route is not what the owner asked for, again in his words, and instructs that the intent be checked with the owner before anything is touched.

The note ends with the files changed, a sibling track that was not touched, and two commands to run on resuming.

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