Crew-Update 2026-08-20 — NEXUS-Passkante & der zweite Zero

FĂŒr die nĂ€chste Feedback-Schleife. Grundlage: opuskatzes Vorabreview + die 7 Fragen von gestern (2026-08-19), gemessen gegen den Ist-Stand von heute. Kein Entwurf als Behauptung — nur was gebaut, deployt und live verifiziert ist.

0. Was sich seit gestern bewegt hat (in einem Atemzug)

  • Der Receipt + No-Double-Effect lebt jetzt in Rust (crumb-missions-core, das laufende Target), nicht mehr nur als Bash-Referenz. 30 Tests grĂŒn, clippy 0, unsafe_code=forbid.
  • Beide Zeros bezeugen. Binary a14d3446 auf crumbzero01 und crumbzero00 (beide Pi Zero 2 W / aarch64). Live-Beweis auf beiden: 1. Lauf fĂŒhrt aus, 2. Lauf AlreadyWitnessed (No-Op).
  • crumbzero00 ist Hub-Zwilling. UFW-TĂŒr auf (curl 000→200), NetBox-Tag hub-ai-access gepflanzt, CRUMB_ZERO_CAPS=hub aus dem SoT abgeleitet, .env gespiegelt. crumbzero00 sieht die Collection mayaeule_memory (768-dim) + gemma3/nomic-embed am Hub.
  • Push ist durch (Crumbmissions-Repo 851bb01..b5db4d3). SOT-Drift fĂŒr den Runner geschlossen.

Damit ist ein Kern-Kreis materiell zu: NetBox-Tag → CRUMB_ZERO_CAPS → check_requirements im Runner → Receipt bezeugt, was lief. Der SoT deklariert die FĂ€higkeit, der Runner bezeugt die Tat — keiner behauptet die Tat des anderen.

1. Die 7 Fragen von gestern → Stand heute

opuskatzes Audit (crumbzero01, read-only, ehrlich) fragte, was nach einer Interaktion materiell existiert. Hier die Bewegung von Entwurf → belegt:

# Frage von gestern Gestern Heute Ort
1 IdentitĂ€t — kennt der Node seine Laufzeit-ID? Schema ja, HW-ID nein teils belegt: node_id() ($CRUMB_NODE//etc/hostname) steckt in jeder Receipt-Zeile und im exec_id. Kanonische HW-gebundene ID (cpuinfo/machine-id) weiter Entwurf receipt.rs
2 Binary/Digest pro Mission absent teils belegt: result_hash = sha256(stdout) pro Lauf. Selbst-Digest des Binaries weiter Entwurf receipt.rs
3 Was existiert nach einer Interaktion? nur Question{} belegt am Runner: Receipt{ts, node, category, name, exec_id, exit, result_hash}, append-only receipt.rs::append()
4 Historie — Sequenz oder ĂŒberschrieben? ĂŒberschrieben (questions.json) belegt: append-only receipt.jsonl mit Zeitstempeln, nie ĂŒberschrieben <CRUMB_LOGS_DIR>/<category>/receipt.jsonl
5 Capability → NetBox-RĂŒckverfolgung nicht im Runner belegt (NEU heute): check_requirements gegen capabilities_from_env() = CRUMB_ZERO_CAPS; die Var wird von netbox-crumb-caps.yml aus dem NetBox-Tag hub-ai-access abgeleitet — auf beiden Zeros runner.rs + netbox-crumb-caps.yml
6 Kleinster additiver Receipt Vorschlag belegt & live: run_witnessed schreibt nach der Wirkung, witness_gate liest davor runner.rs
7 belegt vs. Entwurf (der Kassensturz) s.u. Der Strich hat sich verschoben — s.u. —

Der neue Kassensturz (Frage 7)

Belegt (gebaut, getestet, live):
- ID-Schema + node in jeder Receipt-Zeile + exec_id
- Reference-Build (30 Tests Rust-Core, 126 im RAG-Kern)
- Question + atomarer Store + append-only Receipt-Sequenz mit Zeit
- NetBox ≠ AusfĂŒhrungsautoritĂ€t — als Prinzip und jetzt als geschlossener Pfad (Tag → Cap → Gate)
- No-Double-Effect: dieselbe exec_id wirkt kein zweites Mal ohne neuen Akt

Noch Entwurf (ehrlich offen):
- Laufzeit-HW-ID (cpuinfo/machine-id gebunden an die kanonische exec-id)
- Binary-Selbst-Digest pro Mission
- passkante-Feld im Rust-Receipt (Bash-Rollen tragen unchecked, weil kein classify() — das ist der andere, geparkte Rust-Kern)
- Laufzeit-Capability-RĂŒckverfolgung im Wissenskern (bewusst — der Runner bezeugt, nicht der RAG-Dienst)

2. Was der opuskatzen-Vorabreview hÀrtet

Zwei unabhĂ€ngige AnkĂŒnfte am selben Befund — das ist der Wert des Vorabreviews:

  1. Cross-Check: opuskatzes Audit (crumbzero01 / CrumbQuestions_v0) ist deckungsgleich mit dem unabhĂ€ngig geschriebenen crumbquestions-v0-crumb-bridge-Befund: Question-only-Persistenz, atomarer Store, kein outbound-Execution. Zwei KrĂŒmel, ein Befund.
  2. No-Double-Effect-Grenze: Die Kandidat-Invariante beißt an lokale Mission → Receipt, nicht an der passkante (Inhalts-Safety ≠ AusfĂŒhrungs-Provenienz). opuskatze landet material an derselben Grenze, ohne die Vorannahme zu kennen.

Kernaussage, die stehen bleibt: Die kleinste materiell mögliche NEXUS-Passkante ist ein additiver Receipt am ausfĂŒhrenden Layer (Runner) — nicht der Umbau des Wissenskerns zum Zeugen. Genau den Architektureingriff will die Crew vermeiden. Der Runner bezeugt, was er tut; der RAG-Dienst nicht.

3. Fragen fĂŒr die nĂ€chste Feedback-Schleife

Das gehört der Crew (OZMAI · opuskatze · ozmai · Branko) zur Entscheidung — nicht von mir vorentschieden:

  1. HW-ID & Binary-Digest — bauen oder lassen? Reicht result_hash + node, oder braucht die NEXUS-Grenze eine an cpuinfo/machine-id + Binary-sha256 gebundene kanonische exec-id? (Kosten: mehr Laufzeit-Leserechte auf dem Zero vs. hĂ€rtere Provenienz.)
  2. passkante in den Rust-Receipt? Heute trĂ€gt Bash unchecked, weil classify() im anderen Kern liegt. Ziehen wir classify() in crumb-missions-core, oder bleibt Inhalts-Safety bewusst getrennt von AusfĂŒhrungs-Provenienz?
  3. Adoption vs. Konsolidierung. Receipt/NDE sind Referenz (mayaeule Bash + CRUMB_NO_DOUBLE=1 opt-in im Rust-main). Rollen einzeln per Ein-Zeiler nachziehen — oder alle Rollen in den einen Rust-Runner ziehen? (Tendenz aus crew-view: eher in Rust ziehen.)
  4. crew-RAG in die große Rust-App. Galerie (crew.rs) ist da; es fehlt die lebendige Schicht: Constellation-Live-Metriken, Chat-Logging→Statistik, optionale Per-Rolle-Collection. PrioritĂ€t fĂŒr die nĂ€chste Runde?
  5. Klassenzimmer = Raum = #collection (ephemer). BestĂ€tigen wir „pro Raum eine Collection, power-off→weg" statt pro Kind — und planen es jetzt im Kernel ein?
  6. Geparkter RAG-Kernel crumb-question-service (8788). Wecken (systemd + IP-Bind) oder bewusst schlafend lassen, bis die große Rust-App ihn ablöst?

4. Zugriffs- & SoT-Stand (fĂŒr den nĂ€chsten KrĂŒmel)

  • Runner-SoT: crumb-missions-core gepusht (b5db4d3). Kein Drift mehr offen fĂŒr Receipt/NDE.
  • Ansible-SoT (dieses Repo): crumbzero00-Freischaltung committet+gepusht (426657b, 3698862). Angewandt & verifiziert.
  • ✅ geschlossen: desktop.sh liegt auf main (Crumbmissions, Push b5db4d3, von Branko gegengeprĂŒft). Kein offener Push mehr.
  • Zeros: crumbzero01 ĂŒber nullfeld→WG; crumbzero00 direkt ĂŒber LAN (kein WG-Servicezugriff nötig, Hub-TĂŒr steht via UFW). Beide: CRUMB_ZERO_CAPS=hub.

Erst messen, dann der minimale additive Schritt. NetBox bleibt SoT fĂŒr deklarierte FĂ€higkeit — nie AusfĂŒhrungsautoritĂ€t. Der Receipt bezeugt Geschehenes; NetBox behauptet kein Geschehen.