Entwicklungsprozess

1. Warum es diesen Meta-Artikel gibt

Die übrigen Handbuchartikel erklären Funktionen: Chat, Projekte, Datenschutz, Inferenz, Einstellungen oder Administration. Dieser Artikel erklärt die Ebene dahinter: wie Ephraim entwickelt wird, welche Arbeitsregeln das Projekt prägen und warum der Git-Verlauf viele kleine, konkrete Schritte zeigt statt weniger großer Sammeländerungen.

Der Entwicklungsprozess ist selbst ein Teil der Vertrauensarchitektur. Schulen, Eltern, Förderer, Datenschutzbeauftragte und Administratorinnen müssen nicht jede Codezeile lesen. Sie sollen aber erkennen, dass Ephraim nicht aus beliebigen Experimenten besteht. Planung, Umsetzung, Prüfung, Dokumentation und Handbuchpflege sind getrennte, sichtbare Schichten.

2. Das Team hinter Ephraim

Ephraim ist ein Lehrer-Schüler-Projekt. Das ist für den Entwicklungsprozess entscheidend: Ephraim wird noch nicht im Unterricht eingesetzt. Anforderungen entstehen deshalb aus eigener Beobachtung und Erprobung durch Schülerinnen, Schüler und Lehrkräfte: Wie würde eine typische Unterrichtssituation aussehen? Welche Vorbereitung braucht eine Lehrkraft? Welche Oberfläche verstehen Lernende ohne zusätzliche Erklärung? Ist ein Sicherheitsmechanismus erklärbar? Wird eine Antwort als nützlich, irritierend oder zu mächtig erlebt?

Schülerinnen und Schüler sind damit nicht Testpersonen eines fertigen Produkts. Sie arbeiten an der Frage mit, welche Anforderungen ein schulisches KI-System überhaupt erfüllen muss. Diese Perspektive ist für Ephraim grundlegend: Der spätere Einsatz im Unterricht wird vorbereitet, indem das Team vorher aus Schüler- und Lehrerperspektive beobachtet, ausprobiert, kritisiert und daraus eigene Anforderungen formuliert.

• Johan Becker Entwicklung, punktuelle Kernbeiträge und technische Umsetzung einzelner Bausteine.
• Matias Kühn Qualitätssicherung aus Nutzersicht, Rückmeldung zu Verständlichkeit, Wirkung und Stabilität.
• Luka Löhr Entwicklung Lead mit Schwerpunkt Architektur, Sicherheit, Streaming, Runtime und Adminlogik.
• Dr. Daniel Roth Projektleitung und Entwicklung, Verbindung von Unterricht, Produktentscheidungen, Datenschutz und Betrieb.
• Levi Neisius Qualitätssicherung, insbesondere Prüfung von Bedienwegen, Projekterfahrung und eigener Erprobung.
• Anna Csàki Qualitätssicherung, Rückmeldungen zur Schülerperspektive, Sprache und Nachvollziehbarkeit.
• Carl Brunner Qualitätssicherung, Tests von Funktionen, Grenzen und Unterrichtstauglichkeit.

Diese Rollen sind nicht starr wie in einem Unternehmen. Sie beschreiben den Arbeitsschwerpunkt. Gerade die Qualitätssicherung ist mehr als „Fehler suchen“: Sie prüft, ob Ephraim für Lernende plausibel bleibt. Ein technischer Erfolg reicht nicht, wenn eine Funktion für den späteren Schulalltag unklar, ablenkend oder schwer erklärbar wäre.

3. Was die HOPP-Foundation ermöglicht

Die HOPP-Foundation hat die Beschaffung einer NVIDIA DGX Spark für die lokale Schul-KI finanziert. Diese Förderung ist für den Entwicklungsprozess strukturell wichtig: Dadurch entsteht eine lokale, schulisch kontrollierte KI-Entwicklung, statt die spätere schulische Nutzung direkt an externe Cloud-Chatbots zu koppeln.

Die Hardwareförderung schafft keinen fertigen Unterrichtsassistenten. Sie schafft die Voraussetzung dafür, dass das Team die anspruchsvollen Fragen selbst bearbeiten kann: Wie wird Inferenz lokal betrieben? Wie werden Rollen, Projekte und private Daten getrennt? Wie erklärt man einer Schule, was auf dem Server passiert? Wie prüft man ein System, das Antworten generiert, Dateien auswertet, Projekte begleitet und gleichzeitig Datenschutzgrenzen einhalten muss?

Warum Ephraim entwickelt wurde

Der HOPP-Antrag zeigt, dass Ephraim nicht aus einer kurzfristigen Begeisterung für Chatbots entstanden ist. Am Lessing-Gymnasium gab es bereits vorher eine längere Entwicklungslinie: ein Jugend-forscht-Projekt zu einem lokalen KI-Assistenten, ein lokaler KI-Testlauf für das Kollegium, eine schulöffentliche Diskussion über KI, schulinterne Fortbildungen und praktische Erfahrungen mit KI-generierten, passgenauen Verwaltungswerkzeugen und unterrichtsnahen Prototypen. Ephraim ist die systematische Weiterentwicklung dieser Erfahrungen.

Der Antrag benennt das Grundproblem klar: Der Nutzen von KI wird besonders groß, wenn sie mit konkreten schulischen Kontexten arbeiten darf. Persönliches Lernen, Rückmeldungen, Lernstandsanalysen, Projektarbeit und Verwaltungsvorgänge lassen sich nur begrenzt sinnvoll unterstützen, wenn jeder Personenbezug ausgeschlossen bleibt. Gleichzeitig fehlten für Schulen Lösungen, die personenbezogene Daten verarbeiten dürfen und zugleich die Leistungsfähigkeit moderner Modelle erreichen. Genau aus dieser Spannung entsteht Ephraim.

Hinzu kommt die technische Erfahrung aus dem lokalen Testlauf: Ohne ausreichende Performance entsteht kein realistischer KI-Eindruck. Ein zu langsames Modell zeigt zwar das Prinzip, bildet aber nicht die Möglichkeiten moderner Inferenz ab. Die DGX Spark schafft deshalb nicht nur mehr Geschwindigkeit, sondern eine neue Entwicklungslage: Das Team prüft Anforderungen an eine lokale Schul-KI praktisch, statt nur über Cloud-Systeme zu sprechen.

4. Die drei Gedächtnisse des Projekts

Ephraim nutzt drei Formen von Projektgedächtnis. Sie erfüllen unterschiedliche Aufgaben und ersetzen einander nicht.

Das fachliche Projektgedächtnis liegt in einem internen Notion-Projektboard mit Aufgaben, Hauptseite und Verlaufschronik. Notion ist dabei kein Teil der Ephraim- Laufzeit und verarbeitet keine KI-Anfragen der Nutzerinnen und Nutzer; es ist ein internes Werkzeug für Planung und Rückblick. Der Git-Verlauf ist die technische Spur. Die Dokumentation erklärt, wie das System funktioniert. Die Handbücher verdichten diese Informationen für Menschen ohne Code-Kenntnis.

5. Wie eine Änderung durch das Projekt läuft

Eine typische Änderung beginnt nicht mit einer fertigen Spezifikation. Sie beginnt mit einer eigenen Beobachtung: Eine typische Unterrichtssituation wird später eine Funktion brauchen, der Betrieb braucht mehr Kontrolle, Datenschutz braucht eine präzisere Grenze oder die Bedienung ist noch nicht klar genug. Daraus entsteht ein kleiner, überprüfbarer Arbeitsschritt.

1. Bedarf klären: Das Problem wird konkret beschrieben, etwa als erwarteter Unterrichtsablauf, Adminaufgabe oder Datenschutzgrenze.
2. Schritt begrenzen: Die Änderung wird so klein geschnitten, dass sie in einem überschaubaren Lauf gebaut und geprüft wird.
3. Implementieren: Code wird in der passenden Schicht geändert: Oberfläche, API, Service, Datenbank, Betrieb oder Handbuch.
4. Prüfen: Je nach Risiko folgen Syntaxprüfung, Funktionstest, E2E-Test, Playwright-Screenshot, Smoke-Test oder manuelle Sichtprüfung.
5. Dokumentieren: Technische Dokumentation und Handbücher werden angepasst, wenn Verhalten, Betrieb oder Nutzerverständnis betroffen sind.

In einem Lehrer-Schüler-Projekt ist dieser Zyklus besonders konkret. Ein Beispiel: Wenn eine Projektfunktion technisch funktioniert, ist sie noch nicht fertig. Sie muss für eine Lehrkraft in der Vorbereitung handhabbar sein, für Schülerinnen und Schüler im Projektchat eindeutig bleiben und für Administratorinnen betrieblich erklärbar sein. Deshalb erzeugt eine Beobachtung aus der Qualitätssicherung oft keine einzelne Fehlerkorrektur, sondern eine kleine Kette: Text präzisieren, UI-Zustand verbessern, Test ergänzen, Handbuch nachziehen.

6. Was der Verlauf von Januar bis Anfang Juni 2026 zeigt

Zum Stand 04.06.2026 enthält der lokale Hauptverlauf über 1700 Commits. Die interne Verlaufschronik unterscheidet elf Phasen bis 04.06.2026; die Commit-Historie bestätigt die späten Schwerpunkte: Recovery, Chat-Aufbewahrung, TTS-Härtung, öffentliche Dokumentation, Whitepaper und Benchmarks. Der Verlauf zeigt einen klaren Reifeweg: von der Chat-Vertikale zur datenschutzbewussten und nachweisfähigen Schulplattform.

Die letzten drei Phasen sind für den Entwicklungsprozess besonders wichtig. Sie zeigen den Übergang von schneller Produktentwicklung zu überprüfbarer Betriebsreife. Feature Freeze bedeutet in diesem Kontext nicht, reale Ausfallpfade zu ignorieren. Buddy-Recovery, Chat-Aufbewahrung und TTS ohne Fallback sind notwendige Korrekturen für Datenschutz, Kontowiederherstellung und Betrieb. Whitepaper und Benchmarks zeigen anschließend, dass Ephraim nicht nur gebaut, sondern erklärt und nachgewiesen werden muss.

7. Technische Prinzipien, die die Entwicklung steuern

Der Entwicklungsprozess folgt einigen festen technischen Entscheidungen. Sie sind nicht nur Geschmack, sondern senken Betriebsrisiko und machen das System für Schule und Administratoren beherrschbar.

• Lokale KI statt Cloud-Abhängigkeit: Die produktive Inferenz läuft auf der Ephraim Spark. Das Sprachmodell verarbeitet die freigegebenen Inhalte dort, nicht bei externen Chatbot-Diensten.
• Einfacher Webstack: Ephraim nutzt PHP, MySQL in Produktion, eine MariaDB-kompatible DDEV-Entwicklungsumgebung und Vanilla JavaScript. Es gibt keinen Frontend-Build-Schritt und kein großes JavaScript-Framework.
• DDEV für lokale Entwicklung: Entwicklerinnen und Entwickler arbeiten mit einer reproduzierbaren lokalen Umgebung, bevor Änderungen in den Schulbetrieb gehen.
• Lokal gebündelte Bibliotheken: Drittanbieter-Komponenten werden bewusst ins Projekt aufgenommen und kontrolliert verwaltet, statt bei jedem Seitenaufruf von externen Quellen geladen zu werden.
• Strenge Trennung von Code und Darstellung: Inline-JavaScript und Inline-CSS werden vermieden. Eine strenge Content-Security-Policy schützt gegen eingeschleusten Browsercode.
• Dokumentation als Arbeitsmittel: Technische Dokumente erklären den Code für Menschen und für KI-Assistenten, die bei der Entwicklung helfen.

8. Rolle von KI-Assistenten im Entwicklungsprozess

Ephraim wird mit Unterstützung von KI-Assistenten entwickelt. Diese Unterstützung ist kein Widerspruch zum Anspruch an Datenschutz und Kontrolle. Entscheidend ist die Rolle: KI-Assistenten helfen beim Lesen, Strukturieren, Erklären, Testen, Refactoring, Schreiben von Dokumentation und bei der Code-Generierung. Genutzt werden insbesondere Codex, Cursor und Claude. Sie sind Arbeitswerkzeuge im Entwicklungsprozess, nicht die Autorität über das System.

Die technische Autorität bleibt der ausgeführte Code, die Migrationen, Tests, Konfigurationen und Dokumentation. Wenn ein Assistent einen Vorschlag macht, muss der Vorschlag in diese Schichten passen. Der Git-Verlauf zeigt deshalb nicht nur Feature- Commits, sondern auch Härtungen, Korrekturen, Dokumentationsspiegel, Testpläne, Screenshotläufe und Nacharbeiten.

Der entscheidende Paradigmenwechsel liegt darin, dass ein kleines schulisches Team heute Entwicklungsarbeit leisten kann, die Ende 2025 in dieser Geschwindigkeit und Breite für ein Lehrer-Schüler-Projekt praktisch nicht erreichbar gewesen wäre. KI erzeugt Code, erklärt bestehende Teile, findet Zusammenhänge und schreibt erste Entwürfe. Das ersetzt keine Verantwortung. Es verschiebt aber die Grenze dessen, was ein kleines Team mit guter Führung, klaren Anforderungen und konsequenter Prüfung bauen kann.

Deshalb ist die Kontrollschicht genauso wichtig wie die Generierung. Jede relevante Änderung wird über passende Prüfungen abgesichert: automatisierte Tests, Smoke- und E2E-Läufe, KI-gestützte Sicherheits- und Architektur-Audits, Screenshot-Prüfungen sowie manuelle Tests durch Schülerinnen, Schüler und Lehrkräfte. Auch Audits kommen also aus der KI-gestützten Arbeitsweise; verbindlich werden sie erst, wenn ihre Befunde verstanden, priorisiert, umgesetzt und nachgeprüft sind. Manuelle Prüfung bleibt notwendig, weil ein Test zwar technische Erwartungen kontrolliert, aber nicht vollständig beurteilt, ob ein Ablauf verständlich, pädagogisch sinnvoll und vertrauenswürdig ist.

9. Wie Qualität geprüft wird

Qualität entsteht in Ephraim aus mehreren Prüfebenen. Nicht jede Änderung braucht den gleichen Aufwand. Eine neue Adminfunktion hat andere Risiken als ein Handbuchabsatz, eine Datenbankmigration andere Risiken als ein Screenshot. Der Prüfaufwand richtet sich nach Reichweite und Risiko.

• Syntax und Laufzeit: PHP-Dateien werden auf Syntax geprüft; JavaScript-Module werden syntaktisch validiert, wenn sie geändert werden.
• Lokale Umgebung: DDEV bildet Webserver, PHP und Datenbank lokal nach, damit Änderungen vor dem Einsatz getestet werden.
• Funktionstests: Für kritische Wege gibt es Smoke- und E2E-Tests, zum Beispiel für Projekte, Mailfluss, Ratenbegrenzung oder PDF-Rückläufe.
• Visuelle Prüfung: Bei Handbüchern und UI-Arbeit werden Screenshots genutzt, damit Text, Navigation und Bilder nicht nur technisch vorhanden, sondern lesbar sind.
• Dokumentationsprüfung: Neue Handbuchartikel müssen in die zentrale Themenliste eingetragen sein, einen passenden Artikelaufbau haben und ohne eigene Navigationsduplikate auskommen.
• Sicherheitsprüfung: Änderungen an Anmeldung, Rollen, Projekten, Uploads, Exporten und Adminfunktionen werden besonders eng an Datenschutz- und Zugriffskanten geprüft.

E2E bedeutet End-to-End: Ein vollständiger Weg wird aus Nutzersicht durchgespielt. Bei den Projektprüfungen heißt das nicht nur „Button geklickt“. Ein synthetisches Unterrichtsprojekt wird angelegt, Teilnehmende starten oder bleiben aus, ein Projektchat wird geführt, ein persönlicher Abschluss erzeugt, Fazit- und Beobachtungszustände werden geprüft und die Lehrkraftsicht wird mit den gespeicherten Daten abgeglichen. Solche Testläufe liefern deshalb auch gute Anschauungsbeispiele für Handbücher, solange klar bleibt, dass die Personen fiktiv und die Rohchats keine Handbuchinhalte sind.

Screenshot-Regeln für Handbücher

Handbuch-Screenshots sollen einen stabilen Desktop-Zustand zeigen. Smartphone- und Tabletgrößen werden trotzdem geprüft, damit Layout, Umbrüche und Schaltflächen auch auf kleinen Bildschirmen nicht überlaufen. Diese Ansichten werden aber nicht als eigene Mobile-Screenshots in die Handbücher aufgenommen.

Neue Screenshots entstehen möglichst aus nachvollziehbaren DDEV- und Playwright- Szenarien. Testdaten bleiben fiktiv, freundlich benannt und fachlich plausibel. Ein Screenshot darf keine produktiven personenbezogenen Daten, Tokens, Secrets oder zufälligen lokalen Browserzustände zeigen. Pflichtzustände wie Nutzungsordnung oder Onboarding werden für den Testnutzer korrekt erledigt, damit kein Hinweis nur kaschiert wird.

Technisch gilt: Neue App-Screenshots werden in CSS-Pixeln aufgenommen, typischerweise mit 1440 × 1000 Pixeln. Retina-Aufnahmen werden nicht als doppelt große Bilder eingebunden. Nach dem Lauf werden Bild, Maße, HTML-Attribute, Bildunterschrift und Layout in Desktop-, iPad- und Smartphonebreite geprüft.

Beispiel: die inhaltlich geführte Projekte-E2E-Prüfstrecke

Die Projektprüfstrecke ist ein Beispiel dafür, wie Ephraim Automatisierung und pädagogisches Nachdenken verbindet. Der Test tut nicht so, als sei ein grüner Button schon ein gutes Unterrichtswerkzeug. Er baut eine kleine Unterrichtssituation nach: Eine Lehrkraft legt ein Projekt mit Monitoring- und Fazitoptionen an, zwei fiktive Schülerinnen oder Schüler werden freigegeben, eine Person arbeitet wirklich, die andere startet nicht. Die arbeitende Person untersucht, warum wiederverwendbare Raketen sinnvoll sein können, und vergleicht Kosten, Materialverbrauch, technische Risiken und Umweltfolgen. Dabei wird geprüft, ob Ephraim einen fachlich verständlichen Projektverlauf, ein reduziertes Lehrerfeedback und eine transparente Schüleransicht desselben Feedbacks abbildet.

Zusätzlich gibt es eine Qualitätsbenchmark mit mehreren synthetischen Profilen: sehr dünner Arbeitsstand, Datenschutzrevision, selbstsicheres Fehlkonzept, große iterative Arbeit und starke Erweiterung. Damit prüft Ephraim, ob Fazit und Lehrkraftfeedback nicht einfach freundlich klingen, sondern angemessen reagieren: keine erfundene Leistung bei wenig Daten, keine Umdeutung eines Fehlkonzepts zum Erfolg, klare Würdigung echter Arbeit und ein konkreter nächster Schritt. Genau diese Artefakte sind später auch als Beispiele im Handbuch nutzbar, weil sie zeigen, welche Art von pädagogischer Verdichtung Ephraim leisten soll.

Die Schüler-QS ist dabei ein eigener Qualitätskanal. Sie prüft nicht nur, ob ein Knopf reagiert, sondern ob ein Ablauf aus Lernendenperspektive verstanden wird: Wo landet man nach einem Projektcode? Ist klar, dass Lehrkräfte Projektchats nicht mitlesen? Fühlt sich eine KI-Antwort hilfreich oder bevormundend an? Werden Visualisierungen als Teil des Lernens wahrgenommen oder als technischer Effekt? Solche Rückmeldungen sind für Ephraim zentral, weil das System nicht nur administrativ korrekt, sondern pädagogisch brauchbar werden muss.

10. Datenschutz als Entwicklungsregel

Datenschutz wird nicht erst am Ende über das fertige Produkt gelegt. Er wirkt bereits auf die Architekturentscheidungen: lokale Inferenz, verschlüsselte Speicherung, getrennte Rollen, begrenzte Protokolle, explizite Projektkontexte und klare Adminrechte.

Diese Regel zeigt sich im Verlauf an mehreren Stellen: Entfernung von externen KI- Fallbacks im Produktivbetrieb, Umstieg auf lokale Spark-Inferenz, Krypto-Upgrade, Datei-Sicherheitskette, 2FA, Projektgrenzen, kontrollierter Basiswissensabruf, Exportfunktionen und tiefere Datenschutz-Handbücher. Datenschutz ist damit kein einzelnes Modul, sondern eine Reihe von Entscheidungen quer durch das System.

11. Warum Drittanbieter-Komponenten streng behandelt werden

Ephraim nutzt Bibliotheken für Markdown, mathematische Formeln, Codehervorhebung, Plots, chemische Strukturen, Terminalansichten, E-Mail, PDF und Vorlagen. Diese Bausteine sind notwendig, werden aber nicht als unkontrollierter Strom externer Updates betrachtet. Sie werden lokal gebündelt, inventarisiert und über einen Freigabeprozess gepflegt.

Der Prozess trennt Versionshinweis, technische Prüfung, Freigabe, Installation, Backup und Rollback. Das schützt den späteren Unterrichtsbetrieb vor spontanen Änderungen. Eine neue Version ist damit nicht automatisch besser für Ephraim. Sie wird erst dann zum Zielstand, wenn sie für Sicherheit, Lizenz, Funktion und Betrieb geprüft wurde.

12. Warum Handbücher Teil des Entwicklungsprozesses sind

Die Handbücher sind nicht die technische Wahrheit. Sie sind die Übersetzung der technischen Wahrheit in eine Sprache für Lehrkräfte, Schülerinnen, Eltern, Förderer, Schulleitung, Ämter und Administratorinnen. Deshalb entstehen Handbuchartikel nicht losgelöst vom System, sondern aus Code, Dokumentation, sichtbarer Oberfläche und überprüften Screenshots.

Ende Mai und Anfang Juni 2026 wurde diese Schicht stark ausgebaut: Artikel zu Admin-Dashboard, Einstellungen, Projekten, Visualisierungen, Basiswissen, Passwörtern, Datenschutz, Inferenz, Kryptoarchitektur, Drittanbieter-Komponenten, Recovery, Benchmarks und Whitepaper wurden ergänzt oder vertieft. Das ist kein Nebenschauplatz. Je näher Ephraim an den geplanten Schulbetrieb rückt, desto wichtiger wird die verständliche Erklärung für Menschen, die das System verantworten oder nutzen.

13. Was daraus für Schulen und Förderer folgt

Ephraim ist ein wachsendes Schulprojekt mit professionellen Entwicklungsregeln. Der Verlauf zeigt hohes Tempo, aber auch wiederkehrende Korrektur: Funktionen werden eingeführt, gehärtet, dokumentiert, optisch geprüft und bei Bedarf neu abgegrenzt. Für Schulen ist das wichtig, weil KI-Systeme vor einem Unterrichtseinsatz nicht nur beeindruckend, sondern erklärbar, betreibbar und datenschutzbewusst sein müssen.

Förderer sehen im Entwicklungsprozess, wofür Unterstützung wirkt: nicht nur für Hardware oder einzelne Funktionen, sondern für ein kontrolliertes Ökosystem aus lokaler KI, sicherer Webplattform, geplanten Unterrichtsprojekten, Adminwerkzeugen, Dokumentation und Handbüchern. Die Entwicklung bleibt nachvollziehbar, weil Projektboard, Git-Verlauf, Tests und Dokumentation die zentralen Entscheidungen sichtbar machen.

Für das Lessing-Gymnasium entsteht damit mehr als ein Werkzeug. Ephraim ist auch ein Lernprojekt über digitale Souveränität: Schülerinnen und Schüler erleben, dass KI nicht nur konsumiert wird. Sie sehen, wie ein Modell betrieben, abgesichert, erklärt und kritisch geprüft wird. Lehrkräfte sehen, welche neuen Formen von Projektarbeit möglich werden. Förderer sehen, dass Hardwareförderung dann besonders wirksam wird, wenn sie in einen transparenten Entwicklungsprozess eingebettet ist.