DanielandClaude Opus 5.5
31131cc5c3
- 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>
42 lines
3.0 KiB
Markdown
42 lines
3.0 KiB
Markdown
# 0004 – Prozessmodelle liegen im eigenen Repository `Prozessbibliothek`
|
||
|
||
Status: vorgeschlagen · Datum: 2026-09-25 · Beteiligte: AG Prozesse · Ersetzt: 0003
|
||
|
||
## Kontext
|
||
Nach ADR 0003 lagen die Prozessmodelle in `prozesse/` innerhalb von `Projektwissen`. Damit waren Fachdaten und
|
||
Werkzeuge verschränkt (Issue #9): Wer ein Modell ändert, arbeitet im selben Verlauf, in denselben Issues und
|
||
Pull Requests wie am Konverter, an den Skills und an der Doku. Fachleute, die nur Modelle pflegen, müssen sich
|
||
durch Werkzeug-Änderungen lesen, und die Abnahme eines Modells geht im Verlauf der Werkzeuge unter.
|
||
|
||
## Entscheidung
|
||
Die Prozessmodelle liegen im eigenen Repository `AG_Prozesse/Prozessbibliothek`, das als Klon neben
|
||
`Projektwissen` im Workspace liegt (`workspace.toml`, `scripts/setup_workspace.py`).
|
||
|
||
- **Aufbau:** ein Ordner je Prozess direkt in der Wurzel, `<name>/` mit genau drei Dateien: Steckbrief
|
||
`README.md`, Arbeitsschritt-Beschreibung `<name>.md`, daraus erzeugte `<name>.bpmn`. In der Wurzel sonst nur
|
||
`README.md`, `AGENTS.md`, `CLAUDE.md`, `.gitattributes` und `.gitignore`. Das Repository enthält keinen Code.
|
||
- **Die `.md` ist maßgeblich** und die `.bpmn` wird mitcommittet, damit sie ohne Python heruntergeladen und in
|
||
PICTURE importiert werden kann. Der Steckbrief trägt den Status `Entwurf` oder `abgenommen`. Die Abnahme ist ein
|
||
eigener Pull Request in der Bibliothek. Diese Punkte bleiben aus ADR 0003 unverändert.
|
||
- **Regeln, Vorlagen und Prüfung bleiben in `Projektwissen`:** Ablageregeln in
|
||
`docs/leitfaden/08_prozessbibliothek.md`, Steckbrief-Vorlage `docs/vorlagen/prozess_readme.md`, Prüfung mit
|
||
`scripts/pruefe_prozesse.py` (Byte-Vergleich, Ordnerstruktur, Status) gegen den Klon. So gibt es den Konverter
|
||
nur an einer Stelle, und Regel und Prüfung ändern sich im selben Pull Request.
|
||
- **Ist die Bibliothek nicht geklont**, ist das für die Prüfung kein Fehler: geprüft werden dann nur die
|
||
Skill-Beispiele, und `pruefe_prozesse.py` sowie `pytest` weisen deutlich darauf hin.
|
||
- Issues zu einzelnen Modellen gehören in die Bibliothek, Issues zu Konverter, Skills und Doku nach
|
||
`Projektwissen`.
|
||
|
||
## Folgen
|
||
Modelle haben einen eigenen, lesbaren Verlauf, eigene Issues und eigene Pull Requests. Eine Konverteränderung,
|
||
die die Ausgabe verändert, braucht jetzt **zwei Pull Requests**: den in `Projektwissen` und einen in der
|
||
Bibliothek mit den neu erzeugten `.bpmn` (`python scripts/pruefe_prozesse.py --erzeugen` schreibt in den Klon).
|
||
Beide werden gemeinsam gemergt, damit die Bibliothek zum Konverter auf `main` passt. Wer nur `Projektwissen`
|
||
geklont hat, prüft keine Modelle mit; `scripts/hallo.py` meldet den fehlenden Klon.
|
||
|
||
## Verworfene Alternativen
|
||
Weiter `prozesse/` in `Projektwissen` (die Verschränkung bliebe); Prozessordner unter `prozesse/` im neuen Repo
|
||
(doppelter Pfad ohne Nutzen); eigenes Prüfskript in der Bibliothek (bräuchte eine Kopie von `md_to_bpmn.py`, die
|
||
auseinanderlaufen kann); Git-Submodul (für die Zielgruppe zu fehleranfällig, der Workspace klont Repos bereits
|
||
nebeneinander).
|