RAP-Story — ER, Akt 2: Aus Worten wird Modell

Aus der echten Genesis-Sitzung vom 7. Juni 2026.

Aus dem Verständnis wird jetzt ein Modell — und das Modell wird nicht am Reißbrett entworfen, sondern im Gespräch geschärft. Drei knappe Sätze des Trainers bauen die Architektur an drei Stellen um.

Was sagt der Architekt?

„A ist 90% — entscheidend ist ja der Hund und den kenne ich. Der muss versichert sein und so. Einfach einen fremden Hund mitbringen geht auf gar keinen Fall! […]

Email als Brücke zum Halter und für das Login kann man schon verlangen. Dann kann ich leichter Rundmails verschicken und Rechnungen mit Anlagen.

Ich muss das Tier ja kennenlernen, bevor ich mich darauf einlasse. Manche Hunde und manche Halter können so viel Ärger machen. Also ich will die Unterlagen beim ersten Treffen sehen. Dann mach ich ein Foto von den Unterlagen und von dem Tier und das landet dann alles hier im System, ok?"

Und später, zum Bezahlmodell ganz knapp:

„B1; bei guter Begründung und rechtzeitiger Nachricht vorher verschieben wir den Termin. Wenn der Halter einfach nicht auftaucht, zahlt er ohne Pardon."

Was denkt die KI?

Mit dem dritten Satz wird eine Entdeckung sichtbar, die im Schema noch nicht vorgesehen war: Onboarding ist nicht einstufig. Eine Online-Anmeldung bindet noch nicht — erst muss der Trainer den Hund persönlich kennengelernt, die Unterlagen gesichtet, ein Foto gemacht haben. Erst danach wird der Vertrag wirksam.

Das verändert das Schema an drei Stellen — und macht es dabei kleiner, nicht größer:

  • Hund bekommt acceptance_status und accepted_at. Die zunächst gedachten vaccination_status/insurance_status-Enums fliegen raus — ersetzt durch ein abgeleitetes Feld (vaccination_valid_until >= TODAY). Wer das Datum hat, hat die Wahrheit; ein parallel gepflegtes Status-Feld kann nur Drift produzieren.
  • Anmeldung wird „pro Hund" statt „pro Halter". Bringt Renate Krüger zwei Hunde, sind das zwei parallele Verträge.
  • Das Bezahlmodell Monatspauschale entkoppelt Geld von Anwesenheit: per_session_rate_eur entfällt, der Stornierungs-Code wird dramatisch einfacher. Eine geschäftliche Vereinfachung gebiert eine Schema-Vereinfachung.

Wie fragt sie nach?

Die Forks in diesem Akt sind Geschäftsentscheidungen, keine technischen:

  • Erstgespräch kostenlos oder bezahlte Probestunde? — der Architekt halbiert die Frage: Kennenlern-Gespräch gratis, danach eine kostenpflichtige Probestunde, bar vor Ort, dann erst Vertrag.
  • Abrechnungs-Modell? — eindeutig die Monatspauschale.

Auffällig: Der Architekt antwortet selten aus der vorgegebenen Auswahl, sondern teilt die Frage in zwei. Das ist kein Fehler des Workflows, sondern sein Erfolg.

Was wird in welchen Tranchen erzeugt?

Auf das GO des Architekten („Kann ich jetzt wirklich GO sagen und dann baust du das System?") folgt ein disziplinierter Bau in klaren Tranchen — protokolliert im eigenen Bau-Tagebuch Construction.md:

  1. Sechs Klassen-MDs unter docs/classes/, jede mit Entity-Kategorie: Halter [reference_data], Hund [asset_instance], Anmeldung [planning], Lehreinheit [operational_event], Fortschrittsbericht [operational_event], Rechnung [finance].
  2. DataModel.md mit vier farbigen Bereichen (Anbahnung 🤝, Hunde & Halter 🐕, Training 📅, Abrechnung 💶), Crud.md (Formular-Layouts), config.json (Port, Pauschale 80 €, Probestunde 50 €), welcome.md (öffentliche Landing-Page).
  3. Sechs Seed-Files mit erfundenen, aber glaubwürdigen Daten: 5 Halter, 6 Hunde, 6 Anmeldungen, 7 Lehreinheiten, 1 Fortschrittsbericht, 7 Rechnungen — Hamburger Stadtteile, gemischte Rassen (Labrador, Französische Bulldogge, Dackel-Mischling, Jack Russell, Schäferhund-Mischling, Australian Shepherd; bewusst keine Designer-Pudel).
  4. Server-Start ./run -s hundeschule --aitest, Schema-Generierung (12 Tabellen), Seed-Load.

Eine kleine Bauwunde im ersten Anlauf, ehrlich protokolliert: Die Felder waren als decimal deklariert — der RAP-Typ heißt aber number. Vier Anmeldungen wurden abgelehnt („Field 'monthly_rate_eur' must be a string"), Typ korrigiert, Server neu gestartet, zweiter Seed-Load lief durch.

Was kommt am Ende heraus?

Ein lauffähiges System. UI antwortet mit HTTP 200, die Datenbank ist gefüllt:

  • 5 Halter, 6 Hunde, 6 Anmeldungen (2 pending, 4 accepted)
  • 7 Lehreinheiten (alle Lifecycle-Stadien einmal), 1 Fortschrittsbericht
  • 7 Rechnungen (1 Probestunde bar, 6 Monatsrechnungen, davon 3 bezahlt)

Und ein Aha-Moment beim ersten Klick: „Ich hab das Datenmodell-Layout gemacht […] man zupft es nur noch zurecht und es ist optisch überzeugend und ständig konsistent mit der Anwendung." Das ER-Diagramm liegt nicht neben dem Code, sondern entsteht aus ihm.

Was überrascht: dass drei kurze Sätze ein Schema umbauen — und dass die Umbauten es fast immer vereinfachen. Wer das Datum speichert statt eines abgeleiteten Status, wer Geld von Anwesenheit entkoppelt, baut weniger Code, nicht mehr.

← Übersicht: RAP-Story | ← Vor: ER, Akt 1 — Gespräch mit dem Hundetrainer | Weiter: View, Akt 1 — Sieben Sichten →