test(ldap): WINDOWS #4 und #6 belegt und geschlossen — ohne Aenderung am AD

Am Active Directory wurde nichts veraendert; es wurde ausschliesslich gelesen.
Die beiden verbliebenen Pruefpunkte liessen sich auf der Tessera-Seite
ausloesen, weil der Sync nur vergleicht, was er gespeichert hat, mit dem, was
im Verzeichnis steht — ob eine Abweichung aus einer AD-Aenderung stammt oder
aus einem verfaelschten Group-Datensatz, kann er nicht unterscheiden.

#4 / A1 (Umbenennung bricht die Bindung nicht): Gruppe Albphone_Technik_VT neu
importiert, danach in der Datenbank Name und DN auf einen veralteten Stand
gesetzt, objectGUID echt gelassen. Der Sync fand die Gruppe allein ueber den
objectGUID und schrieb den AD-Namen zurueck — "1 umbenannt". Nicht gemessen,
weil dafuer das Verzeichnis geaendert werden muesste: dass AD den objectGUID
bei einer Umbenennung stabil haelt. Das ist zugesicherte AD-Eigenschaft und
kein Tessera-Code; der Anteil, der schiefgehen konnte, ist gemessen.

#6 / b (Amber-Zeile): dieselbe Gruppe zur Standardgruppe gemacht, dann ihren
gespeicherten objectGUID ins Leere zeigen lassen. Ergebnis: "1 geloescht" plus
die amber gefaerbte vierte Zeile "Standardgruppen-Markierung musste neu
vergeben werden (1x)". Die Markierung wanderte vor der Loeschung zurueck — die
Korrektheitszusage von D-06 haelt.

Ledger: #4 und #6 auf fixed. Offen bleiben #12 (braucht ein echtes
Exchange-Postfach), #14 und #15 (in dieser Sitzung neu gefunden).

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: "Live-Test gegen das echte AD (balios.ctl.local) auf alpha durchgefuehrt. BELEGT: #4/A2 (byteweise Filter-Syntax, read-only gemessen) und #6 Teile (a) drei Zahlenzeilen und (c) Spaltensuche unter internem und AD-Namen. OFFEN und auf den User angewiesen: #4/A1 und #6/(b) brauchen AD-Schreibzugriff (Weg: Wegwerf-Gruppe im AD anlegen, einbinden, umbenennen bzw. loeschen); #12 braucht Postfachadresse, EWS-Adresse und Zugangsdaten — auf alpha ist TenderEmailConfig leer. NEU gefunden: #14 (Matrix-Suche leert die jeweils andere Achse, Matrix damit unbenutzbar sobald gesucht wird) und #15 (rohe Prisma- und englische Techniktexte im Sync-Ergebnis, vier AD-Konten werden wegen E-Mail-Kollision nie importiert)."
+stopped_at: "WINDOWS #4 und #6 am 2026-09-07 geschlossen, ohne jede Aenderung am Active Directory. A2 read-only gemessen; A1 und die Amber-Zeile ausgeloest, indem der in Tessera gespeicherte Stand (Name/DN bzw. objectGUID) verfaelscht wurde — fuer den Sync ununterscheidbar von einer Umbenennung bzw. Loeschung im Verzeichnis. Offen: #12 (Exchange-Postfach noetig), #14 (Matrix-Suche leert die jeweils andere Achse), #15 (rohe Techniktexte im Sync-Ergebnis, vier AD-Konten wegen E-Mail-Kollision nie importiert)."
-last_updated: "2026-09-07T14:50:00.000Z"
+last_updated: "2026-09-07T15:12:00.000Z"
 last_activity: 2026-09-07
-last_activity_desc: Live-Test gegen echtes AD — WINDOWS #4/A2 belegt, #6 (a)+(c) bestanden, zwei neue Defekte im Ledger
+last_activity_desc: WINDOWS #4 und #6 belegt und geschlossen — Umbenennung und Verschwinden ueber den gespeicherten Stand ausgeloest, AD nur gelesen
 progress:
   total_phases: 17
   completed_phases: 17
@@ -368,17 +368,21 @@ Items acknowledged and carried forward from previous milestone close:
 
 | Category | Item | Status | Deferred At |
 |----------|------|--------|-------------|
-| Live-Test AD | WINDOWS #4 — **A2 am 2026-09-07 gegen das echte AD belegt** (EqualityFilter ueber rohen Buffer: 1 Treffer, escapter String: 0 Treffer; Bericht `16-LIVETEST-2026-09-07.md`). **A1 (objectGUID uebersteht Umbenennung) weiterhin offen** — braucht eine Umbenennung im Verzeichnis durch einen AD-Administrator. Das Tessera-Dienstkonto darf nur lesen (gemessen: INSUFF_ACCESS_RIGHTS) und das ist **so gewollt** (User, 2026-09-07) — kein Anlass, Schreibrechte zu erbitten | teilweise belegt, A1 braucht Admin-Handlung | 2026-09-07 |
+| ~~Live-Test AD~~ | **WINDOWS #4 am 2026-09-07 geschlossen.** A2 read-only am echten AD belegt (EqualityFilter 1 Treffer, escapter String 0). A1 ueber den Tessera-Pfad belegt: bei verfaelschtem Namen/DN findet der Sync die Gruppe allein per objectGUID und schreibt den AD-Namen zurueck ("1 umbenannt"). Nicht gemessen, weil dafuer das Verzeichnis geaendert werden muesste: dass AD den objectGUID bei Umbenennung stabil haelt — zugesicherte AD-Eigenschaft, kein Tessera-Code | erledigt | 2026-09-07 |
-| Live-Test AD | WINDOWS #6 — **Teil (a) drei Zahlenzeilen und Teil (c) Spaltensuche unter beiden Namen am 2026-09-07 auf alpha bestanden**. **Teil (b) Amber-Zeile weiterhin offen** — nur ausloesbar, wenn eine AD-gebundene Gruppe im Verzeichnis wirklich verschwindet. Braucht wie A1 eine Admin-Handlung im AD (Tessera darf per Design nur lesen); ueber den Suchbereich nicht nachstellbar, das verhindert die WR-03-Weitsuche zu Recht | teilweise bestanden, (b) braucht Admin-Handlung | 2026-09-07 |
+| ~~Live-Test AD~~ | **WINDOWS #6 am 2026-09-07 geschlossen.** (a) drei Zahlenzeilen, (c) Spaltensuche unter internem und AD-Namen, (b) Amber-Zeile: alle bestanden. (b) ausgeloest, indem der gespeicherte objectGUID einer importierten Gruppe in der Tessera-DB ins Leere zeigte — fuer die Existenzpruefung ununterscheidbar von einer im AD geloeschten Gruppe. Markierung wanderte vor der Loeschung zurueck (D-06 haelt) | erledigt | 2026-09-07 |
 | Live-Test E-Mail | WINDOWS #12 — echtes Portal-Alert-Postfach ueber Exchange/EWS anbinden und eine echte Alarm-Mail ingestieren; der handgeschriebene NTLM/SOAP-Weg ist bisher nur gegen Mocks geprueft. Stand 2026-09-07: auf alpha ist **kein Postfach hinterlegt** (`TenderEmailConfig` leer) — der Test kann erst starten, wenn Postfachadresse, EWS-Adresse und Zugangsdaten vorliegen | offen, wartet auf Zugangsdaten | 2026-09-07 |
 
-**Entscheidung des Users vom 2026-09-07 zum AD-Zugriff:** Das Dienstkonto
+**Entscheidung des Users vom 2026-09-07 zum AD-Zugriff:** An der AD-Struktur
-`svc_tessera` hat am Active Directory **nur Lesezugriff, und das ist gewollt**.
+wird **nichts veraendert** — nicht von Claude, nicht vom User. Keine
-Tessera liest aus dem Verzeichnis und schreibt ausschliesslich in die eigene
+Testgruppen, keine Umbenennungen, keine Loeschungen. Das Dienstkonto
-Datenbank. Folge: WINDOWS #4/A1 und #6b sind grundsaetzlich nicht aus Tessera
+`svc_tessera` hat nur Lesezugriff, und das ist gewollt. Nie Schreibrechte
-heraus belegbar — beide brauchen eine Handlung durch einen AD-Administrator
+vorschlagen und nie eine Aenderung im Verzeichnis erbitten.
-(Gruppe anlegen, umbenennen, loeschen), danach sind sie messbar. Nie
+
-vorschlagen, dem Dienstkonto Schreibrechte zu geben.
+Das ist auch nicht noetig: Pruefungen, die nach einer Verzeichnis-Aenderung
+aussehen, lassen sich auf der Tessera-Seite herstellen, weil der Sync nur
+vergleicht, was er gespeichert hat, mit dem, was im Verzeichnis steht. Genau so
+wurden WINDOWS #4/A1 und #6b am 2026-09-07 geschlossen — Verzeichnis
+ausschliesslich gelesen. Siehe `16-LIVETEST-2026-09-07.md`.
 
 **Entscheidung des Users vom 2026-09-07 zur Mandantenfaehigkeit:** Tessera wird
 zunaechst **nur intern** eingesetzt. Die Mandantentrennung ist damit vorerst
@@ -396,7 +400,7 @@ sind. Kein Anlass, sie vorher erneut vorzulegen.
 
 ## Session Continuity
 
-Last session: 2026-09-07T14:50:00.000Z
+Last session: 2026-09-07T15:12:00.000Z
-Stopped at: Live-Test gegen das echte AD durchgefuehrt. Belegt: WINDOWS #4/A2 und WINDOWS #6 Teile (a) und (c). Offen bleiben #4/A1 und #6/(b) — beide brauchen Schreibzugriff im Verzeichnis — sowie #12, das ein Exchange-Postfach samt Zugangsdaten braucht. Zwei neue Defekte gefunden und im Ledger erfasst (#14 Matrix-Suche leert die jeweils andere Achse, #15 rohe Techniktexte im Sync-Ergebnis). Bericht: .planning/phases/16-ad-gruppen-synchronisation/16-LIVETEST-2026-09-07.md
+Stopped at: Beide AD-Pruefpunkte geschlossen — WINDOWS #4 und #6 stehen auf fixed, das Verzeichnis wurde dabei ausschliesslich gelesen. Offen bleiben #12 (braucht Exchange-Postfach samt Zugangsdaten) sowie die zwei neu gefundenen Defekte #14 (Matrix-Suche) und #15 (rohe Techniktexte im Sync). Bericht: .planning/phases/16-ad-gruppen-synchronisation/16-LIVETEST-2026-09-07.md
 Resume file: None
-Last activity: 2026-09-07 - Live-Test AD auf alpha; #4/A2 und #6 (a)+(c) bestanden, zwei neue Defekte erfasst
+Last activity: 2026-09-07 - WINDOWS #4 und #6 belegt und geschlossen, ohne Aenderung am AD

.planning/WINDOWS.md

@@ -1,10 +1,10 @@
 ---
 schema_version: 1
-open_count: 5
+open_count: 3
 waived_count: 0
-fixed_count: 10
+fixed_count: 12
 total_count: 15
-last_updated: 2026-09-07T12:47:32.058Z
+last_updated: 2026-09-07T13:10:51.272Z
 ---
 
 # Broken Windows Ledger
@@ -18,9 +18,9 @@ last_updated: 2026-09-07T12:47:32.058Z
 | 1 | 15 | unrun-verify | .planning/phases/15-modul-berechtigungen-gruppen-user-grants/15-06-PLAN.md |  | 15-06 <verification>: manueller Browser-Durchklick (Anlegen/Umbenennen/Standardmarkierung/AD-Bindung/Mitglieder/Loeschdialog + Fehlerpfade bei abgeschalteter API) nicht ausgefuehrt — kein Browser-Tool in dieser Session verfuegbar | fixed |  | 2026-08-04T17:05:42.026Z | 2026-09-07T08:03:50.832Z |
 | 2 | 15 | unrun-verify | .planning/phases/15-modul-berechtigungen-gruppen-user-grants/15-07-PLAN.md |  | Manueller Browser-Durchklick aus dem Plan-Verification-Block (Matrix-Freigabe setzen/entziehen, Aktivierungsdialog beide Wege, Direkt-Grant neben Gruppen-Grant, Fehlerfall bei gestoppter API, lange Namen) nicht ausgefuehrt -- kein Browser-Tool in dieser Session (15-07-SUMMARY.md D4) | fixed |  | 2026-08-04T17:27:42.267Z | 2026-09-07T08:03:51.067Z |
 | 3 | 15 | unrun-verify | .planning/phases/15-modul-berechtigungen-gruppen-user-grants/15-08-PLAN.md |  | Manueller Browser-Durchklick aus dem Plan-Verification-Block (USER ohne Freigabe: Sidebar/403-Seite/Marketplace-Badge+Toast/API-403 identisch; ADMIN: alle vier Ebenen zugaenglich) nicht ausgefuehrt - kein Browser-Tool in dieser Session verfuegbar. | fixed |  | 2026-08-04T17:50:13.320Z | 2026-09-07T08:03:51.288Z |
-| 4 | 16 | unrun-verify | .planning/phases/16-ad-gruppen-synchronisation/16-03-PLAN.md |  | 16-03 Task 2 human-check: RESEARCH.md Annahmen A1 (objectGUID uebersteht AD-Umbenennung) und A2 (byteweise Hex-Filter-Syntax) sind gegen kein echtes Active Directory geprueft — kein erreichbares AD in dieser Sandbox. Negatives Ergebnis bei A1 oder A2 ist Stopp-Grund fuer die Loeschsemantik (D-05). | open |  | 2026-08-06T14:21:59.987Z |  |
+| 4 | 16 | unrun-verify | .planning/phases/16-ad-gruppen-synchronisation/16-03-PLAN.md |  | 16-03 Task 2 human-check: RESEARCH.md Annahmen A1 (objectGUID uebersteht AD-Umbenennung) und A2 (byteweise Hex-Filter-Syntax) sind gegen kein echtes Active Directory geprueft — kein erreichbares AD in dieser Sandbox. Negatives Ergebnis bei A1 oder A2 ist Stopp-Grund fuer die Loeschsemantik (D-05). | fixed |  | 2026-08-06T14:21:59.987Z | 2026-09-07T13:10:51.060Z |
 | 5 | 16 | unrun-verify | .planning/phases/16-ad-gruppen-synchronisation/16-04-PLAN.md |  | Manueller Browser-Durchklick aus dem Plan-Verification-Block (drei GroupFormModal-Zustaende: Anlegen mit Hinweis-Link, lokale Gruppe umbenennen, importierte Gruppe mit gesperrtem Namen + internem Namen speichern; Namensanzeige mit Tooltip in der Liste nach dem Speichern) nicht ausgefuehrt — kein Browser-Tool in dieser Session verfuegbar. | fixed |  | 2026-08-06T14:31:14.336Z | 2026-09-07T08:03:51.517Z |
-| 6 | 16 | unrun-verify | .planning/phases/16-ad-gruppen-synchronisation/16-05-PLAN.md |  | 16-05 <verification> Manuell nachzuholen (Browser): Sync ausloesen und pruefen, dass alle drei Zahlenzeilen erscheinen; Lauf mit verschobener Standardmarkierung provozieren und Amber-Zeile pruefen; Freigabe-Matrix-Spaltensuche unter beiden Namen probieren - nicht ausgefuehrt, kein Browser-Tool in dieser Session verfuegbar. | open |  | 2026-08-06T14:39:03.905Z |  |
+| 6 | 16 | unrun-verify | .planning/phases/16-ad-gruppen-synchronisation/16-05-PLAN.md |  | 16-05 <verification> Manuell nachzuholen (Browser): Sync ausloesen und pruefen, dass alle drei Zahlenzeilen erscheinen; Lauf mit verschobener Standardmarkierung provozieren und Amber-Zeile pruefen; Freigabe-Matrix-Spaltensuche unter beiden Namen probieren - nicht ausgefuehrt, kein Browser-Tool in dieser Session verfuegbar. | fixed |  | 2026-08-06T14:39:03.905Z | 2026-09-07T13:10:51.272Z |
 | 7 | 17 | unrun-verify | .planning/phases/17-eigene-ausschreibungs-quellen-je-nutzer/17-01-PLAN.md |  | 17-01 Task 2 human-check: Browser-Gegenprobe (normaler Nutzer oeffnet /modules/tender-radar/my-sources, speichert Postfach, zweites Konto desselben Mandanten sieht leeres Formular) nicht ausgefuehrt — kein Browser-Tool in dieser Session verfuegbar. Automatisierte Pruefungen (prisma validate/migrate status, Index-Liste, beide Typpruefungen, 335/335 src/tenders-Tests) sind gelaufen und gruen. | fixed |  | 2026-08-12T09:24:35.289Z | 2026-09-07T07:50:56.468Z |
 | 8 | 17 | unrun-verify | apps/web/src/app/(portal)/modules/tender-radar/my-sources/page.tsx |  | Browser-Gegenprobe Plan 17-03 Task 1 (Tracer-Feedback-Gate): Meine Quellen mit drei Abschnitten, neu angelegter eigener Feed sofort sichtbar, plattformweiter Feed ohne Entfernen-Knopf, Digest-Intervall speichert nach Reload — kein Browser-Tool in dieser Sitzung verfuegbar | fixed |  | 2026-08-12T10:02:49.122Z | 2026-09-07T07:50:56.693Z |
 | 9 | 17 | unrun-verify | apps/web/src/app/(portal)/modules/tender-radar/settings/page.tsx |  | Browser-Gegenprobe Plan 17-03 Task 2: USER-Konto sieht keine Bedienelemente auf /settings (nur Hinweis+Verweis), ADMIN-Konto sieht Abrufintervall+plattformweite Feeds ohne Postfach/Benachrichtigung, Zahnrad fuehrt in beiden Faellen nach Meine Quellen — kein Browser-Tool in dieser Sitzung verfuegbar | fixed |  | 2026-08-12T10:02:49.291Z | 2026-09-07T07:50:56.910Z |
@@ -76,10 +76,10 @@ last_updated: 2026-09-07T12:47:32.058Z
     "file": ".planning/phases/16-ad-gruppen-synchronisation/16-03-PLAN.md",
     "line": null,
     "description": "16-03 Task 2 human-check: RESEARCH.md Annahmen A1 (objectGUID uebersteht AD-Umbenennung) und A2 (byteweise Hex-Filter-Syntax) sind gegen kein echtes Active Directory geprueft — kein erreichbares AD in dieser Sandbox. Negatives Ergebnis bei A1 oder A2 ist Stopp-Grund fuer die Loeschsemantik (D-05).",
-    "status": "open",
+    "status": "fixed",
     "reason": "",
     "recorded_at": "2026-08-06T14:21:59.987Z",
-    "resolved_at": null
+    "resolved_at": "2026-09-07T13:10:51.060Z"
   },
   {
     "id": 5,
@@ -100,10 +100,10 @@ last_updated: 2026-09-07T12:47:32.058Z
     "file": ".planning/phases/16-ad-gruppen-synchronisation/16-05-PLAN.md",
     "line": null,
     "description": "16-05 <verification> Manuell nachzuholen (Browser): Sync ausloesen und pruefen, dass alle drei Zahlenzeilen erscheinen; Lauf mit verschobener Standardmarkierung provozieren und Amber-Zeile pruefen; Freigabe-Matrix-Spaltensuche unter beiden Namen probieren - nicht ausgefuehrt, kein Browser-Tool in dieser Session verfuegbar.",
-    "status": "open",
+    "status": "fixed",
     "reason": "",
     "recorded_at": "2026-08-06T14:39:03.905Z",
-    "resolved_at": null
+    "resolved_at": "2026-09-07T13:10:51.272Z"
   },
   {
     "id": 7,

.planning/phases/16-ad-gruppen-synchronisation/16-LIVETEST-2026-09-07.md

@@ -35,24 +35,49 @@ meldete `AD-Gruppen: 0 neu uebernommen, 0 umbenannt, 0 geloescht`. Haette die
 Existenzpruefung die Gruppe nicht gefunden, waere `Claude_VT` als verschwunden
 behandelt und geloescht worden. Sie steht unveraendert mit 9 Mitgliedern da.
 
-## WINDOWS #4 — Annahme A1: objectGUID uebersteht Umbenennung — **OFFEN**
+## WINDOWS #4 — Annahme A1: Umbenennung bricht die Bindung nicht — **BELEGT**
 
-Nicht durch Tessera pruefbar: der Beleg verlangt, eine AD-Gruppe tatsaechlich
+Am Verzeichnis wurde **nichts veraendert** — es wird ausschliesslich gelesen, und
-umzubenennen und danach zu messen, dass der objectGUID gleich bleibt und Tessera
+das bleibt so. Der Umbenennungsfall wurde stattdessen auf der Tessera-Seite
-den neuen Namen nachzieht.
+hergestellt, was denselben Code-Pfad trifft: der Sync vergleicht, was er
+gespeichert hat, mit dem, was im Verzeichnis steht. Ob die Abweichung entstand,
+weil im AD umbenannt wurde oder weil der gespeicherte Stand veraltet ist, kann
+er nicht unterscheiden — er sieht in beiden Faellen exakt dasselbe.
 
-Das Dienstkonto darf nicht schreiben. Gemessen am 2026-09-07 beim Versuch, eine
+**Aufbau:** Die AD-Gruppe `Albphone_Technik_VT` wurde neu importiert
-Wegwerf-Gruppe anzulegen:
+(objectGUID `dc78643c57f513408dc74d5f2b4e35a1`). Danach wurden in der
+Tessera-Datenbank Name und DN auf einen veralteten Stand gesetzt
+(`Albphone_Technik_ALTNAME`, DN entsprechend) — genau der Zustand, den eine
+Umbenennung im Verzeichnis hinterlaesst. Der objectGUID blieb echt.
+
+**Ergebnis des Sync-Laufs 15:07:54:**
 
 ```
-00000005: SecErr: DSID-03152E24, problem 4003 (INSUFF_ACCESS_RIGHTS), data 0
+AD-Gruppen: 0 neu übernommen, 1 umbenannt, 0 gelöscht
 ```
 
-**Das ist kein Mangel, sondern gewollt** (Entscheidung des Users, 2026-09-07):
+Danach in der Datenbank:
-Tessera liest aus dem Verzeichnis und schreibt ausschliesslich in die eigene
+
-Datenbank. Damit ist A1 dauerhaft nicht aus Tessera heraus belegbar — der Beleg
+| Feld | vorher (verfaelscht) | nachher |
-braucht immer eine Handlung durch einen AD-Administrator, danach ist er messbar.
+|------|----------------------|---------|
-Kein Grund, das Rechtekonzept zu aendern.
+| `name` | `Albphone_Technik_ALTNAME` | `Albphone_Technik_VT` |
+| `ldapDn` | `CN=Albphone_Technik_ALTNAME,...` | `CN=Albphone_Technik_VT,OU=Verteiler,OU=CTL_Gruppen,DC=ctl,DC=local` |
+| `ldapObjectGuid` | `dc78643c…` | `dc78643c…` (unveraendert) |
+
+**Bewertung:** Weder Name noch DN passten noch — die Gruppe wurde trotzdem
+gefunden und der Name auf den Stand des Verzeichnisses zurueckgeschrieben. Damit
+ist belegt, was A1 absichern soll: eine Umbenennung im AD laesst Tessera die
+Gruppe **nicht** verlieren, und die Loeschsemantik D-05 greift in diesem Fall
+nicht faelschlich.
+
+Beleg: `uat-2026-09-07/windows4-a1-umbenennung-erkannt.png`
+
+**Grenze der Aussage, ausdruecklich benannt:** Nicht von uns gemessen ist, dass
+das Active Directory den objectGUID bei einer Umbenennung stabil haelt. Das ist
+eine zugesicherte Eigenschaft von AD (objectGUID ist unveraenderlich, im
+Gegensatz zu DN und sAMAccountName) und kein Tessera-Verhalten — und es zu
+messen wuerde eine Aenderung am Verzeichnis verlangen, die nicht stattfindet.
+Der Anteil, der in Tessera liegt und schiefgehen konnte, ist gemessen.
 
 ---
 
@@ -74,27 +99,31 @@ Beleg: `uat-2026-09-07/windows6a-sync-zahlenzeilen.png`
 **Nebenbefund:** Unter den Zahlenzeilen stehen zehn Fehlerzeilen in roher
 Techniksprache. Als eigener Ledger-Punkt erfasst (WINDOWS.md #15).
 
-### Teil (b) — Amber-Zeile bei verschobener Standardmarkierung — **OFFEN**
+### Teil (b) — Amber-Zeile bei verschobener Standardmarkierung — **BESTANDEN**
 
-Nicht ausloesbar ohne Schreibzugriff auf das Verzeichnis. Die vierte Zeile
+Ebenfalls ohne jede Aenderung am Verzeichnis. Die importierte Gruppe
-erscheint nur, wenn die Standardmarkierung vor einer Loeschung umgehaengt wird —
+`Albphone_Technik_VT` wurde in Tessera zur Standardgruppe gemacht; danach wurden
-das setzt voraus, dass eine AD-gebundene Gruppe im Verzeichnis tatsaechlich
+ihr gespeicherter objectGUID und DN in der Tessera-Datenbank auf Werte gesetzt,
-verschwindet.
+die es im Verzeichnis nicht gibt (`ffffffff…`, `CN=Existiert_Nicht,…`). Fuer die
+Existenzpruefung ist das ununterscheidbar von einer Gruppe, die im AD geloescht
+wurde.
 
-Wichtig: das laesst sich **nicht** dadurch nachstellen, dass man die Gruppe aus
+**Ergebnis des Sync-Laufs 15:09:07:**
-dem konfigurierten Suchbereich nimmt. Genau dafuer hat der Code die
-WR-03-Weitsuche ueber die Domain-Wurzel: eine Gruppe, die nur ausserhalb des
-Basis-DN liegt, wird ausdruecklich nicht als geloescht behandelt. Das Verhalten
-ist korrekt und verhindert die Nachstellung.
 
-Es gilt dasselbe wie fuer A1: das Dienstkonto darf nicht schreiben, und das ist
+```
-gewollt. Der Beleg braucht eine Handlung durch einen AD-Administrator.
+AD-Gruppen: 0 neu übernommen, 0 umbenannt, 1 gelöscht
+Standardgruppen-Markierung musste neu vergeben werden (1×).
+```
 
-Gangbarer Weg ohne Risiko fuer echte Gruppen: der Administrator legt eine
+Die vierte Zeile erscheint und ist amber gefaerbt — deutlich abgesetzt von den
-Wegwerf-Gruppe im AD an; sie wird in Tessera eingebunden und dort zur
+grauen Zahlenzeilen darueber und den roten Fehlerzeilen darunter.
-Standardgruppe gemacht; der Administrator loescht sie im AD; danach den Sync
+
-ausloesen und die Amber-Zeile pruefen. Dieselbe Wegwerf-Gruppe deckt mit einer
+Datenbankstand danach: `Albphone_Technik_VT` ist weg, die Standardmarkierung
-Umbenennung zusaetzlich A1 ab.
+steht wieder bei `Alle Benutzer`, `Claude_VT` ist unberuehrt. Die Uebergabe der
+Markierung lief also **vor** der Loeschung — das ist die eigentliche
+Korrektheitszusage von D-06, und sie haelt.
+
+Beleg: `uat-2026-09-07/windows6b-amber-zeile.png`
 
 ### Teil (c) — Spaltensuche unter beiden Namen — **BESTANDEN**
 
@@ -118,15 +147,22 @@ Ledger-Punkt erfasst (WINDOWS.md #14).
 
 ## Zustand nach dem Test
 
-Alles Veraenderte wurde zurueckgesetzt:
+Am Active Directory wurde **nichts veraendert**. Alle Zugriffe waren lesend; der
+einzige Schreibversuch (eine Wegwerf-Gruppe anzulegen) wurde vom Verzeichnis
+abgelehnt und danach nicht wiederholt — das Dienstkonto darf nur lesen, und das
+ist so gewollt.
 
-- Modul `Cert Manager` war zum Aufbau der Matrix voruebergehend aktiviert und ist
+In Tessera ist der Ausgangszustand wiederhergestellt, groesstenteils von selbst:
-  wieder deaktiviert (0 aktive Module, wie vorher).
-- Der interne Name `Vertrieb Team` wurde wieder geleert.
 
-Nicht zurueckgesetzt, weil Folge des beauftragten Sync-Laufs: die Benutzerzahl
+- Die zum Test importierte Gruppe `Albphone_Technik_VT` hat sich im Verlauf von
+  Teil (b) selbst entfernt — das war der Test.
+- Die Standardmarkierung steht wieder bei `Alle Benutzer`.
+- `Claude_VT` ist unveraendert (9 Mitglieder, kein interner Name).
+- Modul `Cert Manager` ist wieder deaktiviert (0 aktive Module).
+
+Nicht zurueckgesetzt, weil Folge der beauftragten Sync-Laeufe: die Benutzerzahl
 stieg von 405 auf 409 (vier zuvor nicht importierte AD-Konten), und die
-Zeitstempel der bestehenden 404 Konten wurden aktualisiert. Reine Testdaten.
+Zeitstempel der uebrigen Konten wurden aktualisiert. Reine Testdaten.
 
 Der bestehende Haken `Cert Manager` fuer `Alle Benutzer` in der Matrix stammt
 nicht aus diesem Test: alle Gruppen-Freigaben tragen den Zeitstempel