RAP-Story — View, Akt 1: Sieben Sichten auf denselben Datenhaushalt

Aus der echten Genesis-Sitzung vom 14. Juni 2026 (Step D — Views).

Das Datenmodell steht — sechs sortenreine Töpfchen. Jetzt kommt die Schicht, in der der Trainer nicht eine Entität öffnet, sondern eine Frage stellt und das System die Antwort aus mehreren Entitäten komponiert.

Was sagt der Architekt?

Jetzt hast du meinen Datenhaushalt in lauter sortenreine Töpfchen gepackt […]. Ich denke aber oft im Zusammenhang über alles nach.

Zum Beispiel will ich wissen, was an einem bestimmten Termin passiert ist. Da sind ja oft mehrere Halter mit ihren Hunden dabei. […] Du kannst Tabellen als Ansicht erzeugen, aber vermutlich wäre auch eine deiner ausklappbaren Baum-Ansichten gut geeignet.

Und dann will ich natürlich die Entwicklung eines Hundes im zeitlichen Längsschnitt verstehen […]. Diese Ansicht können wir ja vielleicht später dem Halter auch mal direkt über die neue Website zugänglich machen.

Eine kleine Grafik mit Zeitachse wäre auch hübsch. […] Ach ja, ich will einen Report haben, welche Anmeldungen noch pending sind.

Was denkt die KI?

Fünf Sichten in einem Atemzug — aber nicht gleich tief. Drei sind Single-Entity-Filter (Pending-Anmeldungen, Geld-Sicht, Termin-Liste), zwei sind echte Quer-Sichten mit Multi-Entity-Join (Hund-Längsschnitt, Termin-Baum), eine ist eine Visualisierung (Zeitachse).

Und im Nebensatz blitzt schon der übernächste Schritt auf: „später dem Halter auch mal direkt zugänglich machen" — das ist der Keim für das Halter-Portal. Wenn die Hund-Längsschnitt-View von Anfang an einen Halter-Filter mitdenkt, spart das später eine Verdoppelung.

Beim Hinschauen auf die Anmeldung-Entity dann ein Geschenk des Modells: Der pending-Zustand enthält implizit drei Sub-States, die sich allein aus dem NULL-Pattern zweier Datumsspalten ablesen lassen:

Sub-State Bedingung Bedeutung
🆕 frisch nur submitted_at Online-Anfrage, Kennenlern offen
👋 terminiert kennenlern_at gesetzt Probestunde steht an
⏳ Entscheidung offen probestunde_at gesetzt Trainer muss accept/reject

Diese Sub-States entstehen ohne eigene Status-Spalte.

Wie fragt sie nach?

Statt sofort fünf Views zu generieren, ordnet die KI nach Unabhängigkeit (Pending → Geld → Hund-Längsschnitt → Termin-Baum → Zeitachse) und stellt drei — nicht zehn — Rückfragen, bei denen das Bauchgefühl des Architekten entscheidet:

  1. Fortschrittsbericht-Lücke in der Termin-Ansicht — Platzhalter „📝 Bericht steht aus" oder kein Knoten?
  2. Hund-Längsschnitt — ein Hund per URL-Parameter (elegant fürs spätere Halter-Portal) oder Tree-View über alle Hunde?
  3. Status „offen" in Rechnung — bezahlt: bool, bezahlt_am: date NULL oder status: enum?

Der Architekt antwortet in vier Zeilen: „keine Markierung; für mich der volle Überblick, für den Halter auf seine Hund(e) eingeschränkt; ich hab ‚bezahlt am' stehen." — drei Entscheidungen, jede mit architektonischer Konsequenz.

Was wird in welchen Tranchen erzeugt?

  • Sicht (1) „Offene Anmeldungen": views/Verwaltung/Offene Anmeldungen.md, fünf Spalten, Filter status = 'pending', Sortierung ASC (älteste oben = dringend zuerst). Zwei Mini-Forks am Rand (zwei Bereiche statt drei; ASC statt DESC) — vom Architekten in vier Worten beantwortet: „Verwaltung und Training ist perfekt. ASC ist gut."
  • Dann der Foto-Wunsch („direkt während des Unterrichts vom Handy aus solche Fotos schicken") — und der entscheidende Modell-Aha: Der Architekt sagt „Fortschrittsbericht", meint aber per-Session-Foto+Text. Das Modell ist klüger als die Worte: Lehreinheit.photos (Halter), customer_summary (Halter), notes (Trainer-intern) warten schon genau auf diesen Workflow. Keine neue Spalte — die Mobile-ACTION wird an Lehreinheit angekoppelt und als eigener Schritt vermerkt.

Was kommt am Ende heraus?

Die erste View steht, der Weg für die übrigen ist geordnet — und ein Pivot rahmt den Verlauf neu. Mitten im Foto-Strang merkt der Architekt:

ANMERKUNG UNTER UNS (Claude/Gero). Jetzt leite ich unwillkürlich zu einer ACTION über. Man könnte an der Stelle jetzt auch die VIEW-Definitionen für beendet erklären.

Die KI legt drei Wege vor; der Architekt findet einen vierten: „Ich glaube, das Foto-Thema ist nicht ganz soo wichtig, dass wir deswegen die Erzeugung der VIEWS verschieben sollten." — also: alle Views jetzt, Foto-Upload-ACTION als eigener späterer Schritt.

Was überrascht: der Reflex, jeden neuen Bedarf mit einer neuen Spalte zu erschlagen — und wie oft das falsch ist. Vor jeder neuen Spalte erst fragen: kann das NULL-Pattern bestehender Spalten die Information schon tragen?

← Übersicht: RAP-Story | ← Vor: ER, Akt 2 — Aus Worten wird Modell | Weiter: View, Akt 2 — Drill-Down & Tierfreundlichkeit →