Onboarding-Neubau — Greenfield-Datenmodell & Rebuild-Plan (Option A)
Zielgruppen: IT-Dev/Architektur (Datenmodell, Slice-Plan) · Business/Management (Kernaussage, Aufwand, was bleibt). Status: Programm G1–G5 abgeschlossen (MED-D-294…302, Option A) — kanonisches
Feld+ Feld-Engine · einFormularVorgang-Store (Ausfüll + Onboarding) · echter Item↔Vorgang-Link · Alt-Code entfernt; Fragebogen bewusst purpose-built (MED-D-300), interaktive Item↔Mandat-Zuordnung + N3–N5 offen. Neuschnitt MED-D-630 (2026-09-26, Issue #630): Die Onboarding-Liste im Kunden-Detail ist eine reine Abhak-Liste der Basis-Unterlagen (Fehlt/Erhalten/Geprüft) — ohne Mandat-Auswahl je Item und ohne "Formular anfordern" (Formulare: Reiter "Dokumente" → "Formulare zum Ausfüllen"; ein bereits verknüpftes Formular erscheint nur als Status-Hinweis). Mandats-Unterlagen sind als eigene Checkliste je Mandat mit Vorlage je Produkt gebaut (Slice 2, #630; Standard-Liste per Migration v66). Auslöser: Nutzer „voller Greenfield-Neubau — wir haben noch keine Echtdaten, können also frei neu aufbauen." Stand-Bezug:0.130.0, 2026-09-13. Setzt die Onboarding-Neubaustudie (Richtung MED-D-291) um; löst den offenen Punkt MED-OP-ONB-1. True North: #1 („Wo steht der Kunde / was fehlt?") wird direkter beantwortet, weil Checkliste und tatsächlich ausgefüllter Vorgang endlich eine verbundene Sache sind.
1. Kernaussage (BLUF)
Heute wird derselbe Zweck dreifach gebaut — drei Feld-Modelle, drei Kundenstrecken, drei Server-Services, plus eine Onboarding-Checkliste ohne Code-Link zu den Vorgängen, die der Kunde tatsächlich ausfüllt. Weil noch keine Echtdaten im System liegen, schneiden wir das Datenmodell frei neu (keine Migration, keine Rückwärtskompatibilität) auf vier Einsen:
- Ein
Feld(kanonisch, Weltmodell/G-8) + eine Feld-Engine, die es rendert. - Ein
FormularVorgang(typ + Feld-Schema) statt dreier Server-Services. - Ein geführter Kundenfluss (der MED-D-285-Stepper); Formular/Fragebogen werden Schritte darin.
- Ein echter Item↔Vorgang-Link — die Onboarding-Checkliste treibt die Vorgänge.
Erwartete Wirkung: ~40–50 % weniger Onboarding-Code, ein Begriff statt drei, und True North #1 direkt beantwortbar — bei unverändertem Compliance-Niveau (DSGVO · eIDAS · Audit-Log · Datensparsamkeit bleiben).
2. Warum jetzt Greenfield geht (und was trotzdem gilt)
- Keine Echtdaten → das Datenmodell darf umgeschnitten werden: kein Migrationspfad, keine Alt-Feld-Backfills, keine hash-verkettete Bestandswahrung. Der teuerste Teil (drei Modelle → eins) wird dadurch überhaupt erst risikoarm.
- Trotzdem echt (kein Freibrief):
- Die App ist live deployed (
app.medidentas.com) — die Strecken müssen während des Umbaus lauffähig bleiben; beide E2E-Suiten (gemockt + full-stack) sind die Absicherung. - Compliance-Substanz bleibt Pflicht: append-only Audit-Log (G-4), Datensparsamkeit (G-6), DSGVO/eIDAS (SES-Einwilligung mit Fassungs-Version), Abschnitts-Freigabe (N2, bereits gebaut). Vereinfacht wird die Struktur, nicht der Schutz.
- Die App ist live deployed (
3. Zielarchitektur
3.1 Datenmodell (kanonisch)
Wertobjekt Feld (G-8 / Weltmodell — die eine Definition, überall gleich strukturiert):
| Attribut | Typ | Zweck |
|---|---|---|
schluessel | string | stabiler Datenmodell-Key |
label | string | sprechendes Label (G-3) |
art | text · zahl · datum · iban · plz · tel · betrag · jn · auswahl | Anzeige + weiche Validierung (nie blockierend) |
optionen? | {wert,label}[] | nur bei art='auswahl' (löst das alte select) |
wichtigkeit | pflicht · wichtig · optional | eine Skala (subsumiert Onboarding-pflicht:bool und Fragebogen-klasse) |
markierbar | boolean | erlaubt „weiß nicht"/„wird nachgeliefert" (DM-9) |
strukturTyp? | oeffnungszeiten | null | zusammengesetzte Sonderfelder |
abschnitt | string | Gruppierung → Stepper-Schritt und Abschnitts-Freigabe (N2) |
Entität FormularVorgang (ersetzt Onboarding-Einladung · Ausfüll-Formular · Fragebogen-Einladung):
id · token · mandantId · typ (onboarding|ausfuellformular|fragebogen|lead) · schemaRef · kundenWerte · kundenMarkierungen · sichtung · status · belegNr? · pruefsumme? · eingereichtAm? · **onboardingItemId?** (der fehlende Link)
Das Feld-Schema (geordnete Feld[] + Abschnitte) lebt als Katalog (schemaRef → Definition), nicht je
Vorgang doppelt (G-2, derived state nie doppelt speichern). Festwerte/Vorbefüllung aus dem Stammsatz bleiben
abgeleitet.
3.2 Server — ein Service
FormularVorgangService bündelt, was heute in OnboardingFormularService + AusfuellformularService +
dentmarking-service liegt: erstellen(typ, mandantId, schemaRef[, onboardingItemId]) · kontext(token) ·
speichern · einreichen (SES: Beleg + Prüfsumme + Audit, G-4) · Sichtung (alleAkzeptieren = N2,
feldSichten = Ausnahme) · Stammdaten-Rückübernahme. formular-vorgaenge.ts (Ausfüllgrad · SLA ·
Wiedervorlage-Helfer) wird absorbiert, nicht mehr als Klammer über drei Services gebraucht.
3.3 Client — eine Feld-Engine, ein Fluss
PubFeldEngineComponentrendert jedesFeld(art→Eingabetyp, Markierungs-Chips, weiche Hinweise/ Formatvorschläge) — löst die drei hand-geschriebenen Feld-Renderer ab.- Ein öffentlicher Fluss (der MED-D-285-Stepper) komponiert die Abschnitte eines Vorgangs zu Schritten;
Token = Zugang. Die geteilten Bausteine (
ladeFehlerAuswerten·bindeTurnstileCallback— MED-D-293) sind schon da.
3.4 Item-getrieben
Jedes Onboarding-Checklisten-Item, das Kunden-Input braucht, referenziert seinen Vorgang
(item.vorgangId bzw. vorgang.onboardingItemId). „Aus Item erzeugen" legt den Vorgang mit gesetztem Link
an; die Item-Zeile zeigt dann Status + öffnet den echten Vorgang. Das ist der in MED-D-293 bewusst
deferierte, jetzt sauber (per Datenmodell, nicht per Titel-Match) baubare Link.
4. Mapping der drei Alt-Feld-Modelle → das eine Feld
| Alt | Alt-Form | → kanonisch |
|---|---|---|
Onboarding StammdatenFeld | key·label·pflicht:bool·typ(text/select/email/tel)·optionen? | schluessel·label·wichtigkeit(pflicht→pflicht, sonst optional)·art(select→auswahl, email/tel/text 1:1)·optionen |
Ausfüll-Formular KundenFeld | schluessel·label·art(ValidierungsArt)·wichtigkeit(pflicht/wichtig/optional) | 1:1 (ist bereits am nächsten am Ziel) |
Fragebogen KatalogFeld | schluessel·art(jn/zahl/text)·klasse(essenziell/wichtig/nice)·strukturTyp·markierbar | art(jn 1:1)·wichtigkeit(essenziell→pflicht, wichtig→wichtig, nice→optional)·strukturTyp·markierbar |
Die drei divergenten Achsen (pflicht:bool · wichtigkeit · klasse) kollabieren auf eine Skala
pflicht·wichtig·optional. select→auswahl, jn/oeffnungszeiten bleiben als eigene art/strukturTyp.
5. Slice-Plan (migrationsfrei, je Slice testbar)
| Slice | Inhalt | Liefert | Tests |
|---|---|---|---|
| G1 ✅ | Kanonisches Feld + Schema-Katalog ins Weltmodell (G-8); die 3 Alt-Kataloge auf ein Schema pro Typ überführen — gebaut (MED-D-295): feld.ts + formular-schema.ts (Adapter), +9 Vitest, Weltmodell §3.4 | eine Feld-Definition | ✅ Vitest (Schema-Konsistenz, Mapping) |
| G2 ✅ (Kern) | FormularVorgang-Entität + FormularVorgangService (schema-getrieben) + Persistenz (Tabelle formular_vorgang, Migration v57) — gebaut (MED-D-296): erstellen/kontext/speichern/einreichen + Sichtung inkl. N2 + Korrektur-Schleife, +8 Vitest. Routen-Verdrahtung + Ablösung der 3 Alt-Services → nach G3 gezogen (paart mit der UI, damit nichts „floatet") | ein Server-Vorgang | ✅ Vitest (erstellen/kontext/einreichen/Sichtung) + Full-Stack-E2E (Migration) |
| G3 ✅ (MED-D-300) | Etappe 1 ✅ (MED-D-297): PubFeldEngineComponent + Adoption im Ausfüll-Formular. Etappe 2 ✅ (MED-D-298): Ausfüll-Flow komplett auf FormularVorgangService/formular_vorgang verdrahtet, AusfuellformularService abgelöst (voller Rewrite, Contract erhalten, Full-Stack-E2E 5/5). Etappe 3a ✅ (MED-D-299): Onboarding-Strecke auf die Feld-Engine. Abgeschlossen (MED-D-300): die eine Feld-Engine gilt für die strukturell gleichen Wege (Ausfüll + Onboarding ✅); der Fragebogen bleibt bewusst purpose-built (reiche Domänen-UX = Feature, nicht in die generische Engine zwingen — G-3), die Store-Vereinheitlichung bleibt bewusst auf den Ausfüll-Flow begrenzt (Onboarding/Fragebogen anders geformt — keine Wide-Table, G-8). | ein Kundenweg (Server + Client) | client/e2e + client/e2e-fullstack |
| G4 ✅ (MED-D-301) | Item↔Vorgang-Link (onboardingItemId) real verdrahtet + „Formular aus Item anfordern" (je Item idempotent) + Status/Öffnen/Link an der Item-Zeile (mandant-detail); Part B (MED-OP-ONB-1): abgeleiteter Onboarding-Bedarf gruppiert je gebuchtem Mandat („Jetzt gebraucht", Produkt-Playbook, G-2). Bewusst offen: interaktive Item↔Mandat-Zuordnung (neue Persistenz) → Folgeschritt. | Checkliste treibt Vorgänge | ✅ +2 Vitest + 2 Full-Stack-E2E (onboarding-item-vorgang.spec.ts) |
| G5 ✅ (MED-D-302) | Alt-Code entfernt: die dormante ausfuellformular-Tabelle + Repo-Methoden (repo.ts/memory-repo.ts/d1-repo.ts/schema.ts) + Migration v58 (DROP TABLE). Der Rest des Alt-Plans entfällt: AusfuellformularService fiel bereits in G3E2; OnboardingFormularService/Fragebogen bleiben (Strecken weiter live, Fragebogen purpose-built MED-D-300). Historische Migrations-Schritte + das Ausfuellformular-Interface (externe Vorgangs-Sicht) bleiben. | weniger toter Code | ✅ 709 Vitest + Full-Stack-E2E 7/7 (v58-DROP bootet sauber) |
Danach (aus der Neubaustudie): N3 Portal als einziger Zugang (an DSGVO/AVV-Gate MED-KB-13, offen) ·
N4 ✅ feldset-tolerante + kollisionssichere Stammdaten-Hash-Kette (MED-D-305/306 — statt „1 Snapshot je
Einreichung": die Kette ist bereits per-Snapshot, nur die Kanonisierung wurde feldset-tolerant/kollisionssicher
gemacht) · N5 ✅ gebaut, flag-gated/dormant Consent → DocuSign (MED-D-307, OP-SIGN-1): die Einwilligung
läuft auf Wunsch (EINWILLIGUNG_PROVIDER=docusign) als echte SES über den Provider statt als SES-Attrappe;
Go-Live (Flag in Prod) bleibt am OP-SIGN-1-Gate (echte Rechtswirkung + AVV).
Nutzer-Zusatz zu H5 (in G2/G4 einplanen): der Betreuer muss angeben können, was jetzt dringend gebraucht wird, und das soll gruppiert aus den gebuchten Beratungsmandaten hervorgehen (MED-OP-ONB-1).
6. Was bleibt (bewusst nicht wegwerfen)
- N2 Abschnitts-Freigabe (MED-D-292) — die
sichtung+abschnitt-Gruppierung tragen direkt ins neue Modell. - Feld-Sichtung als Ausnahmepfad (MED-D-89), submitted ≠ actual (4-Augen), SES-Einwilligung mit Fassungs-Version.
- Geteilte Bausteine (MED-D-293) +
pub-bausteine.ts-Präsentationsatome. - Weiche Validierung + KI-Formatvorschlag (MED-OP-VALID-1) — hängen bereits am kanonischen
feld-typ.ts.
7. Risiken & offene Punkte
- Aufwand: mehrere Sessions (G1–G5). Konkurriert mit Dexman (medipulse-Wettbewerbsdruck) um dieselbe Zeit — Reihenfolge (Onboarding-Fundament zuerst vs. Dexman zuerst) ist eine offene Priorisierungs-Frage.
- Live-Betrieb: jeder Slice muss die deployten Strecken grün halten (E2E-Gate).
- Compliance: G-4/G-6/DSGVO/eIDAS beim Neuschnitt aktiv wahren (nicht implizit verlieren).
- Fragebogen-Spezifika (
oeffnungszeiten, gewichteter Score) müssen im kanonischenFeldsauber Platz finden.
Dieses Dokument ist der Design-Beschluss (MED-D-294). Die Slices werden einzeln als
MED-D-ngebaut; vor dem ersten Bau-Slice ist nur die Reihenfolge gegen Dexman noch zu setzen.