Aus der echten Genesis-Sitzung vom 19. Juni 2026 (Step F — Foto-Upload).
Die Foto-Action läuft. Dann stellt der Architekt eine beiläufige Frage — und sie verändert das Datenmodell.
Was sagt der Architekt?
Hast du mir gerade nebenbei erklärt, dass ich während einer ganzen Outdoor-Stunde nur ein einziges Bild hochladen kann? Oder meintest du, dass ich jedes Bild einzeln machen muss — also nicht zwei, drei erst machen und dann in einem Rutsch hochladen?
Was denkt die KI?
Beides war so, wie der Trainer es nicht will — und das gibt die KI ehrlich zu. Der Grund liegt im Modell: das Foto-Feld war als photos media[] deklariert — ein Array. Im Framework verhält es sich aber wie ein einzelner Wert: der Validator verlangt einen String, die Media-Verknüpfung kennt nur eine Referenz pro Feld. „Array" steht dran, ist aber keins — ein echter Widerspruch zwischen Spezifikation und Code. Ein zweites Foto an derselben Stunde hätte das erste überschrieben.
Wie fragt sie nach?
Statt gegen das wacklige media[] zu kämpfen, schlägt die KI das saubere Modell vor: eine Kind-Entity Aufnahme — verkettet auf die Lehreinheit (lehreinheit), mit einem skalaren bild (das funktioniert zuverlässig), einem aufgenommen_am-Zeitstempel und einer optionalen bildnotiz. Eine Stunde hat damit beliebig viele Aufnahmen; „in einem Rutsch" heißt: mehrere Schnappschüsse sammeln, dann werden daraus mehrere Aufnahme-Zeilen.
Der Architekt, knapp:
Ja, dann mach das mal so. … Hauptsache wir finden jetzt einen Weg.
Was wird in welchen Tranchen erzeugt?
Entity Aufnahme — wieder die Drei-Stellen-Freischaltung (Klassendatei + DataModel + Crud.md). Beim Server-Neustart liest RAP die geänderte Spezifikation, vergleicht sie mit der Datenbank und führt die Migration aus: CREATE TABLE aufnahme — in Sekunden. (Genau das Bild, das RAP gern selbst benutzt: die Küche liest die neue Speisekarte und räumt die Vorratskammer um.)
Die Action umgebaut: sie sammelt mehrere Aufnahmen in einer Vorschau-Leiste und lädt sie gemeinsam hoch — je Foto eine Aufnahme-Zeile, danach die Stunde auf completed. Die Offline-Outbox arbeitet pro Foto; ein Flush-Guard verhindert, dass beim Wieder-Online-Gehen zwei parallele Upload-Läufe dasselbe Foto doppelt schicken.
Belegt wurde alles mit einem Headless-Browser-Test: zwei Fotos online → eine Lehreinheit mit zwei Aufnahmen; ein Foto offline aufgenommen → in der Queue → online → automatisch nachgeladen. Und das Aufnahme-Datum war der Aufnahme-Tag, nicht der Upload-Tag.
Was kommt am Ende heraus?
Mehrere Fotos je Stunde, online wie offline, mit korrektem Datum — und damit ist der Action-Schritt der Hundeschule abgeschlossen. Als Ausblick bleibt zweierlei: echtes media[] als Framework-Erweiterung und eine Row-Level-Permission.
Was überrascht: dass eine beiläufige UI-Frage im selben Dialog zur Schema-Ergänzung wird, die in Sekunden migriert und lauffähig ist. Das gelingt nicht trotz, sondern wegen der klaren RAP-Architektur: Entitäten, Fremdschlüssel, Areas und Actions sind feste Schienen, auf denen eine solche Erweiterung läuft, statt sich durch handgeschriebenen Code zu wühlen. Der Mensch sagt das Ziel, die Konstrukte tragen den Weg.
← Übersicht: RAP-Story | ← Vor: Action, Akt 3 — Ein Foto von der Wiese | Weiter: Politur — Kommt das Foto bei der Halterin an? →