- beispiele/referenz_gewannenfestlegung.md/.bpmn: aus dem ersten echten Einlese-Durchgang (input/Gewannenvermessung.md), als „Test“ markiert, fachlich nicht abgenommen. 4 Lanes, externer Pool, 14 Gateways, verschachtelte Varianten; Byte-Vergleich über pruefe_prozesse.py. - tests/test_referenzmodelle.py: je Referenzmodell keine Lane „Nicht zugeordnet“, höchstens vier Kanten je Gateway, keine Kante durch eine Raute (Geometrie aus test_md_to_bpmn.py übernommen). - Gefunden: Kante S12→S13 läuft durch die Raute von S13 – als xfail(strict=True) mit Verweis auf #8. AGENTS.md regelt, dass xfail nur für so erfasste Konverterfehler an Referenzmodellen zulässig ist. - Anleitung, Fallstricke (zwei Einträge), STATUS. - Tests: python -m pytest -q -> 82 bestanden, 1 xfail (#8). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
7.5 KiB
7.5 KiB
Projektwissen AG_Prozesse – Anweisungen für KI-Agenten und Mitwirkende
Kanonische, werkzeugneutrale Anweisungsdatei. Claude Code liest sie über CLAUDE.md.
Sie bleibt bewusst kurz: Details liegen in docs/ und werden nur bei Bedarf gelesen.
Worum es geht
- Arbeitsgruppe der sächsischen Flurbereinigungsbehörden („LNO Sachsen") zur Modellierung von Verwaltungsprozessen in BPMN 2.0. Zielwerkzeug für den Import ist PICTURE.
- Kernwerkzeug ist der Skill
sn-bpmn: Prozessbeschreibung (Rohtext, Stichpunkte, Word/PDF) → strukturierte Arbeitsschritt-.md→ BPMN-2.0-Datei (.agents/skills/sn-bpmn/md_to_bpmn.py). - Dieser Ordner ist der Klon des Repositories
AG_Prozesse/Projektwissen. Weitere Repositories der Gruppe würden als eigenständige Git-Klone in Unterordnern liegen und inworkspace.tomlstehen – derzeit gibt es keine. - Die Arbeitsweise (Skripte, Skills, Git-Regeln) stammt aus
AG_QGIS/Projektwissen, siehedocs/entscheidungen/0001-uebernahme-aus-ag-qgis.md.
Zuerst lesen – nur was die Aufgabe braucht
docs/status/STATUS.md– aktueller Stand, offene Baustellen, wer woran arbeitet.docs/wissen/fallstricke.md– bekannte Stolperfallen (BPMN-Layout, PICTURE-Import, Werkzeuge).- Für Modellierungsaufgaben:
.agents/skills/sn-bpmn/SKILL.mdund die dort genannten Dateien. - Fachbegriffe:
docs/wissen/glossar.md. Übersicht aller Dokumente:docs/README.md.
Harte Regeln
Git und Server – der Mensch drückt ab
- Nie pushen, mergen, taggen oder etwas auf Gitea verändern. Agenten bereiten vor, eine Person sendet ab.
.claude/settings.jsonsperrtgit push,git merge,git rebase,git tagtechnisch. - Hauptbranch ist
main. Nie direkt aufmaincommitten: eigener Branchfeature/<nr>-<kurzname>bzw.bugfix/<nr>-<kurzname>, dann Pull Request. Vollständig:docs/leitfaden/05_git_arbeitsweise.md. - Sitzungsbeginn:
python scripts/hallo.py(bzw./hallo), bevor irgendetwas geändert wird.
Tests
- Vor jedem Commit:
python -m pytest -q– alle Tests grün. - Neue Funktionalität ohne Test wird nicht gemergt – im Konverter wie in den Skripten. Mindestens ein Test je neuem beobachtbarem Verhalten, ohne Netzwerk. Bei einer Fehlerbehebung zuerst der Test, der den Fehler zeigt.
- Jeder neue oder geänderte Test bekommt einen deutschen Docstring, erste Zeile in der Form
"""Prüft, dass …""". - Tests werden nicht gelöscht, nicht mit
skipstillgelegt und nicht in ihrer Erwartung angepasst, um grün zu werden – außer das Verhalten wurde bewusst geändert und der Pull Request begründet es. - Einzige Ausnahme: ein bekannter, per Issue erfasster Konverterfehler an einem Referenzmodell
(
beispiele/referenz_*.md) darf alsxfail(strict=True)mit Issue-Nummer im Grund eingetragen werden (tests/test_referenzmodelle.py). Nie für Fehler, die die eigene Änderung verursacht. - Referenzmodelle unter
.agents/skills/sn-bpmn/beispiele/referenz_*.mdsind echte, größere Prozesse zum Testen von Konverteränderungen. Ändert sich deren.bpmn, im Pull Request mit Vorschau begründen.
Inhalte
- Keine personenbezogenen Daten, keine Zugangsdaten, keine internen Originalunterlagen im Repository, in der Doku
oder in Prompts. Quelldokumente (Word/PDF) bleiben lokal unter
referenz/(nicht versioniert); ins Repository kommen nur die daraus abgeleiteten, bereinigten Arbeitsschritt-.mdund BPMN-Dateien. Dasselbe gilt für den Eingangsordnerinput/(Skillsn-einlesen): Dateien dort nie löschen, verschieben oder umbenennen; einziger Eingriff ist der Einlese-Vermerk überscripts/einlesen.py. - Prozessmodelle liegen in
prozesse/<name>/(ADR 0003, Regeln inprozesse/README.md). Die.mdist maßgeblich, die.bpmnwird nie von Hand bearbeitet, sondern mitpython scripts/pruefe_prozesse.py --erzeugenneu erzeugt. Den Statusabgenommensetzt der Agent nie von sich aus. - Rollen und Verantwortliche in Prozessmodellen als Funktion benennen („Sachbearbeitung Flurbereinigung"), nie als Person.
- Keine Python-Abhängigkeiten außer der Standardbibliothek und
pytestohne Issue-Absprache und Eintrag infallstricke.md. Einzige eingebettete Fremdbibliothek ist bpmn-js unterwerkzeuge/vorschau/bpmn-js/– nicht von Hand ändern, Aktualisierung nachwerkzeuge/vorschau/README.md. - Die Markdown-Syntax und das Ablageformat unter
prozesse/sind Verträge. Wer sie ändert, prüft vorher alle Modelle unterprozesse/, ziehtAnleitung.mdbzw.prozesse/README.mdnach und nennt die Änderung im Pull Request unter „Änderungen an Syntax und Ablageformat“. - Kein Umbau „nebenbei". Strukturänderungen nur über eigenes Issue.
Allgemein
- Sprache: Doku, Kommentare, Docstrings, Commit-Nachrichten, Issues und PRs auf Deutsch, mit echten Umlauten
(Prüfung:
python scripts/pruefe_umlaute.py). Bezeichner nach dem Stil der jeweiligen Datei.
Arbeitsablauf in Kurzform (Details: Skill sn-aufgabe-bearbeiten)
python scripts/hallo.py– Stand holen.- Gitea-Issue lesen (Skill
sn-ticket,python scripts/gitea.py ticket Projektwissen <nr>) oder als Entwurf vorbereiten. Ziel und Abnahmekriterien klären, bevor etwas geändert wird. - Branch
feature/<issue-nr>-<kurzname>bzw.bugfix/<issue-nr>-<kurzname>vonmain. Ohne Issue kein solcher Branch: erst den Entwurf, dann legt der Mensch das Issue an (Ausnahme:doku/…). - In kleinen Schritten umsetzen; nur betroffene Dateien und Abschnitte lesen.
python -m pytest -q(enthältpruefe_prozesse.py) undpython scripts/pruefe_umlaute.py. Erzeugte BPMN-Dateien zusätzlich in PICTURE importieren und das Ergebnis im PR nennen.- Pull-Request-Text vollständig nach
docs/vorlagen/pull_request.mdvorbereiten – alle Abschnitte einschließlich Checkliste –, mit Übergabenotiz (Skillsn-uebergabe). Push und Pull Request macht der Mensch. - Neue Erkenntnisse in
docs/wissen/oderdocs/entscheidungen/festhalten, nicht nur im lokalen Gedächtnis des Werkzeugs.
Tokensparend arbeiten
- Gezielt
grep, dann nur die nötigen Abschnitte lesen.md_to_bpmn.py(über 1000 Zeilen) nie komplett laden. - Keine Dateien oder Testausgaben in den Chat kopieren; Pfade mit Zeilennummern nennen.
- Am Ende jeder Aufgabe eine Übergabenotiz, damit die nächste Sitzung nicht neu erkunden muss.
- Breite Suchen an einen Unteragenten delegieren, wenn das Werkzeug das kann; Hauptkontext schlank halten.
Befehle
- Sitzungsbeginn:
python scripts/hallo.py(Claude Code:/hallo) - Tickets:
python scripts/gitea.py tickets|python scripts/gitea.py ticket Projektwissen 12|… suche "<text>" - Tests:
python -m pytest -q - Umlaute prüfen:
python scripts/pruefe_umlaute.py - Prozessmodelle prüfen bzw. alle
.bpmnneu erzeugen:python scripts/pruefe_prozesse.py [--erzeugen] - Diagramm im Browser ansehen (offline):
python scripts/vorschau.py <datei.bpmn|datei.md> - Eingangsordner prüfen bzw. Einlese-Vermerk setzen:
python scripts/einlesen.py [--json]|python scripts/einlesen.py vermerk input/<datei>.md --ergebnis neu|aktualisiert --ziel <pfad> - Workspace einrichten oder aktualisieren:
python scripts/setup_workspace.py(mit--pullfür fast-forward) - Entwurf umwandeln:
python .agents/skills/sn-bpmn/md_to_bpmn.py entwuerfe/<name>.md entwuerfe/<name>.bpmn
Skills
Liegen in .agents/skills/ (Agent-Skills-Standard) und werden nach .claude/skills/ gespiegelt:
sn-bpmn, sn-einlesen, sn-aufgabe-bearbeiten, sn-ticket, sn-uebergabe.