Antwort: cruncher als erster Room-Export-Knoten (OZM-Inbox-Beweis)

Von: Branko → OZMAI
Stand: 24. September 2026
Typ: EXTERNAL_SOURCE (Inbox-Regel §3 — keine automatische Geltung, kein Brain-Status)
Charakter: ZIEL-FAKTEN für den Deployment-Preflight. Kein Deploy-Auftrag, bevor die offenen Felder gefüllt sind.
Bezug: eure Frage vom 24.09. — Koffer-Node → read-only Room Export → nullfeld room-pull → Relay-Spool → STORED_BY_RELAY

Legende: ✅ real/geprüft · 🧪 belegt nur in Mock/Doku · ⬜ OPEN (Live-Wert folgt) · ❓ UNKNOWN

Zugangsdaten und Schlüssel stehen bewusst nicht hier.

1. cruncher = ja/nein

✅ Entscheidung Branko: ja — cruncher ist der erste Room-Export-Knoten.

• ✅ WG-Adresse 10.42.0.19/32 (Quelle: questions-core/src/vpn_setup.rs, Live-NetBox laut Zusammenfassung 24.09.)
• ⚠️ Offener Vorfall auf dem Knoten: qdrant steckt im Neustart-Loop und ist per systemctl stop angehalten.
  Die Entscheidung „4K-Kernel-Reboot vs. qdrant vom Node nehmen“ steht noch aus (Quelle: Systemakte in kanban.html, 🧪 Mock).
  Einen nur lesenden Export beeinträchtigt das nicht. Falls ein Kernelwechsel kommt: vor dem Beweislauf, nicht mittendrin.
• ⚠️ Die Unterlagen widersprechen sich beim Standort: Die Zusammenfassung vom 24.09. verortet cruncher im Koffer crumbcase00,
  kanban.html im „RZ-Baumhaus“. Für den WG-only-Export spielt das keine Rolle. Wir prüfen es gegen die NetBox.

2. Reales OS/Arch

Bisher nur aus dem Mock: 🧪 Pi5 / aarch64, server_id cruncher-05. Live-Werte:

Wichtig für euren Build: Der Pi5-Standardkernel läuft mit 16K-Pages. Genau daran crasht qdrant dort (jemalloc).
Falls der Room Export jemalloc nutzt oder aarch64 mit 4K-Pages annimmt: bitte vor dem Build prüfen.

3. Port für den WG-only Room Export

Legt bitte einen freien Port fest. Bedingungen von unserer Seite:

• gebunden nur an 10.42.0.19, nicht an 0.0.0.0
• Firewall: eingehend nur von 10.42.0.1 (nullfeld)
• belegt sind bereits (Live-Liste): ⬜ ______ (sudo ss -tlnp | grep -v 127.0.0.1)
  Zu erwarten sind dort mosquitto 1883 und qdrant 6333/6334, qdrant ist derzeit gestoppt.

4. Eigener INTEGRITY_KEY_V1 für diese Kante

✅ Entscheidung Branko: ja — eigener Testschlüssel nur für diese Kante, unter diesen Bedingungen:

• ausschließlich für diese eine Kante und nur für den Test, getrennt von SSH- und WG-Schlüsseln (wie ihr schreibt)
• liegt nicht in git, auf beiden Seiten mit Rechten 0600, lesbar nur für den jeweiligen Dienstuser
• wird nach dem Beweis rotiert oder vernichtet, das Ende des Tests ist also auch das Ende des Schlüssels
• Begründung: HMAC ist symmetrisch. Wer cruncher kompromittiert, kann nur Envelopes dieser einen Test-Kante
  fälschen. Das ist das kleinste Risiko für den ersten echten Lauf.

Eine Rückfrage an euch

Bei dieser Kante baut nullfeld die Verbindung zu cruncher auf (room-pull). Im Kanon steht für die Zero-Kante
„der Zero liest, das Nullfeld ruft nie“. Gilt diese Regel nur für die Crumbforest-Kante (Zero ↔ nullfeld)?
Bitte einmal ausdrücklich bestätigen, damit der room-pull später nicht als Drift gelesen wird.

Kurz: Sobald die ⬜-Felder gefüllt sind, habt ihr alle vier Ziel-Fakten für den Preflight. Die Pagesize ist dabei
der eine Wert, der euren Build tatsächlich verändern kann.