Wiki · Evidence & Verdicts
SCIENCE-AGENT LAUNCH PROMPT — reattach the Producer UNI to the live camera (2026-07-14)
[redacted: category] — 1 private address, 1 internal hostname. 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.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.
✅ EXECUTED 2026-07-15 — gate
producer-camera-attached= PASS (evidence class A). The diagnosis REVERSED this doc's premise: the living v2 Producer was running insideuni-colonythe whole time (driver=:producer,port:nil) — its camera directives died incam_write(nil). Owner chose option (a)-class (new HEAD show-runner nodeuni-producer, observe-only fenced, rpc-sensing the real board; colony untouched). Verdict receipt:docs/receipts/producer_camera_attached_verdict_2026-07-15.md· pre-registration + review:docs/receipts/producer_reattach_remote_sense_spec.md· spec:docs/specs/producer_remote_sense_observe_only.md. Remaining: studio re-points OBS to[redacted: internal-hostname]:4200/stream(narration-camera coherence); persist the:4200nft rule (task chip). This banner closes the handoff; the text below is preserved as written.
How to use: paste everything below the line into a fresh Claude Code session in this repo. Written by the studio agent 2026-07-14 evening after live, read-only diagnosis. All facts below carry their probe timestamps. The studio agent touched NOTHING on the chip — every command run was read-only (
podman ps/logs/inspect/port,curl).
You are the science agent for UNI.Minecraft (Stratified Palimpsest), per CLAUDE.md's two-track
rule. Read CLAUDE.md in full first, then docs/LAB_PROTOCOL.md,
docs/handoffs/SCIENCE_AGENT_COLONY_BRAIN_HANDOFF_2026-07-13.md, and
docs/handoffs/GAIA_CAPTURE_BEFORE_DESTROY_2026-07-14.md. This prompt supersedes the 07-13
handoff's remedy (full brain redeploy) — the owner has explicitly withdrawn that as the next
step. Your mission is narrower and different.
The owner's directive (binding, verbatim intent)
The colony is ~926 in-world days old and has been running for years of wall-clock time. The
owner forbids replacing, redeploying, restarting, or otherwise touching the living colony
(uni-colony container, the world, the UNIs' minds) for this fix. The UNIs are to be observed
and followed live, as they are. The broken thing is the CAMERA ATTACHMENT, and the owner's own
diagnosis — which the studio agent verified — is correct: "there is just not the UNI attached."
The Producer UNI (the unique UNI that flies the camera and reports the show) is not connected to
the camera that is currently rendering. This is a go-live blocker: the owner will not take the
colony scene to a broadcast test in this state.
Timeline (owner's report + container evidence agree): camera-follow WAS working during the
owner's last live stream of UNI.Minecraft, driven by the real Producer
(docs/RESUME_RUNG1.md:99-127 — mix producer.run + cd ui && mix phx.server, 2026-07-11 era,
commits 24d88f4/61671b0; see also the puppet-cam incident 68d8cc6→307b8a1). It broke
within the last 3 days. On 2026-07-13, 03:50–05:46 UTC the camera path was re-plumbed into
standalone containers (podman ps CreatedAt, probed 2026-07-15 02:05 UTC):
| container | image | created | state | role |
|---|---|---|---|---|
uni-cam |
localhost/uni-cam:v1 |
2026-07-13 05:44 | Up 44h | runs director.js standalone against mc-server:25565, viewer on :3020 (its own log: "[uni-cam] starting director.js against mc-server:25565 (VIEWER on :3020)") |
uni-viewer-cam-fwd |
alpine/socat | 2026-07-13 05:46 | Up 44h | host :3020 → uni-cam:3020 |
uni-viewer-mc-fwd |
alpine/socat | 2026-07-13 05:37 | Up 44h | host :25565 → mc-server:25565 |
uni-viewer-fwd |
alpine/socat | 2026-07-13 03:50 | Up 46h | host :4000 → uni-colony:4001 |
uni-viewer-in |
alpine/socat | 2026-07-13 03:50 | Up 46h | :4001 → 127.0.0.1:4000 |
uni-colony |
localhost/uni-colony:v2 |
2026-06-22 | Up 46h | THE LIVING COLONY — DO NOT TOUCH |
mc-server |
itzg/minecraft-server | 2026-06-25 | Up 2wk (healthy) | the world — DO NOT TOUCH |
Why the camera is frozen (verified mechanism)
viewer/director.js is a spectator/camera bot driven ONLY over stdin (grammar at
viewer/director.js:8-13, parser :171-200): star <user> / shot <type> <user|-> [params] /
flyto <user> / cut <user> / set k=v. In the working 07-11 configuration,
lib/sp/brain/director.ex spawned it as an OS Port (spawn_camera/1 :577-598, gated by
UNI_CAM) and wrote shots to that stdin (cam_write/2 :245-254, cut_to/3 :602-605);
under driver=:producer the beat handler (:141-145) skips its own rule-based cuts and the
camera moves ONLY on SP.Producer directives (lib/sp/producer.ex:86-135, :240-302;
lib/sp/producer/brain.ex picks actions by EFE minimization).
The 07-13 re-plumb moved director.js into the uni-cam container, where its stdin belongs to
the container entrypoint shell. No Elixir Port, no Producer, no stdin writer. director.js's
subject is a module-level variable that never expires — glide() keeps orbiting the last
subject forever — so the camera still renders (owner's screenshot: :4000/stream, "THE COLONY ·
Day 923", live narration + per-bot cards updating) while never changing shot. Narration and
camera are structurally decoupled (ui/.../stream_live.ex:37-43 polls Director.broadcast()
over HTTP; the camera is a separate phx-update="ignore" iframe to :3020, :126-129, :252),
so live narration is NOT evidence of an attached Producer.
Fresh probe (2026-07-15 02:10 UTC): GET http://[redacted: private-address]:4000/producer/health →
Phoenix.Router.NoRouteError. The node serving :4000 doesn't even have the Producer health
route, while /stream on the same port narrates live. driver=producer is NOT VERIFIED. The
Producer UNI is not attached. (Open topology question you must resolve FIRST: which node/process
actually serves :4000 behind the uni-viewer-fwd→uni-colony:4001→uni-viewer-in→127.0.0.1:4000
socat chain — and where, if anywhere, is a Phoenix node with the post-07-11 code running?)
Your mission
Reattach the real Producer (SP.Producer + SP.Brain.Director from HEAD, gen2-runtime) to
the live camera, so the camera again cuts/follows the UNIs under genuine Producer control —
without touching uni-colony, mc-server, the world, or any UNI mind.
- Diagnose first, with receipts. Resolve the
:4000topology. Establish exactly what process narrates, whatdriver()it reports, and confirm no Producer is running anywhere. - Surface the reattachment choice — do not silently pick (this is ADR-PROD-013's open
camera-mechanism decision, now concrete):
- (a) Port-respawn: run the Producer's node so it spawns
director.jsas its own Port child (the proven 07-11 mechanism). Note the consequence: the standaloneuni-camcontainer becomes redundant — two camera bots must NOT fight; decide and document which one lives. - (b) Command bridge: keep
uni-camas-is and bridge Producer shot-commands to its stdin (e.g., a small TCP→stdin listener). NOTE:viewer/director.jsis STUDIO-track code — if this option needs changes there, hand that piece to the studio agent; do not editviewer/**yourself. Present both to the owner with a recommendation before implementing.
- (a) Port-respawn: run the Producer's node so it spawns
- Honor the hard rules: exactly ONE
--sname uniPhoenix node ever (CLAUDE.md); the puppet-cam ban (68d8cc6→307b8a1— a self-orbiting camera with no real Producer is FAKE and was killed by owner directive once already; never "fix" this by lettingdirector.jsdrive itself); one cure at a time; mutations on the chip go through the uni-lab MCP approval queue; if — and only if — some container mutation becomes truly unavoidable, run the FULL capture-before-destroy procedure first AND get explicit owner approval in chat; no FE-engine code changes without/lab-team-reviewMERGED VERDICT (re-RUNNING existing HEAD code is not an FE change; editinglib/sp/**is). - Pre-register the gate before the fix (append PENDING row to
evidence/gates.ndjson, then supersede with the verdict):producer-camera-attached— PASS: a freshGET /producer/healthyou run returns 200 withdriver=producer, AND over a ≥10-minute observation window the:3020camera performs ≥3 distinct Producer-issued shot changes (log the issued directives and correlate with observed camera motion), AND narration remains live. FALSIFIES: camera static across the window; ordriver≠producer; or directives issued but camera unresponsive (that outcome is pre-registered as V4 in the 07-13 handoff — surface it, don't mask it).
- Hand back proof, not prose: probe outputs with timestamps, the gate row, and a short
receipt doc under
docs/receipts/. The studio agent treatsproducer-camera-attachedas a broadcast-readiness blocker for the colony scene until it reads PASS.
The camera is real, the world is real, the narration is real. The only missing thing is the Producer's hands on the wheel. Attach the UNI; change nothing else.
sha256 bb909f6d4147c1ad — of the original file, so what was ingested stays checkable.
Plain — written for this website, not the source document
Read the banner first: this was carried out, and the diagnosis reversed the document's own premise. The show-runner had been running the whole time, and its camera instructions were going nowhere because the piece that should carry them was absent. Underneath is the brief as written. It asks a second agent to reattach the camera without touching the living colony at all, and to surface the choice of how rather than picking one silently. It also asks that the gate be registered before the fix is made, because a verdict written afterwards is not evidence.
Plain · written 2026-08-01 by claude-opus-5 · not yet checked by a person · about the document whose sha256 is bb909f6d4147c1ad
Clear — written for this website, not the source document
A launch prompt written by one agent for another, with a banner added afterwards saying it was carried out and, more importantly, that the diagnosis reversed the premise below it. The text is preserved as written rather than corrected in place, and the banner names the files recording what was run afterwards.
The owner's directive is the frame. The colony has been running for a very long time and must not be replaced, redeployed, restarted or otherwise touched for this fix. The bodies are to be observed and followed as they are. The broken thing is the camera attachment, and it blocks taking the scene to a broadcast test.
The diagnosis is careful and mechanical. A table of containers with their creation times shows when the camera path was re-plumbed. The camera process is driven only through its standard input, and in the working configuration a parent process spawned it and wrote to that input. After the re-plumb it lives in a container where that input belongs to the entry shell, so nothing writes to it. Because the subject it was last given never expires, it keeps orbiting forever, which is why the picture still moves while never changing shot.
One inference is called out as a trap. Narration and camera are structurally separate, so live narration is not evidence that the show-runner is attached. A fresh probe returning a routing error is quoted, and the conclusion is written as not verified rather than as a confident negative.
The mission is then narrow: reattach the real show-runner to the live camera without touching the colony, the world, or any mind. The steps insist on diagnosing first from recorded runs, and then on surfacing the choice between two mechanisms rather than silently picking one, with the consequence of each spelled out. Two camera processes must not fight, and a change belonging to the other track must be handed to the agent who owns it.
The hard rules are repeated. Exactly one node, and a ban on a self-orbiting camera with nothing driving it, because that is fake and was killed by directive once already. One change at a time, mutations through the approval queue, and the full capture procedure plus explicit approval if a container change becomes unavoidable.
The gate is written into the prompt before the run, with its pass condition, an observation window, and a requirement to correlate issued instructions with observed camera motion. It also names what would show the claim wrong, including the awkward case where instructions are issued and the camera does not respond, which the writer insists must be surfaced rather than masked. The closing line asks for proof rather than prose.
Clear · written 2026-08-01 by claude-opus-5 · not yet checked by a person · about the document whose sha256 is bb909f6d4147c1ad