Meilenstein: Crumb Bridge

Status: lokal verifiziertes Review-/Audit-/Rewrite-Dokument
Stand: 2026-08-09
Provenienz: /home/sysop/workspace/crumb-question-core

1. Kurzfassung

Crumb Bridge ist der erste kleine Rust-Krümel zwischen dem bestehenden HTML-Einstieg und einem späteren lokalen Habitat-Kern.

Der Meilenstein ist ausdrücklich:

  • kein neues WordPress
  • kein AI-Portal
  • kein vollständiger CrumbCore-Rewrite
  • kein Produktionsdeployment
  • noch kein SSH-Service
  • noch kein Qdrant-/Vektor-Backend

Die Brücke beweist zunächst nur den kleinsten gemeinsamen Weg:

HTML-Frontend
    -> klassische Session-Authentisierung
    -> User-/Admin-Scope
    -> Fragen-CRUD
    -> später Vektor-Adapter
    -> später SSH-Krümelschlüssel

2. Ausgangslage aus dem Review

Der bisherige CrumbCore-Bestand ist groß, historisch gewachsen und enthält mehrere fachliche sowie betriebliche Grenzen, die in einem Rewrite nicht stillschweigend verloren gehen dürfen.

Aus der lokalen Bestandsaufnahme waren für diesen Krümel besonders relevant:

  • Der HTML-/Frontend-Einstieg bleibt wichtig, solange der SSH-Zugang noch nicht als eigener Krümel-Schlüssel existiert.
  • Authentisierung muss vor dem CRUD-Kern liegen.
  • User- und Admin-Zugriffe dürfen nicht nur in der Oberfläche, sondern müssen im Backend begrenzt werden.
  • Fragen-/Diary-/Wissensdaten dürfen später nicht ohne Scope in eine Vektorsuche gelangen.
  • Der Vektorzugang ist ein Adapter und nicht die Identität oder der Kern des Systems.
  • Die alte Anwendung bleibt Referenz und Einstiegskontext; dieser Rust-Krümel ersetzt sie nicht automatisch.

3. Auditumfang

Geprüft wurde der lokale Prototyp in:

/home/sysop/workspace/crumb-question-core

Geprüfte Bestandteile:

  • Cargo.toml
  • src/main.rs
  • src/lib.rs
  • static/index.html
  • README.md
  • lokale HTTP-Routen
  • Authentisierung und Session-Cookie
  • User-/Admin-Sichtbarkeit
  • Fragen-CRUD
  • Rust-Formatierung, Tests und Clippy

Nicht Bestandteil dieses Audits:

  • TLS-Zertifikate und Reverse Proxy
  • SSH-Subsystem und PTY-Isolation
  • persistente Datenbank
  • Qdrant oder andere Vektorspeicher
  • Passwort- und Benutzerverwaltung für Produktion
  • 2FA, Passkarte oder 3-Faktor-Authentisierung
  • Backup, Restore und Migration
  • Deployment über systemd, Ansible oder NetBox
  • vollständige CKL-Zertifizierung

4. Derzeit belegte Implementierung

HTTP-Service

127.0.0.1:8788

Routen:

GET    /
GET    /health
POST   /api/auth/login
POST   /api/auth/logout
GET    /api/auth/me
GET    /api/questions
POST   /api/questions
GET    /api/questions/:id
PUT    /api/questions/:id
DELETE /api/questions/:id

Frontend

Das Frontend ist statisch in den Rust-Binary-Pfad eingebunden und wird über / ausgeliefert.

Es enthält nur den notwendigen Brückenfluss:

Login
  -> Identität und Rolle anzeigen
  -> Frage anlegen
  -> eigene Fragen anzeigen
  -> eigene Frage löschen
  -> Logout

Es gibt kein Dashboard, keine Persona-Auswahl, kein Ranking und keine versteckte Telemetrie.

Authentisierung

Die erste Stufe verwendet klassische lokale Benutzername-/Passwort-Authentisierung mit Argon2-Hashing und einem HttpOnly-Session-Cookie.

Rollen:

admin
user

Die Demo-Zugänge sind nur ein lokales Entwicklungsgerüst:

user  / user
admin / admin

Sie dürfen nicht als Produktionskonfiguration verstanden oder übernommen werden.

Zugriffsscope

  • Nicht authentifizierte CRUD-Anfragen werden mit 401 Unauthorized abgewiesen.
  • Ein user sieht und bearbeitet nur eigene Fragen.
  • Ein admin kann den gesamten Fragenbestand sehen und verwalten.
  • Die owner_id wird im Backend gesetzt, nicht aus dem Frontend übernommen.

5. Rewrite-Entscheidung

Der erste Rust-Rewrite übernimmt nicht die alte Oberfläche und nicht die alte gesamte Anwendung. Er übernimmt nur den belegten Vertrag, der für die Brücke notwendig ist:

Frage
  id
  owner_id
  text

Die bewusst kleine interne Aufteilung lautet:

auth/session boundary
  klassische Anmeldung, Session, Rolle

question CRUD
  Create, Read, Update, Delete

frontend bridge
  HTML-Einstieg ohne Build-Kette

future vector boundary
  späterer Adapter mit verpflichtendem Scope

future ssh boundary
  späterer Terminal-/Schlüsselzugang

Der Rewrite bleibt damit rückwärts erklärbar:

alte HTML-Oberfläche und bestehende CrumbCore-Erfahrung
  -> lokaler Rust-HTTP-Kern
  -> gleicher Einstiegsgedanke, kleinerer überprüfbarer Umfang

6. Verifikation

Die lokale Verifikation wurde mehrfach ausgeführt und zuletzt mit folgendem Ergebnis abgeschlossen:

cargo fmt --check                         bestanden
cargo test                                3 Tests bestanden
cargo clippy --all-targets --all-features \
  -- -D warnings                          bestanden

Zusätzliche Live-HTTP-Prüfung:

/health                                  200 ok
/                                        200 HTML-Frontend
CRUD ohne Login                          401
User-Login                               200 + Session-Cookie
User erstellt Frage                      201 + owner_id
User liest eigene Frage                  erfolgreich
User ändert eigene Frage                 erfolgreich
Admin sieht User-Frage                   erfolgreich
User löscht eigene Frage                 204

Die Live-Prüfung wurde als temporäres Ad-hoc-Skript ausgeführt und danach entfernt. Das ist eine reproduzierte Entwicklungsverifikation, aber noch keine vollständige Produktions-Sicherheitsprüfung.

7. Auditbefund

Positiv

  • Der HTML-Einstieg ist vorhanden und lokal erreichbar.
  • Der Backend-Kern erzwingt Auth vor dem Fragen-CRUD.
  • User-/Admin-Scope ist im Backend und nicht nur im Frontend implementiert.
  • owner_id wird serverseitig vergeben.
  • Der Fragenbestand bleibt klein und verständlich.
  • Der Rust-Service läuft ohne externe KI- oder Cloud-Abhängigkeit.
  • Vektor- und SSH-Komplexität wurden nicht vorzeitig in den CRUD-Kern hineingezogen.
  • Der Prototyp bleibt als Brücke zur alten Anwendung lesbar.

Offene Risiken

  • Die Fragen werden inzwischen lokal in data/questions.json gespeichert;
    Benutzer und Sessions sind weiterhin nur im Prozess.
  • Die Demo-Passwörter sind bekannt und nicht für Betrieb geeignet.
  • HTTPS ist noch nicht im Rust-Service selbst eingerichtet.
  • Es gibt noch keinen SSH-Service und keine Terminal-Isolation.
  • Es gibt noch keinen Vektor-Adapter und keine geprüfte Löschung aus einem Index.
  • Session-Ablauf, CSRF-Schutz, Rate-Limiting und Account-Administration fehlen.
  • Der Admin-Endpunkt ist aktuell Rollen-Scope, noch kein vollständiges Admin-CRUD für Benutzer.
  • Der aktuelle Prototyp ist noch nicht migrations- oder backupfähig.

8. Nicht-Ziele dieses Meilensteins

Dieser Meilenstein baut ausdrücklich nicht:

  • einen Blog
  • ein CMS
  • einen Chatbot
  • ein neues WordPress
  • einen autonomen Agenten
  • eine globale Wissensmaschine
  • ein Kinderprofiling-System
  • ein Ranking- oder Telemetriesystem
  • eine Cloud-Abhängigkeit
  • einen Ersatz für den produktiven alten CrumbCore

9. Nächste Brücken, in dieser Reihenfolge

A. Persistenz

Die erste lokale, nachvollziehbare Fragenhaltung ist umgesetzt:

 data/questions.json

Sie wird atomisch über eine temporäre Datei geschrieben und überlebt einen
Service-Neustart. Als nächste Persistenzstufe folgen Schema/Migration,
Benutzerhaltung, Backup, Restore und vollständige Löschung.

B. Echtes Benutzer-/Admin-CRUD

Nicht nur Rollen prüfen, sondern Benutzer verwalten:

Admin:
  Benutzer anlegen
  Benutzer deaktivieren
  Passwort zurücksetzen
  Rolle ändern
  Sessions widerrufen

Ohne offene Registrierung als Standard.

C. HTTPS-Brücke

Den lokalen HTTP-Service hinter einen kontrollierten TLS-Einstieg setzen. Zertifikat, Bind-Adresse, Proxy und Deployment müssen anschließend separat geprüft werden.

D. Vektor-Adapter

Erst nach stabiler Persistenz und Scope-Prüfung:

Question owner/scope
  -> Embedding
  -> Qdrant payload mit owner/scope
  -> scoped search
  -> scoped delete

Kein globales Retrieval als Abkürzung.

E. SSH-Krümelschlüssel

Erst wenn der Zugriffspfad klar ist:

SSH key
  -> authentisierte Session
  -> begrenzter Habitat-Kontext
  -> gleiche CRUD-/Scope-Grenzen wie HTTP

SSH darf nicht an der HTTP-Auth vorbei einen zweiten, unkontrollierten Datenpfad erzeugen.

10. Abnahmeformel

Der Meilenstein gilt als lokal angenommen, wenn:

HTML-Einstieg erreichbar
+ Login erforderlich
+ User/Admin-Scope im Backend wirksam
+ Fragen-CRUD verifiziert
+ keine versteckte KI-/Cloud-Abhängigkeit
+ nächster Vektor-/SSH-Schritt separat begrenzt

Das ist der erste Krümel der Brücke: klein genug zum Prüfen, offen genug für den späteren SSH- und Vektorzugang, aber nicht groß genug, um wieder zu einem unübersichtlichen AI-CMS zu werden.