Update NTFS path policy documentation

Sonstiges/LIAM_NTFS_AdditionalConfiguration_BlackWhitelist_Konzept.md

@@ -43,6 +43,70 @@ NtfsExcludePaths=Archiv;*\Temp;Abteilung\Alt;\\server\share\legacy\*
 NtfsIncludePaths=Fachbereiche\*;Shares\Produktion\*;\\server\dfs\namespace\link\*
 ```
 
+## Aktueller Implementierungsstand
+
+Die nachfolgend beschriebene Path-Policy ist im NTFS-Provider inzwischen implementiert.
+
+### 1. Materialisierung und Traversierung sind getrennt
+
+In `GetChildDataAreasAsync()` wird pro gefundenem Pfad heute getrennt entschieden:
+
+- darf der Pfad als DataArea geliefert werden
+- darf unterhalb des Pfads weiter traversiert werden
+
+Das ist wichtig fuer Include-Regeln. Ein Zwischenpfad darf fuer die Traversierung erlaubt sein, auch wenn erst ein tiefer liegendes Zielobjekt tatsaechlich auf der Whitelist steht.
+
+### 2. Matching ist klassifizierungsunabhaengig
+
+Die Path-Policy arbeitet fuer:
+
+- `ServerRoot`
+- `ClassicShare`
+- `DfsNamespaceRoot`
+- `DfsLink`
+- `Folder`
+
+mit derselben Matching-Logik.
+
+Die Klassifikation bleibt fuer die fachliche Verarbeitung der DataArea relevant, nicht mehr fuer Blacklist-/Whitelist-Matching.
+
+### 3. Relative und absolute Pfade werden parallel ausgewertet
+
+Jeder klassifizierte Pfad wird gegen mehrere Kandidaten gematcht:
+
+- relativer Pfad unterhalb von `RootPath`
+- normalisierter absoluter UNC-Pfad
+
+Dadurch koennen Regeln sowohl knapp relativ als auch explizit absolut formuliert werden.
+
+### 4. Include-Regeln duerfen Traversierungs-Vorpfade freischalten
+
+Wenn `NtfsIncludePaths` gesetzt ist, darf ein Pfad auch dann traversiert werden, wenn er selbst noch nicht final matcht, aber zu einem spaeter passenden Zielpfad fuehren kann.
+
+Beispiel:
+
+```text
+NtfsIncludePaths=Abteilung\IT\*
+```
+
+Dann darf `Abteilung` fuer die Traversierung erhalten bleiben, damit `Abteilung\IT\TeamA` ueberhaupt erreicht werden kann.
+
+### 5. `LoadDataArea()` respektiert die Policy
+
+Direktes Laden eines Pfads ueber `LoadDataArea()` wird ebenfalls durch die Path-Policy eingeschraenkt.
+
+Ausnahme:
+
+- der konfigurierte `RootPath` selbst bleibt ladbar
+
+Damit kann die Filterung nicht einfach durch direktes Laden einer UID umgangen werden.
+
+### 6. Permission-Management bleibt fachlich auf Folder beschraenkt
+
+`IsPermissionManagedFolderPath()` verwendet dieselbe generische Path-Policy, bleibt aber weiterhin nur fuer als `Folder` klassifizierte Pfade zulaessig.
+
+Die Path-Policy ist also klassifizierungsunabhaengig, das Berechtigungs-Handling selbst aber bewusst nicht.
+
 ## Matching-Regeln
 
 Empfohlene Semantik:
@@ -61,18 +125,20 @@ Empfohlene Prioritaet:
 2. Wenn Include-Regeln gesetzt sind, sind nur passende Pfade erlaubt.
 3. Exclude-Regeln werden danach angewendet und gewinnen bei Kollision.
 
-Damit bleibt das Verhalten ohne neue Konfiguration unveraendert, und spaetere Whitelist-Faelle sind sauber modellierbar.
+Das entspricht dem aktuell implementierten Verhalten.
 
 ## Technische Einhaengepunkte
 
 ### 1. Provider-seitige Policy-Methoden
 
-Im NTFS-Provider sollte eine kleine Policy-Schicht entstehen, zum Beispiel:
+Im NTFS-Provider existiert dafuer inzwischen eine kleine Policy-Schicht, insbesondere:
 
 - `GetAdditionalConfigurationValues(string key)`
-- `ShouldTraversePath(string fullPath)`
+- `ShouldIncludeDataArea(...)`
+- `ShouldTraverseDataArea(...)`
 - `MatchesPathPolicy(...)`
 - `TryMatchPathPolicy(...)`
+- `CanPathLeadToPattern(...)`
 
 Die Methode `IsAdditionalConfigurationEnabled()` bleibt fuer boolesche Flags bestehen und wird durch Listen-/String-Helfer ergaenzt.
 
@@ -80,7 +146,7 @@ Die Methode `IsAdditionalConfigurationEnabled()` bleibt fuer boolesche Flags bes
 
 Der erste und wichtigste Einhaengepunkt ist `GetChildDataAreasAsync()`.
 
-Dort wird heute jede gefundene Ebene verarbeitet und bei `depth > 1` weiter traversiert. Genau dort sollte vor `BuildDataAreaAsync()` und vor dem rekursiven Abstieg entschieden werden, ob ein Pfad ausgeschlossen ist.
+Dort wird heute jede gefundene Ebene verarbeitet und vor `BuildDataAreaAsync()` sowie vor dem rekursiven Abstieg durch die Path-Policy geprueft.
 
 Vorteil:
 
@@ -94,15 +160,19 @@ Vorteil:
 
 Damit wird vermieden, dass ein Ordner zwar nicht mehr als DataArea sichtbar ist, aber weiterhin im Permission-Flow auftaucht.
 
-## Bewusste Abgrenzung fuer Schritt 1
+### 4. Wiederverwendung fuer `LoadDataArea()`
 
-Nicht Teil des ersten Schritts:
+Auch `LoadDataArea()` verwendet die Path-Policy inzwischen, damit gefilterte Pfade nicht per Direktzugriff wieder sichtbar werden.
+
+## Offene Abgrenzung
+
+Bewusst weiterhin nicht umgesetzt:
 
 - Umbau von `cNtfsBase` auf generische Filter-Callbacks
 - freie Regex-Konfiguration in `AdditionalConfiguration`
 - unterschiedliche Regeln je Klassifikationstyp
 
-Diese Themen koennen spaeter folgen, sind aber fuer den initialen Nutzen nicht noetig.
+Diese Themen koennen spaeter folgen, sind fuer den aktuellen Nutzen aber nicht noetig.
 
 ## Logging
 
@@ -124,10 +194,12 @@ Das ist wichtig, damit fehlende DataAreas spaeter im Betrieb nachvollziehbar ble
 
 1. Listenparser fuer `AdditionalConfiguration` im NTFS-Provider einfuehren.
 2. Pfadnormalisierung und Matching fuer relative sowie absolute Pfade kapseln.
-3. `GetChildDataAreasAsync()` um `ShouldTraversePath()` erweitern.
+3. `GetChildDataAreasAsync()` um `ShouldTraverseDataArea(...)` erweitern.
 4. Debug-Logging fuer Skip-Faelle einfuehren.
 5. Dieselbe Policy in `IsPermissionManagedFolderPath()` und `LoadDataArea()` wiederverwenden.
 
+Diese Punkte sind im aktuellen Implementierungsstand umgesetzt.
+
 ## Kurzfazit
 
 Die generische Path-Policy im NTFS-Provider ist klein genug fuer eine risikoarme Implementierung, passt in die vorhandene `AdditionalConfiguration`-Architektur und arbeitet ohne Sonderregeln pro Klassifikationstyp.