DanielandClaude Opus 5.5
55c024dbc9
Jedes Modell bekommt einen eigenen Ordner mit Steckbrief (README.md, Status Entwurf|abgenommen), der maßgeblichen Arbeitsschritt-.md und der daraus erzeugten .bpmn (ADR 0003). - scripts/pruefe_prozesse.py prüft Ordnername, Dateien, Status und ob jede .bpmn byte-gleich mit der Umwandlung ihrer .md ist; --erzeugen erzeugt alle .bpmn neu. md_to_bpmn.py arbeitet deterministisch. - tests/test_pruefe_prozesse.py: Bestandsprüfung plus 11 Fälle für die Prüflogik; pytest.ini sammelt .agents/skills und tests. - Die in Anleitung.md genannten, nie committeten Beispiele liegen jetzt unter .agents/skills/sn-bpmn/beispiele/ und werden mitgeprüft. - Skill sn-bpmn: Entwürfe nach entwuerfe/, neuer Schritt 5 „Ablegen“. - Vorlage docs/vorlagen/prozess_readme.md, Doku und Fallstricke ergänzt. - Tests: python -m pytest -q -> 44 bestanden. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
34 lines
2.3 KiB
Markdown
34 lines
2.3 KiB
Markdown
# 0003 – Prozessmodelle liegen versioniert in `prozesse/<name>/`, die `.md` ist maßgeblich
|
||
|
||
Status: vorgeschlagen · Datum: 2026-09-23 · Beteiligte: AG Prozesse
|
||
|
||
## Kontext
|
||
Der Skill `sn-bpmn` legt Entwürfe in `entwuerfe/` ab; der Ordner ist nicht versioniert. Fertige Modelle hatten damit
|
||
keinen gemeinsamen Ort: Wer ein Modell ändern wollte, musste die letzte Fassung bei der Kollegin erfragen, und niemand
|
||
konnte nachvollziehen, welcher Stand abgenommen war. PICTURE ist Zielsystem des Imports, aber kein Ort für Review
|
||
und Versionsgeschichte.
|
||
|
||
## Entscheidung
|
||
Jedes Prozessmodell liegt in einem eigenen Ordner `prozesse/<name>/` mit genau drei Dateien: Steckbrief `README.md`,
|
||
Arbeitsschritt-Beschreibung `<name>.md` und die daraus erzeugte `<name>.bpmn`.
|
||
|
||
- Die **`.md` ist die maßgebliche Quelle**. Die `.bpmn` wird mit `python scripts/pruefe_prozesse.py --erzeugen`
|
||
erzeugt und mitcommittet, damit sie ohne Python aus Gitea heruntergeladen und in PICTURE importiert werden kann.
|
||
- Ein **Test prüft**, dass jede `.bpmn` byte-gleich mit der Umwandlung ihrer `.md` ist. Das geht, weil
|
||
`md_to_bpmn.py` deterministisch arbeitet (keine Zufalls-IDs, keine Zeitstempel).
|
||
- Der **Steckbrief** trägt den Status `Entwurf` oder `abgenommen`. Entwürfe dürfen auf `main`, damit mehrere
|
||
Personen daran arbeiten können; die Abnahme ist ein eigener Pull Request, der nur den Status ändert.
|
||
- Im Ordner liegen **keine weiteren Dateien**, insbesondere keine Originalunterlagen.
|
||
|
||
## Folgen
|
||
Modelle sind reviewbar (Diff der `.md` statt XML), versioniert und mit Status versehen. Eine Änderung am Konverter,
|
||
die die Ausgabe verändert, macht alle abgelegten `.bpmn` rot, bis sie neu erzeugt sind — gewollt: Der Pull Request
|
||
zeigt dann, welche Modelle sich im Bild ändern, und sie werden gemeinsam neu erzeugt. Nacharbeiten, die nur in
|
||
PICTURE gemacht werden (Layout, Zusatzfelder), gehen bei der nächsten Erzeugung verloren und gehören deshalb in die
|
||
`.md` oder in den Steckbrief.
|
||
|
||
## Verworfene Alternativen
|
||
Nur die `.md` versionieren (Fachleute ohne Python kämen nicht an die `.bpmn`); nur die `.bpmn` versionieren (XML ist
|
||
nicht reviewbar, die Quelle ginge verloren); Status in Kopfzeilen der `.md` (der Parser würde Zeilen wie
|
||
„Verantwortliche Stelle: …“ als Schritt deuten); Ablage nur in PICTURE (keine Versionsgeschichte, kein Review).
|