Projektwissen der AG Prozesse aus AG_QGIS/Projektwissen abgeleitet

Übernommen ohne Historie aus AG_QGIS/Projektwissen (main @ decd2a0), Skill sn-bpmn vom Branch BPMN-Skill @ 6efcac4 (ADR 0001). - Skripte hallo.py, gitea.py, setup_workspace.py auf die Organisation AG_Prozesse umgestellt; das Workspace-Repo zählt über [workspace] repo als Ticket-Repo, auch ohne weitere [[repos]]. - pruefe_umlaute.py prüft jetzt die .py-Dateien des Workspace selbst. - Branchmodell main plus Arbeitsbranches (ADR 0002). - AGENTS.md, README, Leitfäden, Skills, Vorlagen, Fallstricke und Glossar auf die Prozessmodellierung zugeschnitten; QGIS- und Plugin-Spezifisches entfernt. - Tests: python -m pytest -q .agents/skills -> 32 bestanden. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-09-23 12:34:37 +02:00
commit 012509b6d1
36 changed files with 4414 additions and 0 deletions
@@ -0,0 +1,18 @@
+# Dokumentation – Wegweiser
+
+| Ordner | Charakter | Wann lesen |
+|---|---|---|
+| `status/STATUS.md` | lebend, kurz | **immer zuerst** – aktueller Stand, Baustellen |
+| `wissen/fallstricke.md` | lebend | bei Überraschungen; vor Arbeiten am Konverter und am PICTURE-Import |
+| `wissen/glossar.md` | lebend | Fachbegriffe (Flurbereinigung, BPMN) |
+| `entscheidungen/` | append-only (ADR) | warum etwas so ist; neue Entscheidung = neue Datei |
+| `leitfaden/03_arbeitsweise.md` | stabil | Einstieg, Arbeitszyklus, Checklisten |
+| `leitfaden/04_werkzeuge_einrichten.md` | stabil | Einrichtung: Claude Code als CLI und in VS Code; von null zur ersten Aufgabe |
+| `leitfaden/05_git_arbeitsweise.md` | **verbindlich** | Branches, Pull Requests, was der Agent darf |
+| `vorlagen/` | Vorlagen | Issue, PR, Übergabe, Repo-`AGENTS.md` |
+
+Die Fachdoku des Konverters (Markdown-Syntax, Elementkatalog, Modellierregeln) liegt beim Skill in
+`.agents/skills/sn-bpmn/`.
+
+Regel: **Lebende** Dokumente werden mit jeder Änderung gepflegt, **Momentaufnahmen** nicht nachträglich geändert
+(neue Analyse = neue Datei mit Datum).
@@ -0,0 +1,34 @@
+# 0001 – Arbeitsweise aus AG_QGIS/Projektwissen übernehmen, ohne Historie
+
+Status: vorgeschlagen · Datum: 2026-09-23 · Beteiligte: AG Prozesse
+
+## Kontext
+Die BPMN-bezogene Zusammenarbeit bekommt eine eigene Gitea-Organisation `AG_Prozesse`. In `AG_QGIS/Projektwissen`
+sind Regeln, Skripte, Skills und eine Wissensbasis für die KI-gestützte Zusammenarbeit entstanden, und der Skill
+`sn-bpmn` wurde dort auf dem Branch `BPMN-Skill` entwickelt. Das meiste davon ist nicht QGIS-spezifisch.
+
+## Entscheidung
+`AG_Prozesse/Projektwissen` wird **neu angelegt** und übernimmt ausgewählte Dateien aus
+`AG_QGIS/Projektwissen` (Stand `main` @ `decd2a0`, `sn-bpmn` von `BPMN-Skill` @ `6efcac4`) – **ohne Git-Historie**.
+QGIS- und Plugin-Spezifisches (Testrunner, Testkatalog, QGIS-Profil, ALKIS/WFS-Wissen, Modulkarte, Release)
+wird nicht übernommen.
+
+Folgende Grundsätze aus AG_QGIS gelten hier unverändert (dort ADR 0001, 0002, 0004, 0006, 0008):
+
+- `AGENTS.md` ist die einzige kanonische Anweisungsdatei; `CLAUDE.md` ist nur ein Zeiger darauf.
+- Das Repository heißt `Projektwissen`, der lokale Ordner `AG_Prozesse/`. Weitere Repositories der Gruppe werden
+  als eigenständige Klone daneben gelegt und in `workspace.toml` eingetragen.
+- Geteiltes Wissen liegt versioniert in `docs/`, nicht im lokalen Gedächtnis eines KI-Werkzeugs.
+- Die Anleitung beschreibt Claude Code; die Dateistruktur bleibt werkzeugneutral (`.agents/skills/` ist kanonisch).
+- Agenten verändern nichts auf dem Server; Push, Merge und Tag macht der Mensch.
+
+## Folgen
+Die Historie bleibt übersichtlich und enthält keine QGIS-Inhalte, auch nicht solche, die dort früher einmal
+committet und wieder entfernt wurden. Die Herkunft ist über diese Datei und die genannten Commits nachvollziehbar.
+Verbesserungen an den gemeinsamen Skripten (`hallo.py`, `gitea.py`, `setup_workspace.py`) müssen künftig in beiden
+Repositories nachgezogen werden, solange es kein gemeinsames Werkzeug-Repository gibt. Der Branch `BPMN-Skill` in
+AG_QGIS ist abgelöst.
+
+## Verworfene Alternativen
+Klonen und Löschen mit voller Historie (fremde Historie, alte Inhalte bleiben sichtbar); gemeinsames
+Werkzeug-Repository für beide Gruppen (derzeit mehr Aufwand als Nutzen, später möglich).
@@ -0,0 +1,21 @@
+# 0002 – Branchmodell: `main` plus Arbeitsbranches
+
+Status: vorgeschlagen · Datum: 2026-09-23 · Beteiligte: AG Prozesse
+
+## Kontext
+In AG_QGIS gibt es drei Release-Kanäle (`unstable`, `testing`, `stable`), weil QGIS-Plugins über Plugin-Feeds an die
+Arbeitsplätze ausgeliefert werden. Hier gibt es keine Auslieferung: Ergebnisse sind Dokumente, Prozessmodelle und
+der Konverter, die direkt aus dem Repository genutzt werden.
+
+## Entscheidung
+Es gibt einen Hauptbranch **`main`**. Gearbeitet wird auf `feature/<issue-nr>-<kurzname>` bzw.
+`bugfix/<issue-nr>-<kurzname>`, zurückgeführt per Pull Request mit Review. Auf `main` wird nie direkt committet;
+auf Gitea wird `main` gegen direkte Pushes geschützt.
+
+## Folgen
+Keine Kanäle, keine Rückführung zwischen Kanälen, keine Release-Tags. Wird später eine versionierte Auslieferung
+nötig (etwa des Konverters), werden Tags auf `main` gesetzt und diese Entscheidung ergänzt.
+
+## Verworfene Alternativen
+Drei Kanäle wie in AG_QGIS (Aufwand ohne Auslieferungsweg); direkt auf `main` arbeiten (kein Review, keine
+Nachvollziehbarkeit).
@@ -0,0 +1,29 @@
+# Entscheidungen (ADR)
+
+Eine Datei je Entscheidung, fortlaufend nummeriert, nie nachträglich geändert. Wird eine Entscheidung ersetzt,
+bekommt die alte den Status „ersetzt durch NNNN“ und die neue verweist zurück.
+
+Vorlage:
+
+```markdown
+# NNNN – Titel
+
+Status: vorgeschlagen | angenommen | ersetzt durch NNNN   ·   Datum: JJJJ-MM-TT   ·   Beteiligte: …
+
+## Kontext
+Warum stand die Entscheidung an? Welche Randbedingungen?
+
+## Entscheidung
+Was wurde entschieden (ein Satz), danach die wichtigsten Details.
+
+## Folgen
+Was wird dadurch einfacher, was schwerer, was muss getan werden?
+
+## Verworfene Alternativen
+Kurz, mit Grund.
+```
+
+| Nr. | Titel | Status |
+|---|---|---|
+| 0001 | Arbeitsweise aus AG_QGIS/Projektwissen übernehmen, ohne Historie | vorgeschlagen |
+| 0002 | Branchmodell: `main` plus Arbeitsbranches | vorgeschlagen |
@@ -0,0 +1,134 @@
+# Arbeitsweise: So arbeiten wir mit KI-Agenten an Prozessmodellen
+
+Für Kolleginnen und Kollegen, die neu einsteigen. Fachwissen wird vorausgesetzt, Software-Erfahrung nicht.
+Wir arbeiten mit Claude Code; die Dateien bleiben werkzeugneutral (ADR 0001). Die Kurzfassung für den Agenten
+selbst ist `AGENTS.md`, dieser Leitfaden erklärt das Warum und das Wie. Git im Detail: `05_git_arbeitsweise.md`.
+Einrichtung Schritt für Schritt: `04_werkzeuge_einrichten.md`.
+
+## 1. Zwei Arten von Arbeit
+
+| Arbeit | Wer | Womit | Ergebnis |
+|---|---|---|---|
+| **Einen Prozess modellieren** | Fachleute | Skill `sn-bpmn` | BPMN-Datei für PICTURE |
+| **Werkzeug und Wissen verbessern** | alle, die einen PR stellen | Skill `sn-aufgabe-bearbeiten` | Pull Request auf `main` |
+
+Wer nur modelliert, braucht Git kaum: Claude Code im Ordner `AG_Prozesse` starten, Quelle nennen, Entwurf prüfen,
+umwandeln. Git und Pull Requests kommen erst ins Spiel, wenn sich am Konverter, an den Regeln oder an der Doku
+etwas ändern soll — oder wenn ein abgenommenes Modell im Repository abgelegt wird (STATUS, Baustelle 2).
+
+## 2. Einen Prozess modellieren
+
+```mermaid
+flowchart TD
+    A["Quelle nach referenz/ legen<br/><i>Word, PDF, Rohtext</i>"] --> B["Agent: sn-bpmn<br/>Entwurf entwuerfe/&lt;name&gt;.md"]
+    B --> C["Annahmen lesen, Entwurf fachlich prüfen und anpassen"]
+    C -->|"noch nicht richtig"| C
+    C -->|"passt so, wandle um"| D["&lt;name&gt;.bpmn"]
+    D --> E["Import in PICTURE"]
+    E -->|"Darstellungsfehler"| F["Issue anlegen<br/><i>Skill sn-ticket</i>"]
+```
+
+- **Der Agent wartet nach dem Entwurf.** Er wandelt erst um, wenn du ausdrücklich zustimmst. Das ist Absicht: die
+  fachliche Richtigkeit verantwortest du, nicht der Agent.
+- **Annahmen ernst nehmen.** Der Agent nennt, wo er Schrittgrenzen, Verzweigungen oder Verantwortliche geraten hat.
+  Genau dort liegen die Fehler.
+- **Rollen statt Personen.** Verantwortliche immer als Funktion („Sachbearbeitung"), nie mit Namen.
+- **Darstellungsfehler in PICTURE** (Kanten durch Elemente, überlappende Lanes) sind Fehler des Konverters, nicht
+  deines Entwurfs. Issue anlegen, mit dem Entwurf als Beispiel (bereinigt).
+
+## 3. Wie man einem Agenten einen Auftrag gibt
+
+Der Agent liest `AGENTS.md` automatisch. Was er **nicht** weiß: was genau gewollt ist, wo es endet, und was fachlich
+richtig ist. Ein guter Auftrag hat vier Teile:
+
+1. **Ziel und Issue:** „Bearbeite Issue #12: …“ oder das Ziel in zwei Sätzen.
+2. **Kontext-Zeiger statt Erklärungen:** „Betroffen ist die Lane-Beschriftung in `md_to_bpmn.py`, Regel in
+   `Modellierregeln.md` Abschnitt Lanes.“
+3. **Grenzen:** „Keine Änderung an der Markdown-Syntax. Keine neuen Abhängigkeiten. Kein Umbau.“
+4. **Abnahme:** „Fertig ist es, wenn ein Test für einen Rollennamen über 30 Zeichen existiert, alle Tests grün sind
+   und die Übergabenotiz geschrieben ist.“
+
+Beispiel eines schlechten Auftrags: „Mach die Diagramme schöner.“ Das erzeugt lange Erkundung, unklare Änderungen
+und einen PR, den niemand reviewen kann.
+
+**Während der Arbeit:** Rückfragen beantworten, fachlich prüfen, was der Agent behauptet, und ihn bei
+Abschweifungen zurückholen („Nur Issue #12“). Wenn er anfängt, Tests zu ändern statt Code, nach der Begründung
+fragen.
+
+## 4. Die Regeln und warum es sie gibt
+
+| Regel (aus `AGENTS.md`) | Warum |
+|---|---|
+| Der Mensch pusht, mergt und legt Tickets an | Jede Aktion auf dem Server trägt den Namen einer Person |
+| Nie direkt auf `main` | `main` ist der abgenommene Stand, den alle nutzen |
+| Neues Konverter-Verhalten nur mit Test | Tests sind der einzige schnelle Nachweis für Agentenarbeit; Layoutfehler kommen sonst unbemerkt zurück |
+| Keine personenbezogenen Daten, keine Originalunterlagen | Alles, was der Agent liest, geht an den Anbieter; das Repository ist für die ganze Gruppe sichtbar |
+| Kein Umbau nebenbei | Umbauten ohne Plan sind nicht reviewbar |
+| Deutsch mit echten Umlauten | Modelle landen in PICTURE und werden von Fachleuten gelesen |
+| Übergabenotiz | Die nächste Person oder der nächste Agent soll nicht von vorn beginnen |
+
+## 5. Wissen festhalten
+
+| Situation | Was tun |
+|---|---|
+| Etwas hat überraschend Zeit gekostet | Eintrag in `docs/wissen/fallstricke.md` (Rubrik, Datum, Quelle) |
+| Markdown-Syntax, Element oder Modellierregel geändert | `.agents/skills/sn-bpmn/Anleitung.md`, `Elementkatalog.md`, `Modellierregeln.md` |
+| Team hat etwas entschieden | neue Datei `docs/entscheidungen/NNNN-<thema>.md` nach Vorlage |
+| Aufgabe abgegeben oder pausiert | Übergabenotiz im PR (Vorlage) und Zeile in `STATUS.md` |
+| Fachbegriff musste erklärt werden | `docs/wissen/glossar.md` |
+
+Der Skill `sn-uebergabe` führt den Agenten am Ende jeder Aufgabe durch genau diese Liste. Das eigene Gedächtnis des
+Werkzeugs (Claude Auto-Memory) ist ein Notizzettel; teilbares Wissen gehört in die Dateien oben.
+
+## 6. Was liegt wo, und was liest der Agent
+
+| Datei | Wird gelesen |
+|---|---|
+| `AGENTS.md` | ja, über `CLAUDE.md` (`@AGENTS.md`) – kanonisch |
+| `CLAUDE.md` | ja, enthält nur den Verweis und wenige Claude-spezifische Zeilen |
+| `.agents/skills/` | kanonischer Ort; gelesen wird der Spiegel `.claude/skills/` |
+| `.claude/commands/` | Slash-Befehle, z. B. `/hallo` |
+| `.claude/settings.json` | Berechtigungen – sperrt `git push`, `merge`, `tag` |
+| `docs/` | auf Abruf, nicht automatisch |
+| `referenz/`, `entwuerfe/` | nur, wenn du darauf verweist; nicht versioniert |
+| `CLAUDE.local.md` | ja, lokal, nicht versioniert |
+
+## 7. Häufige Fragen
+
+**Der Agent kennt den Skill `sn-bpmn` nicht.** Er wurde im falschen Ordner gestartet, oder der Skill-Spiegel fehlt:
+`python scripts/setup_workspace.py --nur-skills`.
+
+**Der Agent wandelt sofort um, ohne auf mich zu warten.** Das widerspricht dem Skill. Stoppen und auf Schritt 3
+in `.agents/skills/sn-bpmn/SKILL.md` verweisen.
+
+**Der Agent „repariert“ rote Tests durch Anpassen der Erwartung.** Nach Begründung fragen; nur akzeptieren, wenn das
+Verhalten bewusst geändert wurde und das Issue es abdeckt.
+
+**Der Agent hat eine Datei komplett umgeschrieben.** Diff prüfen, auf das Issue zurückführen, Rest verwerfen.
+
+**Zwei Personen arbeiten am selben Thema.** In `STATUS.md` steht, wer woran arbeitet; vorher dort eintragen und
+kleine PRs machen.
+
+## 8. Checklisten
+
+**Vor dem PR**
+
+- [ ] Issue verlinkt, Branch von `main`
+- [ ] `python -m pytest -q .agents/skills` grün, `python scripts/pruefe_umlaute.py` ohne Funde
+- [ ] Bei geänderter BPMN-Ausgabe: PICTURE-Import dokumentiert
+- [ ] Keine personenbezogenen Daten, keine Originalunterlagen
+- [ ] Übergabenotiz im PR; Wissensbasis nachgezogen, falls nötig
+- [ ] Diff gelesen: nur, was das Issue verlangt
+
+**Review**
+
+- [ ] Fachlich richtig? (BPMN-Regeln, Begriffe)
+- [ ] Tests vorhanden und sinnvoll (nicht nur angepasst)?
+- [ ] Umfang überschaubar (< 400 Zeilen)?
+- [ ] Nach dem Merge: `STATUS.md`
+
+**Sitzungsende (auch bei Abbruch)**
+
+- [ ] Zwischenstand auf dem Arbeitsbranch committet
+- [ ] Offene Fragen im Issue notiert
+- [ ] `STATUS.md`-Zeile aktualisiert
@@ -0,0 +1,186 @@
+# Werkzeuge einrichten: von null bis zur ersten Aufgabe
+
+Stand 23.09.2026. Ergänzt [`03_arbeitsweise.md`](03_arbeitsweise.md) um die konkrete Einrichtung. Wer Abschnitt 2
+durchgearbeitet hat, kann beide Varianten aus Abschnitt 3 und 4 nutzen und jederzeit zwischen ihnen wechseln —
+sie greifen auf dieselben Dateien zu.
+
+## 1. Zwei Varianten
+
+Wir arbeiten mit **Claude Code**. Es gibt zwei Formen, dieselbe Software zu bedienen:
+
+| Variante | Form | Wofür geeignet |
+|---|---|---|
+| **A · Claude Code CLI** | Terminal | lange, eigenständige Aufgaben; Skripte |
+| **B · Claude Code in VS Code** | Erweiterung mit Chatpanel | Einstieg; Entwürfe und Diffs im Editor sehen und einzeln annehmen |
+
+Beide lesen `CLAUDE.md` (und darüber `AGENTS.md`), beide finden die Skills unter `.claude/skills/`, beide
+arbeiten über Git mit Gitea. **Empfehlung für Einsteiger: Variante B**, weil man jede Änderung — auch am
+Arbeitsschritt-Entwurf — als Diff sieht, bevor sie übernommen wird.
+
+**Nicht genutzt und nicht unterstützt:** Cloud-Agenten (Claude Code Web, Codex Cloud, Copilot Coding Agent) —
+sie setzen GitHub voraus, wir arbeiten mit Gitea. Reine Chat-Oberflächen ohne Ordnerzugriff (claude.ai,
+chatgpt.com) sind für Fachfragen brauchbar, aber nicht für Änderungen am Repository. Wer nur Chat hat,
+formuliert Issues nach [`docs/vorlagen/issue.md`](../vorlagen/issue.md) und lässt sie von jemandem mit Agent
+umsetzen.
+
+## 2. Gemeinsame Grundlage (einmal pro Rechner)
+
+### 2.1 Konten und Zugänge
+
+- **Gitea-Konto** auf `entwicklung.flurneuordnung-sachsen.de` mit Schreibrecht in der Organisation `AG_Prozesse`
+  (beim Maintainer anfragen). Für HTTPS-Push ein **Zugriffstoken** anlegen:
+  Gitea → Einstellungen → Anwendungen → Token, Berechtigung `repository: read/write`.
+- **Claude-Konto**: Abo (Pro, Max, Team, Enterprise) oder Console-Konto. Dienstliche E-Mail verwenden;
+  die Abrechnung klärt die Behörde.
+- **Behördennetz:** ausgehendes HTTPS zu `claude.ai` und `api.anthropic.com` muss möglich sein. Bei Proxy die
+  Variablen `HTTPS_PROXY` und `HTTP_PROXY` setzen; bei Problemen mit der Zertifikatsprüfung die IT ansprechen.
+- **PICTURE-Zugang** zum Prüfen des BPMN-Imports (nicht für alle nötig).
+
+### 2.2 Git
+
+- **Windows:** [Git for Windows](https://git-scm.com/downloads/win) mit den Standardoptionen. Enthält Git Bash
+  und den Credential Manager, der sich das Gitea-Token nach dem ersten Push merkt. Claude Code setzt Git for
+  Windows voraus.
+- **macOS/Linux:** Git über Xcode-Tools bzw. die Paketverwaltung.
+- Einmalig einstellen — **die E-Mail-Adresse muss die des Gitea-Kontos sein.** Gitea ordnet Commits über die
+  Adresse dem Benutzerkonto zu; passt sie nicht, erscheinen die Commits im Browser ohne Zuordnung, und niemand
+  sieht, wer etwas geändert hat. Nachträglich lässt sich das nur durch Umschreiben der Historie korrigieren.
+  ```bash
+  git config --global user.name  "Vorname Nachname"
+  git config --global user.email "<dienstliche Adresse aus dem Gitea-Konto>"
+  ```
+  Wer den Rechner auch privat nutzt, setzt die dienstliche Adresse besser **je Repository** statt global —
+  `--local` statt `--global`.
+- Prüfen, bevor der erste Commit entsteht:
+  ```bash
+  git -C AG_Prozesse config user.email     # muss die Gitea-Adresse sein
+  ```
+
+### 2.3 Python
+
+Benötigt: **Python ≥ 3.11** und das Paket `pytest` für die Tests des Konverters.
+
+- Python von python.org installieren, beim Setup „Add to PATH" anhaken, dann `python -m pip install pytest`.
+- Prüfen: `python --version` und `python -m pytest --version` müssen beide ohne Fehler durchlaufen.
+
+Die Skripte (`hallo.py`, `gitea.py`, `setup_workspace.py`, `pruefe_umlaute.py`) und der Konverter
+`md_to_bpmn.py` brauchen **nur die Standardbibliothek**.
+
+### 2.4 Projektwissen holen
+
+```bash
+git clone https://entwicklung.flurneuordnung-sachsen.de/AG_Prozesse/Projektwissen.git AG_Prozesse
+cd AG_Prozesse
+python scripts/setup_workspace.py       # spiegelt die Skills, holt ggf. weitere Repos
+python -m pytest -q .agents/skills      # erwartet: alle Tests grün
+```
+
+Der Zielordner `AG_Prozesse` ist bewusst anders benannt als das Repository: darin können später weitere
+Repositories der Gruppe nebeneinander liegen.
+
+## 3. Variante A: Claude Code CLI
+
+1. **Installieren.**
+   Windows (PowerShell): `irm https://claude.ai/install.ps1 | iex`
+   macOS/Linux: `curl -fsSL https://claude.ai/install.sh | bash`
+   Node.js wird nicht benötigt; der Installer aktualisiert sich selbst.
+2. **Anmelden:** `claude` starten, im Browser mit dem Claude-Konto anmelden.
+3. **Starten:** im Ordner `AG_Prozesse` `claude` eingeben. Beim ersten Mal den Import `@AGENTS.md` bestätigen.
+4. **Prüfen:** `/context` listet `CLAUDE.md` und `AGENTS.md` unter „Memory files". `/hallo` und die Skills
+   (`sn-bpmn`, `sn-aufgabe-bearbeiten`, `sn-ticket`, `sn-uebergabe`) erscheinen im Menü.
+5. **Berechtigungen:** Der Standardmodus fragt vor Änderungen. Für Routinearbeit ist „Accept edits" praktikabel.
+   `--dangerously-skip-permissions` niemals außerhalb einer Sandbox.
+   Das Repo verbietet über `.claude/settings.json` ohnehin `git push`, `git merge` und `git tag` —
+   siehe [`05_git_arbeitsweise.md`](05_git_arbeitsweise.md) Abschnitt 6.
+6. **Erste Aufgabe:** Abschnitt 6 dieser Seite.
+
+Die Auto-Memory ist lokal und wird nicht geteilt; Teilbares gehört nach `docs/` — Skill `sn-uebergabe`.
+
+## 4. Variante B: Claude Code in VS Code
+
+1. **VS Code installieren**, dann **den Ordner `AG_Prozesse` öffnen** (Datei → Ordner öffnen).
+2. **Erweiterung installieren:** `Strg+Shift+X` → „Claude Code" (Herausgeber Anthropic) → Installieren.
+   Die Erweiterung bringt eine eigene CLI-Kopie mit; die Installation aus Variante A ist nur nötig, wenn man
+   `claude` zusätzlich im integrierten Terminal nutzen will.
+3. **Anmelden:** Symbol in der Aktivitätsleiste → Sign in → Browser-Anmeldung.
+4. **Python-Interpreter wählen:** `Strg+Shift+P` → „Python: Select Interpreter" → das Python aus Abschnitt 2.3.
+5. **Arbeiten:** Panel öffnen. Markierter Text wird automatisch mitgesendet (`Alt+K` fügt einen Verweis ein).
+   Diffs erscheinen im Editor und werden einzeln angenommen oder verworfen. Den Berechtigungsmodus wählt man
+   unten im Eingabefeld; Pläne lässt man vor der Umsetzung im Plan-Modus prüfen.
+
+### 4.1 Empfohlene Erweiterungen
+
+| Erweiterung | Kennung | Wofür |
+|---|---|---|
+| Claude Code | `anthropic.claude-code` | der Agent selbst |
+| Python | `ms-python.python` | Syntax, Interpreterwahl, Debugger |
+| Markdown Preview Mermaid Support | `bierner.markdown-mermaid` | zeigt Mermaid-Diagramme in der Vorschau |
+
+Ein BPMN-Betrachter als Erweiterung ist nicht nötig: `md_to_bpmn.py` kann eine Vorschau ohne PICTURE erzeugen,
+siehe `.agents/skills/sn-bpmn/Anleitung.md`.
+
+### 4.2 Persönliche Einstellungen
+
+**Diese Einstellungen gehören in die Benutzereinstellungen, nicht ins Repository.** Das Repo enthält bewusst
+keinen `.vscode/`-Ordner. Wer sie haben will, kopiert sie sich in die eigene `settings.json`
+(`Strg+Shift+P` → „Preferences: Open User Settings (JSON)").
+
+```jsonc
+{
+  "files.exclude": { "**/__pycache__": true, "**/.pytest_cache": true },
+
+  // Einheitliche Dateiform — das Repo ist auf UTF-8 und LF eingestellt
+  "files.encoding": "utf8",
+  "files.eol": "\n",
+  "[python]": { "editor.tabSize": 4, "editor.insertSpaces": true },
+  "[markdown]": { "editor.wordWrap": "on" }
+}
+```
+
+## 5. Einschränkungen und Datenschutz
+
+- **Gitea statt GitHub.** Alle Cloud-Agenten setzen GitHub voraus und entfallen damit. Issues und Pull Requests
+  entstehen im Gitea-Browser; lesend geht die API auch ohne Anmeldung — dafür gibt es `scripts/gitea.py` und
+  den Skill `sn-ticket`.
+- **Inhalte gehen an den Anbieter.** Alles, was der Agent liest, wird an den Anbieter übertragen — auch eine
+  Prozessbeschreibung aus `referenz/`. Deshalb: keine Zugangsdaten, keine personenbezogenen Daten, keine als
+  vertraulich eingestuften Unterlagen in Prompts oder Dateien. Im Zweifel die Quelle vorher bereinigen.
+- **Der Mensch drückt ab.** Agenten dürfen nicht pushen, mergen, taggen oder irgendetwas auf dem Gitea-Server
+  verändern. Das ist in `.claude/settings.json` technisch hinterlegt, nicht nur als Bitte formuliert.
+- **Windows-Symlinks.** `setup_workspace.py` fällt auf eine Junction oder Kopie zurück, wenn Symlinks nicht
+  erlaubt sind. Nach Änderungen an Skills `python scripts/setup_workspace.py --nur-skills` erneut ausführen.
+
+## 6. Von null zur ersten Aufgabe (etwa eine Stunde)
+
+1. Abschnitt 2 durcharbeiten; `python -m pytest -q .agents/skills` ist grün.
+2. Variante A oder B einrichten. Prüfung: der Agent nennt auf Nachfrage die Regeln aus `AGENTS.md`.
+3. `/hallo` ausführen — holt den Stand.
+4. Zum Kennenlernen einen kleinen, unkritischen Prozess modellieren lassen (Skill `sn-bpmn`), den Entwurf
+   prüfen, umwandeln und in PICTURE importieren.
+5. Für Änderungen am Repository: `python scripts/gitea.py tickets`, ein Ticket auswählen, in
+   `docs/status/STATUS.md` unter „Wer arbeitet woran" eintragen.
+6. Auftrag nach dem Muster in [`03_arbeitsweise.md`](03_arbeitsweise.md) Abschnitt 3 geben, mit dem Skill
+   `sn-aufgabe-bearbeiten`.
+7. Ergebnis prüfen: Tests grün, Diff gelesen.
+8. Branch pushen (selbst!), Pull Request im Gitea-Browser nach
+   [`docs/vorlagen/pull_request.md`](../vorlagen/pull_request.md), Übergabenotiz aus dem Skill `sn-uebergabe`.
+9. Review durch eine Kollegin oder einen Kollegen; nach dem Merge `STATUS.md` nachziehen.
+
+## 7. Prüfliste „Einrichtung fertig"
+
+- [ ] `git --version` und `python --version` (≥ 3.11) laufen, `python -m pytest --version` ohne Fehler
+- [ ] `git config user.email` im Ordner `AG_Prozesse` liefert die Adresse des Gitea-Kontos
+- [ ] `python scripts/setup_workspace.py` ohne Fehler, `.claude/skills/` vorhanden
+- [ ] `python -m pytest -q .agents/skills` grün
+- [ ] `python scripts/hallo.py` läuft und zeigt den Stand
+- [ ] `python scripts/gitea.py tickets` läuft
+- [ ] Claude Code im Ordner `AG_Prozesse` gestartet; `/context` zeigt `CLAUDE.md` und `AGENTS.md`
+- [ ] Gitea-Token gespeichert (Test: `git fetch` ohne Passwortabfrage)
+
+## Quellen
+
+- Claude Code: [VS-Code-Erweiterung](https://code.claude.com/docs/en/vs-code) ·
+  [Gedächtnis und CLAUDE.md](https://code.claude.com/docs/en/memory) ·
+  [Skills](https://code.claude.com/docs/en/skills) ·
+  [Einstellungen und Berechtigungen](https://code.claude.com/docs/en/settings)
+- [Agent-Skills-Standard](https://agentskills.io/home)
@@ -0,0 +1,150 @@
+# Git-Arbeitsweise — verbindlich für alle Repositories
+
+Stand 23.09.2026. Diese Regeln gelten für **jedes** Repository der Organisation `AG_Prozesse`, für Menschen und für
+KI-Agenten gleichermaßen. Die Kurzfassung für den Agenten steht in `AGENTS.md`; hier steht das Vollständige mit
+Begründung. Wer eine Abweichung braucht, macht ein Issue auf — nicht einfach einen Push.
+
+> **Die goldene Regel**
+>
+> Auf `main` wird nicht gearbeitet. `main` nimmt ausschließlich fertige Arbeit per Pull Request entgegen.
+> Gearbeitet wird in kurzlebigen Branches, die nach dem Merge gelöscht werden.
+>
+> **Und: Der Mensch drückt ab.** Agenten bereiten alles vor. Push, Merge und Tag macht eine Person mit ihrem
+> eigenen Zugang.
+
+## 1. Das Modell
+
+Es gibt genau einen dauerhaften Branch: **`main`**. Er ist immer der abgenommene Stand. Alles andere sind
+Arbeitsbranches, die von `main` abzweigen und per Pull Request zurückkommen (ADR 0002). Release-Kanäle wie in
+AG_QGIS gibt es hier nicht, weil nichts ausgeliefert wird.
+
+## 2. Der normale Weg
+
+```bash
+# 1. main aktualisieren (macht auch /hallo bzw. python scripts/hallo.py)
+git switch main
+git pull --ff-only
+
+# 2. Eigenen Branch abzweigen
+git switch -c feature/12-lane-beschriftung
+
+# 3. In kleinen Schritten arbeiten und committen
+git add .agents/skills/sn-bpmn/md_to_bpmn.py .agents/skills/sn-bpmn/test_md_to_bpmn.py
+git commit -m "Lane-Beschriftung bricht lange Rollennamen um (#12)"
+
+# 4. Prüfen
+python -m pytest -q .agents/skills
+python scripts/pruefe_umlaute.py
+
+# 5. Push — durch den Menschen, mit dessen Zugangsdaten
+git push -u origin feature/12-lane-beschriftung
+```
+
+Danach im Gitea-Browser einen **Pull Request nach `main`** öffnen, nach der Vorlage
+`docs/vorlagen/pull_request.md`, mit Übergabenotiz (Skill `sn-uebergabe`).
+
+Ein Pull Request sollte an einem Tag entstehen und in einer Viertelstunde reviewbar sein. Mehr als etwa
+400 geänderte Zeilen heißt: das Issue war zu groß.
+
+## 3. Branch-Namen
+
+| Präfix | Beispiel | Wofür |
+|---|---|---|
+| `feature/` | `feature/12-lane-beschriftung` | neue Funktion, neues Prozessmodell |
+| `bugfix/` | `bugfix/15-gateway-kanten` | Fehlerbehebung |
+| `doku/` | `doku/glossar-bpmn` | nur Dokumentation, ohne Issue zulässig |
+
+**Regeln für den Namen:** Kleinbuchstaben, ASCII, Bindestriche statt Leerzeichen. Keine Umlaute, kein `ß`, keine
+Punkte. Issue-Nummer direkt nach dem Präfix, damit Gitea den Branch dem Ticket zuordnet.
+
+## 4. Commit-Nachrichten
+
+Deutsch, Präsens, erste Zeile höchstens 72 Zeichen, Issue-Nummer am Ende in Klammern.
+
+```
+Lane-Beschriftung bricht lange Rollennamen um (#12)
+
+PICTURE schneidet Lane-Titel über 30 Zeichen ab. Der Konverter bricht
+jetzt an Wortgrenzen um; kurze Namen bleiben einzeilig.
+```
+
+Was die Nachricht beantworten muss: **was** ändert sich und **warum**. Das *Wie* steht im Diff.
+Nicht brauchbar: „Fix", „Update", „Änderungen", „wip".
+
+## 5. Sitzungsbeginn
+
+Vor dem ersten Handgriff — auch wenn es „nur schnell etwas" ist:
+
+```bash
+python scripts/hallo.py        # oder in Claude Code: /hallo
+```
+
+Das holt den Stand vom Server (`git fetch`), aktualisiert `main` per Fast-Forward, wo das gefahrlos möglich ist,
+und meldet alles Übrige, ohne es anzufassen. Es merged nicht, es stasht nicht, und es fasst keine ungesicherten
+Änderungen an.
+
+## 6. Was der Agent darf und was nicht
+
+| Der Agent darf | Der Agent darf nicht |
+|---|---|
+| `git fetch`, `git pull --ff-only`, `git status`, `git log`, `git diff` | `git push` in jeder Form |
+| lokale Branches anlegen und wechseln | `git merge`, `git rebase` |
+| `git add`, `git commit` auf einem Arbeitsbranch | `git tag` |
+| Tests laufen lassen, BPMN-Dateien erzeugen | Pull Requests mergen |
+| Issue- und PR-Texte als Entwurf vorbereiten | `git reset --hard`, `git push --force`, `git clean` |
+| Tickets über `scripts/gitea.py` lesen | irgendetwas auf dem Gitea-Server verändern |
+
+Das ist nicht nur eine Bitte. `.claude/settings.json` im Repo verbietet die entsprechenden Kommandos technisch;
+der Agent bekommt eine Ablehnung statt einer Ausführung. Wer die Regel für einen Einzelfall aussetzen will, tut
+das bewusst und lokal, nicht im Repo.
+
+**Warum so streng:** Ein Push trägt den Namen einer Person und ihre Verantwortung. Ein Agent kann fachlich nicht
+beurteilen, ob ein Prozessmodell abgenommen ist — und ein versehentlicher Push auf `main` trifft sofort alle
+anderen Behörden.
+
+## 7. Branch-Schutz auf Gitea einrichten (Maintainer)
+
+Je Repository unter **Einstellungen → Branches** (englisch: *Settings → Branches*) eine Branch-Schutzregel für
+`main` anlegen:
+
+| Einstellung | Wert | Wirkung |
+|---|---|---|
+| Branch-Name | `main` | betrifft genau diesen Branch |
+| Push deaktivieren | an | kein direkter Push, nur Merge über Pull Request |
+| Merge-Freigabe erforderlich | mindestens 1 | Review durch eine andere Person ist Pflicht |
+| Veraltete Freigaben verwerfen | an | ein neuer Push macht das Review ungültig |
+
+**Ausnahme beim Anlegen:** Der allererste Stand eines neuen Repositorys wird direkt nach `main` gepusht, weil es
+vorher nichts gibt, wogegen ein Pull Request laufen könnte. Die Schutzregel danach setzen.
+
+## 8. Aufräumen
+
+Nach dem Merge wird der Arbeitsbranch gelöscht — in Gitea per Schaltfläche direkt am gemergten Pull Request,
+lokal so:
+
+```bash
+git switch main
+git pull --ff-only
+git branch -d feature/12-lane-beschriftung
+git fetch --prune
+```
+
+## 9. Häufige Fehler
+
+**„Ich habe direkt auf `main` committet."** Solange nichts gepusht ist, ist das reparabel:
+`git switch -c feature/<nr>-<name>` legt einen Branch auf dem aktuellen Stand an, danach
+`git switch main && git reset --hard origin/main`. Der `reset` ist hier zulässig, weil er nur die lokale
+Kopie auf den Serverstand zurücksetzt — trotzdem vorher `git log` prüfen.
+
+**„Mein Branch ist hinter `main`."** Vor dem Pull Request aktualisieren:
+`git switch main && git pull --ff-only`, dann zurück auf den Arbeitsbranch und `git merge main`.
+Kein `rebase` auf bereits gepushten Branches — das schreibt Historie um, die andere schon haben.
+
+**„`git pull` will einen Merge-Commit machen."** Dann ist der lokale Branch vorausgelaufen. `--ff-only` bricht
+in dem Fall bewusst ab. Erst klären, was die eigenen Commits sind, statt blind zu mergen.
+
+## Siehe auch
+
+- `AGENTS.md` — Kurzfassung der harten Regeln
+- `docs/leitfaden/03_arbeitsweise.md` — der Arbeitszyklus vom Issue bis zum Merge
+- `docs/entscheidungen/0002-branchmodell-main.md` — warum das Modell so aussieht
@@ -0,0 +1,34 @@
+# Status des Projekts
+
+Kurz und aktuell. Wird bei jedem Merge und jeder Übergabe gepflegt (Skill `sn-uebergabe`). Älteres wandert nach unten
+in „Erledigt" oder wird gelöscht. **Stand: 23.09.2026.**
+
+## Aktuelle Phase
+
+**Aufbau.** Das Repository wurde aus `AG_QGIS/Projektwissen` abgeleitet (ADR 0001): Arbeitsweise, Skripte und
+Skills sind übernommen, alles QGIS- und Plugin-Spezifische ist entfernt. Kern ist der Skill `sn-bpmn`
+(Prozessbeschreibung → BPMN 2.0 für PICTURE), übernommen vom Branch `BPMN-Skill` in AG_QGIS.
+
+## Wer arbeitet woran
+
+| Person / Behörde | Schwerpunkt | Stand |
+|---|---|---|
+| Daniel Helbig (LK Meißen) | Aufbau des Repositorys, Skill `sn-bpmn` | aktiv |
+
+## Offene Baustellen (priorisiert)
+
+1. **Ersten Stand auf Gitea bringen** (`main`) und Branch-Schutz für `main` setzen (nur per Pull Request).
+2. **Ablageort für abgenommene Prozessmodelle festlegen.** Entwürfe liegen unversioniert in `entwuerfe/`.
+   Vorschlag: `prozesse/<name>/<name>.md` plus `<name>.bpmn`, versioniert, Änderungen per Pull Request. → ADR.
+3. **Glossar um BPMN-/PICTURE-Begriffe ergänzen** und die Flurbereinigungsbegriffe auf das prüfen, was für
+   Prozesse gebraucht wird.
+4. **Leitfäden vom Team gegenlesen lassen.** `docs/leitfaden/03–05` sind für die Prozessarbeit neu gefasst;
+   die Beispiele (Issue #12 usw.) sind erfunden und durch echte zu ersetzen, sobald es sie gibt.
+5. **Umgang mit `sn-bpmn` in AG_QGIS klären.** Der Branch `BPMN-Skill` in `AG_QGIS/Projektwissen` ist durch dieses
+   Repository abgelöst und kann dort nach Absprache gelöscht werden.
+
+## Erledigt
+
+- 23.09.2026 **Repository aus AG_QGIS/Projektwissen abgeleitet** (Stand `decd2a0` bzw. `BPMN-Skill` @ `6efcac4`),
+  ohne Historie. Skripte auf die Organisation `AG_Prozesse` umgestellt, Hauptbranch `main`, Test über `pytest`
+  (32 Tests grün), `pruefe_umlaute.py` prüft jetzt den Workspace selbst.
@@ -0,0 +1,14 @@
+# <Repo-Name>
+
+Teil des Projektwissens der AG Prozesse. Übergeordnete Regeln, Fallstricke und Skills liegen im Workspace:
+`../AGENTS.md` und `../docs/` (wenn dieses Repo als Unterordner des Workspace geklont ist).
+Einzelklon? Projektwissen holen: https://entwicklung.flurneuordnung-sachsen.de/AG_Prozesse/Projektwissen
+
+## Rolle
+<Ein bis drei Sätze: Was liegt in diesem Repository, wer nutzt es.>
+
+## Aufbau
+<Ordner mit Einzeiler; große Dateien (> 600 Zeilen) mit Zeilenzahl nennen.>
+
+## Zusätzliche Regeln
+<Nur, was über den Workspace hinausgeht.>
@@ -0,0 +1,3 @@
+@AGENTS.md
+
+Beim Arbeiten im Workspace (`../AGENTS.md` vorhanden) gelten dessen Regeln und Skills zusätzlich.
@@ -0,0 +1,18 @@
+## Ziel
+<Was soll am Ende möglich sein? Ein Satz aus Nutzersicht.>
+
+## Betroffen
+Bereich: Prozessmodell | Konverter `md_to_bpmn.py` | Skill | Skripte | Doku
+Dateien (falls bekannt):
+
+## Fachlicher Hintergrund
+<Begriffe, Regeln, Beispiel (keine echten Verfahrensdaten, keine Namen). Verweise auf Glossar.>
+
+## Abnahmekriterien
+- [ ] <beobachtbares Verhalten 1>
+- [ ] <beobachtbares Verhalten 2>
+- [ ] Bei Änderungen am Konverter: Test vorhanden, `python -m pytest -q .agents/skills` grün
+- [ ] PICTURE-Import: <nötig / nicht nötig>
+
+## Nicht Teil dieses Issues
+<Abgrenzung, damit der Agent nicht abschweift.>
@@ -0,0 +1,16 @@
+## Was
+<Zwei Sätze. Issue: #…>
+
+## Wie geprüft
+- `python -m pytest -q .agents/skills`: <Ergebniszeile>
+- `python scripts/pruefe_umlaute.py`: <Ergebniszeile>
+- PICTURE-Import: <PICTURE-Version, Datei, Ergebnis> | nicht nötig, weil …
+
+## Übergabenotiz
+<nach docs/vorlagen/uebergabe.md>
+
+## Checkliste
+- [ ] Nur Änderungen zum Issue
+- [ ] Keine personenbezogenen Daten, keine internen Originalunterlagen
+- [ ] Doku des Skills nachgezogen (Anleitung, Elementkatalog, Modellierregeln) oder nicht betroffen
+- [ ] Wissensbasis nachgezogen (oder „nichts Neues“)
@@ -0,0 +1,10 @@
+## Übergabenotiz
+
+**Aufgabe:** <Issue-Link und Ziel in einem Satz>
+**Stand:** fertig | in Arbeit | blockiert – <wo genau>
+**Geändert:** <Dateien mit Kurzgrund, keine Diffs>
+**Nachweis:** `pytest`: <Ergebniszeile>; PICTURE-Import: <was, womit, Ergebnis | nicht nötig, weil …>
+**Entscheidungen/Annahmen:** <fachliche Annahmen, die jemand bestätigen sollte>
+**Offen / nächste Schritte:** <konkret, in Reihenfolge>
+**Wissensbasis:** <Einträge in fallstricke/glossar/STATUS | „nichts Neues“>
+**Kontext für die nächste Sitzung:** <die zwei bis drei Dateien/Abschnitte, mit denen es weitergeht>
@@ -0,0 +1,50 @@
+# Fallstricke und Erkenntnisse
+
+Gemeinsames Gedächtnis: Dinge, die man **nicht aus dem Code ablesen kann** und die schon einmal Zeit gekostet haben.
+Kurz, konkret, mit Datum und Quelle. Neue Einträge oben in der passenden Rubrik. Veraltetes löschen, nicht auskommentieren.
+
+## BPMN und PICTURE (Skill sn-bpmn, md_to_bpmn.py)
+
+- **Ein Gateway hat in PICTURE nur vier feste Anschlusspunkte (N/O/S/W auf der Rautenkontur), keinen
+  variablen Rand wie ein Rechteck.** Eine Kante, die diesen Punkt verlässt bzw. dort ankommt, darf sich
+  danach **nicht** direkt zur Ziel-/Quellkoordinate drehen, wenn diese auf der anderen Achse liegt – sonst
+  läuft der rechtwinklige Streckenzug quer durchs Innere der Raute zurück, statt außen herumzugehen
+  (`orthogonal_points()` in `md_to_bpmn.py`, behoben BPMN-Skill 21.09.2026). Ursache: die feste
+  Anschlusspunkt-Zuteilung (`assign_gateway_sides()`, Präferenzreihenfolge S/O/W/N bzw. N/W/O/S) kennt die
+  tatsächliche Lage des anderen Endes nicht. Die Kante muss beim Verlassen/Ankommen an einer Raute zuerst
+  ein Stück auf der sicheren Stub-Achse bleiben (die einzige garantiert freie Koordinate außerhalb der
+  Kontur), bevor sie zur anderen Achse abbiegt – sonst reicht ein einfacher Bounding-Box-Test nicht, um den
+  Fehler zu erkennen (ein Punkt auf der Rautenkontur liegt immer innerhalb der Bounding-Box). Prüfen mit
+  echter Diamant-Geometrie (Manhattan-Abstand zum Mittelpunkt, skaliert auf die Halbachsen, < 1 heißt innen),
+  nicht mit der Bounding-Box – siehe `test_kante_fuehrt_nicht_durchs_innere_eines_gateways` in
+  `test_md_to_bpmn.py`.
+
+## Text und Sprache
+
+- **Deutscher Text ohne Umlaute/ß ist ein eigenständiges Muster, kein Einzelfall.** KI-generierter Text weicht
+  gern auf ASCII aus (`gueltig` statt `gültig`, `ueber` statt `über`) – in AG_QGIS über alle Plugins verteilt
+  gefunden (Plugin_SN_Basis #42), im BPMN-Skill in Elementnamen und Docstrings. Neuen deutschen Text
+  (Beschriftungen im Modell, Kommentare, Docstrings) immer mit echten Umlauten/ß schreiben. Vor dem Commit
+  `python scripts/pruefe_umlaute.py` laufen lassen – findet das Muster in `.py`-Dateien (String-Inhalte und
+  Kommentare mit Leerzeichen). Die Wortstammliste ist bewusst konservativ; Ersatz fürs Lesen ist sie nicht.
+  Arbeitsschritt-`.md` prüft das Skript nicht. (AG_QGIS 09/2026)
+
+## Umgebung und Werkzeuge
+
+- **Gitea ordnet Commits über die E-Mail-Adresse zu.** Stimmt `user.email` nicht mit einer im Gitea-Konto
+  hinterlegten Adresse überein, erscheinen die Commits ohne Zuordnung zum Benutzer. Es gilt die dienstliche
+  Adresse, die im Gitea-Konto hinterlegt ist. Wer den Rechner auch privat nutzt, setzt sie je Repository mit
+  `git config --local` statt global. Nachträglich nur durch Umschreiben der Historie korrigierbar. (AG_QGIS 04.09.2026)
+- **`pytest` ist die einzige Abhängigkeit außerhalb der Standardbibliothek.** Die Tests des Konverters brauchen
+  es; `md_to_bpmn.py` selbst läuft ohne. (23.09.2026)
+- **`.vscode/` gehört nicht ins Repository.** Einstellungen mit Pfaden eines einzelnen Arbeitsplatzes gehören in
+  die Benutzereinstellungen, siehe `docs/leitfaden/04_werkzeuge_einrichten.md`. (AG_QGIS 04.09.2026)
+
+## Zusammenarbeit
+
+- **Tool-Gedächtnis ist lokal.** Die Claude-Auto-Memory sieht niemand sonst. Geteiltes Wissen nur in diesem Ordner.
+- **Issues sind teils Diskussionen**, nicht Aufträge (Label `Diskussion`). Vor der Umsetzung Konsens im Issue
+  abwarten oder im PR als Annahme kennzeichnen.
+- **Quelldokumente enthalten oft Interna.** Word/PDF-Prozessbeschreibungen nur lokal unter `referenz/` ablegen
+  (nicht versioniert). Vor dem Committen eines Arbeitsschritt-Entwurfs prüfen, dass keine Namen, Aktenzeichen
+  oder Verfahrensdaten darin stehen. (23.09.2026)
@@ -0,0 +1,41 @@
+# Glossar
+
+Fachbegriffe und Abkürzungen, die in Prozessmodellen, Issues und Gesprächen vorkommen. Ergänzen, wenn ein Begriff
+im Issue erklärt werden musste.
+
+## Flurbereinigung
+
+| Begriff | Bedeutung |
+|---|---|
+| **LNO** | Ländliche Neuordnung; Sammelbegriff für Flurbereinigungsverfahren in Sachsen |
+| **FlurbG** | Flurbereinigungsgesetz. § 38: Vorarbeiten und gemeinschaftliche Anlagen; § 41: Wege- und Gewässerplan mit landschaftspflegerischem Begleitplan |
+| **Plan 41** | Wege- und Gewässerplan nach § 41 FlurbG |
+| **Verfahren** | Ein Flurbereinigungsverfahren; identifiziert über die **VKZ** |
+| **VKZ / Verfahrensnummer** | Verfahrenskennzahl (sechsstellig) |
+| **Verfahrensgebiet** | Flächenumring des Verfahrens |
+| **Neuordnungsgebiet / Neuvermessungsgebiet** | Gebiet der Bodenordnung bzw. Gebiet, in dem Grenzen neu vermessen werden |
+| **Beteiligung** | Welche Flurstücke und Eigentümer an einem Verfahren beteiligt sind |
+| **ALKIS** | Amtliches Liegenschaftskatasterinformationssystem |
+| **Gemarkung / Flurstück** | Katasterbezirk bzw. Katasterparzelle |
+| **NoBIS** | Fachverfahren der Flurbereinigung (Neuordnungs-Bodenordnungs-Informationssystem) |
+| **BI-Server** | Berichtssystem, aus dem Auswertungen zu Verfahren und Beteiligten kommen |
+
+## Prozessmodellierung
+
+| Begriff | Bedeutung |
+|---|---|
+| **BPMN 2.0** | Business Process Model and Notation, offener OMG-Standard für Prozessdiagramme; Austauschformat `.bpmn` (XML) |
+| **PICTURE** | Prozessmanagement-Werkzeug der Verwaltung; Ziel des BPMN-Imports |
+| **Arbeitsschritt-`.md`** | Strukturierte Markdown-Beschreibung eines Prozesses, Eingabe für `md_to_bpmn.py`; Syntax in `.agents/skills/sn-bpmn/Anleitung.md` |
+| **Task / Aufgabe** | Ein Arbeitsschritt im Modell |
+| **Gateway** | Verzweigung oder Zusammenführung (Raute); XOR = genau ein Weg, AND = alle Wege |
+| **Lane / Swimlane** | Bahn für eine verantwortliche Rolle; entsteht aus den Verantwortlichen der Arbeitsschritte |
+| **Start- / Endereignis** | Anfang bzw. Ende des Prozesses |
+| **Elementkatalog** | Liste der von PICTURE unterstützten BPMN-Elemente, `.agents/skills/sn-bpmn/Elementkatalog.md` |
+
+## Organisation
+
+| Begriff | Bedeutung |
+|---|---|
+| **AG Prozesse** | Arbeitsgruppe Prozesse der sächsischen Flurbereinigungsbehörden; Gitea-Organisation `AG_Prozesse` |
+| **AG QGIS** | Schwestergruppe für die QGIS-Plugins; Gitea-Organisation `AG_QGIS`, Herkunft der Arbeitsweise (ADR 0001) |