{
"event": "UserPromptSubmit",
"prompt": "supervision: 1. Faktischer Befund\nProblemdefinition ist korrekt\n\nWenn die DB in pipeline_steps.config als Single Source of Truth gedacht ist, dann ist jede Hardcodierung von Modellnamen in der Pipeline eine funktionale Umgehung dieser Quelle. Das führt deterministisch zu Deinem Symptom: GUI Änderung wirkt nicht.\n\nDie betroffenen Stellen sind logisch plausibel\n\nDie aufgelisteten Stellen sind genau die typischen Orte, an denen so etwas passiert: Pipeline Entry Points und Step Defaults. Besonders kritisch sind direkte Literal Übergaben wie {\"model\": \"mistral\"} in pipeline.py, weil sie jede Upstream Konfiguration aushebeln.\n\n2. Kritische Schwachstellen im SOLL Entwurf\n2.1 get_step_model ist aktuell nicht korrekt implementierbar ohne Zusatzannahmen\n\nDu verwendest from db import db und dann db.execute(...).\nOhne Klarheit, was db konkret ist, ist das nur ein Platzhalter. Für sauberes Design gilt:\n\nDie Pipeline muss eine definierte DB Zugriffsschicht nutzen.\n\nDiese Schicht muss in CLI Kontext funktionieren.\n\nFehlerverhalten muss konsistent sein.\n\nWenn es in Deinem Projekt bereits einen standardisierten DB Zugriff gibt, muss pipeline_config.py genau den verwenden. Sonst wird das Modul ein Fremdkörper.\n\n2.2 JSON Extraktion ist formal okay, aber unvollständig robust\n\nJSON_UNQUOTE(JSON_EXTRACT(config, '$.model')) liefert NULL, wenn config NULL ist oder wenn model fehlt. Das passt zu Deinem Exception Ansatz.\n\nWas fehlt:\n\nWas passiert, wenn config kein gültiges JSON ist.\n\nWas passiert, wenn model leerer String ist.\n\nWas passiert, wenn mehrere Zeilen matchen.\n\nDu brauchst deterministische Regeln:\n\nDu erwartest genau eine Zeile pro (pipeline_id, step_type).\n\nWenn mehr als eine existiert, ist das ein Datenfehler und muss explizit eskalieren.\n\n2.3 Pipeline ID Default ist eine harte Kopplung\n\npipeline_id: int = 5 ist faktisch eine neue Hardcodierung.\nWenn es wirklich immer Pipeline 5 ist, dann muss das als Konvention dokumentiert und zentral konfiguriert sein. Sonst wird es später wieder falsch.\n\nBesser:\n\nPipeline ID kommt als Parameter aus dem Aufrufkontext.\n\nOder sie kommt aus einer dedizierten Umgebungsvariable.\n\nOder es gibt eine Default Pipeline ID in der Datenbank, die als aktiv markiert ist.\n\n2.4 Schrittweise Konfig Übergabe muss konsistent sein\n\nDu willst, dass Steps kein stilles Fallback haben. Gleichzeitig muss die Pipeline dann garantiert überall model übergeben.\n\nDas ist korrekt, aber es ist eine Breaking Change innerhalb des Python Layers. Das ist nur dann risikolos, wenn Du alle Aufrufpfade kontrollierst. Du hast zwar die zentralen Pfade genannt, aber Du musst sicherstellen, dass es keine weiteren Call Sites gibt.\n\nKonsequenz:\n\nZusätzlich zum Hook brauchst Du einen Test, der alle Step Aufrufe scannt und sicherstellt, dass model immer in config enthalten ist.\n\n3. Bewertung nach Prinzipien\nDRY\n\nSehr gut. Du eliminierst doppelte Wahrheitsquellen.\nDie DB wird wieder Single Source of Truth.\n\nSRP und Clean Architecture\n\nGut, wenn pipeline_config.py wirklich nur Konfig liest und keine Pipeline Logik enthält.\nAktuell ist die Gefahr, dass es zu einem zweiten DB Access Layer wird, wenn db nicht standardisiert ist.\n\nKISS\n\nGut. Ein get_step_model ist die minimal ausreichende Abstraktion.\n\nYAGNI\n\nGut. Keine zusätzliche Feature Architektur. Kein Caching. Kein DI Framework.\n\nRobustheit\n\nDein Ansatz ist robust, wenn Du die Pipeline ID Kopplung sauber löst und Mehrfachzeilen als Fehler behandelst.\n\n4. Risikoprüfung\nRisiko “Pipeline Ausfall bei fehlendem Config”\n\nDeine Einstufung “mittel” ist korrekt.\nAber das Risiko ist gewollt, weil es Konfigfehler sichtbar macht.\n\nWichtig ist die betriebliche Folge:\n\nDer Fehler muss im PHP Aufrufer eindeutig sichtbar werden.\n\nDie Fehlermeldung muss maschinenlesbar sein, nicht nur Text.\n\nWenn der PHP Prozess nur “subprocess failed” sieht, ist das operativ schlecht.\n\nMinimalanforderung:\n\nException Text muss Step Type und Pipeline ID enthalten.\n\nExit Code muss ungleich 0 sein.\n\nOptional: Fehler als JSON an stderr.\n\nRisiko “Bestehende DB Config falsch”\n\nDeine Einstufung “niedrig” ist nur dann belastbar, wenn Du sicher weißt, dass die DB Einträge vorhanden und enabled sind. Im Dokument steht das als Tabelle, aber ohne Nachweis. Für Deine interne Umsetzung ist es ok, für externe Abnahme wäre ein DB Dump oder Screenshot erforderlich.\n\nRisiko “Breaking Change für CLI Scripts”\n\nEher mittel als niedrig, weil Standalone Scripts oft isoliert laufen und selten dieselben DB Konventionen haben. Du willst aber konsistent werden. Dann musst Du diese Scripts entweder vollständig an die DB anbinden oder sie klar als Dev Tools markieren und die Hardcodierung bewusst erlauben.\n\n5. Konkrete Korrekturen am Plan\n5.1 get_step_model muss deterministisch sein\n\nErgänze Regeln:\n\nErwartet genau eine Zeile.\n\nMehr als eine Zeile ist ein Datenfehler.\n\nenabled = 1 ist korrekt, aber dann muss die Pipeline bei disabled Steps nicht nach Model fragen.\n\nSQL sollte zusätzlich sicherstellen, dass nur eine Zeile kommt. Beispiel: LIMIT 1 plus Unique Constraint auf (pipeline_id, step_type) wäre besser. Wenn kein Unique Constraint existiert, ist das ein strukturelles Risiko.\n\n5.2 Pipeline ID darf nicht als Default Literal im Code stehen\n\nEntweder:\n\npipeline_id wird beim Pipeline Start bestimmt und an get_step_model übergeben.\nOder:\n\nPIPELINE_ID kommt aus Env.\nOder:\n\nDB hat eine active Pipeline.\n\n5.3 Tests erweitern\n\nDein Testplan ist zu schmal. Ergänze:\n\nTest, der sicherstellt, dass pipeline.py nirgendwo Literal Modelle enthält.\n\nTest, der sicherstellt, dass jeder Step Call ein model erhält.\n\nIntegration Test, der Step Type Mapping prüft. Ein Tippfehler in step_type ist sonst ein sofortiger Ausfall.\n\n6. Antworten auf die drei Supervisor Fragen\n1. Exception oder Fallback mit Warning\n\nFür die zentrale Pipeline: Exception ist korrekt.\nBegründung: Silent Fallback ist genau der Fehler, den Du eliminieren willst. Ein Warning bringt Dir im Betrieb nichts, wenn trotzdem das falsche Modell läuft.\n\nEinzige Ausnahme: Ein expliziter Dev Modus, der klar markiert ist und nicht produktiv aktiv sein darf. Wenn Du so etwas nicht brauchst, dann lasse es weg.\n\n2. Standalone Scripts ebenfalls umstellen\n\nJa, wenn sie produktiv oder wiederholt genutzt werden.\nWenn es reine Einmal Tools sind, dann musst Du sie entweder:\n\nklar als Dev Utility deklarieren und Hardcoding bewusst erlauben,\noder:\n\nkonsistent an dieselbe DB Konfiguration anbinden.\n\nDas Schlechteste wäre ein Mischzustand ohne klare Entscheidung.\n\n3. Gewünschtes Default Model für DB Update\n\nKein Default Model durch Supervisor Entscheidung.\nDie DB ist die Wahrheit. Das Modell pro step_type muss fachlich begründet sein pro Schritt. Du hast bereits eine Tabelle, in der taxonomy_build auf gemma3 steht und vision auf minicpm. Das ist ein guter Ansatz. Aber “Default für alles” ist fachlich falsch, weil die Aufgaben unterschiedlich sind.\n\nWenn Du trotzdem eine Standardkonvention willst, dann nur so:\n\nEin Basismodell für Textaufgaben.\n\nEin spezifisches Modell für Vision.\n\nEin spezifisches Modell für Embeddings.\n\nUnd jede Abweichung ist ein expliziter DB Eintrag.\n\n7. Entscheidungsempfehlung\n\nGenehmigung unter Bedingungen:\n\nPipeline ID Hardcoding entfernen.\n\nMehrfachzeilenfall definieren und absichern, ideal mit Unique Constraint.\n\nTests um Hardcode Scan und Step Call Konfig Vollständigkeit erweitern.\n\nStandalone Scripts klassifizieren: produktiv und dann anbinden, oder dev-only und dann bewusst ausnehmen.\n\nWenn Du diese vier Punkte einziehst, ist der Task fachlich sauber und die Umsetzung risikoarm. <-- validiere und integriere entsprechend"
}