docs(16): close Phase 16 UAT with A1 accepted as an open assumption

The user has no write access to the company AD, so tests 1, 3, 4 and 8 cannot
be run there, and building a throwaway domain controller for them was judged
disproportionate now that the one substantive defect at this spot is found and
fixed (UAT test 2 -> quick task 260811-f9i).

Recorded rather than hidden: A1 (objectGUID survives a rename) now rests on
Microsoft's documentation, not on our own measurement. The Tessera-side rename
and delete logic stays covered by unit tests against fixtures. If a rename ever
fails to propagate in production, 16-VERIFICATION.md names that as the starting
point.

Phase 16 marked complete in STATE.md.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

.planning/STATE.md

@@ -4,14 +4,14 @@ milestone: v1.1
 milestone_name: Ausschreibungs-Radar
 current_phase: 16
 current_phase_name: AD-Gruppen-Synchronisation
-status: verifying
+status: complete
-stopped_at: Completed 16-05-PLAN.md — Phase 16 complete (5/5), PERM-02 closed
+stopped_at: Phase 16 abgeschlossen — UAT durchgefuehrt, kritischer Sweep-Fehler gefunden und behoben (260811-f9i), Rest-Annahme A1 bewusst als offen akzeptiert
-last_updated: "2026-08-06T14:41:05.149Z"
+last_updated: "2026-08-11T09:25:00.000Z"
-last_activity: 2026-08-06
+last_activity: 2026-08-11
-last_activity_desc: Phase 16 execution started
+last_activity_desc: Phase 16 UAT abgeschlossen; objectGUID-Existenzpruefung repariert
 progress:
   total_phases: 16
-  completed_phases: 14
+  completed_phases: 15
   total_plans: 80
   completed_plans: 78
 ---
@@ -27,12 +27,17 @@ See: .planning/PROJECT.md (updated 2026-07-17)
 
 ## Current Position
 
-Phase: 16 (AD-Gruppen-Synchronisation) — EXECUTING
+Phase: 16 (AD-Gruppen-Synchronisation) — COMPLETE
 Plan: 5 of 5
-Status: Phase complete — ready for verification
+Status: Abgeschlossen. UAT 2/5/6 bestanden, 7 teilweise, 1/3/4/8 bewusst
-Last activity: 2026-08-06 — Phase 16 execution started
+uebersprungen (kein AD-Schreibzugriff, Entscheidung des Users 2026-08-11).
+UAT-Test 2 hat einen kritischen Fehler in der Loescherkennung aufgedeckt, der
+beim ersten echten Sync alle AD-gebundenen Gruppen entfernt haette — behoben in
+260811-f9i. Offene Annahme A1 (objectGUID uebersteht Umbenennung) steht
+dokumentiert in 16-VERIFICATION.md.
+Last activity: 2026-08-11 — UAT abgeschlossen, Sweep-Fix ausgeliefert
 
-Progress: [██████████] 98%
+Progress: [██████████] 100%
 
 ## Performance Metrics
 
@@ -317,7 +322,7 @@ Items acknowledged and carried forward from previous milestone close:
 
 ## Session Continuity
 
-Last session: 2026-08-06T14:41:05.118Z
+Last session: 2026-08-11T09:25:00.000Z
-Stopped at: Completed 16-05-PLAN.md — Phase 16 complete (5/5), PERM-02 closed
+Stopped at: Phase 16 abgeschlossen — UAT durchgefuehrt, objectGUID-Sweep repariert und gepusht
 Resume file: None
 Last activity: 2026-07-14 - Built LDAP per-user exclude/denylist filter (9d1323f), migration applied on live DB, verified via Playwright: sync deactivated 4 excluded service accounts (administrator/krbtgt/guest/dns-ldap), 2 real LDAP users stay active, 0 wrongly created

.planning/phases/16-ad-gruppen-synchronisation/16-UAT.md

@@ -1,29 +1,42 @@
 ---
-status: testing
+status: complete
 phase: 16-ad-gruppen-synchronisation
 source: [16-VERIFICATION.md]
 started: 2026-08-06T15:15:00Z
-updated: 2026-08-11T08:40:00Z
+updated: 2026-08-11T09:20:00Z
 ---
 
 ## Current Test
 
-number: 1
+none — UAT am 2026-08-11 abgeschlossen.
-name: AD-Umbenennung behaelt dieselbe Kennung (Annahme A1)
+
-expected: |
+## Entscheidung 2026-08-11
-  Eine im Active Directory umbenannte Gruppe behaelt ihre unveraenderliche
+
-  objectGUID. Nur dann kann der Sync eine Umbenennung von einem Verschwinden
+Tests 1, 3, 4 und 8 werden NICHT durchgefuehrt. Entscheidung des Users, mit
-  unterscheiden — die Grundlage von Erfolgskriterium 3.
+Begruendung akzeptiert:
-awaiting: user response
+
-blocked_on: |
+- Der User hat keine Schreibrechte im AD (balios.ctl.local) — Gruppen dort
-  Schreibzugriff im AD (balios.ctl.local) — die importierte Gruppe CN=Claude_VT
+  anlegen, umbenennen oder loeschen ist ihm nicht moeglich.
-  muss dort umbenannt werden. Danach Test 2, 3, 4 und der offene Teil von Test 7.
+- Der Aufwand fuer den Ersatzweg (eigener Wegwerf-Domaenencontroller im
+  Container) steht nicht im Verhaeltnis zum Rest-Erkenntnisgewinn, nachdem der
+  eine substanzielle Fehler an dieser Stelle bereits gefunden und behoben ist
+  (siehe Test 2 und Quick-Task 260811-f9i).
+- Wortlaut der Entscheidung: "Mach den Test einfach nicht. Wenn mir irgendwann
+  mal auffaellt, dass das nicht funktioniert, aendern wir das."
+
+Damit gilt fuer SC-3 und SC-4: die Tessera-seitige Logik ist durch Unit-Tests
+gegen Testdaten belegt, die Annahme ueber das Verhalten des Verzeichnisses (A1:
+objectGUID uebersteht eine Umbenennung) stuetzt sich auf die Microsoft-
+Dokumentation und wurde nicht am lebenden Verzeichnis nachgestellt. Faellt beim
+ersten echten Einsatz auf, dass eine Umbenennung nicht nachzieht, ist das der
+Ansatzpunkt.
 
 ## Tests
 
 ### 1. AD-Umbenennung behaelt dieselbe Kennung (Annahme A1)
 expected: Gegen ein echtes AD (ViCoTest, balios.ctl.local), read-only — eine importierte Gruppe suchen, ihre objectGUID notieren, die Gruppe im AD umbenennen, erneut suchen, GUID vergleichen. Die GUID muss identisch bleiben.
-result: [pending]
+result: skipped
+reason: Kein Schreibzugriff im AD; Ersatzweg als unverhaeltnismaessig verworfen (siehe Entscheidung 2026-08-11). A1 bleibt eine dokumentierte, nicht nachgestellte Annahme.
 
 ### 2. Binaerer Existenz-Filter liefert korrekte Treffer (Annahme A2)
 expected: Gegen dasselbe AD, read-only — eine Suche mit dem byteweise escapten (objectGUID=...)-Binaerfilter absetzen. Eine weiterhin existierende Gruppe muss einen Treffer liefern, eine tatsaechlich geloeschte keinen. Ein negatives Ergebnis bei Test 1 ODER 2 ist ein Stopp-Grund fuer die Loeschsemantik aus D-05.
@@ -49,11 +62,13 @@ notes: |
 
 ### 3. Umbenennung im AD zieht in Tessera nach (SC-3, end-to-end)
 expected: Gruppe im echten AD umbenennen, Sync laufen lassen. Group.name und Group.ldapDn ziehen nach, der Zaehler groupsRenamed steigt, es findet KEINE Loesch-und-Neuanlage statt, Mitgliedschaften und Modulfreigaben bleiben erhalten, ein gesetzter interner Name bleibt unveraendert.
-result: [pending]
+result: skipped
+reason: Siehe Entscheidung 2026-08-11. Die Tessera-seitige Umbenennungslogik ist durch Unit-Tests gegen Testdaten belegt (ldap.service.spec.ts), der Durchlauf am lebenden Verzeichnis entfaellt.
 
 ### 4. Loeschung im AD entfernt die Gruppe — Verschiebung nicht (SC-4, end-to-end)
 expected: Gruppe im echten AD loeschen, Sync laufen lassen — die Tessera-Gruppe wird samt GroupMembership und ModuleGrant kaskadierend entfernt, und war sie die Standardgruppe, wandert die Markierung weiter. Zusaetzlich: eine lediglich in eine andere OU VERSCHOBENE Gruppe darf NICHT geloescht werden, sondern erzeugt eine Fehlerzeile (WR-03-Fix).
-result: [pending]
+result: skipped
+reason: Siehe Entscheidung 2026-08-11. Die Filtermechanik, an der dieser Test wirklich hing, ist ueber Test 2 am echten AD geklaert und der dort gefundene Fehler behoben (260811-f9i).
 
 ### 5. Browser: Import-Sektion auf /admin/ldap
 expected: Sektion "AD-Gruppen importieren" — Discovery liefert nur Gruppen (keine OUs), Checkbox-Auswahl funktioniert, Import-Button traegt die Auswahlzahl und ist bei leerer Auswahl deaktiviert, bereits importierte Gruppen tragen das Badge und sind deaktiviert, Ergebnisblock erscheint, Fehlerzustaende sind sichtbar (nicht still). Deckt die als `verification: backstop` markierten UI-Zustaende ab: leer, ladend, Fehler, Overflow, lange Namen.
@@ -106,16 +121,17 @@ notes: |
 
 ### 8. Nebenlaeufigkeit und Layoutstress (backstop-Aussagen)
 expected: Kein beobachtbares Fehlverhalten bei parallelen Anfragen, bei Reihenfolgeunabhaengigkeit, bei Sortier-Divergenz zwischen AD-Name und internem Namen, und bei sehr langen Texten in Listen und Dialogen. Diese Aussagen sind bewusst als `verification: backstop` deklariert — kein Code-Beleg reicht zu ihrer Bestaetigung.
-result: [pending]
+result: skipped
+reason: Siehe Entscheidung 2026-08-11. Backstop-Aussagen, im Browser-Durchlauf vom 2026-08-11 ist nichts davon negativ aufgefallen — das ist aber Beobachtung, kein Nachweis.
 
 ## Summary
 
 total: 8
-passed: 2
+passed: 3
 partial: 1
 issues: 1
-pending: 4
+pending: 0
-skipped: 0
+skipped: 4
 blocked: 0
 issues_detail: |
   Test 2 hat einen kritischen Fehler aufgedeckt (Existenzpruefung fand nie etwas,

.planning/phases/16-ad-gruppen-synchronisation/16-VERIFICATION.md

@@ -1,8 +1,10 @@
 ---
 phase: 16-ad-gruppen-synchronisation
 verified: 2026-08-06T15:07:32Z
-status: human_needed
+status: accepted_with_open_assumptions
-score: 5/5 must-haves (code-level) — 2 davon PRESENT_BEHAVIOR_UNVERIFIED wegen ungeprüfter Live-AD-Annahmen
+accepted_at: 2026-08-11
+accepted_by: user
+score: 5/5 must-haves (code-level) — 2 davon PRESENT_BEHAVIOR_UNVERIFIED wegen ungeprüfter Live-AD-Annahmen; A2 am 2026-08-11 geprüft, widerlegt und der gefundene Fehler behoben (260811-f9i)
 behavior_unverified: 2
 overrides_applied: 0
 human_verification:
@@ -37,6 +39,40 @@ behavior_unverified_items:
 
 # Phase 16: AD-Gruppen-Synchronisation Verification Report
 
+## Nachtrag 2026-08-11 — Abschluss der offenen Punkte
+
+Die sechs `human_verification`-Punkte unten sind am 2026-08-11 abgearbeitet
+worden, mit einem substanziellen Fund und einer bewussten Entscheidung:
+
+**Geprüft und bestanden (Browser, alpha.tessera.ctl.de, Playwright):** die
+Import-Sektion, der Gruppen-Dialog in allen drei Zuständen, der Fehlerpfad des
+Sync-Berichts und die Spaltensuche der Freigabe-Matrix unter internem wie
+AD-Namen. Details in `16-UAT.md`, Tests 5 bis 7.
+
+**Geprüft und WIDERLEGT — Annahme A2:** der binäre `(objectGUID=...)`-Filter
+wurde als escapter String gebaut und fand am echten AD nie etwas, auch nicht für
+existierende Objekte. Beide Suchen der Existenzprüfung teilten sich diesen
+Filter, also hätte der erste echte Sync-Lauf jede AD-gebundene Gruppe samt
+Mitgliedschaften und Modulfreigaben gelöscht. Behoben in Quick-Task 260811-f9i
+(Commit `d2019dc`): `EqualityFilter` über den rohen Buffer, gegengeprüft am
+echten Verzeichnis, plus zwei Regressionstests. Damit ist SC-4 nicht mehr
+`PRESENT_BEHAVIOR_UNVERIFIED`, sondern in seiner kritischen Mechanik belegt.
+
+**Bewusst nicht geprüft — Annahme A1 und die End-to-End-Läufe (Tests 1, 3, 4, 8):**
+der User hat keine Schreibrechte im AD, und der Ersatzweg über einen eigenen
+Wegwerf-Domänencontroller wurde als unverhältnismäßig verworfen, nachdem der eine
+substanzielle Fehler bereits gefunden war. A1 (objectGUID übersteht eine
+Umbenennung) stützt sich damit auf die Microsoft-Dokumentation, nicht auf eine
+eigene Messung. Die Tessera-seitige Umbenennungs- und Löschlogik ist durch
+Unit-Tests gegen Testdaten belegt. Fällt im Betrieb auf, dass eine Umbenennung
+nicht nachzieht, ist das der Ansatzpunkt — siehe `16-UAT.md`, Abschnitt
+"Entscheidung 2026-08-11".
+
+Ebenfalls offen und bewusst so belassen: die Zahlenzeilen eines ERFOLGREICHEN
+Sync-Laufs (Test 7, zweiter Teil). Die lassen sich ohne AD-Rechte nachholen,
+sobald einmal ein Sync mit eng gesetztem Filter auf alpha läuft.
+
+
 **Phase Goal:** Ausgewählte AD-Gruppen werden als Tessera-Gruppen angelegt und dauerhaft nachgeführt, statt jede Gruppe von Hand anzulegen und zu binden. Der Admin wählt aus der AD-Gruppenliste aus, welche Gruppen übernommen werden; der bestehende Benutzer-Sync hält Bestand, Namen und Mitgliedschaften danach aktuell.
 **Verified:** 2026-08-06T15:07:32Z
 **Status:** human_needed