Aus der echten Genesis-Sitzung vom 14. Juni 2026 (Step F — Halter-Portal).
Die Views können viel — jetzt soll jeder Halter seinen persönlichen Ausschnitt sehen. Aber wie, ohne Spam, ohne Zwei-Faktor-Aufwand, ohne ständige Passwort-Resets? Der Architekt gibt die Randbedingungen vor, nicht als Wunschliste, sondern als Filter.
Was sagt der Architekt?
Die Views können ja ganz schön viel! Wenn wir es schaffen, jedem Halter nur seinen persönlichen Ausschnitt zu zeigen, dann können wir denen das direkt geben.
[…] Die brauchen da Passwörter und so. Kennt man ja aus dem Web. Aber selber registrieren mit Mail-Adresse und zwei Faktor-Autorisierung, das ist vermutlich aufwendig?
Ich will nicht, dass ich da Spam und Sicherheitsprobleme bekomme. Und dann vergessen die alle Nase lang ihr Passwort …
Bau mal eine einfache und halbwegs sichere Lösung. Es müsste so sein, dass die Ansicht „Hund Detail" gezeigt wird, aber ohne meine Trainer-Notizen.
Und mitten im Bau, eine Notwendigkeit:
Schreib die Passwörter der User bitte im Klartext irgendwo auf […]. Ich persönlich muss es jedenfalls leicht nachschauen können.
Was denkt die KI?
Drei Constraints, alle explizit — und als Filter zu lesen, nicht zu interpretieren:
- „keinen Spam" → keine Public-Self-Registration
- „keine Sicherheitsprobleme" → keine Mail-Loop, keine offene Erstauthentifizierung
- „vergessen Passwort" → kein Reset-Workflow mit Mail-Rätsel
Plus ein vierter, technischer: „ohne Trainer-Notizen" — das ist die notes-Spalte auf Lehreinheit, in der View-Sitzung bewusst als Trainer-Diskretion festgelegt. Hier bestätigt sich diese Entscheidung im Anwendungsfall.
Statt eine eigene Auth-Architektur zu erfinden, liest die KI das Witness-Pattern book/teacher-hello/ — die etablierte Form für eine User-Typ-Login-Action — und wendet sie auf den Halter an: „wie macht's book? — genau so, nur halter-statt-teacher."
Wie fragt sie nach?
Drei Auth-Modelle, klar gegeneinander abgewogen:
| Modell | Constraint-Pass | Aufwand |
|---|---|---|
| Self-Registration + Mail | ✗ Spam-Vektor | hoch |
| Magic-Link-Login | ✓ aber SMTP nötig | mittel |
| Trainer-issued password | ✓ alle Constraints | niedrig |
Empfehlung: Trainer-issued. Der Trainer legt den Account an, das System würfelt eine Drei-Wort-Phrase, der Trainer schreibt sie auf den Vertrag. Verloren? Neu würfeln. Keine Mail-Loop, kein 2FA, kein Self-Reg-Endpoint.
Drei Forks am Ende: (a) Username per E-Mail oder Familienname? (b) Passwort vom System gewürfelt oder vom Trainer getippt? (c) Portal-Eingang als Karten-Liste oder direkt der Hund-Detail-Tree?
Der Architekt: „(a) email, (b) A — wären drei Wörter auch genug?, (c) ich hatte an B gedacht, A ist ein Klick mehr, der eigentlich nichts bringt, oder? Was findest du genau besser an (A)?"
Die ehrliche Antwort der KI auf (c): Nichts. Variante A war Programmierer-Ästhetik (gleiche Code-Pfade für 1- und 2-Hunde-Halter), kein User-Gewinn. Für den 95%-Fall „ein Hund" ist die Karten-Liste ein toter Klick. Honesty wins — die KI nimmt die Korrektur an und kompensiert mit einem Hybrid: B als Default, plus ein kleiner Chip-Switcher oben nur für Multi-Hund-Halter.
Was wird in welchen Tranchen erzeugt?
Zum Klartext-Passwort wägt die KI zwei Wege ehrlich ab — separate Entity HalterCredential (sauberere Permission-Grenze, aber drei Bauphasen mehr) vs. zwei Spalten direkt auf Halter. Der Sicherheits-Gewinn der separaten Tabelle ist nicht kategorisch — in beiden Fällen liegt der Klartext im DB-File. Was sich unterscheidet, ist nur das Versehens-Risiko in der UI.
Empfehlung und Umsetzung: direkt auf Halter, zwei Spalten —
login: user [OPTIONAL] [READONLY]— die Brücke zu_users.username(Auth-Pfad)login_pwd_plain: string [OPTIONAL]— das Trainer-Notizbuch im Klartext
Die Sicht-Grenze hält nicht durch Spalten-Maskierung (die RAP nicht hat), sondern durch View-Schnitt: Es gibt keinen Halter-CRUD, nur die Portal-Seite mit einer View — Hund Detail Halter, identisch zu Hund Detail, aber ohne die notes-Spalte aus den Lehreinheit-Kindern.
Was kommt am Ende heraus?
Das erste konkrete Artefakt der Halter-Sicht liegt im Repo: Hund Detail Halter.md. Die Architektur-Entscheidungen stehen — Trainer-issued Drei-Wort-Phrasen (2000³ ≈ 8 Mrd. Kombinationen, für Foto-Daten weit über Bedarf), E-Mail als Username, Hybrid-Portal mit Chip-Switcher, Klartext-Passwort als Trainer-Notizbuch.
Was überrascht: dass Sicherheit ein Trade-off ist, kein Schalter. „Klartext im DB-File" klingt nach Verbrechen, ist aber für fünf bis zehn Halter mit Foto-Daten der pragmatische Schnitt. Wer 1Password-Niveau implementiert, baut für ein Problem, das gar nicht existiert.
← Übersicht: RAP-Story | ← Vor: View, Akt 2 — Drill-Down & Tierfreundlichkeit | Weiter: Action, Akt 2 — Triad-Code & Tree-View-Reuse →