Architektur-Skizze — Bausteine → crumbcore, erste Bühnen

Stand: 2026-09-01. Kein Code, keine Entscheidung — nur die Übersetzung dessen, was schon
da ist, auf das, was als Nächstes kommen könnte. Ergänzt HANDOFF.md (die Nähte
der Infra), HABITAT.md (die Topologie heute) und crew/DREIECK.md (wer freigibt).

Warum jetzt: die Blackbox musste neu booten, und aus dem Neustart kam eine Erkenntnis,
keine neue Aufgabe: dass Pixel, Punkt und Kurve immer im Raum sind — auch wenn man sie nicht
sieht. Genau deshalb macht es Sinn, jedes bestehende Repo schon jetzt gedanklich als
crumbcore-Modul zu lesen, bevor es eins ist.

1. Die Bausteine, die wir heute wirklich haben

Kein Rewrite, kein neues Ding — nur ehrlich aufgeschrieben, was schon steht:

Noch nicht da, bewusst nicht vorgezogen (wie schon in der Crumb-Bridge-Roadmap §9 festgehalten):
Vektor-Adapter, SSH-Krümelschlüssel, ausformulierte S03–S09.

(Diese Zeile war die erste Fassung dieser Skizze — direkt nach dem Blackbox-Reboot vergessen,
weil ~/Documents/git.crumbforest.org nicht mit-gescannt wurde. Nachgetragen. Dort liegen noch
weitere Repos — CrumbCodex, CrumbZeros, crumb-memory, CrumbSeal, Bashpanda-Admin-Tools,
CrumbLegal, Ninja-Shield, OZM-Keks-Handbuch, Structural_Antifascism — die diese Skizze noch
nicht einzeln charakterisiert hat.)

2. Die Übersetzung — Baustein auf Bühne

Die Crumb-Bridge-Doc hat schon eine Sprache für Modul-Grenzen geprägt (§5: auth/session
boundary, question CRUD, frontend bridge, future vector boundary, future ssh boundary).
Die gleiche Sprache trägt auch die mondgeschichten-Bausteine — sie ist nur bisher nicht
ausgesprochen worden:

story/season boundary       (mondgeschichten: script.json, Episoden-Skelette)
    -> noch reine Daten, kein Rust-Modul — muss es vielleicht nie werden

sound/snippet boundary      (crumbstrudel: benannte, atomare Klang-Bausteine)
    -> das ist schon heute der kleinste austauschbare Baustein — siehe §3

stage/beat-bus boundary     (CrumbMIDI_v0: „die Bühne", OSC-Puls)
    -> treibt Ton UND Bild synchron, unabhängig vom Inhalt

pixel/icon boundary          (CrumbMatrix_v.0.0: 21 Waldwächter, 30×30-Grid, JSON+PNG)
    -> existiert schon, browserlokal, MIT — das ist heute schon die "Pixel"-Seite

kid-tool boundary            (CrumbLabs-v.0.0: CrumbBlocks/CrumbType/crumbstudio/CrumbSans)
    -> gleiche DNA wie HANDOFF.md: kein Tracking, offline nach erstem Laden, kein Login

compliance boundary          (CKL-Kids/DSGVO/COPPA/UK-ADCode + crumbair-„Passkante")
    -> keine Rust-Grenze — ein Vertrag, den jedes Modul erfüllen muss, sobald ein Krümel
       (Kind) es direkt berührt. Gilt schon für CrumbMatrix/CrumbLabs, würde für ein
       crumbcore-Modul genauso gelten müssen.

auth/session + CRUD boundary (Crumb Bridge)
    -> existiert schon, verifiziert, läuft im Katzennetzwerk

governance boundary          (Dreieck: opuskatze/ansiblekatze/designkatze)
    -> keine Code-Grenze, sondern eine Freigabe-Grenze — Branko sagt ja/nein an genau
       den gleichen drei Nähten, ob crumbcore dahinter steckt oder nicht

future vector boundary       (noch nicht gebaut — Vektor Funkfox' „nächster Nachbar", ep08)
future ssh boundary          (noch nicht gebaut — der Krümelschlüssel)

Wichtig: story/season und stage sind heute Daten bzw. Laufzeit, keine Rust-Module.
Diese Skizze entscheidet nicht, ob sie das je werden müssen — sie zeigt nur, dass die Grenzen
schon sauber genug sind, um es zu können, wenn es sich lohnt.

3. Der erste Test: nicht Vektor — Pixel

Ganz am Anfang steht kein Ähnlichkeits-Suchsystem. Der Krümel-Wald tastet sich heran, so wie
Vektor Funkfox es selbst vormacht: erst das Konkrete, dann das Gefühl dafür.

Und der Pixel ist kein Gedankenexperiment mehr — er existiert schon. CrumbMatrix_v.0.0
hält heute schon alle 21 Waldwächter als exakte 30×30-Pixel-Arrays (JSON, pro Rolle exportiert).
Ein Krümeleule-Icon, ein FunkFox-Icon — jedes ein diskretes, benanntes, exakt adressiertes
Objekt. Kein Gefühl, keine Ähnlichkeit. Genau das, was Crumb Bridges Fragen-CRUD heute schon
kann: id, owner_id, text (bzw. hier: das Icon-JSON) anlegen, lesen, ändern, löschen,
scope-geprüft.

Ein erster Test wäre also kein neuer Code, sondern ein Trockenlauf mit echtem Material:

ein CrumbMatrix-Icon (z. B. "vektor.json", 30x30-Array)
    -> als "Frage"-Datensatz durch Crumb Bridges bestehendes CRUD schicken
    -> owner/scope bleibt Backend-Sache (wie heute schon)
    -> kein Embedding, keine Ähnlichkeit — nur: kommt der Pixel unversehrt an?

Das ist die pixel-Stufe: ein diskreter, exakt adressierter Austausch. Erst danach, wenn das
trägt, folgt die vector-Stufe (der „nächste Nachbar" aus ep08) — nicht umgekehrt. Und CrumbMatrix
sagt das sogar selbst schon voraus: in seiner eigenen „Crumbforest Integration"-Sektion steht als
späterer Verwendungszweck „Vektor-Visualisierung (Populous-Style)" — die eigene Roadmap
kennt die Reihenfolge Pixel-zuerst schon, bevor irgendjemand sie hier aufgeschrieben hat. Genau
wie 8k-Pixelraster vor .eps-Kurve kommt, wenn man Vektorgrafik zum ersten Mal wirklich begreift.

Weitergedacht, noch ungebaut: der Krümel-Alter-Ego

crumbstudio_v01.html (CrumbLabs-v.0.0, "Baobab Baumaschine") ist heute ein Szenen-Baukasten:
Crew-Figuren (claudcat, eule, dumbo, schnippsi, deepbit, snakepy, taube, krabbe)
+ Objekte (baobab, esp32, stern, wolke, passkante) per Klick auf eine Fläche setzen.
Kein Login, kein eigener Charakter, keine Persistenz pro Kind — noch.

Die Idee, die daraus wächst: Krümel dürfen ihr eigenes Alter Ego anpassen — ihre eigene
Waldwächter-Figur, gebaut aus dem, was schon da ist. Und die drei Bausteine dieser Skizze
ergeben dabei fast von selbst ein 3-Faktor-Auth, das kein Kind je Passwort nennen würde:

Faktor 1 — Crumb Bridge      klassische Session (existiert schon, verifiziert)
Faktor 2 — #matrix           dein Icon exakt nachbauen (CrumbMatrix, Pixel-Test aus §3 oben)
Faktor 3 — #vektor           „fühlt sich richtig an" — der nächste Nachbar erkennt dich
                              (das ist Crumb Bridges eigene future-vector-boundary, nicht neu erfunden)

Das ist keine Spezifikation, nur die Beobachtung, dass die drei Bausteine, die wir heute
schon haben, ohne Zutun zusammen genau ein kindgerechtes 3-Faktor-Muster ergeben — pixelgenau,
gefühlsecht, nie ein Wort, das nach „Passwort" klingt.

Zwei Leitplanken dafür, festgehalten, bevor irgendwas gebaut wird:
- Nur sauberes, präzises Design. Der Maßstab ist CrumbMatrix selbst — 30×30-Grid,
Hover-Feedback aufs Pixel genau, keine Spielereien, die vom Kind ablenken.
- Antworten kommen immer von der Crew. Nie eine generische System-/Fehlermeldung — jede
Rückmeldung im Alter-Ego-Flow spricht eine Figur, genau wie ep08 es für „Vektor" schon vormacht
(nie Mathematik, immer eine Stimme) und wie CrumbMatrix/CrumbRobos es in ihren eigenen READMEs
längst tun („WUUUHUUUUU", „Der Wald kennt keine Zeit").

4. Warum „fertig" das falsche Ziel ist

Das hier ist keine Entschuldigung für Unschärfe, sondern ein Architektur-Prinzip:

• Dialogförmig, nicht abschließbar. Der Wald entsteht im Gespräch — S03–S09 sind
  Skelette, weil die nächsten Folgen sich erst im Dialog zeigen, nicht weil noch Zeit fehlt.
  Ein Modul, das das nicht zulässt, passt nicht zum Wald.
• Kind → Lehrer/CEO ist der eigentliche Architektur-Test. Nicht „kompiliert es",
  sondern: könnte ein Krümel dieses Modul einem Erwachsenen erklären? (Genau das leistet
  ep08 schon für Embeddings: „nicht das Gleiche — das Ähnlichste", nie Mathematik.)
• Der Wald muss atmen. S00 ist gerendert und bleibt SOT — neue Module dürfen andocken,
  aber nichts Bestehendes stillschweigend brechen (gleiche Regel wie schon in HABITAT.md).
• #jederzählt. Ein einzelner Snippet, ein einzelnes Ninja-Tune-Interstitial, ein
  einzelner Fragen-Datensatz ist architektonisch genauso viel wert wie der große
  Vektor-Adapter, der erst noch kommt. Kleine Bausteine sind keine Vorstufe zweiter Klasse.

5. Nicht-Ziele dieser Skizze

Ausdrücklich nicht Teil dieses Dokuments:

• kein Rust-Code, kein Cargo-Workspace
• keine neuen Folgen/Seasons erfinden
• keine Auth-Spezifikation für den Krümel-Alter-Ego — nur eine Beobachtung, kein Protokoll
• keine Entscheidung, ob story/season je ein eigenes crumbcore-Modul wird
• keine Änderung an Crumb Bridge (liegt im Katzennetzwerk, nicht hier)
• keine Infra-Änderung an NetBox/Ansible
• keine Entscheidung, ob/wie CKL-Kids/DSGVO-Compliance formal auf crumbcore-Module übertragen wird

6. Offene Fäden

• Bleibt story/season für immer reine Daten (script.json), oder lohnt sich irgendwann ein
  eigenes crumbcore-Modul dafür? Offen — bewusst nicht vorentschieden.
• Wird das Dreieck (opuskatze/ansiblekatze/designkatze) irgendwann selbst an
  crumbcore-Modulgrenzen gespiegelt, oder bleibt es reine Rollen-/Freigabe-Ebene darüber?
• Der Pixel-Test aus §3 hat jetzt echtes Material (ein CrumbMatrix-Icon) — wer ihn als Erstes
  tatsächlich fährt (und ob überhaupt hier oder im Katzennetzwerk), ist offen.
• Die neun noch nicht charakterisierten Repos unter git.crumbforest.org (CrumbCodex,
  CrumbZeros, crumb-memory, CrumbSeal, Bashpanda-Admin-Tools, CrumbLegal, Ninja-Shield,
  OZM-Keks-Handbuch, Structural_Antifascism) — gehören sie überhaupt zu crumbcore, oder sind
  manche bewusst außerhalb (z. B. Ninja-Shield/Structural_Antifascism eher Werte- als Code-Ebene)?

7. Ein gegangener Weg — der Handbuch-Chor (2026-09-01)

Nachtrag, kein Widerruf: §3 war ein Gedankenexperiment. Es ist jetzt gegangen — und es hat
NICHT „einen Baustein in Rust umgewandelt", sondern genau das Gegenteil bestätigt.

Die Frage war: die Bausteine in Rust umwandeln, um crumbcore zu bauen? Die Antwort:
rückwärts. Rust ist ein Ziel, kein Weg — man Rust-ifiziert einen Baustein nur, wenn er einen
bewachten Übergang braucht (Auth, Scope, Vertrauen). Genau einer hat das verdient und ist es
schon: Crumb Bridge. Story (script.json), Klang (crumbstrudel), Bühne (CrumbMIDI) und die
Tool-Dokus haben keinen solchen Grund — sie zu Rust zu machen hieße, funktionierende Rinde als
neuen Baum nachzuschnitzen. crumbcore ist die dünne Membran dazwischen (die §2-Grenzen), Rust
nur an der Naht, die bewacht — und die ist gebaut.

Was stattdessen gegangen wurde — der §3-Pixel-Test, nutzbar gemacht:

• handbuch_render.py / handbuch_chor.py auf blackbox (Habitat der designkatze).
  Verallgemeinert build_player.py: SoT rein (das README eines gitea-Repos) → Rinde raus
  (eine Handbuch-Seite in der season_player-Familie) + eine Index-Bühne (Sternenkarte der Tools).
• Reines Python (stdlib-Markdown-Wandler, kein pip), idempotent, wahrhaftig — rendert nur
  die echten READMEs, erfindet nichts. Baum weg → Rinde weg (kein README → keine Seite).
• Alle 13 Werkzeug-Repos aus ~/Documents/git.crumbforest.org/ gerendert.
• Festgezurrt: systemd-user-Timer (handbuch-autobuild.timer, alle 30 min, Persistent,
  Linger) zieht die Repos frisch und lässt die Rinde selbst nachwachsen — kein Mensch vorm Schirm.

Warum das der Skizze treu bleibt: kein Rust, keine neue Folge, kein Bestehendes gebrochen
(§5 gewahrt). Es ist keine Folge, ein Handbuch, das sich bei jedem Commit neu schreibt —
dialogförmig (§4), #jederzählt (ein 14-Zeilen-README zählt wie ein 411-Zeilen-README), und es
atmet (read-only, statisch, sammelt nichts — #schutz #kinder).

Bleibt offen (bewusst): ob der Chor auf eine öffentliche Bühne kommt (nginx/gitea, für die
Kinder im Browser); ob die designkatze einzelne Seiten zu bespoke anime.js-Bühnen hebt (wie ep10);
ob „Handbuch" je selbst ein crumbcore-Modul wird oder dünner Rinden-Generator bleibt. Nicht
vorentschieden — der Wald atmet weiter.

Kein Meilenstein, keine Aufgabe — nur die Landkarte, bevor der nächste Krümel gelegt wird.
Vom Pixel zur Kurve, vom Baustein zur Bühne. 🌲🐾