test(admin): WINDOWS #14 und #15 abgenommen — Ledger ohne offene Punkte

Abnahme im Browser auf alpha gegen das echte AD, nachdem der User die Container
neu erstellt hatte. Voraussetzungen gemessen statt angenommen: Container
tatsaechlich getauscht, Migration 20260909120000_user_email_optional angewandt,
User.email is_nullable = YES. Die Migration lief beim API-Start automatisch mit.

#15 — der Sync meldet jetzt "Erstellt: 4" statt vier stiller Fehlschlaege. Die
kollidierenden Konten sind angelegt und aktiv, ohne Adresse; mbuntz behaelt als
erster Anspruch seine. Der Bericht zeigt zwei verstaendliche deutsche
Abschnitte statt Prisma-Text und englischer Meldungen. Die beiden Folgestellen
vertragen Konten ohne Adresse: die Benutzerliste zeigt einen Gedankenstrich,
und die Suche im Mitglieder-Dialog liefert die Konten sauber statt
abzustuerzen — das war der eigentliche Fallstrick.

#14 — die Matrix-Suche laesst die nicht getroffene Achse stehen. Alle vier
Faelle geprueft: Modulname behaelt die Gruppenspalten, Gruppenname behaelt die
Modulzeile, der AD-Name findet dieselbe Spalte wie der interne Name
(Regression #6c intakt), und eine Suche ohne Treffer erklaert sich in einem
verstaendlichen Satz.

Am Active Directory wurde nichts veraendert; es wurde nur gelesen. Der fuer die
Regressionsprobe gesetzte interne Name ist wieder geleert.

Ledger danach: 0 offen, 15 behoben, 1 zurueckgestellt (#12 — es gibt intern
kein Postfach fuer Ausschreibungs-Alarme).

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FYZcd3SSmo14QTqWx2KKzU

.planning/STATE.md

@@ -5,10 +5,10 @@ milestone_name: Plattform-Berechtigungen
 current_phase: 17
 current_phase_name: eigene-ausschreibungs-quellen-je-nutzer
 status: verified
-stopped_at: "Quick-Task 260909-ab3 abgeschlossen und verifiziert (8/8): Matrix-Suche leert die jeweils andere Achse nicht mehr (#14), AD-Konten mit doppelter Mailadresse werden ohne Adresse angelegt statt still zu scheitern, Sync-Bericht spricht Deutsch statt roher Prisma-Texte (#15). Dabei einen Sicherheitsfund geschlossen (T-Q3-01: bedingungsloses Ueberschreiben der Mailadresse haette Uebernahme einer fremden Adresse samt Passwort-Reset erlaubt) — per Rueckbau falsifiziert, nicht nur gruen getestet. User.email ist jetzt optional, die Migration laeuft beim naechsten API-Start automatisch mit (Dockerfile fuehrt migrate deploy aus). OFFEN: Browser-Abnahme der fuenf Punkte nach dem Neubau durch den User; #14 und #15 bleiben bis dahin im Ledger offen."
-last_updated: "2026-09-09T09:30:00.000Z"
+stopped_at: "WINDOWS #14 und #15 am 2026-09-09 auf alpha abgenommen und geschlossen. Der Sync legt die vier kollidierenden Konten jetzt an (ohne Adresse, erster Anspruch behaelt sie) und meldet das in verstaendlichem Deutsch statt in Prisma-Text; Benutzerliste und Mitgliedersuche vertragen Konten ohne Adresse. Die Matrix-Suche laesst die nicht getroffene Achse stehen, in allen vier geprueften Faellen, Regression #6c intakt. Das Ledger ist damit erstmals ohne offene Punkte: 15 behoben, 1 zurueckgestellt (#12, kein Alarm-Postfach vorhanden). Ebenfalls zurueckgestellt bleibt Abnahmeplan 02-05 (Mandantentrennung, intern zweitrangig)."
+last_updated: "2026-09-09T08:30:00.000Z"
 last_activity: 2026-09-09
-last_activity_desc: WINDOWS #14 und #15 repariert und verifiziert, Sicherheitsfund T-Q3-01 mitgeschlossen — Browser-Abnahme offen
+last_activity_desc: WINDOWS #14 und #15 im Browser abgenommen und geschlossen — Ledger erstmals ohne offene Punkte
 progress:
   total_phases: 17
   completed_phases: 17
@@ -362,7 +362,7 @@ None yet.
 | 260805-fok | Standardgruppe bei Mandanten-Anlage + Startup-Reparatur — GroupsService.ensureDefaultGroup(tenantId) mit D-13-Waechter (null Gruppen, nicht fehlende Markierung), verdrahtet in TenantService.create und AdminSeedService.ensureDefaultGroupsForAllTenants; schliesst die Migrations-Backfill-Luecke auf frischen Installationen (Testserver: tenants=1 users=4 groups=0) | 2026-08-05 | 9d1254c,0d7d8a5 | [260805-fok-standardgruppe-bei-mandanten-anlage-und-](.planning/quick/260805-fok-standardgruppe-bei-mandanten-anlage-und-/) |
 | 21 | Verschluesselungsschluessel in den Beispiel-Umgebungsdateien dokumentiert: .env.example hatte gar keinen Eintrag, .env.prod.example nannte noch den alten Namen CALENDAR_ENCRYPTION_KEY. Compose-Teil des Backlog-Punkts war bereits mit 7bda56d erledigt (Vorgabewert raus, :?-Abbruch statt Ersatzwert) | 2026-08-11 | 379606e | — |
 | 260907-let | Verbindungstest fuer das Postfach im Ausschreibungs-Radar nachgeruestet (WINDOWS #16): POST /modules/tender-radar/email-config/test plus Knopf "Verbindung testen" im Formular unter Meine Quellen. Nutzt die vorhandene testConnection() beider Inbox-Provider, Muster vom DKV-Modul. userId ausschliesslich aus dem Auth-Kontext (eigener IDOR-Test mit Koeder-userId), leerer Benutzername oder leeres Passwort faellt auf die gespeicherten verschluesselten Zugangsdaten desselben Nutzers zurueck, keine Zugangsdaten in Logs oder Antwort. Verifiziert: 646/646 API- und 228/228 Web-Tests, beide Typpruefungen sauber, Sprachschluessel-Gate von rot auf gruen. Offen: Browser-Abnahme gegen ein echtes Postfach (Ende-der-Phase, braucht Neubau durch den User) | 2026-09-07 | c4db3b2 | [260907-let-verbindungstest-fuer-das-postfach-im-aus](./quick/260907-let-verbindungstest-fuer-das-postfach-im-aus/) |
-| 260909-ab3 | Zwei Befunde aus der Live-Pruefung behoben. **#14:** Die Suche in der Freigaben-Matrix filterte beide Achsen mit demselben Begriff und leerte dadurch die jeweils andere — jetzt bleibt die nicht getroffene Achse vollstaendig stehen, die Gruppensuche unter internem UND AD-Namen (#6c) ist per Regressionstest gesichert. **#15:** AD-Konten mit bereits vergebener Mailadresse werden nun angelegt, nur ohne Adresse (Produktentscheidung des Users vom 2026-09-09; der erste Anspruch behaelt die Adresse), auf BEIDEN Wegen — Sync und Einzelimport. Rohe Prisma-Texte gehen nur noch ins Log, der Bericht zeigt drei verstaendliche deutsche Abschnitte. **Sicherheitsfund nebenbei geschlossen (T-Q3-01):** der Update-Zweig schrieb die Mailadresse bedingungslos um, ein Verzeichniseintrag haette so die Adresse einer echten Person uebernehmen und deren Passwort-Reset empfangen koennen. `User.email` ist jetzt optional (Migration geschrieben, laeuft beim naechsten API-Start automatisch mit). Verifiziert 8/8: 651/651 API- und 233/233 Web-Tests, beide Typpruefungen sauber; die Sicherheitspruefung wurde durch Rueckbau falsifiziert (ohne Besitzpruefung schlaegt der Test fehl). Offen: Browser-Abnahme nach dem naechsten Neubau | 2026-09-09 | 2167046 | [260909-ab3-matrix-suche-und-sync-meldungen-reparier](./quick/260909-ab3-matrix-suche-und-sync-meldungen-reparier/) |
+| 260909-ab3 | Zwei Befunde aus der Live-Pruefung behoben. **#14:** Die Suche in der Freigaben-Matrix filterte beide Achsen mit demselben Begriff und leerte dadurch die jeweils andere — jetzt bleibt die nicht getroffene Achse vollstaendig stehen, die Gruppensuche unter internem UND AD-Namen (#6c) ist per Regressionstest gesichert. **#15:** AD-Konten mit bereits vergebener Mailadresse werden nun angelegt, nur ohne Adresse (Produktentscheidung des Users vom 2026-09-09; der erste Anspruch behaelt die Adresse), auf BEIDEN Wegen — Sync und Einzelimport. Rohe Prisma-Texte gehen nur noch ins Log, der Bericht zeigt drei verstaendliche deutsche Abschnitte. **Sicherheitsfund nebenbei geschlossen (T-Q3-01):** der Update-Zweig schrieb die Mailadresse bedingungslos um, ein Verzeichniseintrag haette so die Adresse einer echten Person uebernehmen und deren Passwort-Reset empfangen koennen. `User.email` ist jetzt optional (Migration geschrieben, laeuft beim naechsten API-Start automatisch mit). Verifiziert 8/8: 651/651 API- und 233/233 Web-Tests, beide Typpruefungen sauber; die Sicherheitspruefung wurde durch Rueckbau falsifiziert (ohne Besitzpruefung schlaegt der Test fehl). **Am 2026-09-09 im Browser abgenommen, beide Ledger-Punkte geschlossen** (Bericht: 260909-ab3-UAT-2026-09-09.md) | 2026-09-09 | 2167046 | [260909-ab3-matrix-suche-und-sync-meldungen-reparier](./quick/260909-ab3-matrix-suche-und-sync-meldungen-reparier/) |
 
 ## Deferred Items
 
@@ -402,7 +402,7 @@ sind. Kein Anlass, sie vorher erneut vorzulegen.
 
 ## Session Continuity
 
-Last session: 2026-09-09T09:30:00.000Z
-Stopped at: Beide gefundenen Defekte repariert und verifiziert, gepusht. Es wartet nur noch die Browser-Abnahme durch den User nach dem naechsten Neubau (API + Web). Danach koennen #14 und #15 geschlossen werden. Zurueckgestellt bleiben #12 (kein Alarm-Postfach vorhanden) und Abnahmeplan 02-05 (Mandantentrennung, intern zweitrangig).
+Last session: 2026-09-09T08:30:00.000Z
+Stopped at: Nichts in Arbeit, nichts offen. Das Broken-Windows-Ledger ist leer (15 behoben, 1 zurueckgestellt). Zurueckgestellt: #12 (kein Postfach fuer Ausschreibungs-Alarme vorhanden) und Abnahmeplan 02-05 (Mandantentrennung, solange Tessera nur intern laeuft). Naechster Bau-Kandidat aus dem Backlog waere das Mandanten-Branding (eigenes Logo und eigene Farben je Mandant).
 Resume file: None
-Last activity: 2026-09-09 - #14 und #15 repariert, T-Q3-01 geschlossen, verifiziert und gepusht
+Last activity: 2026-09-09 - #14 und #15 abgenommen und geschlossen, Ledger ohne offene Punkte

.planning/WINDOWS.md

@@ -1,10 +1,10 @@
 ---
 schema_version: 1
-open_count: 2
+open_count: 0
 waived_count: 1
-fixed_count: 13
+fixed_count: 15
 total_count: 16
-last_updated: 2026-09-09T05:20:34.736Z
+last_updated: 2026-09-09T06:25:18.145Z
 ---
 
 # Broken Windows Ledger
@@ -28,8 +28,8 @@ last_updated: 2026-09-09T05:20:34.736Z
 | 11 | 13 | unmet-truth | apps/api/src/tenders/tender-fingerprint.ts |  | Cross-Source-Dedup kollabiert die Mehrzahl echter Duplikate nicht: tenderFingerprint() haengt [buyerName, title, cpvDivisionKey, deadlineKey, valueBucket] zu einem String und hasht ihn. Die Scraper-Adapter liefern cpvDivisions immer leer, DOE dagegen meist gefuellt - dieselbe Ausschreibung ergibt aus beiden Quellen verschiedene Fingerabdruecke, die Fingerprint-Stufe greift also gerade dort nicht, wo sie greifen soll. Steht als offener Rest in 13-VERIFICATION.md (status gaps_found, 3/4 Wahrheiten), war aber bisher nicht im Ledger und damit unsichtbar. Die frueher vermutete Ursache (Normalizer-Defaults) ist mit 9881005 geschlossen und nicht gemeint. | fixed |  | 2026-09-07T08:09:04.188Z | 2026-09-07T08:42:34.794Z |
 | 12 | 14 | unrun-verify | .planning/phases/14-rss-email-alert-ingestion-module-rollout/14-03-PLAN.md |  | 14-03 Task 4 (checkpoint human-verify, gate blocking): echtes Portal-Alert-Postfach ueber den Exchange/EWS-Weg anbinden und eine echte Alarm-Mail ingestieren. Zu belegen sind (a) die Mail erzeugt eine mandantenprivate Ausschreibung, (b) ein anderer Mandant sieht sie nicht, (c) der EWS-Body-Abruf liefert nicht-leeren, nicht-verstuemmelten Inhalt gegen einen echten Exchange-Server. Der handgeschriebene NTLM/SOAP-Weg ist nur gegen gemocktes httpntlm.post geprueft, nie gegen einen echten Server. Braucht ein echtes Postfach - vom User am 2026-07-24 bewusst zurueckgestellt. Stand bisher nur in 14-VERIFICATION.md (status human_needed), nicht im Ledger. | waived | Zurueckgestellt auf Entscheidung des Users vom 2026-09-09: es gibt intern derzeit KEIN Postfach, in das Ausschreibungs-Alarme hereinkommen — die Voraussetzung des Pruefpunkts existiert nicht. Ein frueheres Missverstaendnis hatte ein solches Postfach angenommen. Nachzuholen, sobald ein Alarm-Postfach eingerichtet ist: dann sind (a) mandantenprivate Ausschreibung aus der Mail, (b) Unsichtbarkeit fuer andere Mandanten und (c) nicht-leerer, nicht-verstuemmelter Nachrichtentext zu belegen. Teilentlastung vom 2026-09-09: der handgeschriebene NTLM/EWS-Weg wurde beim Test von #16 erstmals gegen den echten Exchange owa.ctl.de gemessen — Anmeldung, FindFolder und Ordneraufloesung funktionieren, belegt durch die echte ServerVersionInfo-Antwort (Exchange 15.2) im API-Protokoll. Der frueher als fragil markierte Verbindungsaufbau ist damit nicht mehr ungeprueft; offen bleibt allein das Einlesen einer echten Alarm-Mail. | 2026-09-07T08:09:04.406Z | 2026-09-09T05:20:34.736Z |
 | 13 | 1 | unmet-truth | apps/web/src/app/globals.css |  | Tailwind-4-Dunkelvariante war nie an die .dark-Klasse gebunden: globals.css definierte die Farbtokens unter .dark, deklarierte aber kein @custom-variant dark. In Tailwind 4 haengt die dark:-Utility-Variante per Vorgabe an prefers-color-scheme, nicht an einer Klasse. Die App schaltet den Modus jedoch ueber next-themes mit attribute=class. Folge: JEDE dark:-Utility im Web-Quellcode (ueber 100 Vorkommen in 10+ Dateien - Status-, Warn- und Fehlerfarben, Hinweisboxen, Badges in der Administration) blieb wirkungslos, sobald der Nutzer im Portal auf dunkel stellte, waehrend sein Betriebssystem hell stand. Am laufenden System gemessen: html.dark gesetzt, prefers-color-scheme hell, dark:bg-gray-800 ergab transparent und dark:text-green-400 blieb ohne Wirkung. Unentdeckt geblieben, weil Hintergrund und Textfarbe ueber CSS-Variablen unter .dark laufen und deshalb korrekt umschalten. Aufgedeckt beim Logo-Einbau 260907-fgv, dessen Plattenkontur dark:stroke-white/25 aus demselben Grund nicht griff. | fixed |  | 2026-09-07T09:32:24.960Z | 2026-09-07T09:35:49.019Z |
-| 14 | 15 | unmet-truth | apps/web/src/app/(portal)/admin/modules/grants/page.tsx |  | Die Suche in der Freigaben-Matrix macht die Matrix unbenutzbar, sobald sie etwas findet: derselbe Suchbegriff filtert BEIDE Achsen unabhaengig voneinander (page.tsx:137 filtert Module ueber m.name, page.tsx:145 filtert Gruppen ueber internalName/name). Ein Begriff, der nur eine Achse trifft, leert die andere vollstaendig — es bleibt nie ein Kaestchen zum Klicken uebrig. Am 2026-09-07 im Browser auf alpha gemessen: Suche 'Claude_VT' bzw. 'Vertrieb' laesst die Gruppenspalte stehen, entfernt aber jede Modulzeile; Suche 'Cert' laesst die Modulzeile stehen, entfernt aber jede Gruppenspalte. Damit scheitert genau der Zweck der Suche — in einer grossen Matrix die Kreuzung Modul x Gruppe finden. Belege: .planning/phases/16-ad-gruppen-synchronisation/uat-2026-09-07/befund-matrix-suche-gruppenname.png und befund-matrix-suche-modulname.png | open |  | 2026-09-07T12:46:56.172Z |  |
-| 15 | 16 | unmet-truth | apps/api/src/ldap/ldap.service.ts |  | Der Sync reicht rohe Techniktexte an den Administrator durch und laesst echte AD-Konten still liegen. Am 2026-09-07 auf alpha gegen das echte AD gemessen (Lauf 14:42): zehn Fehlerzeilen unter den drei Zahlenzeilen, davon zwei Sorten. (1) Vier Konten scheitern mit der woertlichen Prisma-Meldung 'Invalid prisma.user.create() invocation: Unique constraint failed on the fields: (email)' — CN=uvertrieb_ro, uvertrieb_rw, uvertrieb_ro_ss, usoftware_rw aus OU=CTL_PWS_Gruppen teilen sich offenbar eine E-Mail-Adresse. Sie werden dadurch NIE importiert, ohne dass der Administrator erfaehrt warum oder was er tun soll. (2) Sechs Eintraege melden englisch 'no username mapped (check sAMAccountName mapping)' — korrekt uebersprungene Kontakte/Ressourcen ohne sAMAccountName, aber die Meldung liest sich wie ein Fehler und ist nicht uebersetzt. Beides braucht eine verstaendliche deutsche Meldung; die E-Mail-Kollision zusaetzlich eine Entscheidung, ob solche Konten ohne E-Mail angelegt oder bewusst uebersprungen werden. Beleg: .planning/phases/16-ad-gruppen-synchronisation/uat-2026-09-07/windows6a-sync-zahlenzeilen.png | open |  | 2026-09-07T12:47:32.058Z |  |
+| 14 | 15 | unmet-truth | apps/web/src/app/(portal)/admin/modules/grants/page.tsx |  | Die Suche in der Freigaben-Matrix macht die Matrix unbenutzbar, sobald sie etwas findet: derselbe Suchbegriff filtert BEIDE Achsen unabhaengig voneinander (page.tsx:137 filtert Module ueber m.name, page.tsx:145 filtert Gruppen ueber internalName/name). Ein Begriff, der nur eine Achse trifft, leert die andere vollstaendig — es bleibt nie ein Kaestchen zum Klicken uebrig. Am 2026-09-07 im Browser auf alpha gemessen: Suche 'Claude_VT' bzw. 'Vertrieb' laesst die Gruppenspalte stehen, entfernt aber jede Modulzeile; Suche 'Cert' laesst die Modulzeile stehen, entfernt aber jede Gruppenspalte. Damit scheitert genau der Zweck der Suche — in einer grossen Matrix die Kreuzung Modul x Gruppe finden. Belege: .planning/phases/16-ad-gruppen-synchronisation/uat-2026-09-07/befund-matrix-suche-gruppenname.png und befund-matrix-suche-modulname.png | fixed |  | 2026-09-07T12:46:56.172Z | 2026-09-09T06:25:17.928Z |
+| 15 | 16 | unmet-truth | apps/api/src/ldap/ldap.service.ts |  | Der Sync reicht rohe Techniktexte an den Administrator durch und laesst echte AD-Konten still liegen. Am 2026-09-07 auf alpha gegen das echte AD gemessen (Lauf 14:42): zehn Fehlerzeilen unter den drei Zahlenzeilen, davon zwei Sorten. (1) Vier Konten scheitern mit der woertlichen Prisma-Meldung 'Invalid prisma.user.create() invocation: Unique constraint failed on the fields: (email)' — CN=uvertrieb_ro, uvertrieb_rw, uvertrieb_ro_ss, usoftware_rw aus OU=CTL_PWS_Gruppen teilen sich offenbar eine E-Mail-Adresse. Sie werden dadurch NIE importiert, ohne dass der Administrator erfaehrt warum oder was er tun soll. (2) Sechs Eintraege melden englisch 'no username mapped (check sAMAccountName mapping)' — korrekt uebersprungene Kontakte/Ressourcen ohne sAMAccountName, aber die Meldung liest sich wie ein Fehler und ist nicht uebersetzt. Beides braucht eine verstaendliche deutsche Meldung; die E-Mail-Kollision zusaetzlich eine Entscheidung, ob solche Konten ohne E-Mail angelegt oder bewusst uebersprungen werden. Beleg: .planning/phases/16-ad-gruppen-synchronisation/uat-2026-09-07/windows6a-sync-zahlenzeilen.png | fixed |  | 2026-09-07T12:47:32.058Z | 2026-09-09T06:25:18.145Z |
 | 16 | 14 | unmet-truth | apps/api/src/tenders/tenders.controller.ts |  | Das Postfach im Ausschreibungs-Radar hat keinen Verbindungstest, obwohl die Faehigkeit fertig vorliegt. Beide Inbox-Provider bringen testConnection() mit (imap.provider.ts:343, exchange-inbox.provider.ts:294), und das DKV-Modul nutzt sie ueber POST /dkv/test-connection samt Knopf 'Verbindung testen' im InboxConfigForm. Beim Ausschreibungs-Radar fehlt beides: der Controller kennt zu email-config nur GET (:343) und PUT (:357), kein Test-Endpunkt, und das Formular unter Meine Quellen hat keinen Knopf. Historie geprueft: der Knopf war nie vorhanden (git log -S testConnection im tender-radar-Frontend ist leer), es ist also eine Luecke, keine Regression. Folge fuer den Betrieb: ein Tippfehler in der EWS-Endpunkt-URL oder falsche Zugangsdaten fallen erst auf, wenn dauerhaft nichts ankommt — und dann ist nicht unterscheidbar, ob die Verbindung scheitert oder schlicht keine Alarm-Mail da war. Das trifft besonders WINDOWS #12, dessen ganzer Zweck der Beleg des handgeschriebenen NTLM/SOAP-Wegs ist. Aufgefallen am 2026-09-07 beim Einrichten des Postfachs. | fixed |  | 2026-09-07T13:22:33.916Z | 2026-09-09T05:20:09.851Z |
 
 ````json
@@ -197,10 +197,10 @@ last_updated: 2026-09-09T05:20:34.736Z
     "file": "apps/web/src/app/(portal)/admin/modules/grants/page.tsx",
     "line": null,
     "description": "Die Suche in der Freigaben-Matrix macht die Matrix unbenutzbar, sobald sie etwas findet: derselbe Suchbegriff filtert BEIDE Achsen unabhaengig voneinander (page.tsx:137 filtert Module ueber m.name, page.tsx:145 filtert Gruppen ueber internalName/name). Ein Begriff, der nur eine Achse trifft, leert die andere vollstaendig — es bleibt nie ein Kaestchen zum Klicken uebrig. Am 2026-09-07 im Browser auf alpha gemessen: Suche 'Claude_VT' bzw. 'Vertrieb' laesst die Gruppenspalte stehen, entfernt aber jede Modulzeile; Suche 'Cert' laesst die Modulzeile stehen, entfernt aber jede Gruppenspalte. Damit scheitert genau der Zweck der Suche — in einer grossen Matrix die Kreuzung Modul x Gruppe finden. Belege: .planning/phases/16-ad-gruppen-synchronisation/uat-2026-09-07/befund-matrix-suche-gruppenname.png und befund-matrix-suche-modulname.png",
-    "status": "open",
+    "status": "fixed",
     "reason": "",
     "recorded_at": "2026-09-07T12:46:56.172Z",
-    "resolved_at": null
+    "resolved_at": "2026-09-09T06:25:17.928Z"
   },
   {
     "id": 15,
@@ -209,10 +209,10 @@ last_updated: 2026-09-09T05:20:34.736Z
     "file": "apps/api/src/ldap/ldap.service.ts",
     "line": null,
     "description": "Der Sync reicht rohe Techniktexte an den Administrator durch und laesst echte AD-Konten still liegen. Am 2026-09-07 auf alpha gegen das echte AD gemessen (Lauf 14:42): zehn Fehlerzeilen unter den drei Zahlenzeilen, davon zwei Sorten. (1) Vier Konten scheitern mit der woertlichen Prisma-Meldung 'Invalid prisma.user.create() invocation: Unique constraint failed on the fields: (email)' — CN=uvertrieb_ro, uvertrieb_rw, uvertrieb_ro_ss, usoftware_rw aus OU=CTL_PWS_Gruppen teilen sich offenbar eine E-Mail-Adresse. Sie werden dadurch NIE importiert, ohne dass der Administrator erfaehrt warum oder was er tun soll. (2) Sechs Eintraege melden englisch 'no username mapped (check sAMAccountName mapping)' — korrekt uebersprungene Kontakte/Ressourcen ohne sAMAccountName, aber die Meldung liest sich wie ein Fehler und ist nicht uebersetzt. Beides braucht eine verstaendliche deutsche Meldung; die E-Mail-Kollision zusaetzlich eine Entscheidung, ob solche Konten ohne E-Mail angelegt oder bewusst uebersprungen werden. Beleg: .planning/phases/16-ad-gruppen-synchronisation/uat-2026-09-07/windows6a-sync-zahlenzeilen.png",
-    "status": "open",
+    "status": "fixed",
     "reason": "",
     "recorded_at": "2026-09-07T12:47:32.058Z",
-    "resolved_at": null
+    "resolved_at": "2026-09-09T06:25:18.145Z"
   },
   {
     "id": 16,

.planning/quick/260909-ab3-matrix-suche-und-sync-meldungen-reparier/260909-ab3-UAT-2026-09-09.md

@@ -0,0 +1,102 @@
+# Abnahme im Browser — 2026-09-09
+
+Durchgefuehrt auf **alpha** (https://alpha.tessera.ctl.de) gegen das echte
+Active Directory, nachdem der User die Container neu erstellt hatte.
+Schliesst WINDOWS.md **#14** und **#15**.
+
+## Voraussetzungen gemessen, nicht angenommen
+
+| Pruefung | Ergebnis |
+|----------|----------|
+| Container wirklich getauscht | alle drei "Up About a minute" |
+| Migration angekommen | `User.email` → `is_nullable = YES` |
+| Migration in der Historie | `20260909120000_user_email_optional` |
+
+Die Migration lief beim Start der API automatisch mit — der Container fuehrt
+`prisma migrate deploy` vor dem Start aus (`apps/api/Dockerfile`). Es war kein
+zusaetzlicher Schritt noetig.
+
+## WINDOWS #15 — Sync-Bericht und Kontenanlage
+
+Ausgangslage vor dem Lauf: 409 Benutzer, **keiner** ohne Adresse, die vier
+kollidierenden Konten **nicht vorhanden**.
+
+Nach `Jetzt synchronisieren`:
+
+```
+Erstellt: 4, aktualisiert: 408, deaktiviert: 0
+```
+
+Darunter zwei neue, verstaendliche Abschnitte — kein Prisma-Text mehr, kein
+Englisch:
+
+> Diese Konten wurden ohne E-Mail-Adresse angelegt, weil die Adresse bereits zu
+> einem anderen Konto gehoert. Anmeldung und Zugriff funktionieren, nur
+> Benachrichtigungen per E-Mail erreichen sie nicht.
+>
+> - uvertrieb_ro — Adresse bereits vergeben an ein anderes Konto: mbuntz@ctl.de
+> - uvertrieb_rw — …
+> - uvertrieb_ro_ss — …
+> - usoftware_rw — …
+
+> Ohne Anmeldenamen uebersprungen — normal fuer Kontakte und Verteiler im
+> Verzeichnis.
+>
+> - CN=backupprtg@albweb.de,CN=Users,DC=ctl,DC=local
+> - CN=Rolf Staudenmayer,OU=CTL_Ressourcen,DC=ctl,DC=local
+> - …
+
+**Datenbankstand danach** — die Produktentscheidung haelt exakt:
+
+| Konto | Adresse |
+|-------|---------|
+| mbuntz | mbuntz@ctl.de (erster Anspruch behaelt sie) |
+| uvertrieb_ro | (keine) |
+| uvertrieb_rw | (keine) |
+| uvertrieb_ro_ss | (keine) |
+| usoftware_rw | (keine) |
+
+Alle vier aktiv. Vorher wurden sie bei **jedem** Lauf still verworfen.
+
+Beleg: `uat-2026-09-09/w15-sync-bericht-deutsch.png`
+
+### Folgestellen, die an Konten ohne Adresse haetten scheitern koennen
+
+| Stelle | Ergebnis |
+|--------|----------|
+| Benutzerliste (`/admin/users`) | zeigt die Konten, Adressspalte `–`, kein Fehler |
+| Suche im Mitglieder-Dialog | Suche nach `uvertrieb` liefert die drei Konten sauber — **kein Absturz** |
+
+Die zweite Stelle war der eigentliche Fallstrick: `GroupMembersModal` rief
+`.toLowerCase()` ungeschuetzt auf der Adresse auf. Ohne den Schutz waere die
+Mitgliedersuche mit dem ersten adresslosen Konto kaputtgegangen.
+
+## WINDOWS #14 — Suche in der Freigaben-Matrix
+
+Aufbau: zwei Gruppenspalten (`Alle Benutzer`, `Vertrieb Team` — interner Name
+fuer die AD-Gruppe `Claude_VT`), eine Modulzeile (`Ausschreibungs-Radar`).
+
+| Sucheingabe | Erwartung | Ergebnis |
+|-------------|-----------|----------|
+| `Ausschreibung` (Modulname) | Modulzeile **und alle** Gruppenspalten bleiben | bestanden — beide Spalten samt Kaestchen da |
+| `Vertrieb` (interner Gruppenname) | Spalte **und** Modulzeile bleiben | bestanden — Kaestchen anklickbar |
+| `Claude_VT` (AD-Name) | dieselbe Spalte, Modulzeile bleibt | bestanden — **Regression #6c intakt** |
+| `gibtesnicht123` | verstaendliche Leermeldung | „Kein Treffer fuer „gibtesnicht123" — weder bei den Modulen noch bei den Gruppen." |
+
+Vor der Reparatur leerte jede Suche die jeweils andere Achse, sodass nie ein
+Kaestchen uebrig blieb.
+
+Beleg: `uat-2026-09-09/w14-matrix-gruppensuche-behaelt-modulzeile.png`
+
+## Zustand nach der Abnahme
+
+- Der interne Name `Vertrieb Team` wurde nur fuer die Regressionsprobe gesetzt
+  und danach wieder geleert.
+- Die vier neu angelegten Konten bleiben bestehen — sie sind das Ergebnis des
+  Tests, kein Testartefakt, und gehoeren fachlich ins Verzeichnis.
+- Am Active Directory wurde **nichts** veraendert; es wurde nur gelesen.
+
+## Ledger
+
+WINDOWS.md danach: **0 offen**, 15 behoben, 1 zurueckgestellt (#12 — es gibt
+intern kein Postfach fuer Ausschreibungs-Alarme).