RAP-Story — Action, Akt 2: Triad-Code und Tree-View-Reuse

Aus der echten Genesis-Sitzung vom 14. Juni 2026 (Step F — Halter-Portal).

Aus den Entscheidungen wird Code — diszipliniert in vier Phasen. Und an einer technischen Nebenbemerkung des Architekten entscheidet sich, ob das Portal Code dupliziert oder den richtigen Hebel findet.

Was sagt der Architekt?

Technische Nebenbemerkung: Wir müssen jetzt innerhalb des Halter-Dialogs den Tree-View rendern. Es kann sein, dass das mit dem CSS nicht ganz einfach wird. Jedenfalls ist vom Coding her maximaler RE-USE angesagt …

Was denkt die KI?

Drei Schichten in einem Satz: der Tree soll als Struktur erscheinen (nicht als drei nebeneinander gestellte Listen); das CSS wird Arbeit kosten (akzeptiert); und der Hauptpunkt — nichts duplizieren, was das Trainer-UI schon kann.

Die naive Lesung wäre: den Renderer-Code aus der EntityTree-Klasse kopieren. Aber die hat 10+ schwere Abhängigkeiten — sie in eine schlanke Portal-Seite zu bootstrappen wäre brittler als nützlich. Die echte Wiederverwendungs-Ebene liegt eine Schicht tiefer: am Server-Endpoint, den das Trainer-UI intern aufruft.

curl "http://localhost:18349/api/views/Hund%20Detail%20Halter?field=id&value=4"

liefert den vollständigen Detail-Tree als ein einziges JSON-Dokument, server-seitig auf Basis des View-Templates aufgelöst — Pina mit ihren Anmeldungen, Lehreinheiten und (noch leeren) Fortschrittsberichten.

Und der entscheidende Beweis: Dasselbe Endpoint mit der Trainer-View Hund Detail liefert in den Lehreinheit-Zeilen zusätzlich die Spalte notes — beim Halter-View ist sie physisch nicht enthalten, weil das Template sie nicht referenziert.

View Lehreinheit-Spalten in der Server-Response
Hund Detail Halter customer_summary, id, photos, scheduled_at, session_state, topic
Hund Detail (Trainer) + notes

Das verschiebt das Sicherheits-Modell: Was in Akt 1 noch „View-Disziplin als Client-Schicht" hieß, ist in Wahrheit „View-Definition als Server-Filter" — also stärker. Der Halter könnte nicht einmal per Dev-Tools-Network-Inspect das Trainer-Notiz-Feld sehen, weil der Server es ihm gar nicht erst sendet.

Wie fragt sie nach?

Hier wird wenig gefragt und viel gebaut — die Forks sind in Akt 1 gefallen. Die einzige offene Designfrage (Code-Kopie vs. Endpoint-Reuse) beantwortet die KI selbst, indem sie die EntityTree-Deps prüft und den günstigeren Hebel wählt.

Was wird in welchen Tranchen erzeugt?

Implementation in vier Phasen:

  1. Halter-Schema-Erweiterung — zwei Spalten an Halter.md; Server-Neustart führt automatisch zwei ALTER TABLE … ADD COLUMN durch (Auto-Backup, ~6 s Downtime, kein Datenverlust).
  2. _users-Bevölkerung + Verkettung — eine Drei-Wort-Phrase je Halter (z. B. wiese-ball-leine für Renate Krüger), gehasht, via POST /api/admin/users eingetragen, dann PUT /api/entities/Halter/{id}. Der User-Type-Validator prüft beim Schreiben, dass _users.username existiert und aktiv ist — Defense-in-Depth gegen Tippfehler.
  3. config.json — systemRoles[halter] (read-only auf die eigenen Entitäten + Ausführungsrecht auf Hund Detail Halter) und loginActions[halter] (size: fullscreen, closeBehavior: logout).
  4. static/halter-portal/-Triad — HTML + CSS + JS nach ACTION-Disziplin: class HalterPortalView mit static async bootstrap(), Mobile-first-CSS mit großen Tap-Targets, eine einzige the…-Variable am Entry-Point.

Dann der Refactor (Akt V): Die drei separaten API-Calls weichen einem GET /api/views/Hund Detail Halter?field=id&value=<id> plus einem schlanken Recursive-Renderer (~80 Zeilen), der das Tree-JSON in HTML übersetzt. Diese 80 Zeilen sind neu, aber keine Duplikation, die später driftet — ändert sich das View-Template, nimmt der Renderer das automatisch mit.

Und weil RAP eine Lehr-Plattform ist: i18n von Anfang an. Obwohl die Hundeschule deutsch-only gedacht war, bekam das Portal de.json + en.json (61 Schlüssel) — ausgelöst durch eine englischsprachige Schulungs-Teilnehmerin. Auch der PWA-Pfad wurde mitgezogen.

Was kommt am Ende heraus?

Ein funktionierendes Halter-Portal, end-to-end verifiziert: Login mit r.krueger@t-online.de / wiese-ball-leine öffnet das Portal fullscreen, oben die Chips [Pina] (Mocca), Pina als Default, ein Klick wechselt den Tree — und die Trainer-Notizen sind nirgends sichtbar, weil der Server sie nicht sendet.

Als Ausblick vermerkt — und in den beiden folgenden Akten dann tatsächlich gebaut: die Foto-Upload-ACTION session-photo (mobil, Kamera, ad-hoc-Lehreinheit). Offen bleibt eine Row-Level-Permission als Framework-Erweiterung.

Was überrascht: dass „maximaler RE-USE" nicht heißt, mehr Code zu kopieren, sondern die richtige Schicht zu wählen. Der Reuse-Hebel lag nicht im Renderer, sondern im View-Endpoint — und nebenbei wurde das Sicherheits-Modell dadurch strenger, nicht schwächer.

← Übersicht: RAP-Story | ← Vor: Action, Akt 1 — Halter-Login | Weiter: Action, Akt 3 — Ein Foto von der Wiese →