name: krumel-onboarding-token-gate
description: "Ziel-Architektur fĂŒr KrĂŒmel-Raspi-Zero-Onboarding: NetBox-Gate vor SSH-AushĂ€ndigung, Token-Kontingent pro pseudonymer ID, direkter Qdrant/Ollama-Zugriff ĂŒber den Zero-Tunnel — Kernprinzip 'Code ohne Raum' schĂŒtzt gegen Gitea-Breach"
metadata:
node_type: memory
type: project

Zielbild fĂŒr den Weg vom NetBox-Eintrag bis zum nutzbaren Raspi Zero in KrĂŒmel-Hand (2026-08-13, im Anschluss an den Pong-Ping-Test von crumbzero01 gegen Qdrant/Ollama):

  1. Zugriffsziel: Raspi Zero soll direkt auf nullfelds Qdrant + Ollama zugreifen dĂŒrfen (aktuell durch Loopback-Bind blockiert, s. [[nullfeld-qdrant-ollama-loopback-bind]]), optional mit OpenRouter fĂŒr externe Modelle bei Bedarf.
  2. Token-Ökonomie: Der KrĂŒmel bekommt sein Token-Kontingent "vom Wald geschenkt" — an die pseudonyme NetBox-Tenant-ID gebunden (Beispiel: crumb_985464, vgl. das Muster kruemel-3a96 aus host_vars/crumbzero01.yml), kein eigenes Konto, kein Bezahlmodell.
  3. App-Anpassung: Rust-App/Mission-Selector auf dem Zero wird auf die neue Config umgestellt → Anschluss an crumbmissions (Bash bleibt Demo/Referenz, echtes SSH-Frontend wird neu gegen den Rust-Core gebaut, s. [[crumbmissions-brotspur-entscheidung]]).
  4. Hartes Gate vor AushĂ€ndigung: kein Zero mit SSH-Zugang geht an ein Kind raus, bevor er nicht vorab durch NetBox gelaufen ist — GerĂ€te-IdentitĂ€t (Device-Type, MAC, Owner-Tenant) zuerst, physische AushĂ€ndigung erst danach.
  5. Sicherheitsprinzip "Code ohne Raum": dadurch bringt ein Gitea-Breach allein keine echte Zugangsberechtigung — WireGuard-Peer-Registrierung, NetBox-Eintrag und physischer SchlĂŒssel leben komplett außerhalb des Repos. Selbst kompletter Quellcode-Diebstahl öffnet keine TĂŒr, weil die TĂŒr (Netzwerk-Zugang, Peer-Erlaubnis) nie im Code selbst steht — nur der Bauplan, nicht der SchlĂŒssel.

Why relevant: direkte Fortsetzung der Session-Kette [[nullfeld-mariadb-socket-bind-fix]] → Pong-Ping-Test crumbzero01 → dieses Zielbild. Der pseudonyme Tenant-Ansatz (crumb_985464/kruemel-3a96) matched bereits docs/NETBOX-ORGANISATION.mds Muster (KrĂŒmel-GerĂ€t → Pseudonym-Tenant, echter Name lebt außerhalb NetBox) — keine neue Ausnahme, sondern konsequente FortfĂŒhrung.

How to apply: bei kĂŒnftigen Onboarding-/Access-Fragen zu Raspi Zeros diese Reihenfolge als Referenz nehmen (NetBox → Ansible-Peer → physische AushĂ€ndigung → Token-Zuteilung → App-Config), nicht abkĂŒrzen. Vor jeder Infra-Änderung, die Zeros direkten Qdrant/Ollama-Zugriff gibt, prĂŒfen ob sie zu diesem Zielbild passt (Loopback-Bind + gezielte Peer-Freigabe statt globaler Öffnung).

Update 2026-08-13, erste echte End-to-End-Antwort auf crumbzero01: das laufende Crumbmissions-Repo auf dem GerĂ€t (/home/sysop/Crumbmissions) hat schon fast das komplette GerĂŒst — mayaeule_zero.sh + check_token_budget() in lib/waldwaechter.sh implementieren die Token-Philosophie fast wortgleich zur Vision ("Was kostet die Frage eines Kindes? Im Wald unbezahlbar — aber Token lehren achtsames Fragen"). Gefixt: .env fehlte komplett, QDRANT_URL defaultete auf localhost → gesetzt auf http://10.42.0.1:6333 (der wg0-Proxy aus [[nullfeld-qdrant-ollama-loopback-bind]]) + QDRANT_COLLECTION=docs_crumbforest_768 (echte Collection statt der nicht existierenden crumbforest_memory). OPENROUTER_API_KEY kam vom User aus 1Password. Live getestet: "Was ist ein Regenbogen?" → echte, kindgerechte Antwort inkl. RĂŒckfrage, 250 Tokens geloggt mit vollem Kosten-Breakdown. Bleibt offen: Qdrant-Memory weiterhin Stub (Fake-4-dim-Vektor gegen 768-dim-Collection), kein Ollama-Pfad im Code, Token-Budget weiterhin lokal/pro-GerĂ€t statt zentral aus einem Wald-Ledger pro NetBox-Pseudonym-ID — "100k fĂŒr crumb_985464" bleibt Vision, kein Mechanismus.

Update 2026-08-13, echtes GedĂ€chtnis + OpenRouter komplett abgelöst: mayaeule_zero.sh bekam echte Embeddings (ollama_embed(), nomic-embed-text via Ollama, statt Fake-Vektor), eigene Qdrant-Collection mayaeule_memory (768-dim, Cosine, getrennt vom RAG-Korpus docs_crumbforest*), score_threshold: 0.65 (empirisch kalibriert: verwandte Fragen 0.72–0.86, unverwandte 0.56–0.57). Live bestĂ€tigt: passende Erinnerung gefunden, unpassende zu Recht nicht.

Danach OpenRouter komplett durch lokales Ollama ersetzt (Vorschlag des Users: "438G frei") — mayaeule_zero.sh + deepbit_zero.sh. Modellwahl per Vergleichstest: llama3.2 (Skript-Fallback) lief sofort, aber grammatisch holprig; gemma3 (per .env-Override) deutlich kohĂ€renter — brauchte proxy_read_timeout auf dem wg0-Proxy von 60s auf 300s, sonst 504 bei grĂ¶ĂŸeren Modellen. Rate-Limits (gitea/bots/openai) sind nur auf git.crumbforest.org gescoped, geprĂŒft.

Kein Deploy-Key fĂŒr Crumbmissions-Gitea auf crumbzero01 — drei Fixes liegen lokal committet (git.crumbforest.org/branko/Crumbmissions, HEAD 7ed3a8f), User pusht selbst. Eine .env.bak-Datei mit Klartext-Key wurde vor dem Commit gelöscht (matchte .gitignore-Pattern nicht exakt — Backup-Dateien mit SekundĂ€rnamen immer separat prĂŒfen).

Update 2026-08-13, NetBox-LĂŒcke teilweise geschlossen: ehrliche Review (netbox_sync.yml --check --diff) zeigte nur unrelated Kernel-Comment-Drift — nichts von der heutigen Arbeit war in NetBox sichtbar. Neuer Tag hub-ai-access (Muster von netbox-inference-roles.yml) markiert GerĂ€te, die Qdrant/Ollama am Hub konsumieren, nicht hosten. crumbzero01 bekam ihn, Bestandstags erhalten, Idempotenz per erneutem --check --diff bestĂ€tigt. Weiterhin offen: WireGuard-Peers/UFW-Regeln selbst tauchen in NetBox nicht auf, nur die FĂ€higkeit.