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>

.agents/skills/sn-bpmn/Modellierregeln.md

@@ -0,0 +1,73 @@
+# BPMN-Modellierregeln
+
+Fachliche Regeln, an denen sich ein Entwurf (`entwuerfe/<name>.md`) und die
+daraus erzeugte BPMN-Datei messen lassen müssen – zusätzlich zur reinen
+Markdown-Syntax aus `Anleitung.md`. Beim Erzeugen und beim Prüfen eines
+Entwurfs (Schritt 2 in `SKILL.md`) gegen diese Liste abgleichen und
+Verstöße im Annahmen-/Hinweis-Abschnitt benennen. Welche Elemente es
+überhaupt gibt und wofür sie stehen, steht in `Elementkatalog.md`.
+
+1. **Verzweigungen laufen passend zusammen.** Verzweigte Pfade müssen in
+   einem Verzweigungselement (Gateway) zusammenlaufen, das zur Art der
+   Verzweigung passt, bevor der Pfad in den nächsten Arbeitsschritt nach
+   der Verzweigung mündet. Pfade nicht einfach ohne zusammenführendes
+   Gateway in denselben Folgeschritt münden lassen. Welcher Gateway-Typ
+   zusammenführt, hängt vom Split ab – und die drei Typen unterscheiden
+   sich fachlich, nicht nur formal:
+   - **XOR-Split** (genau ein Pfad wird genommen) → **XOR-Merge**
+     (Entweder-Oder-Zusammenführung): die ankommenden Pfade laufen
+     unabhängig voneinander einfach weiter, es wird auf nichts gewartet.
+   - **AND-Split** (alle Pfade parallel) → **AND-Merge** (Verschmelzung):
+     wartet, bis **alle** eingehenden Pfade angekommen sind, bevor es
+     weitergeht. Ein AND-Split ohne passenden AND-Merge am Ende der
+     parallelen Pfade führt zu mehrfach durchlaufenen Folgeschritten.
+   - **OR-Split** (ein oder mehrere Pfade) → **OR-Merge**
+     (Oder-Verschmelzung): wartet auf alle **aktiven** eingehenden Pfade,
+     nicht zwingend auf alle theoretisch möglichen.
+   - **Ereignisbasierte Verzweigung** ist ein Sonderfall: Sie darf nicht
+     spiegelbildlich als Zusammenführung genutzt werden, also nie mehr
+     als eine eingehende Kante haben (`md_to_bpmn.py` lehnt das ab).
+
+2. **Nachrichtenfluss nur zwischen Pools.** Ein Nachrichtenfluss verbindet
+   ausschließlich Elemente unterschiedlicher Pools (z. B. den eigenen
+   Prozess mit einem externen Beteiligten). Innerhalb desselben Pools
+   werden Informationsübergaben über den normalen Sequenzfluss
+   modelliert, nie über Nachrichtenfluss.
+
+3. **Datenobjekte, Datenspeicher und Gruppen sind keine Ablaufelemente.**
+   Sie hängen nicht am Sequenzfluss (kein `->` zu/von ihnen) und werden
+   sparsam eingesetzt – nur wenn der Sachverhalt (z. B. ein zentrales
+   Dokument oder eine geteilte Ablage) für das Verständnis des Prozesses
+   wirklich wichtig ist, nicht für jede beiläufig erwähnte Unterlage.
+
+4. **Jede Kante bekommt einen eigenen Anschlusspunkt.** Jeder Eingang und
+   jeder Ausgang an einem Element muss einen eigenen Verbindungspunkt am
+   Element nutzen, nicht denselben Punkt wie eine andere Kante. Laufen
+   mehrere Kanten sichtbar in einem einzigen Punkt zusammen, sieht das
+   Diagramm so aus, als wären mehrere fachlich getrennte Verzweigungen
+   eine einzige Linie – das verschleiert genau die Verzweigung, die
+   dargestellt werden soll. `md_to_bpmn.py` setzt das automatisch um, aber
+   je nach Elementtyp unterschiedlich:
+   - **Bei Task/Ereignis/Datenobjekt usw.** werden mehrere Punkte entlang
+     der tatsächlichen Kontur verteilt (Rechteckkante bzw. Kreisbogen).
+   - **Bei einem Gateway hat PICTURE nur vier feste Anschlusspunkte** – je
+     einen bei 0°/90°/180°/270° (Ost/Süd/West/Nord), die Kante verläuft
+     dort immer gerade. `md_to_bpmn.py` weist deshalb jeder Kante an einem
+     Gateway einen dieser vier Eckpunkte zu, nicht einen Punkt auf der
+     Rautenkante dazwischen. **Daraus folgt eine harte Obergrenze: ein
+     Gateway kann höchstens vier Kanten insgesamt (eingehend plus
+     ausgehend zusammengerechnet) eindeutig darstellen.** Ein XOR-Split
+     mit einer eingehenden Kante hat also nur für maximal drei ausgehende
+     Zweige Platz; bei vier oder mehr Zweigen muss mindestens eine Kante
+     sich einen Punkt mit einer anderen teilen – das ist eine Grenze von
+     PICTURE selbst, kein Darstellungsfehler von `md_to_bpmn.py`. Bei
+     einer Verzweigung mit vielen Zweigen und einer eingehenden Kante
+     lohnt sich daher, die Entscheidung in mehrere, weniger stark
+     verzweigte Gateways aufzuteilen, wenn jeder Zweig einzeln sichtbar
+     bleiben soll.
+
+   Wirkt ein Diagramm trotzdem so, als würden Verzweigungen an einem
+   Punkt zusammenlaufen, zuerst in einem originalgetreuen BPMN-Viewer
+   (z. B. `demo.bpmn.io`) prüfen, ob es an der erzeugten Datei liegt oder
+   tatsächlich an der Vier-Punkte-Grenze eines Gateways mit mehr als vier
+   Kanten.