- ADR 0004 ersetzt ADR 0003: Die Prozessmodelle liegen im Repository AG_Prozesse/Prozessbibliothek, geklont nach Prozessbibliothek/ (neuer Eintrag in workspace.toml, .gitignore). prozesse/ ist entfernt; das Ablageformat (Ordner je Prozess, drei Dateien, Status) bleibt. - pruefe_prozesse.py prüft den Klon (Ort über setup_workspace.repos_root), lässt Punkt-Ordner wie .git aus und erlaubt in der Wurzel nur die Repo-Dateien. Fehlt der Klon, gibt es einen Hinweis statt eines Befunds; pytest warnt dann. - einlesen.py sucht den Bestand in der Bibliothek und nennt Treffer als Prozessbibliothek/<name>/, auch wenn der Klon woanders liegt. - Regeln aus prozesse/README.md nach docs/leitfaden/08_prozessbibliothek.md, inklusive Ablauf bei Konverteränderungen (zwei Pull Requests). - Verweise in AGENTS.md, README, Skills, Leitfäden, Vorlagen, Fallstricken und STATUS nachgezogen. - Tests: python -m pytest -q -> 88 bestanden, 1 xfail (#8), 1 Warnung (Bibliothek noch nicht geklont). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
3.8 KiB
3.8 KiB
name, description
| name | description |
|---|---|
| sn-aufgabe-bearbeiten | Standardablauf für eine Aufgabe im Projektwissen der AG Prozesse (Konverter md_to_bpmn.py, Skills, Skripte, Doku, Prozessmodelle) von Gitea-Issue über Branch, Umsetzung und Tests bis zum vorbereiteten Pull Request mit Übergabenotiz. Verwenden bei "bearbeite Issue", "setze um", "Bugfix", "neue Funktion". |
Aufgabe bearbeiten
Für das reine Modellieren eines Prozesses gilt der Skill sn-bpmn. Dieser Ablauf gilt, wenn etwas im Repository
geändert und per Pull Request zurückgeführt wird.
0. Stand holen (nicht überspringen)
python scripts/hallo.py
Holt den Serverstand und aktualisiert main per Fast-Forward, wo das gefahrlos geht.
Ohne diesen Schritt wird womöglich etwas behoben, das längst behoben ist.
1. Auftrag verstehen (nicht überspringen)
- Issue mit Kommentaren lesen – Skill
sn-ticket,python scripts/gitea.py ticket Projektwissen <nr>. LabelDiskussion= noch kein Konsens: Annahmen im PR kennzeichnen. - Ziel, Abnahmekriterien und Grenzen in drei Sätzen zurückspiegeln, bevor etwas geändert wird. Fehlt ein Abnahmekriterium, ist das die erste Rückfrage – nicht der erste Commit.
2. Kontext laden – gezielt
docs/status/STATUS.md(wer arbeitet woran), bei Überraschungendocs/wissen/fallstricke.md.- Am Konverter:
grep -n "def \|class " .agents/skills/sn-bpmn/md_to_bpmn.pyfür die Struktur, dann nur die betroffenen Abschnitte lesen. Die Datei hat über 1000 Zeilen. - Fachliche Regeln:
.agents/skills/sn-bpmn/Modellierregeln.md,Elementkatalog.md,Anleitung.md.
3. Branch
Immer von main. Vollständig: docs/leitfaden/05_git_arbeitsweise.md.
Kein feature/- oder bugfix/-Branch ohne Issue-Nummer. Gibt es kein Issue, zuerst einen Entwurf vorbereiten
(Skill sn-ticket) und warten, bis der Mensch es angelegt hat. Nur doku/… kommt ohne Issue aus.
git switch main && git pull --ff-only
git switch -c feature/<issue-nr>-<kurzname> # oder bugfix/… ; klein, ASCII, mit Nummer
4. Umsetzen
- Kleine Schritte, jeder für sich prüfbar. Nach jedem Schritt
python -m pytest -q. - Regeln aus
AGENTS.md: nur Standardbibliothek, kein Umbau nebenbei, Stil der Datei beibehalten, Deutsch mit echten Umlauten. - Neue Logik bekommt einen Test – Konverter in
.agents/skills/sn-bpmn/test_md_to_bpmn.py, Skripte intests/test_<skript>.py. pytest, ohne Netzwerk, ein Test je Verhalten. Bei einem Bugfix zuerst den Test schreiben, der den Fehler zeigt. - Jeder neue oder geänderte Test bekommt einen deutschen Docstring, erste Zeile
"""Prüft, dass …""". - Ändert sich die Markdown-Syntax oder ein Element:
Anleitung.mdbzw.Elementkatalog.mdmitziehen. Syntax und Ablageformat sind Verträge (AGENTS.md): vorher alle Modelle der Prozessbibliothek prüfen, danachpython scripts/pruefe_prozesse.py --erzeugenund die neu erzeugten.bpmnals eigenen Pull Request in der Bibliothek vorbereiten (docs/leitfaden/08_prozessbibliothek.md, „Wenn sich der Konverter ändert“).
5. Nachweis
python -m pytest -q→ alles grün.python scripts/pruefe_umlaute.py→ keine Funde.- Ändert sich die erzeugte BPMN-Datei: ein Beispiel erzeugen und in PICTURE importieren. Kannst du das nicht selbst, im PR als offenen Punkt eintragen. Nicht als erledigt ausgeben.
6. Abschluss
- Commit-Nachrichten deutsch, Präsens, erste Zeile ≤ 72 Zeichen, Issue-Nummer am Ende.
- Pull-Request-Text vollständig nach
docs/vorlagen/pull_request.mdvorbereiten: jeder Abschnitt, auch „Änderungen an Syntax und Ablageformat“ (notfalls „keine“) und die Checkliste mit ehrlich gesetzten Haken. Übergabenotiz mit Skillsn-uebergabe. - Hier ist Schluss. Push, Pull Request, Merge und alles auf Gitea macht der Mensch.