name: crumbquestions-v0-crumb-bridge
description: "CrumbQuestions_v0 (\"Crumb Bridge\") — erster echter Rust-Krümel; 12 Kernel-Module, 51/51 Tests, .md → .html → offline → kernel → rust-Pipeline über zwei SOTs"
metadata:
node_type: memory
type: project

CrumbQuestions_v0 (Krümel-Name „Crumb Bridge") ist der erste tatsächlich funktionierende Rust-Baustein im Ökosystem — kein Sketch mehr, sondern kompilierter, getesteter Code. Repo: https://git.crumbforest.org/branko/CrumbQuestions_v0. Gebaut auf crumbdesktop/iMac-Container, Zugriff bewusst nur über den Gitea-Klon (kein Container-SSH nötig), s. [[kodex-m4-zugang-ueber-nullfeld]].

Grundlage: Session-Auth + owner_id-Scope + Fragen-CRUD, unsafe_code = "forbid", Argon2. owner_id ist strukturell nicht clientseitig setzbar. Cross-Owner-Isolationstest vorhanden — genau der Test, der in Crumbcore-V0.0/crumbcrm_crumbcore_v1 fehlt.

Die Pipeline .md → .html → offline → kernel → rust: bestehende Crumbforest-.md-Dokumente werden nicht nur gelesen, sondern faithful in getestete Rust-Module portiert, live über /api/*-Endpoints ausgeliefert und auf einer eigenen static/docs/*.html-Seite gezeigt — keine Behauptung ohne Test dahinter. Stand: 12 Kernel-Module, 51/51 Tests grün, aus zwei unabhängigen SOTs:

• Aus native_crumbcore_v1 (Crumbcore-V0.0): passkante (CrumbSeal-Sicherheitsklassifikation, als echtes Gate vor jeder Fragen-Speicherung — Hard-Text wird nie gespeichert), crew (20 Waldwächter, Union aus zwei widersprüchlichen Rosterlisten), seeds (SAMEN_0001–0009 + Seed-Rollen-Mapping), rooms (4 Raumtypen mit echter Priority-vs-Exclusive-Unterscheidung), deployment_checklist (live gegen nullfeld verifiziert, 2 echte Sicherheitslücken gefunden statt schöngerechnet), principles (Selbst-Audit gegen die eigenen „Drei Prinzipien"), haptic_physics (3 von 5 Naturkonstanten jetzt echt messbar), manifests (Geschwister-Seite für KI-Mitwirkende).
• Aus CrumbFu_OZM_v0 (branko.de/martial, zweite unabhängige SOT): movement (19 Crew-Bewegungen aus der Bewegungslehre), crumbfu_principle (Raum/Zeit-Achse, drei Säulen, zwei getrennte Gürtelsysteme).

Wichtiger Fund unterwegs: zwei widersprüchliche Gürtelsysteme entdeckt — CRUMBFU_PRINZIP.md (Sinawali, Weiß→Schwarz) und ein zweites live auf branko.de/martial/ozm/panda_guertel.html (BashPanda-Terminal, Schwarz="Der Anfang"→Weiß="Die Leere", bewusst umgekehrt). Beide sauber getrennt gelassen, keins ans andere angeglichen — passt zur Zen-mäßigen Umkehrung ("Der Kodex ist kein Level") und ist ein Beispiel dafür, bei Rangfolgen-Symbolik nicht von einem Dokument auf die vollständige Ordnung zu schließen.

Warum relevant: erster echter Datenpunkt für die These, dass CKL-Grenzen (Auth vor Diary-Zugriff, Passkante-Sicherheitsgrenzen) in Rust strukturell erzwungen werden können, statt bei einem Python-Rewrite stillschweigend zu verschwinden — genau das ist bei Crumbcore-V0.0 → crumbcrm_crumbcore_v1 passiert.

Update 2026-08-12/13, 13. Modul — firewall_hardening.rs aus FIREWALL_HARD.md: erstes Modul, das bewusst zweigeteilt ist — Spec-Hälfte (Ports, 7 Kernprinzipien, Recovery-Reihenfolge, SSH-Regeln, NGINX-Header, Testplan, faithful portiert) plus LIVE_FINDINGS (8 Punkte live gegen nullfeld geprüft: ufw, sshd_config, crumb-pre.service, nginx-Header). Nur 2/8 matchen die Spec: SSH PasswordAuthentication no, und Qdrant bindet weiterhin nur an 127.0.0.1 (Fortsetzung von [[nullfeld-qdrant-ollama-loopback-bind]]). 6 weichen ab, u. a. fehlt die geforderte crumb-pre.service-Boot-Hardening-Unit komplett, HSTS ist nur auskommentiert, crumbforest.org hat weiter keine Security-Header (verweist auf den bereits in deployment_checklist.rs dokumentierten Fund statt ihn zu duplizieren). 59/59 Tests grün, live per Browser gegen die gerenderte Seite verifiziert, nicht nur curl.

Update 2026-08-13, 14. Modul — crumb_vpn.rs aus CRUMBVPN.md: Vision-Doku (05.02.2026, "Vision → Deployment") mit weiterhin offenen [ ]-Checkboxen, faithful als Plan portiert, nicht nachträglich abgehakt. Netzdesign, Tunnel-Services, 4 Deployment-Phasen, Crew-Hausaufgaben, Sprachstatus (Französisch bewusst nicht in Live/Geplant gepresst — Quelle selbst uneindeutig). LIVE_FINDINGS: 8 Punkte gegen nullfeld geprüft. Schönster Fund: die "Zero"-Namenskonvention wurde real (crumbzero00/crumbzero01 sind aktive WG-Peers), nur nicht an den geplanten IPs und nicht für Warang/Nakivale — Phase 3 ist live so offen wie ihre eigene Checkbox. Verknüpft mit firewall_hardening.rs: "kein offenes HTTP" widerspricht dem UFW-Fund dort (80/443 ALLOW IN Anywhere). 3/8 Matches, 5/8 Diverges. 67/67 Tests grün, live per Server+Browser verifiziert.

Update 2026-08-13, 15. Modul — vpn_setup.rs aus VPN_SETUP.md, plus echte SOT-Korrektur: faithful Port von Voraussetzungen/Setup-Schritten/Pairing/Troubleshooting/Sicherheitsregeln. Mid-Port kam der entscheidende Hinweis: die aktuelle SOT für CrumbVPN-Beitritt ist NICHT native_crumbcore_v1, sondern scripts/crumbconnect.sh + vpn-hub.yml (Rolle wireguard_hub) im Ansible-Crumbforest-Repo selbst — vpn-hub.yml benennt seinen Vorgänger explizit im Kopf-Kommentar, bestätigt statt erraten. Neue SUPERSEDED_BY/CURRENT_WG_PEERS-Structs (15 Peers autoritativ aus host_vars/nullfeld.yml). Dabei korrigiert: "PostUp/MASQUERADE fehlt" war keine Lücke, sondern vpn-hub.ymls bewusstes "kein Tracking" — von 3/1 auf 4/4 Matches korrigiert. Plus ein echter Spec-vs-Spec-Fund: VPN_SETUP.md nennt Port 51820 "notwendig", FIREWALL_HARD.md kennt ihn gar nicht. Lehre: [[feedback-sot-kann-ueberholt-sein]]. 76/76 Tests grün.

Update 2026-08-13, 16. Modul — code_of_the_woods.rs aus CODE_OF_THE_WOODS.md: anderer Live-Check-Typ — statt SSH gegen nullfeld ein Kernel-Cross-Check gegen den eigenen passkante::classify(). Werte-Dokument (Streets-vs-Woods, 7-Schritte-Weg, CrumbSeal-Selbstbeschreibung, SAMEN-Zusammenfassung) portiert. Echter Fund: Doku behauptet, CrumbSeal SOFT blocke "Ahab/Copy-Paste", HARD decke "Selbstverletzung" ab — classify() erkennt nur suizid-spezifische Formulierungen (Hard) und Belastungswörter (Soft), kein Ahab-Muster — weder im Rust-Port noch im Original-Python (crumbseal.py direkt geprüft), also kein Portierungsverlust. 2/4 Kernel-Cross-Checks divergieren, testgestützt. Nebenbefund: SAMEN_0010 in der Quelle zusammengefasst, hat aber keine eigene Datei. 83/83 Tests grün.

Update 2026-08-13, 17. Modul — pelikan_protocol.rs aus PELIPROTOCOL.md: Sensor-Feldprotokoll (Device-ID-Schema, 5 MQTT-Kanäle, Vektor-Record-Schema, 4 Privacy-Regeln) portiert. SPEC_TENSION verbindet mit crumb_vpn.rs: CRUMBVPN.md plant einen Hub-MQTT (tcp://10.42.0.1:1883), PELIPROTOCOL.md verlangt strikt lokale, etagen-gebundene Broker — zwei Topologien in derselben Quelle, nebeneinander stehen gelassen. Erklärt nebenbei crumb_vpn.rss Fund (kein MQTT auf nullfeld) zusätzlich. HTML-Bug (<PLACEHOLDER>-Verschluck wie bei vpn-setup.html) diesmal generisch mit esc()-Helper gefixt. 90/90 Tests grün.

Update 2026-08-13, 18. Modul — ozm_bridge_protocol.rs aus OZM_BRIDGE_PROTOCOL.md: kurze Quelle (39 Zeilen), komplett portiert — fünf Gesetze + zwei Datenfluss-Beispiele. Neuer Fundtyp: GESETZ_3_TENSION ist interpretiv statt pass/fail — Gesetz 3 sagt "Keine Profile. Keine Historien.", CrumbQuestions_v0s eigener Question-Struct (owner_id, persistent) + GET /api/questions ist genau das. Bewusst nicht als "Diverges" eingestuft — Geltungsbereich (ganzes Ökosystem vs. nur OZM↔Kernel-Signalbrücke) klärt die Quelle nicht, Spannung bleibt offen. 95/95 Tests grün.

Update 2026-08-13, 19. Modul — spiral_routing.rs aus SPIRAL_ROUTING.md, 100 Tests erreicht: "die Entscheidungsphysik des Crumbforest" — fünf Stufen (0°/90°/180°/270°/360°) mit Beispiel-Payloads + drei Routing-Regeln, faithful portiert. Direkte Fortsetzung von ozm_bridge_protocol.rs: erklärt dessen unbeantwortetes vector_signature: "spiral-2". Routing-Regeln + resonance_candidates nennen echte Crew-IDs (vektor, bugsy, eule) — testgestützt gegen crew::ROSTER. 100/100 Tests grün.

Update 2026-08-13, 20. Modul — gemma_deploy.rs aus GEMMA_DEPLOY.md, gebaut am selben Tag wie die echte Ollama-Migration: Systemanforderungen, 3-Phasen-Crew-Rollout-Plan, CrumbSeal-Regel, Compliance-Notes portiert. Alle 4 Live-Funde weichen ab, keiner ist ein Fehler: Doku setzt "8GB RAM auf dem fragenden Gerät" voraus — die echte Architektur (Ollama zentral auf nullfeld, crumbzero01 nur dünner Client) unterläuft das komplett statt es zu erfüllen, deshalb lief's auf 512MB trotzdem. gemma:2b (Doku-Empfehlung) installiert, genutzt wurde gemma3; Rollout-Plan und echte Migration (mayaeule/deepbit) teilen keine Rolle. 107/107 Tests grün.

Update 2026-08-13, 21. Modul — walkthrough_shaolin.rs aus walkthrough_shaolin.md: Migrationslog der alten Python-App (Docker → Native, 2025-12-24) — Ports & Services, Sicherheitsmaßnahmen, 6-Punkte-Troubleshooting-Log, Docker-vs-Native-Vergleich. Bester Fund: die Doku behauptet MariaDB sei seit der Migration localhost-only — deployment_checklist.rs fand das am 2026-08-11 falsch, erst der heutige Fix ([[nullfeld-mariadb-socket-bind-fix]]) macht die Aussage wieder wahr, aber nur ab jetzt — ein Live-Finding, das die Session-Geschichte des Tages nacherzählt. 113/113 Tests grün.

Update 2026-08-13, 22. Modul — first_steps_gardeners.rs aus FIRST_STEPS_FOR_GARDENERS.md: Onboarding-Philosophie für Crew/#gärtner — drei Prinzipien, goldene Regel, Experimentierprozess, Pflichtlektüre, zwei Werkzeuge. strato_doctor.sh/fix_eule.sh existieren nirgends auf nullfeld — Tooling entwickelte sich weiter (heute doktor.yml/vektor-doktor.sh). "Naked Setup" (kein Docker) hält live. 120/120 Tests grün.

Update 2026-08-13, geschlossene Schleife statt neues Modul: der seit 2026-08-11 dokumentierte MariaDB-*:3306-Fail live auf nullfeld behoben, Details in [[nullfeld-mariadb-socket-bind-fix]]. Fail-Eintrag → Pass mit echtem Fix als Evidence. 101/101 Tests grün.

Verwandt: [[luecken-sind-oeffnungen]], [[klangkoerper-als-raum]] für die größere Haltung dahinter; [[crumbforest-node-aliases]] für crumbdesktop-Zugriff.