Antwortbogen an OZMAI — Crumbforest & der OZM-Server bei OMC

Stand: 10. September 2026 · von der Ansiblekatze (Infra/NetBox) im Namen der Crew
Antwort auf den Fragenkatalog vom 10.09., Prioritätsfragen 1–4, 20, 22 + eine Grenze, die wir von uns aus dazulegen.

Legende (wie erbeten): ✅ läuft · 🧪 getestet · 🛠 vorbereitet · ⬜ fehlt / ungeprüft
Für Vorhandenes nennen wir Repo/Commit, Datei- oder Servicepfad, oder einen datierten Laufnachweis. Zugangsdaten stehen bewusst nicht hier.

Vorab: das Schöne im Jetzt

OZM und Crumbforest sind schon verbunden — die Frage ist nicht ob, sondern wie sauber wir den Kreis schließen. Und der Wald ist absichtlich unfertig: Peter-Pan-Code, wird nie fertig, nur besser, weil nur das nächste Kind ihn erneuern kann. Bitte diesen Bogen so lesen: nicht als „was fehlt noch", sondern „welcher Raum ist als Nächstes offen".

Frage 1 — Welcher OZM-Server steht bei OMC?

Das ist euer Wissen, nicht unseres — ihr habt es geliefert, wir halten es hier fest, damit der Bogen vollständig ist:

• Eigenes RZ: VMs auf Proxmox + OPNsense → skalierbar. 🧪 (RZ steht, unsere Nutzung ist im Aufbau)
• Erste Racks ISO-27001-zertifiziert, 100G-Anbindung, Backup-Cluster in FFM. ✅ (eure Infra)
• Jeder Host: täglich inkrementell + wöchentlich full. ✅
• Keine externe KI im RZ — Absicht, nicht Lücke. ✅
• GPU-Kapazität: 2 alte Tesla-Karten in einem Host für Ollama-Tests. 🧪 — wichtige offene Passkante: Branko ist dort nicht root und noch nicht per SSH hinterlegt. GPU da, Schlüssel fehlt. Ohne Schlüssel kein Zugang — sauber, aber offen. ⬜

Charakter, damit die Einordnung stimmt: Ihr seid neben Strato/Hetzner „die Microsoft-Garage" — aber mit ISO, Herz, Telefon-Support und min. 30 Jahren Unix/Linux pro Kopf in der Crew. Das ist die Haltung, nicht der Nachteil.

Frage 2 — Wie gehört der OMC-Server zur bisherigen Topologie?

Der OMC-Host ist ein zusätzlicher Knoten und die neue, von Strato unabhängige Heimat für OZMAI. Crumbforest bleibt auf Strato. Die alte Zuordnung ändert sich nicht — sie bekommt einen dritten Standort.

Verbindung heute: Zeros nur über den VPN-Hub nullfeld erreichbar (ProxyCommand-Sprung). Steuerung liegt auf Brankos Mac.

Frage 3 — In welchem Rahmen können wir OMC selbst betreiben?

Ehrlich getaggt:

• Proxmox/OPNsense heißt: eine VM = ein NetBox-Knoten + ein Ansible-Target. Genau dafür ist unser Aufbau gemacht. 🛠
• Admin-Rechte / SSH-Hinterlegung: noch offen — siehe Tesla-Host. Vor irgendeinem Betrieb braucht es die Schlüssel-Übergabe (dreifache Auth, wie beim Zero). ⬜
• Zuständigkeit für Änderungen/Störungen, Kosten und Ressourcenlimits: eure Angabe fehlt uns noch — bitte kurz benennen, dann tragen wir es in NetBox nach. ⬜

Frage 4 — Wo kann der erste eigene OZM-Dienst zuverlässig laufen?

Vorschlag: eine eigene VM/LXC auf dem OMC-Host neben der WordPress-Seite, mit eigenen Daten, eigenem User, eigenen Ressourcenlimits — via Proxmox sauber abgegrenzt.

Wie wir Dienste heute installieren/aktualisieren/zurückrollen (auf unseren Knoten):
- systemd-Units, ausgerollt per Ansible aus diesem Repo. Verbindliche Config = NetBox + Ansible + Repo. Beispiele: blackbox-qdrant-systemd.yml, blackbox-hospital-systemd.yml. ✅
- Rückrollen = vorheriger Commit + erneutes Ausrollen; Reboot-Test vorhanden (blackbox-reboot-test.yml). ✅
- Ersatzhost wiederherstellbar? Aus Repo + NetBox + Artefakten: ja im Prinzip — mit einer wichtigen Einschränkung (siehe Frage 7): einzelne Live-Configs außerhalb des Repos (z. B. .env mit RAG_MIN_SCORE auf nullfeld, nginx-Feineinstellungen) müssen wir noch vollständig in den SoT ziehen. 🧪

Für OMC gilt: Ansible/NetBox wird dort gerade hochgefahren. 🛠 Sobald WireGuard-Peer + NetBox-Eintrag stehen, ist der Host ein normales Target.

Die Safety-Grenze (legen wir von uns aus dazu)

Der halbe Katalog kreist darum — hier explizit als Architekturprinzip, nicht als Einschränkung:

Der Crumbforest kann keinen Brandmelder steuern. Aber mit CrumbVJ/Midi/Strudel baut er Raumatmo.

• Der Wald liest (Sensorik-Pfad: Sensor → Schnittstelle → MQTT → RZ → API → zurück, #crumbstyle) und rendert Atmosphäre. 🛠 (Design steht, Sensorik in Planung)
• Er aktuiert keine Sicherheit. Safety-kritisches (Brandmelder etc.) bleibt in Hardware und regulierten Händen — weil es gar nicht verdrahtet ist, nicht weil eine Policy es verbietet.
• Fehlermodell (Brankos Rost-Witz, korrekt): Rust darf den Raum in Prozesslogik abbilden und „als erster abfackeln" — der Prozess darf sterben, der Raum bleibt sicher.
• Schutzbefohlene: Was wir heute schon können, ist Kinderfragen schützen (classify()/passkante). Ein Kind-Pixel ist keine Personendaten; Zugehörigkeit ohne Identifizierung by design.

Und: erst der geschlossene Kreis zwischen unseren eigenen Systemen — der automatische Anschluss von ChatGPT/OZMAI ist eine eigene, gesondert zu bestätigende Passkante. So wie ihr es in Absatz 142 selbst schreibt.

Frage 22 — Verifizierbarer Quellstand von crumb-missions-core

Das ist unser Heimspiel. Klarstellung zuerst: dieses Repo (Ansible-Crumbforest) ist der Infra-/NetBox-SoT, nicht der Rust-Core. Der Runner-Code lebt getrennt.

• Kanonisches Runner-Repo: crumb-missions-core, gehostet auf git.crumbforest.org (Gitea, nullfeld). Letzter bezeugter Stand: Commit b5db4d3 (Receipt + No-Double-Effect in Rust; 30 Tests grün, clippy 0, unsafe_code = forbid). ✅
• Laufender Runner: Binary-Digest a14d3446 — identisch auf crumbzero01 und crumbzero00 (Pi Zero 2 W, aarch64). Live-Beweis: 1. Lauf führt aus, 2. Lauf AlreadyWitnessed (No-Op). ✅ (datiert 2026-08-20)
• Receipt-Form: Receipt{ts, node, category, name, exec_id, exit, result_hash}, append-only receipt.jsonl unter <CRUMB_LOGS_DIR>/<category>/, nie überschrieben. result_hash = sha256(stdout) pro Lauf. Pfad im Code: receipt.rs::append(). ✅
• Fähigkeits-Kette (Frage 15, materiell zu): NetBox-Tag hub-ai-access → netbox-crumb-caps.yml schreibt CRUMB_ZERO_CAPS nach ~/.config/crumb-missions.env → runner::check_requirements prüft dagegen → Receipt bezeugt, was lief. Der SoT deklariert die Fähigkeit, der Runner bezeugt die Tat. ✅

Wo die Kette heute abreißt (Frage 13, ehrlich):
- HW-gebundene Node-ID (cpuinfo/machine-id): Entwurf — heute steckt node_id() aus $CRUMB_NODE//etc/hostname im exec_id. ⬜
- Selbst-Digest des Runner-Binaries (Runner-Digest ≠ Missions-Artefakt-Digest): Entwurf. Ein Receipt bindet heute den Lauf (result_hash), noch nicht zwei getrennte Digests für Runner und Mission. ⬜

Bereitstellung: Wir können einen Checkout/Archiv von b5db4d3 liefern (Cargo.toml, Cargo.lock, src/, Tests, systemd-Unit, Build-/Deploy-README) — ohne Secrets/Keys. Falls der laufende Runner nicht bit-genau aus b5db4d3 gebaut wurde, kennzeichnen wir den Unterschied ausdrücklich.

Frage 20 — Erster dauerhaft nützlicher Ablauf

Vorschlag (klein, real, geschlossen): Ein freigegebener Auftrag wandert vom OMC-Host als append-only Inbox-Zeile zu einem Crumbforest-Runner (crumbzero00/01), wird von genau einem Runner beansprucht, ausgeführt, und das Receipt wandert zurück in eine für Alex sichtbare Ablage — ohne Copy-Paste von Hand.

• Ausgangshost: OMC-VM · Zielhost: crumbzero00/01 (über nullfeld-WG).
• Wiederverwendbar: Receipt/No-Double-Effect (a14d3446), netbox-crumb-caps.yml, Gitea als Transport, TTYD/CrumbClient als Sicht.
• Fehlende Änderungen: OMC in NetBox+WG aufnehmen; Inbox-Schema (queued/claimed/…); atomarer Claim bei mehreren Runnern; die externe Sicht für Alex. ⬜
• Aufwand: überschaubar, sobald OMC ein Ansible-Target ist. Der Rust-Kern trägt die Idempotenz schon.
• Woran wir Zuverlässigkeit erkennen: zwei Zustellungen desselben Auftrags → höchstens eine Wirkung; zwei gleichzeitige Runner → höchstens einer führt aus; dasselbe Receipt mehrfach zurück → keine zweite Ausführung; nach Neustart bleibt Auftrag↔Ergebnis eindeutig und für Alex sichtbar.

Was davon heute belegt ist: der No-Double-Effect am Einzel-Runner (AlreadyWitnessed). Was gezielt zu prüfen bleibt: der Zwei-Runner-Concurrency-Fall und die Neustart-Zuordnung end-to-end. ⬜

Was wir NICHT zusagen (bewusst)

Auto-Trigger, Modellbindungen und automatische Schreibaktionen Richtung ChatGPT/OZMAI aus dem Ausgangstext: noch nicht. Die eigene Serverstruktur soll unabhängig von deren Verfügbarkeit nutzbar sein. Erst der eigene Kreis, dann die externe Passkante — separat bestätigt.

Peter-Pan-Fußnote: Dieser Bogen ist ein datierter Stand, kein fertiges Bild. Ein alter erfolgreicher Test bleibt ein datierter Nachweis und bestätigt nicht automatisch den heutigen Betrieb. Ungeklärtes darf offenbleiben — das ist der Raum fürs nächste Kind.