Files
Projektwissen/docs/entscheidungen/0004-prozessbibliothek-eigenes-repo.md
T
DanielandClaude Opus 5.5 31131cc5c3 Prozessbibliothek als eigenes Repository auslagern (#9)
- 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>
2026-09-25 09:40:52 +02:00

3.0 KiB
Raw Blame History

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).