CrumbCore / Crumbforest – Bestandsaufnahme & nächste Pipeline

Status: Arbeitsdokument für die Crew
Stand: 2026-08-07
Provenienz: Workspace-Kopie unter /home/sysop/workspace/Crumbcore-V0.0

0. Leitplanke: CKL ist nicht verhandelbar

Crumbforest ist ein System für Kinder. Die Children’s Knowledge License (CKL) und ihre Schutzprinzipien sind daher kein nachträglicher Compliance-Check, sondern ein Architektur-Gate.

Keine technische Entscheidung gilt als akzeptiert, wenn sie eines dieser Prinzipien verletzt:

• kein Überwachen, Bewerten, Ranking oder Profiling von Kindern
• keine Manipulation oder Ausbeutung
• Datenhoheit und verständliche Nutzung
• sichere Trennung zwischen Kinder-/Tagebuchräumen
• nachvollziehbare Löschung und Exportierbarkeit
• Offline-first, lokale Kontrolle und transparente Grenzen
• keine heimliche Ausleitung von Inhalten an externe Modelle oder Dienste
• kindgerechte, erklärbare und nicht überfordernde Interaktion
• CKL bleibt bei Forks, Migrationen, Rewrites und Deployments sichtbar

Referenzen:

• LICENSE-CKL.md
• ETHICS.md
• DATA_PRIVACY_LOCATION.md
• HANDBUCH_KRUEMEL.md
• HUMAN_CRUMB.md
• MACHINE_CRUMB.md

1. Provenienz und Gegenstand der Analyse

Nicht vermischen:

Crumbcore-V0.0
  historischer/übergeordneter Anwendungskontext

Crumbcore-V0.0/native_crumbcore_v1
  native Debian-Betriebs- und Deploymentbasis

crumbcrm_crumbcore_v1
  separater Rewrite-/Weiterentwicklungsstand

Workspace
  Arbeitskopie für Analyse, Tests und neue Entwicklung

lokales Gitea :3000
  Zwischenstation, Review und Rückfallebene

git.crumbforest.org
  bewusster Veröffentlichungs-/Crew-Stand

Die Analyse startet mit:

/home/sysop/workspace/Crumbcore-V0.0/native_crumbcore_v1

Die native Variante wird immer zusammen mit der Anwendung im Parent-Repo betrachtet. Der native Unterordner enthält vor allem systemd-, NGINX-, Installations-, Backup-, VPN- und Sicherheitsmaterial; die RAG-/Chat-/Datenlogik liegt überwiegend unter app/.

2. Bekannter Ausgangsbestand

Codebase-Memory für Crumbcore-V0.0:

• 3.228 Nodes
• 6.265 Edges
• 291 Dateien
• 207 Funktionen
• 70 Klassen
• 77 HTTP-Routen
• 687 CALLS
• 277 IMPORTS
• 52 Testbeziehungen

Erkannte Sprachen:

• Python: 67 Dateien
• HTML: 63
• Bash: 43
• SQL: 7
• CSS: 7
• JavaScript: 1
• YAML: 1

Native-Scope:

• 1.178 Nodes
• 1.278 Edges
• 81 Dateien
• 46 Funktionen
• 19 Bash-Dateien
• 2 Python-Dateien
• 2 SQL-Dateien
• 54 Markdown-Dateien

Aktuelle Zielarchitektur des nativen Betriebs:

HTTPS → NGINX → FastAPI/Uvicorn
                    ├── MariaDB/MySQL
                    └── Qdrant

systemd:
  crumbforest.service
  crumbforest-indexing.service

Historische Entwicklung, die erhalten und verstanden werden muss:

CakePHP-Prototyp
  → erstes RAG ohne Agenten
  → Docker-App mit MariaDB + Qdrant
  → FastAPI-/Rollen-/Diary-Ausbau
  → natives Debian-Setup
  → VPN / lokale RZ-Struktur
  → NetBox + Ansible-Betreuung
  → Constellation/Sternenkarte für Qdrant

3. Pipeline der Bestandsaufnahme

Phase A – Herkunft, Laufzeit und Grenzen

• [x] Repo-Pfade, Remotes, Branches und Commits dokumentieren.
  Belegt 2026-08-07 (Codebase-Graph + git log, lokale Klone /Users/bmt/rewrite_core/):
  Crumbcore-V0.0 → git.crumbforest.org/branko/Crumbcore-V0.0.git, Branch main, HEAD 14a0e79 ("wuhuuu"), Arbeitsbaum sauber.
  crumbcrm_crumbcore_v1 (Rewrite) → git.crumbforest.org/branko/crumbcrm_crumbcore_v1.git, Branch main, HEAD f40b67e, Arbeitsbaum sauber.
• [ ] SOT, Workspace, lokales Gitea und veröffentlichter Crew-Stand klar markieren.
• [x] Tatsächliche Produktionspfade gegen Dokumentationspfade prüfen (/opt/crumbforest, Qdrant, MariaDB, NGINX).
  Belegt 2026-08-07, per SSH live auf backbone (87.106.12.97) und nullfeld (194.164.194.191) geprüft — wichtige Verwechslungsgefahr: /opt/crumbforest existiert auf beiden Hosts, ist aber zweierlei:
  — nullfeld (.org/.de/.com): die echte Crumbcore-App. systemctl zeigt crumbforest.service (aktiv, läuft) + crumbforest-indexing.service, dahinter MariaDB + Qdrant, seit Feb. 2026 live, aktiv genutzt (Crew, keine Kinder — s. Frage 3).
  — backbone (.io): kein crumbforest.service, sondern NetBox (seeds.crumbforest.io) plus separate Subdomain-Dienste (chat., forest., research., transformer., monitor., nopaper., ozmai.crumbforest.io) unter demselben Pfadnamen. Wer künftig "/opt/crumbforest" sagt, muss den Host mitnennen.
• [ ] Docker- und natives Setup als historische Varianten vergleichen.
• [ ] NetBox-/Ansible-Verantwortung und tatsächliche Quelle der Deployments nachvollziehen.
• [ ] Keine Secrets aus .env, Datenbanken, Logs oder Backups in dieses Dokument übernehmen.

Ergebnis: Provenienz- und Laufzeitkarte.

Phase B – Datenfluss und CKL-Grenzen

Für jeden Datenfluss dokumentieren:

Eingabe → Authentisierung → Speicherung → Embedding → Retrieval
        → Prompt/Provider → Antwort → Log/Audit → Löschung/Export

• [ ] Kind-/Benutzeridentität und Rollenmodell verfolgen.
• [ ] Tagebuch- und Kinder-Datenflüsse verfolgen.
• [ ] Qdrant-Collection-/Payload-Trennung prüfen.
• [ ] Prüfen, ob child_id in jedem Suchpfad sicher und unveränderbar gesetzt wird.
• [ ] Verhalten bei fehlender, falscher oder fremder child_id testen.
• [ ] Admin-, Demo- und öffentliche Pfade getrennt prüfen.
• [ ] Externe Provider und deren Datenweitergabe sichtbar machen.
• [ ] Chat-, RAG-, Prompt-, Fehler- und Audit-Logs auf Kinderinhalte prüfen.
• [ ] Löschung und Export über MariaDB, Qdrant, Logs und Backups verfolgen.
• [ ] Telemetrie, Ranking, Profilbildung und Tracking explizit ausschließen oder begründen.

Ergebnis: CKL-Datenflusskarte mit roten/harten Grenzen.

Phase C – Funktionale Architektur

• [ ] FastAPI-Einstiegspunkte und Router inventarisieren.
• [ ] ProviderFactory und Embedding-Provider untersuchen.
• [ ] Markdown-Chunking und Indexierungsreihenfolge dokumentieren.
• [ ] Qdrant-Collections und ihre fachlichen Bedeutungen kartieren.
• [ ] MariaDB-Schema und Relationen kartieren.
• [ ] Rollen-/Chat-Routing und crumbseal getrennt betrachten.
• [ ] Constellation-Datenquelle und öffentliche Sicht prüfen.
• [ ] Hintergrundindexierung und Startup-Reihenfolge prüfen.
• [ ] Backup-/Restore-Pfade einschließlich Qdrant prüfen.
• [ ] Vorhandene Tests ausführen, Lücken markieren und keine Tests durch reine Smoke-Checks ersetzen.

Ergebnis: belastbare Architekturkarte statt nur Ordnerübersicht.

Phase D – Betriebs- und Sicherheitsprüfung

• [x] systemd-Units auf Pfade, Benutzer, Rechte und Restart-Verhalten prüfen.
  Belegt 2026-08-11, Quelle: live nullfeld (194.164.194.191) per SSH, gespiegelt in CrumbQuestions_v0/src/deployment_checklist.rs (.md → .html → offline → kernel → rust-Pipeline, portiert aus VERIFICATION_CHECKLIST.md).
  crumbforest/crumbforest-indexing beide systemctl is-enabled → enabled. Prozess läuft als crumbforest-User, nicht root (ps aux | grep uvicorn). /opt/crumbforest Owner crumbforest:crumbforest, drwxr-x---. .env-Rechte -rw-------, exakt wie in der Checkliste erwartet.
• [ ] ProtectSystem, ProtectHome, PrivateTmp, ReadWritePaths gegen den realen Betrieb validieren. (noch nicht geprüft — die Unit-Datei selbst wurde nicht gelesen, nur Laufzeitverhalten)
• [ ] NGINX-Proxy-, TLS-, WebSocket- und statische Pfade prüfen. (Teilbefund: HTTP→HTTPS-Redirect bestätigt (301), volle Proxy-Konfiguration noch offen)
• [x] MariaDB und Qdrant auf Bindings und öffentliche Erreichbarkeit prüfen.
  Belegt 2026-08-11, Quelle: ss -tlnp auf nullfeld, live.
  Qdrant (:6333) und die App (:8000) binden korrekt an 127.0.0.1 — nicht von außen erreichbar. [!] CKL-Risiko: MariaDB (:3306) bindet an *:3306 (alle Interfaces), nicht nur localhost. ufw hat keine explizite Regel für Port 3306 — der Schutz läuft ausschließlich über die Default-Deny-Policy der Firewall, nicht über eine zusätzliche Bind-Beschränkung. Fehlende Verteidigung in der Tiefe: sollte zusätzlich an 127.0.0.1 gebunden werden, nicht nur durch die Firewall abgesichert sein.
• [x] Firewall-/VPN-Annahmen gegen NetBox-/Ansible-Realität prüfen.
  Belegt 2026-08-11, Quelle: ufw status numbered auf nullfeld, live (40 Regeln geprüft).
  Ports 80/443 offen (HTTP/HTTPS), 22 rate-limited, 3000 offen (Gitea), 51820/udp offen (CrumbVPN WireGuard). Mehrere explizite DENY-Regeln gegen einzelne IPs/Subnetze — passt zu den in Memory dokumentierten "jüngsten RZ-Sicherheitsvorfällen". Port 8000/3306/6333 haben keine explizite ALLOW-Regel — 3306 bleibt trotzdem der oben genannte CKL-Risikopunkt, weil der Bind selbst nicht eingeschränkt ist.
• [ ] Installations-, Update- und Backup-Skripte mit Shell-Lint und Dry-Run prüfen.
• [ ] Default-Zugangsdaten und Demo-Modus aus Produktionspfaden entfernen oder hart absichern.
• [ ] Security-Scanner zu einem reproduzierbaren, CKL-relevanten Testkatalog ausbauen.
  Ansatz vorhanden: CrumbQuestions_v0/src/deployment_checklist.rs ist ein erster echter, automatisiert testbarer Katalog (cargo test schlägt fehl, falls ein bekannter Fail stillschweigend auf "Pass" umetikettiert wird) — aber bisher nur 15 der ~90 Original-Punkte, nicht ausgebaut auf die volle Checkliste.
• [ ] Restore-Test durchführen: Datenbank, Vektoren, Konfiguration und Logs.

Ergänzung 2026-08-11, Performance (bonus, nicht ursprünglich in Phase D verlangt): Response-Zeiten /health 1,1ms, /de/login 1,3ms (beide weit unter den in VERIFICATION_CHECKLIST.md erwarteten <1s/<2s). Speicher 192MB RSS (Erwartung <500MB). Disk 438G frei von 492G. Alles im grünen Bereich, live gemessen.

Bekannter Sicherheits-Gap, live bestätigt: curl -I https://crumbforest.org/de/login zeigt keinen der in der Checkliste erwarteten Header (X-Frame-Options, X-Content-Type-Options, X-XSS-Protection). Die eigene Checkliste erwartet sie, die NGINX-Config liefert sie nicht.

Ergebnis: Betriebsrisiko- und Wiederanlaufkarte — Kernpunkte jetzt belegt statt nur angenommen. Zwei offene, dokumentierte Lücken (MariaDB-Bind, fehlende Security-Header), keine davon bisher als kritischer Vorfall bestätigt, beide konkret behebbar.

Phase E – Vergleich mit crumbcrm_crumbcore_v1

Erst nach A–D vergleichen, nicht vorher vermischen:

• [x] Welche Komponenten sind echter Rewrite?
• [x] Welche Teile sind nur umorganisiert oder historisch kopiert?
• [x] Welche CKL-Schutzmechanismen sind besser/schlechter?
• [x] Welche Datenmodelle sind inkompatibel?
• [x] Welche Betriebsannahmen unterscheiden sich?
• [x] Welche Tests und Migrationen existieren?
• [ ] Welche Komponenten sollten übernommen, isoliert oder verworfen werden? (Crew-Entscheidung, s. u.)

Belegt 2026-08-07 — Quelle: Codebase-Graph-Analyse beider lokaler Klone (Crumbcore-V0.0 HEAD 14a0e79, 3228 Nodes · crumbcrm_crumbcore_v1 HEAD f40b67e, 6251 Nodes; Node-Zahl ≠ Codeumfang, Rewrite hat viele HTML/Section-Nodes mehr, aber weniger Python-Logik).

Einordnung:
- Echter Rewrite, nicht nur umsortiert: Admin-Funktionsumfang wurde bewusst reduziert (Nutzerverwaltung, Logs, Vector-Admin, Constellation, Docs-Reader, Pulse fehlen komplett), dafür kamen Compliance-Seiten und Nutzer-Settings neu dazu. Das ist eine Verschiebung von "internem Admin-Werkzeug" hin zu "Endnutzer-zugewandter Kern" — eine echte Architekturentscheidung, kein Copy-Paste.
- CKL-Schutzmechanismen: im Rewrite schlechter, nicht besser. Die einzige inhaltliche Sicherheitsschicht, die es im nativen System überhaupt gibt (CrumbSeal/Passkante, Content-Gate bei Hard-Flags), fehlt im Rewrite vollständig. Wer auf crumbcrm_crumbcore_v1 aufbaut, baut ohne den einzigen vorhandenen Schutzmechanismus weiter — das müsste zuerst nachgezogen werden, nicht als Nice-to-have später.
- Die Diary-Auth-Lücke (Frage 2/3) ist kein Einzelfund, sondern über beide Codebasen identisch — der Rewrite hat sie nicht behoben, weil diary_rag.py praktisch unverändert übernommen wurde. Wird crumbcrm_crumbcore_v1 je produktiv, muss dieser Fix dort genauso nachgezogen werden.
- Rust ist aktuell Dichtung, keine Grenze. Für Frage 7 (harte Rust-Grenzen) relevant: es gibt schon ein Rust-Artefakt im Rewrite-Repo, aber der Autor selbst hat es explizit als unfertige Skizze markiert — kein Beleg für oder gegen die Rust-Hypothese, nur ein Hinweis, dass der Gedanke schon mal skizziert wurde.
- Datenmodelle: beide nutzen dasselbe MariaDB-Schema-Muster (diary_entries, post_vectors, users, audit_log) und dieselbe Qdrant-Collection-Namenskonvention ({prefix}_{locale}, diary_child_{id}) — kompatibel, keine Divergenz gefunden.

Ergebnis: Vergleichsmatrix Crumbcore-V0.0 ↔ crumbcrm_crumbcore_v1 — siehe Tabelle oben.

Phase F – Zukunftsoptionen Python, Go und Rust

Keine Sprachentscheidung aus Bauchgefühl. Zuerst Komponenten schneiden:

Anwendung / UI
RAG-Orchestrierung
Embedding-/Indexierungsworker
CKL-Sicherheitsgrenzen
Event-/Audit-Kern
VPN-/Netzwerknahe Dienste
Deployment-/Agentenlose Betriebshelfer

Für jede Komponente bewerten:

• [ ] Sicherheitskritikalität
• [ ] Datenhoheit und Offline-Fähigkeit
• [ ] Laufzeit-/Speicherbedarf
• [ ] Änderungsfrequenz
• [ ] Crew-Kompetenz und Wartbarkeit
• [ ] Testbarkeit
• [ ] Bibliotheks-/Provider-Ökosystem
• [ ] Deployment über Debian, NetBox und Ansible
• [ ] Migrationsrisiko und Rückfallmöglichkeit

Vorläufige Hypothesen, noch keine Entscheidungen:

• Python/FastAPI kann für RAG, Provider und schnelle fachliche Iteration sinnvoll bleiben.
• Go könnte sich für schlanke native Worker und robuste Betriebsdienste eignen.
• Rust könnte sich für besonders harte CKL-/Daten-/Event-Grenzen eignen.
• Ein kompletter Rewrite ist erst nach Datenfluss- und Testanalyse vertretbar.
• Ein schrittweiser Ersatz einzelner Komponenten ist dem Big Bang vorzuziehen.

Ergebnis: begründete Technologieentscheidung oder bewusstes „noch nicht entscheiden“.

4. Harte Akzeptanz-Gates

Kein Release, keine Migration und kein Rewrite-Schritt ohne:

• [ ] CKL-Check bestanden.
• [ ] Kinder-/Tagebuch-Datentrennung getestet.
• [ ] Löschung und Export nachgewiesen.
• [ ] Externe Datenflüsse dokumentiert und minimiert.
• [ ] Keine versteckten Profile, Rankings oder Telemetrie.
• [ ] Offline-/lokaler Fallback beschrieben.
• [ ] Backup und Restore getestet.
• [ ] Provenienz von Code, Daten und Dokumentation eindeutig.
• [ ] Tests reproduzierbar im Workspace ausführbar.
• [ ] Veröffentlichung zur Crew ausdrücklich freigegeben.

5. Fragen an die Crew

Bitte Ergänzungen nicht nur als Meinungen, sondern möglichst mit Datei-, Commit- oder Laufzeitbezug eintragen:

1. Welche ursprüngliche CakePHP-Idee darf auf keinen Fall verloren gehen?
   [x] belegt — Quelle: Crew-Aussage, 2026-08-07.
   PHP war der "alte Backend-Test" — nicht das, was bleiben muss. Was bleiben muss, ist die Trennung dahinter: statisches Frontend, die Antwort kommt aus der Null (Nullfeld/Backend-Kern liefert die Intelligenz, das Frontend selbst bleibt schlank und austauschbar). Das ist die eigentliche CakePHP-Idee, nicht die konkrete PHP-Implementierung — und deckt sich mit dem, was in Crumbcore-V0.0 heute an FastAPI/Jinja2-Templates ohnehin schon so gebaut ist (server-gerenderte, weitgehend statische Seiten + API-Kern).

2. Wo liegen heute die echten CKL-Grenzen — im Code, in der Datenbank oder nur in Dokumenten?
   [x] belegt — Quelle: Code-Graph-Analyse Crumbcore-V0.0 (lokal + live auf nullfeld:/opt/crumbforest/), 2026-08-07.
   Die jüngsten RZ-Sicherheitsvorfälle bestätigen empirisch, dass ein klassischer Perimeter (zentrale Firewall/Auth) nicht das tragende Modell ist — er wurde kompromittiert. Der reale Schutz läuft über VPN + Passkarte + 3-Faktor-Auth (Stimme, Tanz, SSH-Key) je Krümel, verwaltet über die NetBox.
   Code-Befund: Die gesamte In-App-Authentifizierung ist app/deps.py::current_user() → req.session.get("user"), gesetzt via E-Mail/bcrypt-Login (app/main.py, SessionMiddleware). Kein VPN-, Passkarte- oder 3-Faktor-Bezug im Code. Depends(current_user)/Depends(admin_required) sind auf Admin/CMS-Routen (admin_post.py, admin_users.py, admin_rag.py, admin_roles.py, admin_logs.py) gesetzt, fehlen aber komplett auf app/routers/diary_rag.py (Kind-Tagebuch-RAG) und app/routers/chat.py (Haupt-Persona-Chat) — dort schützt nur Netzwerk-Reachability + der inhaltliche CrumbSeal/Passkante-Filter (Content-Gate, kein Identity-Gate). Per git log --follow unverändert seit Initial Commit 6c38ed6 (2025-12-07) — keine Regression, Ausgangszustand. Wichtig: trotz fehlender Auth zeigt der reale nginx-access.log auf nullfeld null Treffer auf /api/diary/* seit Bestehen — der Pfad ist eingehängt (main.py), aber nie tatsächlich angefragt worden. "Importiert" ≠ "in Anwendung": aktuell kein aktiver Expositionspfad, sondern unbenutzter Code, der vor dem ersten echten Diary-Eintrag eine Zugriffskontrolle braucht. Die 3-Faktor-Prüfung ist damit bestätigt: kein Code-Pfad, sondern bewusstes Zukunfts-Feature — passend zur Krümel-Phase ohne Kinder im System (s. Frage 3).

3. Welche Kinder-/Diary-Flows sind produktiv erprobt?
   [x] belegt: keine — Quelle: MariaDB-Live-Abfrage nullfeld:/opt/crumbforest, 2026-08-07.
   Vier unabhängige Quellen bestätigen Null-Nutzung: diary_entries = 0 Zeilen, children = 0 Zeilen, audit_log mit action LIKE 'diary%' = 0 Einträge, post_vectors mit post_type='diary' = 0 Einträge, nginx /api/diary/* = 0 Treffer seit Bestehen. Die 9 Accounts in users sind durchweg Crew/Team (admin@crumb.local, demo@crumb.local, heimkind@onezeromore.com, u.a.) — keine Ghost-Accounts, keine Kinder. Alle im Chat-Log sichtbaren Rollen (Eule, Deepbit, Bugsy, Vektor, …) wurden von Crew/3FCrumb-Testidentität durchgespielt, nicht von echten Kindern.

4. Welche Teile von Qdrant und Constellation sind kanonisch?
   [x] belegt — Quelle: Code-Graph-Analyse + Live-Log nullfeld:/var/log/crumbforest/chat_history.jsonl (412 Einträge, Feb–Aug 2026), 2026-08-07.
   Kanonische Qdrant-Collections laut RAGService._get_collection_name(): {prefix}_{locale} (Standard-Prefix posts, z. B. posts_de) sowie diary_child_{id} pro Kind (aktuell 0 Instanzen, s. Frage 3). Korrektur zur ursprünglichen Annahme: nicht nur DumboSQL/Vektor, sondern 22 Personas mit realen Interaktionen im Log (Eule 110, Deepbit 63, Ozcrumb 24, Bugsy 21, Capacitoby 20, Cloudcat 19, Funkfox 19, Bashpanda 17, Spider 17, u. a.). Die Constellation-Visualisierung liest nicht live aus Qdrant — constellation.get_nodes() (app/routers/constellation.py:68) baut die Sternenkarte aus Rollen-Config + ChatLogger-Token-Zählern; „Knowledge" = Token-Verbrauch, nicht Vektor-Nähe. Constellation ist optisch ein Sternenraum, inhaltlich ein Token-Usage-Dashboard.

5. Welche Betriebsannahmen stammen noch aus der Docker-Zeit?
   [x] belegt, teilweise — Quelle: Live-Check nullfeld/backbone + Ansible-Crumbforest-Repo, 2026-08-07.
   Der native Betrieb auf nullfeld ist real vollzogen — crumbforest.service läuft direkt via systemd/Uvicorn, nicht in Docker. Reste aus der Docker-Zeit liegen aber noch sichtbar im Deploy-Verzeichnis: /opt/crumbforest/app/Dockerfile und entrypoint.sh existieren dort weiterhin, unbenutzt (kein laufender Container, kein docker/compose-Prozess auf dem Host) — historisches Gepäck, kein aktives Risiko.
   Ergänzung: Es gibt zusätzlich crumbforest.io auf einem eigenen Host (backbone, getrennt von nullfeld/.org — s. Phase-A-Fund oben). Die aktuelle Betriebsrealität ist dort klar nachdocker: borgmatic (borg-basiert) sichert beide Hosts gegenseitig — backbone → nullfeld und nullfeld → backbone, je /opt/crumbforest explizit im Backup-Scope (borgmatic-nullfeld.yaml, borgmatic-backbone.yaml), täglich, verschlüsselt (zstd,3), Aufbewahrung 7 täglich/4 wöchentlich/6 monatlich/2 jährlich. Das ist eine aus der Docker-Ära nicht mitgenommene, sondern neu und nativ aufgebaute Annahme: Persistenz läuft über Dateisystem-Backup, nicht über Docker-Volumes. Einzige dokumentierte Lücke dabei (2026-07-16 geschlossen): /var/lib/gitea fehlte zwischenzeitlich im nullfeld-Backup-Scope — mittlerweile behoben, als Lehre im Config-Kommentar festgehalten.

6. Was wird inzwischen tatsächlich durch NetBox und Ansible kontrolliert?
   [x] belegt — Quelle: Ansible-Crumbforest-Repo, Volltextsuche über alle Playbooks/Rollen, 2026-08-07.
   Laut Aussage erkennt die NetBox Krümel anhand von Stimme/Tanz/SSH-Key (3-Faktor) für SOT-Uploads. Das deckt den Beitrags-/Vertrauenspfad ab — geprüft, ob NetBox auch Deployment/Config der Crumbcore-App steuert oder nur Identität:
   Kein einziges Playbook in Ansible-Crumbforest referenziert crumbforest.service, native_crumbcore_v1 oder app/. Was NetBox/Ansible hier tatsächlich kontrollieren: Geräte-Identität/Tags/MAC (netbox-*.yml), einzelne Infra-Stacks als systemd-Units auf anderen Hosts (z. B. blackbox-hospital-systemd.yml für den separaten Hospital-Krümel-Stack), Backups (borgmatic.yml, s. Frage 5), nginx/VPN. Das Deployment der eigentlichen Crumbcore-App auf nullfeld läuft außerhalb der Ansible-Kontrolle — /opt/crumbforest/app ist dort kein Git-Repo (git log schlägt fehl, "not a git repository"), also weder Ansible-verwaltet noch git-pull-basiert, sondern vermutlich manuell/per Copy deployt. Ergebnis: NetBox deckt Identität/Vertrauen ab, nicht App-Deployment — die beiden Rollen sind sauber getrennt, nicht vermischt.

7. Wo braucht es harte Rust-Grenzen, wo wäre Go ausreichend, wo bleibt Python besser?
   [~] in Analyse, jetzt mit Code-Belegen — Quelle: Crew-Gespräch 2026-08-07 (Bezug: OZM⟡NEXUS, onezeromore.com) + Phase-E-Vergleichsmatrix (s. o.).
   OZM setzt Rust/FPGA für die "nicht verhandelbaren" Determinismus-Grenzen ein (Nullfeld-Konzept). Das spricht dafür, harte CKL-Grenzen (Phase B: child_id-Erzwingung, Löschung/Export) als Kandidat für Rust zu behandeln — nicht aus Performance-, sondern aus Nachweisbarkeitsgründen (kein Blackbox-Verhalten). Für Edge-Inferenz zeigt der aktuelle Container-Betrieb (RPi5 + Hailo-8L statt AMD Ryzen AI Max) zusätzlich: die kleinste tragbare Einheit wird zuerst bewiesen, bevor größere Unified-Memory-Hardware in Betracht kommt — das sollte auch für die Sprachentscheidung gelten (erst schlanker Worker in Go/Rust auf RPi-Klasse-Hardware zeigen, dann größer denken).

Ergänzung 2026-08-07, aus der Phase-E-Vergleichsmatrix: Zwei konkrete Funde stützen die Hypothese jetzt mit echten Vorfällen statt nur Analogie zu OZM:
- CrumbSeal/Passkante — die einzige inhaltliche Schutzschicht — ist beim Rewrite kommentarlos verschwunden. Sie existiert in Crumbcore-V0.0 (app/utils/crumbseal.py), fehlt aber komplett in crumbcrm_crumbcore_v1 — kein Fehler, kein Test schlägt an (der Rewrite hat nur noch 1 Testdatei statt 3), einfach stillschweigend weg. Das ist exakt das Risiko, das "Blackbox-Verhalten" beschreibt: eine reine Python-Konvention ("man ruft die Funktion halt auf") hat nichts, was ihr Fehlen bei einem Rewrite erzwingen würde.
- Die diary_rag.py-Auth-Lücke (Frage 2/3) wurde 1:1 in den Rewrite mitkopiert, nicht neu bewertet — auch das ein Symptom fehlender erzwungener Grenzen: Depends(current_user) ist eine Konvention, kein Vertrag, den der Compiler/das Typsystem prüft.
- Beide Funde sind kein Performance-Problem, sondern ein Nachweisbarkeits-/Vererbungsproblem über einen Rewrite hinweg — spricht für die OZM-Logik: CKL-kritische Pfade (Passkante-Gate, child_id-Scope, Löschung/Export) so bauen, dass ihr Fehlen nicht kompilieren würde, statt sich auf Disziplin/Review zu verlassen. Das im Repo vorhandene einzige Rust-Artefakt (docs/crumbforest/krümel_api_specs.rs) ist dafür kein Beleg — der Autor selbst nennt es "poetisches API-Gerüst zum Weiterträumen", keine echte Implementierung, also bislang nur eine Absichtserklärung, kein Erfahrungswert.
- Konkreter, kleinerer Zwischenschritt vor der großen Sprachentscheidung: unabhängig von Rust/Go/Python könnte ein Contract-Test ("jede Route unter /api/diary und /api/documents MUSS current_user oder admin_required in ihren Dependencies haben, sonst schlägt CI fehl") das konkrete Symptom schon jetzt sprachunabhängig absichern — bevor die größere Architekturfrage entschieden ist.

Update 2026-08-10 — erster echter Beleg statt nur Absichtserklärung: CrumbQuestions_v0 (git.crumbforest.org/branko/CrumbQuestions_v0, Krümel "Crumb Bridge", lokal auf crumbdesktop/iMac-Container gebaut) ist der erste tatsächlich funktionierende Rust-Krümel — kein Sketch mehr. Selbst geklont und unabhängig nachgeprüft (nicht nur das Audit-Dokument der Crew übernommen): cargo fmt --check sauber, cargo clippy --all-targets --all-features -- -D warnings sauber, cargo test 4 grüne Tests (Audit-Dokument nannte 3 — kleine Differenz, vermutlich weil der Persistenz-Test danach dazukam). Code gelesen (src/lib.rs, axum + argon2 + unsafe_code = "forbid"):
- owner_id ist strukturell nicht clientseitig setzbar — NewQuestion hat gar kein owner_id-Feld, es kommt ausschließlich aus der Server-Session. Härtere Garantie als der child_id-Parameter in diary_rag.py, der vom Client mitgeschickt und nur stellenweise gegen die DB geprüft wird.
- Jeder CRUD-Handler prüft current_user() zuerst; Scope danach konsistent role == Admin || owner_id == user.id — kein Handler ohne Check, kein Diary-artiger blinder Fleck.
- Enthält genau den Test, der in Crumbcore-V0.0/crumbcrm_crumbcore_v1 fehlt: user_questions_are_scoped_but_admin_can_see_them — Cross-Owner-Isolation, nicht nur Happy-Path (s. Frage 8).
- Noch kein CrumbSeal/Passkante-Äquivalent — aber das beansprucht der Krümel laut eigenem Scope auch nicht, das kommt erst mit dem Vektor-Adapter.
Kein Vollbeweis für "Rust überall", aber ein erster echter Datenpunkt: an genau der Stelle, wo Python zweimal (nativ und beim Rewrite) eine CKL-Grenze stillschweigend auslassen konnte, erzwingt dieselbe Grenze in Rust der Typ/Compiler von Anfang an mit.
Persönliche Einordnung aus der Crew: die ursprüngliche RAG-Architektur wurde seinerzeit "klassisch CRM" gedacht, nicht CKL-first — dass jetzt ausgerechnet der Fragen-Kern (Identität, Scope, Eigentümerschaft) zur ersten sauber bewiesenen Grundlage des Ökosystems wird, ist eine bewusste Kurskorrektur, keine Fußnote. CKL ist nicht verhandelbar — bleibt Leitplanke für jeden weiteren Krümel dieser Brücke (Vektor-Adapter, SSH-Schlüssel).

1. Welche Tests fehlen, um einen Rewrite überhaupt verantwortbar zu machen?
   [x] belegt — Quelle: Testverzeichnisse beider Codebasen, 2026-08-07.
   Native hat 3 Testdateien (test_vectors.py, test_admin_logs.py, test_integration.py), der Rewrite nur noch 1 (test_integration.py) — Testabdeckung ist beim Rewrite geschrumpft, nicht gewachsen.
   test_integration.py deckt den Diary-Happy-Path ab (test_step_1_create_child … test_step_6_check_status), aber keinen einzigen Fall, in dem ein Nutzer/eine Session versucht, auf ein fremdes child_id zuzugreifen — genau die Lücke aus Frage 2/3 wird also nicht getestet, obwohl der Test extra für Diary geschrieben wurde.
   Für crumbseal/Passkante existiert in keiner der beiden Codebasen ein einziger Test — die einzige inhaltliche Sicherheitsschicht ist komplett ungetestet, auch dort, wo sie noch existiert (native).
   Der Bezugspunkt, dass es besser geht, liegt schon im selben Repo: test_admin_logs.py::test_admin_logs_access prüft explizit client.get("/admin/logs", allow_redirects=False) → erwartet 302 (nicht eingeloggt blockiert), dann app.dependency_overrides[current_user] = ... → erwartet 200 (eingeloggt erlaubt). Exakt dasselbe Muster fehlt 1:1 für /api/diary/*. Konkrete Mindestanforderung für einen verantwortbaren Rewrite: (1) Cross-Child-Isolationstest für Diary/Documents nach dem test_admin_logs-Muster, (2) mindestens ein CrumbSeal/Passkante-Test (Hard-Flag → Safety-Shield-Antwort, kein echter Modellaufruf), (3) ein Test, der /api/diary, /api/documents und chat.py gegen eine Liste "muss current_user/admin_required haben" abgleicht (s. Contract-Test-Vorschlag unter Frage 7) — damit ein zukünftiger Rewrite diese Lücke nicht wieder stillschweigend mitkopiert.

Update 2026-08-10: Genau dieses fehlende Testmuster existiert jetzt anderswo im Ökosystem, unabhängig selbst nachgeprüft — CrumbQuestions_v0 (Rust, s. Frage 7) hat mit user_questions_are_scoped_but_admin_can_see_them exakt den Cross-Owner-Isolationstest, der in beiden Python-Codebasen fehlt. Kein Fremdbeispiel mehr, sondern ein Krümel aus derselben Crew, an dem sich zeigen lässt, dass die drei obigen Mindestanforderungen machbar und schon einmal geschrieben wurden — der Maßstab liegt jetzt im eigenen Ökosystem, nicht nur in der Theorie.

1. Welche Daten müssen offline funktionieren, wenn Provider, VPN oder Internet ausfallen?
   [x] belegt, teilweise — Quelle: Code-Graph-Analyse + Live-Log nullfeld, 2026-08-07.
   Offline-first gilt inzwischen als durch reale Vorfälle bestätigter Architekturentscheid, nicht nur als Prinzip. Der geplante physische Beweis (2000W PV / 2,5kWh Speicher, Verbraucher: 3× RPi5, Mikrotik SXE, Laptops) soll zeigen, dass der Container ohne RZ-/Netzanbindung weiterläuft.
   Code-Befund: ProviderFactory.create_provider() (app/services/provider_factory.py:78-88) braucht für ollama keinen API-Key, nur ollama_base_url — Diary-RAG und Admin-RAG nehmen provider als freien Parameter und könnten rein lokal laufen. Der Haupt-Chat (app/routers/chat.py) hat aber einen hart codierten Vorab-Check (if not settings.openrouter_api_key: raise HTTPException(503, ...)), der vor der eigentlichen Rollen-Modell-Auflösung greift — Chat blockt also ohne OpenRouter-Key komplett, selbst wenn die angefragte Persona lokal über Ollama laufen sollte. Reale Nutzung bestätigt das: von 412 geloggten Interaktionen liefen 401 über OpenRouter (Cloud) und nur 11 über Ollama (2,7 %). Offline-Fähigkeit existiert im Provider-Layer, ist aber im Chat-Entry-Point nicht scharf geschaltet — Nachbesserung nötig, bevor der PV-Inselbetrieb-Test den Chat mit einschließt.

2. Welche Teile gehören in den SOT, welche bleiben Workspace-/Experimentierstand?
   [x] belegt — Quelle: git remote/git log auf beiden Klonen + Live-Check nullfeld, 2026-08-07.
   Beide Codebasen liegen bereits auf git.crumbforest.org/branko/… — formal also schon auf dem "veröffentlichten Crew-Stand", nicht mehr im reinen Workspace (s. Phase-A-Fund oben). Trotzdem sind sie faktisch nicht gleichrangig:

   • Crumbcore-V0.0 ist der einzige Teil mit echtem SOT-Anspruch, weil er der einzige ist, der läuft (nullfeld, crumbforest.service aktiv, echte Nutzung seit Feb. 2026).
   • crumbcrm_crumbcore_v1 ist trotz Gitea-Veröffentlichung faktisch Workspace-/Experimentierstand — kein systemd-Unit auf backbone oder nullfeld, in keinem Ansible-Inventar referenziert, nirgends deployt. "Auf dem SOT-Host liegen" ≠ "SOT sein".
   • Der eigentliche blinde Fleck: /opt/crumbforest/app auf nullfeld — die Version, die tatsächlich für Anfragen zuständig ist — ist selbst kein Git-Repository (git log dort: "not a git repository"). Es gibt also keine strukturelle, nachprüfbare Verbindung zwischen dem, was in git.crumbforest.org als HEAD 14a0e79 steht, und dem, was live auf nullfeld läuft — nur eine stichprobenartig bestätigte Übereinstimmung (bei diary_rag.py identisch, s. Frage 2). Das ist dieselbe Lücke wie bei Frage 6: kein Ansible/CI-Pfad verbindet Repo und Deployment.
     Empfehlung an die Crew: git.crumbforest.org/Crumbcore-V0.0 als Code-SOT führen, aber einen echten Deploy-Nachweis (git-pull-Hook oder minimaler CI-Schritt, der den deployten Commit-Hash auf nullfeld protokolliert) ergänzen — sonst bleibt "SOT" eine Behauptung ohne Beleg für das, was Nutzer tatsächlich erreichen. crumbcrm_crumbcore_v1 sollte explizit als Rewrite-Workspace gekennzeichnet werden, bis es einen eigenen Deploy-Nachweis hat.

Neue Fragen aus dem Crew-Gespräch vom 2026-08-07

1. [!] CKL-Risiko — Kostenaussage im Vektor-Index. Die Persona Vektor zitiert im Live-Log "mit 1€ können 5.000 bis 10.000 echte, kindgerechte Fragen beantwortet werden". Die realen Betriebszahlen aus demselben Log (412 Interaktionen, $1,1308, ~113k Tokens) ergeben aber nur ~360 Fragen pro Dollar — Faktor 15–25 Abweichung, vermutlich aus einem alten Pitchdeck stammend und falsch in den RAG-Kontext gelangt. Solange diese Zahl im Qdrant-Index liegt, wird sie von Personas als Fakt an Kinder/Crew ausgegeben. Braucht: Fundstelle im Index identifizieren, korrigieren oder mit Kontext versehen ("Zielgröße", nicht "Ist-Zustand"). Direkt relevant für CKL-Prinzip "kindgerechte, erklärbare und nicht überfordernde Interaktion" — falsche Zahlen sind das Gegenteil von erklärbar.
   Ergänzung 2026-08-07: chat_history.jsonl hat gar kein cost_usd-Feld im Schema (Keys: timestamp, character, user, interaction, rag, ai, session_id, tokens_estimated). Die im Dokument zitierte $1,1308 muss also extern aus tokens_estimated (Summe 113.076 über alle 412 Einträge) × Modellpreis berechnet worden sein, nicht direkt geloggt. Fundstelle im Vektor-Index selbst noch offen — bräuchte gezielte Qdrant-Payload-Suche nach dem Pitchdeck-Zitat.

2. [?] Crew-Entscheidung erforderlich — Faktencheck-Mechanismus für den RAG-Index. Punkt 11 ist vermutlich kein Einzelfall. Braucht es einen wiederkehrenden Abgleich zwischen geloggten Echtzeit-Betriebswerten (Kosten, Coverage, Uptime) und im Vektor-Index gespeicherten Aussagen aus älteren Dokumenten (Pitchdecks, frühe Konzepte), damit Personas keine veralteten Zahlen zitieren?

3. [?] Crew-Entscheidung erforderlich — PV-Lastprofil und 3D-Drucker. Die geplante PV-Anlage (2000W/2,5kWh) deckt die Dauerlast (RPi5, Mikrotik, Laptops) komfortabel ab. Der 3D-Drucker ist der einzige potenziell spitzenlastige Verbraucher. Soll er über Lastmanagement (zeitlich entkoppelt vom Dauerbetrieb) laufen, oder wird die PV-Dimensionierung direkt für Druckbetrieb mitgeplant?

4. [x] belegt — Nachweispflicht für 3-Faktor-Auth. Siehe Frage 2 — der 3-Faktor-Mechanismus (VPN + Passkarte + weiterer Faktor) ist nicht im App-Auth-Pfad erzwungen und aktuell auch nicht organisatorisch nachgebildet (In-App-Auth = reines Session-Cookie + bcrypt-Login). Das ist kein gebrochenes Versprechen, sondern der erwartete Ist-Zustand vor dem geplanten Ausbau — bestätigt per Git-Historie (unverändert seit Initial Commit) und real: es gibt noch keine Kinder im System (Frage 3), also auch keinen Fall, an dem die Lücke bisher etwas gekostet hätte. Als CKL-Hard-Gate für Phase D zu führen: Auth muss vor dem ersten echten Kind-Account stehen, nicht danach.

6. Arbeitsregel

Wir analysieren zuerst. Wir verändern noch keine Produktionspfade.

Jede Erkenntnis bekommt:

Quelle / Pfad / Commit / Laufzeitstand / CKL-Relevanz

Jede neue Version muss rückwärts erklärbar bleiben:

Was war vorher?
Was wurde geändert?
Warum war es sicherer oder verständlicher?
Wie kann die Crew zurückrollen?

Bugsy-Regel: Ein gefundener Fehler ist kein Makel, sondern eine neue Schutzschicht — sofern wir ihn dokumentieren, testen und nicht wieder in eine andere Repo-/Pfad-Identität hineinvermischen.

7. Nächster konkreter Schritt

Als nächstes wird eine kleine, belegbare Datenflusskarte für den nativen Einstieg erstellt:

native_crumbcore_v1
  → crumbforest.service
  → app/main.py
  → Chat/RAG/Diary-Routen
  → MariaDB + Qdrant
  → Provider/Embedding
  → Logs/Audit/Löschung

Dabei werden keine neuen Features gebaut. Ziel ist ausschließlich, die CKL-relevanten Grenzen des bestehenden Systems sichtbar und testbar zu machen.

Statusfelder für Crew-Beiträge:

[ ] offen
[~] in Analyse
[x] belegt/erledigt
[!] CKL-Risiko
[?] Crew-Entscheidung erforderlich