From 234f80b4fb182551272d609ff0d8071c393f92a1 Mon Sep 17 00:00:00 2001 From: Schalli Date: Tue, 11 Aug 2026 13:21:21 +0200 Subject: [PATCH] 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) --- .planning/STATE.md | 29 +++++----- .../16-ad-gruppen-synchronisation/16-UAT.md | 54 ++++++++++++------- .../16-VERIFICATION.md | 40 +++++++++++++- 3 files changed, 90 insertions(+), 33 deletions(-) diff --git a/.planning/STATE.md b/.planning/STATE.md index 45a5bec..98d5eee 100644 --- a/.planning/STATE.md +++ b/.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 -stopped_at: Completed 16-05-PLAN.md — Phase 16 complete (5/5), PERM-02 closed -last_updated: "2026-08-06T14:41:05.149Z" -last_activity: 2026-08-06 -last_activity_desc: Phase 16 execution started +status: complete +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-11T09:25:00.000Z" +last_activity: 2026-08-11 +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 -Last activity: 2026-08-06 — Phase 16 execution started +Status: Abgeschlossen. UAT 2/5/6 bestanden, 7 teilweise, 1/3/4/8 bewusst +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 -Stopped at: Completed 16-05-PLAN.md — Phase 16 complete (5/5), PERM-02 closed +Last session: 2026-08-11T09:25:00.000Z +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 diff --git a/.planning/phases/16-ad-gruppen-synchronisation/16-UAT.md b/.planning/phases/16-ad-gruppen-synchronisation/16-UAT.md index cc5ab39..f24bc0b 100644 --- a/.planning/phases/16-ad-gruppen-synchronisation/16-UAT.md +++ b/.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 -name: AD-Umbenennung behaelt dieselbe Kennung (Annahme A1) -expected: | - Eine im Active Directory umbenannte Gruppe behaelt ihre unveraenderliche - objectGUID. Nur dann kann der Sync eine Umbenennung von einem Verschwinden - unterscheiden — die Grundlage von Erfolgskriterium 3. -awaiting: user response -blocked_on: | - Schreibzugriff im AD (balios.ctl.local) — die importierte Gruppe CN=Claude_VT - muss dort umbenannt werden. Danach Test 2, 3, 4 und der offene Teil von Test 7. +none — UAT am 2026-08-11 abgeschlossen. + +## Entscheidung 2026-08-11 + +Tests 1, 3, 4 und 8 werden NICHT durchgefuehrt. Entscheidung des Users, mit +Begruendung akzeptiert: + +- Der User hat keine Schreibrechte im AD (balios.ctl.local) — Gruppen dort + anlegen, umbenennen oder loeschen ist ihm nicht moeglich. +- 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 -skipped: 0 +pending: 0 +skipped: 4 blocked: 0 issues_detail: | Test 2 hat einen kritischen Fehler aufgedeckt (Existenzpruefung fand nie etwas, diff --git a/.planning/phases/16-ad-gruppen-synchronisation/16-VERIFICATION.md b/.planning/phases/16-ad-gruppen-synchronisation/16-VERIFICATION.md index 4d71866..1544691 100644 --- a/.planning/phases/16-ad-gruppen-synchronisation/16-VERIFICATION.md +++ b/.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 -score: 5/5 must-haves (code-level) — 2 davon PRESENT_BEHAVIOR_UNVERIFIED wegen ungeprüfter Live-AD-Annahmen +status: accepted_with_open_assumptions +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