ai-workflows — KI-Pipelines als YAML, nicht als Custom-Code.
Mehrstufige KI-Operationen als deklarative YAML-Pipelines: Steps, Bedingungen, Blocking/Resume, Expression-Resolution und pluggable Notifiers. Die Engine für alles, was nicht in eine einzelne Prompt passt — und nicht im Custom-PHP-Code verschwinden soll.
Mehrstufige KI-Logik landet sonst verteilt im Code.
Mit ai-workflows
- Workflow als YAML-Datei — versionierbar, reviewbar, kopierbar
- Blocking-Steps für Human-in-the-Loop, sauber wiederaufnehmbar
- Expression-Resolution für Inputs/Outputs zwischen Steps
- Eigene Step-Typen registrierbar (extensible Step-Architektur)
- Pluggable Notifiers (Slack/E-Mail/Webhooks)
- DDD-Architektur mit deptrac-Enforcement
Bisher
- KI-Multi-Step-Logik verteilt sich auf mehrere Custom-Klassen
- Pausen/Reviews als Hand-Hack mit Status-Feldern
- Keine Wiederverwendbarkeit zwischen Use Cases
- Kein zentrales Tracing, keine Pipeline-Sicht
Vier Bausteine
Pluggable Notifiers
Eigene Notification-Provider (Slack, Teams, E-Mail, Webhook) über Interface registrierbar — zentrales Notify-Layer für alle Workflows.
Expression-Resolution
Outputs eines Steps stehen für nachfolgende Steps via Expression-Syntax zur Verfügung. Verzweigungen und Bedingungen ohne PHP-Code.
Blocking/Resume
Workflows können pausieren — z.B. für menschliche Freigabe — und sauber wiederaufgenommen werden, ohne State zu verlieren.
YAML-Workflows
Workflows als deklarative YAML-Files. Jeder Step hat einen Typ, Input/Output-Definition und optionale Bedingungen.
Architektur
Classes/
├── Domain/ # Value-Objects, Enums, Contracts (Interfaces)
├── Application/ # Orchestrierungs-Services
├── Infrastructure/ # Steps, Adapter, Persistenz
└── Presentation/ # Controller, Event-Listener
Layer-Abhängigkeiten werden über deptrac erzwungen — Domain hat null externe Abhängigkeiten, Application hängt nur an Domain, Infrastructure und Presentation dürfen Framework-Klassen verwenden.
Extension Points
- Interface in
Domain/Contract/definieren - Implementierung in
Infrastructure/anlegen - Auto-Discovery über
_instanceof-Tags in derServices.yaml
Konfiguration & Abhängigkeiten
Workflows werden als YAML-Dateien definiert und über das TYPO3-Konfigurationssystem registriert. Jeder Workflow besteht aus geordneten Steps mit optionalen Bedingungen und Expressions.
Abhängigkeiten
| Paket | Typ | Zweck |
|---|---|---|
symfony/yaml | Required | YAML-Workflow-Parsing |
koh/content-intelligence | Optional | Anbindung Content-Quality-Analyse |
koh/semantic-delivery | Optional | Anbindung Multi-Channel-Delivery |
koh/dev | Dev | Geteiltes QA-Tooling |
Quellcode & Doku
Mirror
Entwickelt wird auf einer eigenen GitLab-Instanz. GitHub ist der öffentliche Spiegel: Jede Version erscheint dort mit ihrem Tag, Packagist liest sie von dort.
Erster Workflow zusammen aufsetzen?
ai-workflows ist Open Source. Wenn du den ersten produktiven Workflow gemeinsam mit mir aufsetzen willst — inklusive Step-Typen, Notifier-Anbindung und Eval-Setup — sprich mich an.
Oder direkt schreiben: mail@ole-hartwig.eu