From ad595ff9b329ffd3831f7976d31ff2938ce40f4b Mon Sep 17 00:00:00 2001
From: Daniel Helbig <daniel.helbig@kreis-meissen.de>
Date: Tue, 18 Aug 2026 21:23:01 +0200
Subject: [PATCH] Wissensdateien mit claude code als Projekt-kontext
 ausgewertet

Signed-off-by: Daniel Helbig <daniel.helbig@kreis-meissen.de>
---
 wissensdateien/sn_basis.md            | 64 +++++++++++++++++++++++++++
 wissensdateien/sn_plan41.md           | 57 ++++++++++++++++++++++++
 wissensdateien/sn_verfahrensgebiet.md | 62 ++++++++++++++++++++++++++
 3 files changed, 183 insertions(+)
 create mode 100644 wissensdateien/sn_basis.md
 create mode 100644 wissensdateien/sn_plan41.md
 create mode 100644 wissensdateien/sn_verfahrensgebiet.md

diff --git a/wissensdateien/sn_basis.md b/wissensdateien/sn_basis.md
new file mode 100644
index 0000000..fe9c400
--- /dev/null
+++ b/wissensdateien/sn_basis.md
@@ -0,0 +1,64 @@
+# Wissensdatei: sn_basis
+
+## 1. Zweck
+
+`sn_basis` ("LNO Sachsen | Plugin Basisfunktionen") ist die **gemeinsame Infrastruktur- und Orchestrierungs-Plugin** der drei Plugins `sn_basis` / `sn_verfahrensgebiet` / `sn_plan41`, die zusammen die Bearbeitung sächsischer Flurbereinigungsverfahren mit offenen Geodaten unterstützen. sn_basis stellt Qt/QGIS-Wrapper, eine generische Prüf-/Datenabruf-Pipeline (Excel-Linkliste → WFS/WMS/REST/OGR → GeoPackage), zentrales Tracking der "Verfahrensgebiet"-Layer, das gemeinsame Menü/Toolbar sowie die Druck-/Layout-Logik für §38-, §41- und Baufreigabe-Karten bereit. Die anderen beiden Plugins sind ohne sn_basis nicht lauffähig.
+Durch Anpassung des Präfixes (sn_) und der ALKIS-WFS-AAA-Dienstadresse kann das Plugin auf andere Bundesländer angepasst werden. (ggf. Optimierung erforderlich)
+## 2. Architektur
+
+- Entry-Point: `__init__.py → classFactory(iface) → main.py: BasisPlugin`.
+- `BasisPlugin.initGui()` baut das gemeinsame Menü/Toolbar `"LNO Sachsen"`, startet den Verfahrensgebiet-Listener und ruft anschließend **`initGui()` auf allen anderen geladenen `sn_*`-Plugins erneut auf** (Iteration über `qgis.utils.plugins`). Ladereihenfolge und Toleranz gegenüber Doppel-Init sind daher wichtig.
+- Verzeichnisse:
+  - `functions/` — Wrapper-/Abstraktionsschicht (Qt, QGIS-Core, QGIS-UI, OS, Variablen, Dialoge, Messages, Layer-Helfer).
+  - `modules/` — Fachlogik (Prüfer-Pipeline, Datenabruf/-schreiber, Print-Logik).
+  - `ui/` — `Navigation`, `DockManager`, `BaseDockWidget`, `ui/tabs/` (PrintTab, SettingsTab).
+  - `styles/` — gemeinsame `.qml`-Stildateien.
+  - `tests/` — 12 unittest-Dateien, lauffähig ohne QGIS.
+- **Zentrales Pattern 1 — Mock-fähige Wrapper:** Jede `functions/*_wrapper.py` versucht `qgis.core`/`qgis.PyQt` zu importieren und fällt bei Fehler auf eine im selben File definierte Mock-Implementierung zurück (`QGIS_AVAILABLE`-Flag). Dadurch ist fast die gesamte Fachlogik ohne laufendes QGIS testbar. **Neue QGIS/Qt-API-Nutzung muss immer hinter diesen Wrappern erfolgen, inkl. Mock-Zweig.**
+- **Zentrales Pattern 2 — Prüfer/Pruefmanager-Pipeline:** `pruef_ergebnis` (Ergebnis-Objekt: `ok`, `meldung`, `aktion`, `kontext`) wird von reinen, UI-freien `*pruefer`-Klassen (`Dateipruefer`, `Linkpruefer`, `Layerpruefer`, `Stilpruefer`, `Datenbankpruefer` [Stub]) erzeugt. `Pruefmanager` ist die einzige Stelle, die daraus ggf. einen Dialog macht (`ui_modus="qgis"` vs. Testmodus). `DataGrabber` (Quelle klassifizieren) → Prüfer → `Datenabruf` (Netzwerk-Fetch inkl. Raumfilter) → `Datenschreiber` (GeoPackage schreiben, Stile in `layer_styles`-Tabelle). Neue Datenimport-Features sollten diesem "klassifizieren → validieren (rein) → zentrale Entscheidung → ausführen"-Muster folgen.
+
+## 3. Domänen-Glossar
+
+- **Verfahrensgebiet (VG)** — die Verfahrensflächen-Layer, zentral über Projektvariable getrackt.
+- **Pruefer/Prüfer, pruef_ergebnis, Pruefmanager** — Validierungspipeline und deren zentrale UI-Entscheidungsstelle.
+- **Dateipruefer / Datenbankpruefer / Linkpruefer / Layerpruefer / Stilpruefer** — Datei-/DB-/Link-/Layer-/Stil-Prüfungen.
+- **DataGrabber / Datenabruf / Datenschreiber / LayerLoader** — Quellklassifizierung / Netzwerk-Fetch / GeoPackage-Schreiber / Layer-Erzeugung inkl. Stil.
+- **Kartenname, Massstab, Druckbereich, Druckpuffer, Zielgroesse, Endlosrolle** — Print-Tab-Konzepte (Kartentyp §38/§41/Baufreigabe, Maßstab, Druckbereich-Modus, Randpuffer, Zielgröße, Endlospapier).
+- **Raumfilter** — `"ohne" | "Verfahrensgebiet" | "Pufferlayer"` — Filtermodus beim Datenabruf.
+- **ALKIS, FlurbG, §38/§41** — amtliches Liegenschaftskatasterinformationssystem; Flurbereinigungsgesetz; die beiden zentralen gesetzlichen Kartentypen.
+
+## 4. Datenquellen / Formate
+
+- WFS, WMS, ArcGIS REST/FeatureServer, OGR (GPKG/SHP/GeoJSON) — provider-gesteuert über die Linkliste.
+- **Excel-Linkliste (.xlsx)**, Pflichtspalten: `ident, gruppe, kartenebene, inhalt, link, provider, stildatei` (gelesen via `openpyxl`, `excel_importer.py`).
+- **GeoPackage (.gpkg)** als primäres Persistenzziel, inkl. Ablage der `.qml`-Stile in der `layer_styles`-Tabelle (SQLite).
+- QGIS-Projektvariablen (Präfix `sn_`) als de-facto Konfigurations-/Zustandsspeicher, kein separates Config-File.
+- Standard-CRS für ad-hoc erzeugte Layer: **EPSG:25833**.
+
+## 5. Abhängigkeiten zu den Geschwister-Plugins
+
+- **Hart-Import aus sn_plan41:** `modules/DataGrabber.py` importiert `sn_plan41.modules.listenauswerter.Listenauswerter` — ohne installiertes sn_plan41 wirft sn_basis einen `ImportError`, obwohl `metadata.txt` diese Abhängigkeit nicht deklariert.
+- **Pfad-Kopplung:** Default-Stilpfade zeigen hart auf `<plugin_root>/sn_plan41/assets/<stildatei>` bzw. `<plugin_root>/sn_verfahrensgebiet/styles/<style>`. Umbenennen/Verschieben von Assets in den anderen Plugins bricht sn_basis stillschweigend.
+- Beide anderen Plugins importieren sn_basis extensiv (Wrapper, Pruefmanager, Dialoge, DockManager/Navigation).
+- Gemeinsamer Zustand: `sn_verfahrensgebiet_layer`-Projektvariable (mit Legacy-Fallbacks `verfahrensgebietslayer`, `tab_a_layer_id`), `verfahrensnummer`.
+- **Praktische Konsequenz:** Alle drei Plugins müssen gemeinsam installiert/geladen sein. Änderungen an Variablennamen, Dialog-Signaturen oder `PruefAktion`-Codes in sn_basis sind Breaking Changes für die anderen beiden — vor Umbenennung immer plugin-übergreifend grep'en.
+
+## 6. Testing & Dev-Tooling
+
+- 12 unittest-Dateien in `tests/`, dank Mock-Wrappern **ohne laufendes QGIS** ausführbar; zusätzlich `tests/start_osgeo4w_qgis.bat` für echte QGIS-Integrationstests.
+- `.coveragerc` beschränkt Coverage auf `modules`; `coverage_html/` und `.coverage` sind (unüblicherweise) ins Repo eingecheckt.
+- `.vscode/launch.json` und `settings.json` zeigen noch auf einen **veralteten `QGIS3`-Profilpfad** (aktuell läuft alles unter `QGIS4`) — bei Remote-Debugging-Bedarf korrigieren.
+- `assets/plan-qgis340ExitCrashFix.prompt.md` ist ein früherer, KI-unterstützter Umsetzungsplan (Signal-Teardown-Fix) — gutes Vorbild für den bevorzugten Planungsstil der Maintainer (minimal-invasiv, explizite Include/Exclude-Entscheidungen, Verifikationsschritte).
+
+## 7. Bekannte Stolperfallen / Konventionen
+
+1. Neue QGIS/Qt-Aufrufe **immer** über die Wrapper-Schicht mit Mock-Fallback — sonst brechen Tests außerhalb QGIS.
+2. Variablen werden automatisch mit `sn_` präfixiert (`variable_wrapper`); Aufrufer übergeben den Key **ohne** Präfix.
+3. Backward-Compat-Fallback-Ketten bei Variablennamen (z. B. Verfahrensgebiet-Layer-ID) beim Refactoring erhalten, nicht brechen.
+4. `functions/qgiscore_wrapper.py::polygon_zu_linie()` ist das Referenzbeispiel für den mehrstufigen QGIS3/4-Kompatibilitäts-Shim-Stil (z. B. weil `QgsGeometry.boundary()` in QGIS 4 entfernt wurde).
+5. `modules/excel_importer.py` hat einen fehlerhaften Kopfkommentar ("gehört zu sn_plan41") — reines Altlast-Artefakt, Datei liegt korrekt in sn_basis.
+6. Durchgängiger defensiver Stil (`try/except: pass`, `getattr(..., None)` + `callable()`-Checks) wegen QGIS3/4- und Mock-Unterschieden — neuer Code sollte diesem Stil folgen.
+7. Nur ein `sn_dock_*`-Dock gleichzeitig sichtbar (`DockManager`); alle Plugin-Aktionen laufen über die eine gemeinsame `Navigation`-Toolbar/-Menü (exklusive `QActionGroup`) — neue Features sollten sich dort einhängen statt eigene UI-Chrome zu bauen.
+8. Signal-Lifecycle-Disziplin ist geschichtsträchtig wichtig: ein dokumentierter QGIS-3.40-Exit-Crash entstand durch offene `QgsProject`-Signalverbindungen — jede neue persistente Signal-Verbindung braucht ein passendes Teardown in `unload()`/`cleanup()`.
+9. `Datenbankpruefer.pruefe()` ist noch ein Stub ("Implementierung folgt").
+10. Debug-`print()`-Statements sind bewusst in mehreren Produktionsmodulen belassen (nicht über Logging geführt).
diff --git a/wissensdateien/sn_plan41.md b/wissensdateien/sn_plan41.md
new file mode 100644
index 0000000..0564915
--- /dev/null
+++ b/wissensdateien/sn_plan41.md
@@ -0,0 +1,57 @@
+# Wissensdatei: sn_plan41
+
+## 1. Zweck
+
+`sn_plan41` ("LNO Sachsen | Plan41") erzeugt die nach **§38/§41 FlurbG** erforderlichen Planunterlagen (Wege- und Gewässerplan). Es hat zwei Kernfunktionen: (1) eine **linkliste-basierte Fachdaten-Pipeline**, die thematische Geodaten (Biotope, Naturschutz, Denkmalschutz, ALKIS-Flurstücke etc.) per WFS/WMS gegen das Verfahrensgebiet filtert und in eine Verfahrens-GeoPackage schreibt (delegiert fast vollständig an sn_basis); (2) die Anbindung an die externe **VLN-Manager-REST-API** zum Laden/Hochladen der eigentlichen Plan-41-Maßnahmen als GeoJSON. Status: `experimental=true`.
+
+## 2. Architektur
+
+- Entry-Point: `__init__.py → classFactory(iface) → main.py: Plan41`.
+- `main.py` erzeugt `Pruefmanager` und `DataGrabber` **aus `sn_basis.modules`** — das Plugin hat keine eigene unabhängige Kernlogik dafür. UI-Registrierung läuft, wie bei sn_verfahrensgebiet, über Laufzeit-Lookup von `sn_basis` (`qgis.utils.plugins.get("sn_basis")`); ohne geladenes sn_basis erscheint **kein Menüeintrag, ohne Fehlermeldung**.
+- Verzeichnisse:
+  - `modules/` — VLN-API + Linklisten-Validierung: `vln_api_client.py` (HTTP-Client, `QgsBlockingNetworkRequest`), `vln_api_logic.py` (UI-Fassade, QSettings-Persistenz), `vln_layer_manager.py` (GeoJSON↔QGIS-Layer, vormals eigenständiges Plugin `vln_karten`, jetzt lokal vendored), `listenauswerter.py` (validiert `DataGrabber`-Zeilen).
+  - `ui/` — `DockWidget` (Tabs: TabA [Daten] + sn_basis PrintTab/SettingsTab), `tab_a_ui.py`/`tab_a_logic.py` (Pipeline- und VLN-API-UI), `ui/tabs/tab_b.py` (unbenutztes Scaffold, nicht in `DockWidget.tabs` eingebunden).
+  - `doc/Datenbank_ERD.md` — Mermaid-ERD des Ziel-GPKG-Schemas (`tbl_akteure`, `tbl_konten`, `tbl_ausbauart`, `tbl_Massnahme`, `p41_Massnahmen_linie`).
+  - `assets/` — ~25 QML-Stile + `Linkliste.xlsx` (Default-Linkliste) + `Verfahrensgebiet.qml`.
+- **Zwei getrennte "Plan 41"-Konzepte im selben Tab, nicht verwechseln:** (a) die generische Linkliste-Pipeline (beliebige Fachdaten → GPKG) und (b) der VLN-API-spezifische `p41`-Layer (Wege-/Gewässerplan-Maßnahmen ↔ Remote-API). Unterschiedliche Speicherziele (GPKG vs. Remote-API).
+- **`_SilentPruefmanagerProxy`-Pattern:** Die Pipeline nutzt einen stillen Pruefmanager-Proxy für Teilschritte (DataGrabber, LayerLoader), damit nicht pro Fachdienst ein Dialog aufpoppt — nur Pipeline-Fehler zeigen einen Hinweisdialog. Bei Logikänderungen unbedingt beibehalten, sonst Dialog-Spam.
+
+## 3. Domänen-Glossar
+
+- **§38/§41 FlurbG** — gesetzliche Grundlage; Plan 41 = Wege- und Gewässerplan.
+- **VKZ** — Verfahrenskennzahl, Primärschlüssel gegenüber der VLN-API.
+- **Raumfilter**: `Verfahrensgebiet | Pufferlayer | ohne` (Default: Pufferlayer, 1000 m Rechteckpuffer um die Verfahrensgebiet-Extent).
+- **Linkliste** — Excel-Tabelle mit Fachdatenquellen (`Provider`, `Link`, `ident`, optional `Inhalt`/`Stildatei`).
+- **Massnahme(n) / Ausbauart / Akteure / Kostentraeger / Bautraeger / Unterhalt** — die eigentlichen Plan-41-Fachdaten: Maßnahmen (Wege-/Gewässerbauvorhaben), Ausbauart (Bauweise+Preis), verantwortliche Akteure, Kostenträger/Bauträger/Unterhaltungslast.
+- **TG (Teilnehmergemeinschaft)** — über VKZ identifizierte Verfahrenseinheit in der VLN-API (`GET /tgen`).
+
+## 4. Datenquellen / Formate
+
+- **Excel-Linkliste** (`assets/Linkliste.xlsx`), Spalten u. a. `ident, Inhalt, Link, Provider, Stildatei`; Provider z. B. `wms` (nur Projekt, nie GPKG) und weitere von `sn_basis.LayerLoader` unterstützte Typen.
+- **VLN-Manager-REST-API**: `https://api.flurneuordnung-sachsen.de/v2`. Login (`POST /person/login`), Verfahrensliste (`GET /tgen`), Daten (`GET/PUT /maps/<layer>/{vkz}`, Layer-Keys: `umringe, p41, st, kas, we` — aktuell nur `p41` im UI verdrahtet). JSON/GeoJSON, Fehler nach RFC 7807, Auth via `X-API-Key`-Header. **CRS fest auf EPSG:25833** (keine Transformation beim Layer-Aufbau).
+- **GeoPackage** — Ziel der Fachdaten-Pipeline (Verfahrens-DB), analog sn_basis.
+- QML-Stile in `assets/` (Fachthemen + zwei dedizierte für den VLN-API-Layer).
+
+## 5. Abhängigkeiten zu den Geschwister-Plugins
+
+- **Sehr starke, umfassende Abhängigkeit von sn_basis** — praktisch jeder nicht-triviale Import kommt aus `sn_basis.*` (UI: DockManager/BaseDockWidget/Tabs; Module: DataGrabber/Pruefmanager/LayerLoader/Datenschreiber/Datenabruf/Stilpruefer; Wrapper-Funktionen durchgängig statt direktem `qgis.*`/PyQt-Import — Ausnahme: das unbenutzte `ui/tabs/tab_b.py`).
+- **Lose/indirekte Kopplung zu sn_verfahrensgebiet**: kein Import, nur ein Hinweistext im UI ("Bitte zuerst in sn_verfahrensgebiet den Layer laden…") sowie die gemeinsame Konvention der Projektvariable `verfahrensgebiet_layer` und ein dupliziertes `Verfahrensgebiet.qml`.
+- **Umgekehrt importiert sn_basis hart aus sn_plan41** (`Listenauswerter`) und referenziert Style-Pfade unter `sn_plan41/assets/` — d. h. die Kopplung ist **zirkulär** (sn_basis ↔ sn_plan41 gegenseitig). Umbenennungen in `sn_plan41/modules/listenauswerter.py` oder `sn_plan41/assets/` brechen sn_basis.
+- Test-Setup (`tests/run_tests.py`) geht explizit von **Geschwister-Verzeichnis-Layout** aus (`sn_plan41` und `sn_basis` als Siblings) — bestätigt die erwartete Repo-Struktur.
+
+## 6. Testing & Dev-Tooling
+
+- unittest-Tests: `test_listenauswerter.py`, `test_tab_a_logic.py`, `test_tab_a_preconditions.py`, `test_tab_a_ui.py`, `test_vln_api_logic.py` (mit 473 Zeilen der größte — VLN-API-Logik ist am besten getestet).
+- `try/except ImportError`-Guard in `vln_api_logic.py` (`VLN_KARTEN_AVAILABLE`) macht das Modul auch ohne QGIS-Laufzeit importierbar.
+- `.vscode/launch.json` — debugpy-Remote-Attach, Port 5678.
+- Gitea-CI wie bei den Schwesterplugins (Tag-Suffix → Release-Channel).
+
+## 7. Bekannte Stolperfallen / Konventionen
+
+1. **Plugin funktioniert nur, wenn sn_basis bereits geladen ist** — `initGui` bricht still ab, ohne Fehlermeldung; ein fehlendes/kaputtes sn_basis sieht für den Nutzer aus wie "sn_plan41 tut nichts".
+2. VLN-API-Zugangsdaten (API-Key, Mail) liegen **unverschlüsselt in QSettings** (Gruppe `vln_karten`) — beim Security-Review erwähnenswert, betrifft aber das Token, nicht das Klartext-Passwort.
+3. **EPSG:25833 ist für die VLN-API hart fixiert**, `setTransformGeometries` wird explizit deaktiviert — jeder hochzuladende Layer muss bereits im richtigen CRS sein, sonst werden beim Upload stillschweigend falsche Koordinaten geschrieben.
+4. `ui/tabs/tab_b.py` ist totes Scaffold-Beispiel (nicht in `DockWidget.tabs`), importiert zudem `qgis.PyQt` direkt statt über den Wrapper — Inkonsistenz, aber ungefährlich, da unreferenziert.
+5. Das HTML-Pipeline-Log (`plan41_lade_log.html`) ist die erste Anlaufstelle beim Debuggen, wenn die Pipeline weniger Layer liefert als erwartet (Status je Fachdienst: `layeraufruf_start/ok`, `layer_nicht_ladbar`, `raumfilter_ausserhalb`, `geladen` etc.).
+6. `modules/vln_layer_manager.py` ist laut eigenem Docstring eine **lokale Kopie** aus einem früher separaten Plugin `vln_karten` — Custom-Layer-Properties (`vln_karten/dataset`, `vln_karten/verfahren`, `vln_karten/api_path`) sind bewusst so benannt, um kompatibel zu bleiben, falls `vln_karten` je wieder parallel installiert wird.
+7. Nicht verwechseln: generische Fachdaten-Pipeline (Linkliste, beliebige Themen) vs. VLN-API-spezifischer `p41`-Datensatz — siehe Architektur-Abschnitt.
diff --git a/wissensdateien/sn_verfahrensgebiet.md b/wissensdateien/sn_verfahrensgebiet.md
new file mode 100644
index 0000000..bb444aa
--- /dev/null
+++ b/wissensdateien/sn_verfahrensgebiet.md
@@ -0,0 +1,62 @@
+# Wissensdatei: sn_verfahrensgebiet
+
+## 1. Zweck
+
+`sn_verfahrensgebiet` ("LNO Sachsen | Verfahrensgebiet") erstellt und verwaltet die **"Verfahrensgebiet"-Fläche** — die Abgrenzung eines Flurbereinigungsverfahrens. Es lädt die Verfahrensfläche, zugehörige Gemarkungen, Flurstücke und Grenzpunkte aus sächsischen ALKIS-WFS-Diensten (alternativ per Shapefile-Import), baut/editiert die Verfahrensgebiet-Polygon-Layer aus einer Flurstücksauswahl und validiert deren Umring automatisiert gegen amtliche Grenzpunktdaten (Knickpunkt-/Umringsprüfung).
+
+## 2. Architektur
+
+- Entry-Point: `__init__.py → classFactory(iface) → main.py: Verfahrensgebiet`.
+- `main.py` ist ein **dünner Orchestrator**, der die eigentliche UI/Dock-Registrierung komplett an `sn_basis` delegiert: `Navigation`/`DockManager` werden über `qgis.utils.plugins.get("sn_basis")` zur Laufzeit angesprochen. **Ohne geladenes sn_basis funktioniert dieses Plugin nicht.**
+- Verzeichnisse:
+  - `functions/` — die eigentliche Fachlogik: WFS-Integration (`verfahrensgebiet_alkis*.py`, `flurstueck_alkis.py`, `gemarkung_alkis.py`, `grenzpunkt_alkis.py`), Geometrieprüfung (`knickpunkt_pruefung.py`, `umringspruefung.py`, `umringstatistik_grenzpunkte.py`), CRUD für die VG-Layer (`verfahrensgebiet_edit_service.py`).
+  - `ui/` — `DockWidget` (Tabs: WorkingTab + sn_basis-PrintTab/SettingsTab), `ui/tabs/working_tab.py` (~800 Zeilen, alle Button-Handler).
+  - `styles/` — QML-Stile (BROR, Flurstücksbeschriftung, Gemarkungen, Verfahrensgebiet).
+  - `tests/` — 11 unittest-Dateien, ~4800 Zeilen, QGIS wird per `sys.modules`-Stub gemockt.
+- **Single-Feature-Layer-Modell:** Die VG-Layer hat immer genau **ein** Feature (alle Quellgeometrien via `QgsGeometry.unaryUnion` vereinigt); `flurstueckskennzeichen` wird kommagetrennt in einem Attribut gespeichert — bewusstes Design, dokumentiert am Kopf von `verfahrensgebiet_edit_service.py`.
+- **LoadStatus-Enum** (`NONE/FIRST/RELOAD/KEEP/APPEND`) wird konsistent für "Layer laden, mit bestehendem umgehen"-Logik verwendet.
+
+## 3. Domänen-Glossar
+
+- **Verfahrensgebiet (VG)** — die final erzeugte Verfahrensflächen-Layer (Zielobjekt).
+- **BROR** (`BauRaumOderBodenordnungsrecht`) — das amtliche ALKIS-Rohobjekt der Verfahrensfläche; Layername im Projekt: `"BauRaumOderBodenordnungsrecht (ALKIS)"`. **BROR ≠ VG**: BROR ist die amtliche Rohquelle, VG die lokal aus Flurstücken abgeleitete/geprüfte Fläche — beide werden auf Flächengleichheit gegeneinander geprüft (Toleranz über Projektvariable `flaechen_toleranz_m2`).
+- **Gemarkung** — Katasterbezirk, 4-stellige Gemarkungsnummer.
+- **Flurstück** — Katasterparzelle, identifiziert über `flurstueckskennzeichen`.
+- **Grenzpunkt** vs. **PunktortTA** — amtlicher Grenzpunkt (`AX_Grenzpunkt`, ohne eigene Geometrie) vs. dessen tatsächliche Koordinate (`AX_PunktortTA`, referenziert über `gehoertZu`/`istTeilVon`).
+- **Knickpunkt** — Eckpunkt ("Knick") der BROR-Polygongeometrie; **Knickpunktprüfung** = automatischer Abgleich Knickpunkte vs. PunktortTA (grün=Treffer, rot=Knickpunkt ohne PunktortTA, orange=PunktortTA ohne zugehörigen Knickpunkt), inkl. automatischer Geometriekorrektur.
+- **Umringsprüfung / Umringstatistik** — Linienbasierter Abgleich BROR-Umring vs. Flurstücksgrenzen bzw. Klassifikation der Umringspunkte nach Güte.
+- **VKZ** (Verfahrenskennzeichen/-nummer) — Projektvariable `verfahrensnummer`.
+
+## 4. Datenquellen / Formate
+
+Alle Kern-Daten kommen aus sächsischen **ALKIS-WFS-Diensten**, CRS **EPSG:25833**:
+
+| Dienst | URL | Typename(s) |
+|---|---|---|
+| ALKIS "sf"  | `https://geodienste.sachsen.de/aaa/public_alkis/sf/wfs` | `adv:AX_BauRaumOderBodenordnungsrecht`, `adv:AX_Flurstueck`, `adv:AX_PunktortTA`, `adv:AX_Grenzpunkt` |
+| ALKIS "vereinf" (mit echter Geometrie) | `https://geodienste.sachsen.de/aaa/public_alkis/vereinf/wfs` | `ave:KatasterBezirk` (Gemarkungen; `adv:AX_Gemarkung` scheidet mangels nutzbarer Geometrie aus) |
+
+Alternativ: **Shapefile-Import via ZIP** für die Verfahrensgebiet-Quelle, weiterhin optional gegen BROR gegengeprüft.
+
+## 5. Abhängigkeiten zu den Geschwister-Plugins
+
+- **Starke Abhängigkeit von sn_basis:** durchgängige Importe (`functions.qt_wrapper`, `.qgisui_wrapper`, `.qgiscore_wrapper`, `.dialog_wrapper`, `.message_wrapper`, `.variable_wrapper`, `.verfahrensgebiet_manager`, `.ly_style_wrapper`, `ui.base_dockwidget`, `ui.tabs.settings_tab`/`print_tab`, `ui.dockmanager.DockManager`, `modules.DataGrabber`/`Pruefmanager`/`pruef_ergebnis`/`layerpruefer`). Sowohl statischer Python-Import als auch Laufzeit-Lookup via `qgis.utils.plugins.get("sn_basis")` für UI-Wiring.
+- **Keine Kopplung zu sn_plan41** — kein einziger Verweis im Code gefunden. Integration läuft ausschließlich indirekt über sn_basis (gemeinsame Projektvariable `sn_verfahrensgebiet_layer`, Layername `"Verfahrensgebiet"`).
+- Konkrete Dialoge in `sn_basis.functions.dialog_wrapper` (`ask_bror_kombination`, `ask_detailpruefung_oder_vg_laden`, `ask_detailpruefung_oder_abbrechen`) existieren **speziell** für die BROR/ALKIS-Workflows dieses Plugins.
+
+## 6. Testing & Dev-Tooling
+
+- unittest-basiert (Runner teils pytest), 11 Testdateien decken fast jedes `functions/`-Modul 1:1 ab. **Lücke:** kein Testfile für `umringspruefung.py` oder `umringstatistik_grenzpunkte.py`.
+- QGIS wird für Tests über `sys.modules`-Injection gestubbt (kein echtes QGIS nötig).
+- `.vscode/launch.json` — debugpy-Remote-Attach auf laufende QGIS-Instanz, Port 5678.
+- Gitea-CI (`.gitea/workflows/release.yaml`): Tag-Push (`v*`) → Channel aus Tag-Suffix (`-testing`/`-unstable`/sonst `stable`) → Release-Zip.
+
+## 7. Bekannte Stolperfallen / Konventionen
+
+1. **WFS-Workarounds in `grenzpunkt_alkis.py` (1600+ Zeilen) sind absichtlich low-level**: Der WAF von `geodienste.sachsen.de` blockiert POST und GML/XML-Filterinhalte in URLs — daher handgebaute WFS-2.0-GET-Requests + manuelles GML-Parsing via `xml.etree.ElementTree`, Batching (`_BATCH_GROESSE=100`, `_BBOX_BATCH=5000`) und BBox-Splitting pro Gemarkung (200 m Puffer). **Nicht "vereinfachen" ohne die Docstrings zu lesen.**
+2. EPSG:25833 ist überall hart codiert (`srsname='EPSG:25833'` in WFS-URIs).
+3. Geometrie-Toleranzen sind bewusst klein und real-vermessungsbasiert: `KOORDINATEN_TOLERANZ_M = 0.01`, `VERBINDUNGSLINIE_PUFFER_M = 0.03`, `LINIE_TOLERANZ_M = 0.0001`, `UMRING_TOLERANZ_M = 0.01`, `MINDEST_FLAECHEN_TOLERANZ_M2 = 0.01` — nicht leichtfertig ändern.
+4. **"Aus Liste" (Verfahrensgebiet erstellen) ist ein Stub** (zeigt nur "noch nicht implementiert"). **"aus Shape" für Flurstücke ist im UI vorhanden, aber der Handler ist auskommentiert.**
+5. Die Knickpunktprüfung wurde laut Changelog mehrfach überarbeitet (zuletzt von Buffer- auf Verbindungslinien-basiert) — vor Änderungen an `knickpunkt_pruefung.py` Tests/Git-Historie prüfen, aktivster und heikelster Teil der Codebasis.
+6. `styles/Gemarkungen_beschriftet.qml` ist ~852 KB groß (Labeling-Regeln für ~2000 Gemarkungen) — vorsichtig direkt bearbeiten.
+7. `[DIAG]`-Präfixe in `gemarkung_alkis.py` sind absichtliche Diagnose-Logs für WFS-Troubleshooting, kein Debug-Müll.