Detail AD group name shortening approach

Sonstiges/LIAM_Finding.md

@@ -212,6 +212,22 @@ Vorschlag zum Fixen:
 - Die Verkürzung sollte deterministisch sein und die stabilen fachlichen Tags erhalten. Kürzen sollte möglichst nur der dynamische Pfadanteil (`NAME` bzw. `RELATIVEPATH`). Wenn das nicht reicht, sollte als Fallback ein stabiler Hash-/Kurzschlüssel im dynamischen Mittelteil verwendet werden, damit der Name reproduzierbar und kollisionsarm bleibt.
 - Der bestehende `LOOP`-Mechanismus zur Kollisionsbehandlung sollte danach unverändert weiterlaufen, damit Längenbegrenzung und Eindeutigkeitslogik sauber getrennt bleiben.
 
+Konkreter Vorschlag für die Verkürzungslogik:
+
+- Den finalen AD-Gruppennamen nicht als Ganzes kürzen, sondern vor dem Zusammenbau logisch in `prefixPart`, `dynamicPart` und `suffixPart` aufteilen.
+- `prefixPart` umfasst die stabilen fachlichen Tags wie Prefix, Scope-Tag und feste Typbestandteile. `suffixPart` umfasst Typ-/Scope-Enden und einen eventuell benötigten `LOOP`-Puffer. Beide Bereiche bleiben unverändert.
+- Nur `dynamicPart` darf verkürzt werden. Dieser Teil stammt fachlich aus `NAME` oder `RELATIVEPATH`.
+- Wenn `dynamicPart` aus `NAME` stammt, wird zuerst nur dieser Name gekürzt.
+- Wenn `dynamicPart` aus `RELATIVEPATH` stammt, sollte segmentbasiert gekürzt werden. Das letzte Segment bleibt möglichst am längsten erhalten, weil es fachlich meist den eigentlichen Zielordner beschreibt.
+- Erste Kürzungsstufe: frühe oder mittlere Segmente verkürzen, bevor das letzte Segment gekappt wird. Beispiel: `Abteilung_Standort_Projekt_Unterordner` wird eher zu `Abt_Sta_Proj_Unterordner` als zu `Abteilung_Standort_Projekt_Unter`.
+- Zweite Kürzungsstufe: wenn die segmentbasierte Verkürzung noch nicht reicht, den mittleren Teil durch einen stabilen Kurzschlüssel ersetzen und Anfang sowie Ende lesbar lassen.
+- Der Kurzschlüssel sollte aus dem ungekürzten Original von `dynamicPart` berechnet werden, nicht aus dem bereits gekürzten Ergebnis. Dadurch bleibt das Resultat reproduzierbar.
+- Als technisches Schema bietet sich `sichtbarerAnfang + "_" + hash8 + "_" + sichtbaresEnde` an. So bleibt der Name lesbar, aber trotzdem kollisionsarm.
+- Für den Hash genügt ein stabiler technischer Fingerprint wie `SHA1` oder `SHA256`, von dem nur wenige Zeichen, z. B. 8 Hex-Zeichen, verwendet werden.
+- Vor der Kürzung muss bereits Reserve für einen möglichen `LOOP`-Suffix eingeplant werden, damit die spätere Kollisionsauflösung nicht erneut über die Maximalgrenze hinausschießt.
+- Logging nur dann, wenn tatsächlich gekürzt wurde. Im Log sollten Originalname, Zielname, alte Länge, neue Länge und die verwendete Strategie (`truncate-name`, `truncate-relativepath`, `hash-fallback`) stehen.
+- Die gesamte Logik sollte in einer zentralen Hilfsmethode gekapselt werden, damit Create, Ensure, Traverse und Preview denselben Namensalgorithmus verwenden.
+
 ### 9. Mittel-Hoch: `LoadDataArea()` behandelt UNC-Pfade fachlich falsch
 
 Die Einzel-Ladefunktion `LoadDataArea()` ist sichtbar unfertig. Das ist nicht nur ein Stilproblem, sondern erzeugt reales Fehlverhalten.