RAP-Story — Action, Akt 3: Ein Foto von der Wiese

Aus der echten Genesis-Sitzung vom 19. Juni 2026 (Step F — Foto-Upload).

Das Halter-Portal steht — jetzt will der Trainer raus auf die Wiese und dort Momente festhalten. Ein Alltagswunsch, in dem mehr Architektur steckt, als er ahnt.

Was sagt der Architekt?

Wenn ich draußen bin mit einem Kunden und seinem Hund, will ich bestimmte Momente festhalten — meistens ein Foto, manchmal ein kurzes Video. Wenn die Bedienung super einfach wäre, könnte ich es gleich hochladen. Das Handy könnte mir ja den richtigen Hundenamen vorschlagen — der Computer kennt doch die Termine? Manchmal schreibe ich einen kurzen Text dazu, den der Besitzer sehen soll. Aber es muss auch ein zweites Feld geben, das nur ich sehe, für die kritischen Sachen. Sind ja oft dieselben: „zieht zu stark", „lässt sich zu leicht ablenken", „will sich zum Boss aufspielen". Wenn ich da zehn zum Auswählen hätte, ginge es schneller — die müsste ich aber auch selber ergänzen können. Und jemand hat gesagt, meine Handy-Bilder sind riesengroß … sind ja nur Bildchen für den Alltag.

Kurz darauf nachgeschoben:

Der Trick mit der Schnellauswahl wäre auch für die offiziellen Texte an den Besitzer ganz gut.

Und eine Sorge:

Wenn ich mal kein Netz habe — merkt sich das Handy das Bild? Dann lade ich es vielleicht erst am nächsten Tag hoch, da würde das Datum nicht mehr stimmen.

Was denkt die KI?

Vier Architektur-Entscheidungen stecken im Alltagstext, ohne dass eine als solche benannt wäre:

  1. Kamera am Handy — der Reflex heißt „HTTPS, Secure Context". Aber ein <input type="file" accept="image/*,video/*" capture="environment"> öffnet die native Kamera und ist kein getUserMedia — er braucht keinen Secure Context. Das entschärft die HTTPS-Sorge; sie gilt nur für den Barcode-Scanner, nicht für diesen Upload.
  2. „den richtigen Hund vorschlagen" — der Tagesplan liefert ihn: die heutigen Lehreinheiten, bei mehreren eine Auswahlliste.
  3. Zwei Textfelder — die existieren schon an Lehreinheit: customer_summary (kundensichtbar) und notes (nur Trainer).
  4. „selber ergänzen können" — und das ist der Schlüssel. Eine Liste, die der Nutzer ohne Programmieren erweitert, ist Laufzeit-Daten, kein Config-Eintrag. Also: eine kleine Entity.

Wie fragt sie nach?

Die Schnellauswahl wird eine Entity Textbaustein (text, zielgruppe, sortierung, aktiv). Der nachgeschobene Wunsch — „auch für die Besitzer-Texte" — kostet kein zweites Konstrukt: ein zielgruppe-Feld (trainer | halter) bedient beide Notizfelder aus einer Liste. Eine Pflege, eine Chip-Logik.

Beim Offline-Thema die entscheidende Umdeutung: nicht das Merken ist das Problem, sondern das Datum. Antwort in zwei Bausteinen — der Aufnahme-Zeitstempel reist mit (vom Gerät übernommen), sodass die Stunde nach dem Aufnahme-Tag datiert wird; und eine Offline-Outbox, die das Foto lokal hält und automatisch hochlädt, sobald wieder Verbindung besteht.

Bilder werden vor dem Upload client-seitig verkleinert — längste Kante etwa 1600 px, JPEG-Qualität ~0,8 → rund 300 KB statt mehrerer MB. „Tempo macht die Dateigröße, nicht die Kantenlänge."

Was wird in welchen Tranchen erzeugt?

Entity Textbaustein. Eine neue Area „Stammdaten" — und der eine Stolperstein des Abends: eine Entity wird in RAP an drei Stellen freigeschaltet (Klassendatei + DataModel + die Crud.md, die die eigentliche Enable-Liste hält; fehlt sie, bleibt die Entity „not enabled", obwohl Klasse und Area korrekt geparst sind). Geseedet mit zehn trainer-internen und sechs kundensichtbaren Bausteinen.

Action session-photo (mobil): die <input capture>-Aufnahme, das Verkleinern, der Hund-Vorschlag aus dem Tagesplan (mit ★ und Vorauswahl bei genau einem Termin), die zwei Notizfelder mit antippbaren Chips und einem „+ neu", und die Offline-Outbox auf Basis von IndexedDB, gestützt durch einen localStorage-Cache des Tagesplans, damit auch offline ein Hund vorgeschlagen werden kann.

Was kommt am Ende heraus?

Eine mobile Action, die online sofort hochlädt und ohne Netz in die Queue legt — das Datum stimmt dank Aufnahme-Zeit, auch beim Upload am Folgetag. Die Befund-Liste pflegt der Trainer selbst, ohne je eine Konfigurationsdatei zu sehen.

Was überrascht: dass „selber ergänzen können" eine Entity ist — ein Alltagswunsch erzeugt ein Stück Datenmodell. Und dass beim Offline-Thema nicht das Merken die Hürde ist, sondern das Datum; die Lösung ist dann nicht mehr Mechanik, sondern die richtige Quelle für die Zeit.

← Übersicht: RAP-Story | ← Vor: Action, Akt 2 — Triad-Code & Tree-View-Reuse | Weiter: Action, Akt 4 — Die Frage, die das Schema ändert →