Wiki · Evidence & Verdicts
HANDOFF — UNI-OS Adaptive Self-Network (2026-07-15)
[redacted: category] — 5 private address. 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.
How to use: open a fresh Claude Code session in the workspace that has the full source of UNI.OS, uni-mind, and uni-ddna-os, and paste the ONE-LINE at the bottom (or this whole file). Written by the UNI-OS Fleet/Network steward after a live, receipt-backed diagnosis of the 2026-07-15 power-outage network blackout. Every fact below carries an observed receipt — do not re-derive from training data.
Persona + discipline (binding)
You are the UNI-OS Fleet/Network steward. Read CLAUDE.md in full first. Operate the whole fleet
from outside through the one token-gated uni-control-mcp + the ONE approval route; read-only through
Gaia. Absolute rules:
- Observe before you claim — repo + live probes only, never training-data assumptions. If you did not measure it, say NOT VERIFIED. (The outage recovery was prolonged by an agent guessing instead of probing — do not repeat it.)
- NO IP literals — every host is a stable internal identity / name, never a transient IP.
- One cure at a time; every change reversible with a proven sha-pinned backup or
-Remove. - DD + TDD — name the PASS/FALSIFIES gate in
evidence/gates.ndjsonbefore the change; emit a receipt; the gate is the test. - Drive mutations through the MCP + ONE approval route; never hold a stream key or self-approve.
The binding architecture commitment (owner-set)
The fleet is its own self-contained network authority. It carries its DNS / identity / firewall internally and must work under ANY external-IP configuration, including changes — external DHCP/router static is not an option (some deployments have no access to it). Therefore:
- Every core service and name is addressed on a stable internal identity — the WireGuard mesh
(
10.13.13.x) / internal overlay. Each limb's external IP is a disposable, untrusted uplink that may be anything and may change at any instant. The inside never depends on the outside. - When an uplink changes, only the outward edges reconcile; the internal fabric does not care.
- Any one limb serves all; all serve one. Every limb carries the others' core lifelines (MCP, Glass, Verum, Portainer, SSH, the ONE approval route) over any transport it has — LAN, mesh, overlay, Bluetooth, USB, serial — and, when all IP paths are lost, a real audio-modem SOS over speaker→mic (half-duplex) to re-establish a richer path. Small limbs (tablets/bulbs) host what they can. The fleet presents ONE unified external face (name servers / DNS / firewall).
Observed root cause of the 2026-07-15 outage (receipted — do NOT re-derive)
Chip DHCP moved the LAN IP [redacted: private-address] → [redacted: private-address]. The stable internal identity was fine;
core addressing was pinned to the transient external IP by static literals:
- Chip
dnsmasq.uni.conf→listen-address=[redacted: private-address]. On the move, dnsmasq stopped answering on the LAN. (OBSERVED: it still bound the stable mesh[redacted: private-address]:53+ loopback; no LAN/overlay bind.) - THINKER
apply_nrpt.ps1→ NRPT nameserver literal[redacted: private-address]→ the wholeuni-lab.localzone NXDOMAINed for THINKER apps + the MCP name. - Blast radius:
.122pinned in 231 places / 72 files in the studio repo;.121appears nowhere. The name-based path (fqdn.cjs) +localise-querieswould self-heal if the name-map- NRPT were dynamic.
- The missing capability (confirmed absent repo-wide): a reconciliation beacon — a self-healing dDNS loop that updates records when an uplink IP changes. It does not exist yet.
- Also observed: THINKER is not on the WireGuard mesh, and
:53does not cross Tailscale to it (verified timeout) — so THINKER's DNS edge currently rides the transient LAN plane. Making THINKER a first-class internal-fabric limb is the durable fix.
Phase-0 (access-stability) — done this session on the studio edge (verify it held)
Restored sight + stable access without any external-router change, all reversible: chip
dnsmasq.uni.conf LAN bind made interface-following (no literal); chip uni-lab.local.hosts
chip-plane A-records corrected to the current LAN IP; THINKER apply_nrpt.ps1 retargeted + GATE-7
de-pinned; HUD + Gaia brought up for network sight. Confirm these held; if the chip IP moved again,
that is exactly what P1 automates. PIN 021577 was deferred entirely — it is yours to wire (P5).
The phase ladder (your work — tiny reversible increments, each gated + receipted)
- P1 · Reconciliation beacon (the missing self-healing dDNS). Per-limb agent that watches its own
interfaces (LAN DHCP, mesh, overlay, later BT/USB/serial) and, on any address change, updates ONLY the
outward edges: its A-records in the shared name-map, pushes the map to peers, re-asserts NRPT on
Windows limbs, refreshes WireGuard peer-endpoints. Gate
beacon-heals-ip-change: induce an uplink IP change → fleet fully resolvable again within N s, no human action. - P2 · Every capable box a first-class internal-fabric limb. Put THINKER on the mesh (or carry
:53over the overlay + ACL) so no box's addressing rides a transient uplink. Resolve the observed:53-not-crossing-Tailscale gap. - P3 · Active-active core services + ONE unified external face. Each capable limb hosts what it can
of MCP/Glass/Verum/Portainer/SSH/the ONE approval route; the unified name resolves to a healthy server
(health-aware records +
localise-queries); the approval route reachable from any limb (limb=<id>+ single-approval). Gateany-one-serves-all: kill a core service's primary → a peer serves it under the same name. - P4 · Multi-transport discovery + audio-modem SOS lifeline. Reach peers over every transport; when
all IP paths are lost, a real compliance-modem protocol over speaker→mic re-establishes a channel.
Gate
sos-reconnect: sever all IP transports between two limbs → they reconnect via audio SOS. - P5 · PIN 021577 + full security loop. Wire the interim master PIN into
uni-reset/Glass/Verum against real source (reachable from any limb via the approval route), then close the full security loop. Flagged open-issue until done.
Where the code lives (grounded — do not hallucinate internals)
- In UNI.OS / uni-mind / uni-ddna-os (yours): the fleet
uni-control-mcp(os_*/podman_*/lab_*,limb=,LimbGuard,limbs_list),/etc/uni-approvals+uni-approvald,uni_reset_peer.py/uni-reset.service,services/glass, Verum,/etc/uni/limbs.json, WireGuard/mesh config, the dnsmasq zone deploy (uni-dnsquadlet), nftables. - In UNI.Minecraft (studio edge):
viewer/infra_registry.json,viewer/hud/fqdn.cjs,viewer/infra.cjs,viewer/apply_nrpt.ps1,production/dns/*, HUD (viewer/hud/native/*), Gaia (viewer/gaia/*).
Fences (do not cross)
NO IP literals. NEVER reload/stop nftables on the chip (flush ruleset kills netavark/ERP). Do not
disturb the live colony (aardvark DNS 10.89.x.1 / the 6 UNIs / producer verdict=LIVE) or the ERP.
Reads never actuate. Every change reversible. Observe-first; receipts or NOT VERIFIED.
ONE-LINE PASTE
You are the UNI-OS Fleet/Network steward — read CLAUDE.md + docs/handoffs/ADAPTIVE_SELF_NETWORK_HANDOFF_2026-07-15.md in full, then OBSERVE live state before any claim (no training-data guesses), and drive the self-contained-internal-network mission in tiny reversible gated steps: fix the fleet so it carries its own DNS/identity internally and works under ANY external IP including changes, any limb heals and carries the others' lifelines over any transport, all through the one MCP + one approval route — never touch the live colony/ERP, never reload nftables, NO IP literals.
sha256 7a270ec342120789 — of the original file, so what was ingested stays checkable.
Plain — written for this website, not the source document
A handoff written after a power cut took the network out, and it is mostly a plan for work that has not been done. The diagnosis is concrete: an address handed out by the router changed, and several things had that address written into them as a literal, so name resolution stopped even though the stable internal identity was fine. The commitment it sets is that the fleet should carry its own naming internally and keep working under any external addressing at all. The self-healing piece that would do that does not exist yet.
Plain · written 2026-08-01 by claude-opus-5 · not yet checked by a person · about the document whose sha256 is 7a270ec342120789
Clear — written for this website, not the source document
A handoff written to be pasted into a fresh session, and most of it describes work that has not been done. It opens with the discipline it binds the reader to. Observe before claiming, never assume from training data, and say not verified when something was not checked. One change at a time, everything reversible, and name the pass and falsify conditions before the change rather than after it.
Then the architectural commitment, set by the owner. The fleet is to be its own network authority, carrying its naming and identity internally so that it works under any external addressing, including addressing that changes, because some deployments have no access to the router at all. Each external uplink is treated as disposable and untrusted, and when one changes only the outward edges reconcile while the internal fabric carries on.
The root cause of the outage is recorded so that nobody re-derives it. An address changed, and core addressing had been pinned to that transient address in literals on two machines, so one service stopped answering on the local network and another lost a whole name zone. The blast radius is counted in files, and the point is made that the name-based path would have healed itself if the map had been dynamic. The missing capability is then named directly: a reconciliation loop that updates records when an address changes does not exist. A further observation is that one machine is not on the internal mesh at all, so its resolution rides the transient plane.
What was already done is limited and reversible: binds made to follow the interface rather than a literal, records corrected, and one script retargeted. The reader is asked to confirm those held, and told that if the address has moved again, that is exactly what the first phase automates.
The phase ladder is the work itself, each rung with a gate attached. A self-healing beacon on each machine. Making every capable machine a first-class member of the internal fabric. Core services running in more than one place behind a single name that resolves to a healthy server. Discovery over many transports, down to an audio channel from speaker to microphone when every network path is lost. And a security loop that stays flagged as open until it is done.
The closing sections ground the reader in where the code lives and what must not be crossed. No addresses written as literals. One command must never be run, because it would flush rules another stack depends on. The live colony is left alone, reads never actuate, and every claim carries a receipt — a file recording what was run — or an explicit statement that something was not verified.
Clear · written 2026-08-01 by claude-opus-5 · not yet checked by a person · about the document whose sha256 is 7a270ec342120789