Lösungsstrategie: Ein Build erzeugt statische Dateien, der Kern existiert einmal, Links sind die einzige Schnittstelle
Die Strategie in einem Satz: Alles, was ein Server tun würde, fällt weg, wandert in den Build oder in den Browser des Kindes, und alles, was ein LLM über die Apps wissen muss, steht in Textdateien. Das Monorepo bündelt das Generische einmal: Kern, Layout, Prüfungen. Eine App liefert nur ihr Fachliches und reicht es dem Kern hinein, statt dass der Kern die App kennt.
Grundentscheidungen
| Thema | Entscheidung | ADR |
|---|---|---|
Betrieb |
Statische Site auf GitHub Pages, kein Backend |
|
Repository und Build |
Monorepo, Eleventy 3.1.6 exakt gepinnt |
|
Wiederverwendung |
Kern einmal unter |
|
Adressen |
Basis-URL an einer Stelle; Organisation |
|
Seiten |
Kompetenzseiten aus Markdown-Front-Matter mit festem Gerüst; Regeln als Build-Fehler |
|
Bilder |
Eine Zeichenfunktion für Build (Mini-DOM) und Browser |
|
Tutor |
|
|
Videos |
Zwei-Klick-Einbettung mit lokalem, neutralem Platzhalter |
|
Zahlen und Terme |
Rundungsregel nach getippten Stellen; eigene Parser ohne |
|
Diagnose |
Test ohne Noten, Ergebniszeile für den Tutor, nur im |
|
Auslieferung |
|
|
Gestaltung |
Primärfarbe folgt dem Fach, eine Tabelle in |
|
Mathe-Karte |
Im Monorepo; App-Einträge aus den App-Konfigurationen |
Jedes Qualitätsziel hat einen Lösungsansatz
| Ziel | Ansatz | Wo im System |
|---|---|---|
QZ-1 Datenschutz by Design |
Kein Backend, nichts verlässt den Browser. Der Build bricht ab, wenn eine Seite, ein Modul oder ein Stylesheet eine fremde Ressource lädt. Videos erst nach Klick, dann nur |
ADR-001, ADR-005, ADR-008, ADR-019; |
QZ-2 Tutor-Anschlussfähigkeit |
Deterministischer Zufall aus einer vorlesbaren Aufgabennummer; URL-Parameter für jeden freien Wert; |
ADR-004, ADR-007, ADR-015; |
QZ-3 Fachlich richtige Rückmeldung |
Exakte Brüche statt Gleitkomma; eine Rundungsregel; Hinweise statt Fehler; typische Fehler mit eigenem Fehlercode. Alle Apps prüfen mit demselben Kern-Code; der Generator-Vertrag läuft für jede Kompetenz jeder App. Das Bild entsteht aus derselben Aufgabe wie die Übung. |
ADR-006, ADR-009, ADR-013, ADR-016; |
QZ-4 Neue Apps und Kompetenzen schnell und einheitlich |
Ein Monorepo, ein Kern, ein Layout: Kern-Korrektur = ein Commit. Eine Kompetenz = drei Dateien und eine Zeile; Menü, Checkliste, Test, Übersicht, Manifest, Karten-Eintrag erzeugt der Build. Regelverstöße brechen den Build. Cache-Schutz ohne Handarbeit. |
ADR-012, ADR-013, ADR-014, ADR-017, ADR-018; |
QZ-5 Zugänglich auf jedem Gerät |
Statisches HTML mit Text und Bild ohne JavaScript; Systemschriften; Mobile-first ab 360 px; Labels, |
ADR-001, ADR-011, ADR-016, ADR-017; |
Organisation: Vertikale Scheiben je Kompetenz und je App
Das Monorepo wuchs in vertikalen Scheiben: zuerst der Walking Skeleton mit der kompletten Binom-App
(PR #1), dann Prozent- und Zufall-Trainer und die Mathe-Karte parallel in eigenen Worktrees (PR #2),
dann Korrekturen wie das neutrale Play-Symbol (PR #3). Vor der Entscheidung für das Monorepo stand ein
Spike mit 20 künstlichen Apps; seine Messwerte begründen ADR-012.
Innerhalb einer App ist jede Kompetenz eine Scheibe durch alle Schichten: Seite, Generator mit Prüfer,
Bild, Test, Checklistenzeile, Menü, Abschnitt in llms.txt.
Feedback
Was this page helpful?
Glad to hear it! Please tell us how we can improve.
Sorry to hear that. Please tell us how we can improve.