{
"event": "UserPromptSubmit",
"prompt": "validiere diese supervision faktisch (code=wahrheit): Schritt 1: Konsistenz und harte Probleme prüfen\n\nPackage Namen sind aktuell nicht paketfähig.\nVerzeichnisse wie mcp-db sind als Python Package nicht importierbar, weil der Name ein Minuszeichen enthält. Dein pyproject.toml nennt zusätzlich mcp_db und gleichzeitig existiert im Plan mcp-db. Das ist ein Widerspruch.\nKonsequenz: Ohne vorherige Umbenennung auf mcp_db, mcp_tasks, mcp_contracts, mcp_docs, mcp_code ist das Packaging Konzept nicht stabil umsetzbar.\n\nserver_factory.py lädt die falsche .env.\nPath(__file__).parent \/ \".env\" zeigt auf shared\/.env, nicht auf die jeweilige Server Umgebung. Damit ist das Verhalten je Server nicht reproduzierbar.\nKonsequenz: .env Pfad muss als Parameter in die Factory.\n\nLogger Singleton via lru_cache ist so nicht sicher.\nDu cachest get_logger(client_name, log_config). log_config ist sehr wahrscheinlich ein Objekt und damit nicht hashbar. Dann bricht lru_cache zur Laufzeit. Selbst wenn hashbar, entsteht Cache Fragmentierung durch unterschiedliche Instanzen.\nKonsequenz: Entweder Cache nur über client_name plus stabilen Key aus primitiven Werten, oder ganz ohne lru_cache und dafür explizite Lebensdauer Steuerung.\n\nDB Konfiguration ist im Plan unvollständig und vermischt.\nDu verwendest im DatabaseConfig DB_NAME. Im Konfig Abschnitt listest Du aber primär Host, Port, User, Password und zusätzlich separate Log DB Felder. Das Loggen braucht eine zweite Datenbank Konfiguration oder eine eindeutig getrennte Struktur.\nKonsequenz: DatabaseConnection.get_connection muss entweder eine echte DbDsn Struktur bekommen oder Du definierst klar: eine Instanz für App DB, eine Instanz für Log DB.\n\nEntscheidung 3 widerspricht Abschnitt 3.1.\nIn 3.1 schlägst Du eine vollständige Zerlegung in viele Dateien vor. In Entscheidung 3 empfiehlst Du teilweise Zerlegung.\nKonsequenz: Du brauchst eine einheitliche Zielstruktur, sonst wird Phase 3 chaotisch und schwer testbar.\n\nStandardisierung auf pymysql blendet Pooling Thema aus.\nmysql.connector Pooling war explizit im Ist Zustand genannt. Bei Umstieg auf pymysql fällt das weg, sofern Du nicht selbst poolst oder bewusst auf Pooling verzichtest.\nKonsequenz: Das gehört als explizite Architekturentscheidung in den Plan, sonst riskierst Du stille Performance Regression.\n\nlogging.basicConfig in einer Factory ist nicht deterministisch.\nbasicConfig wirkt nur beim ersten Aufruf, wenn bereits Handler existieren, passiert nichts. Bei fünf Servern im selben Prozess oder bei Tests kann das Verhalten abweichen.\nKonsequenz: Logging Setup muss idempotent sein und klar pro Server konfiguriert werden.\n\nDie Metriken sind als Ziele formuliert, aber nicht als messbare Gates pro Phase.\nDu nennst globale Ziele wie LOC Reduktion, aber die Phasen brauchen messbare Zwischenzustände, sonst kannst Du nicht sauber abnehmen.\n\nSchritt 2: Korrekturen, die ich als Pflicht markiere\n\nUmbenennung der Server Package Ordner vor Phase 1.\nZiel: importierbare Python Packages ohne sys.path.insert.\nErgebnis: mcp_db, mcp_tasks, mcp_contracts, mcp_docs, mcp_code.\n\nVerbindliche Konfig Struktur definieren.\nMinimal und klar getrennt:\nAppDbConfig für die Fachdatenbank.\nLogDbConfig für die Log Datenbank.\nBaseConfig aggregiert beide oder liefert Builder Methoden, aber vermischt keine Felder.\n\nserver_factory.create_mcp_server bekommt Parameter für .env und Logging.\nPflicht Parameter: env_path, log_configurer oder ein bool, der bewusst sagt, ob Logging im Server oder extern gesetzt wird.\n\nLogger Singleton ohne nicht hashbare Parameter.\nOption A: get_logger(client_name: str), Log DB Config kommt aus BaseConfig intern.\nOption B: Cache Key ist ein Tuple aus Host, Port, User, DbName, ClientName.\n\nPhase 3 Entscheidung fixieren und den Validator Plan daran anpassen.\nWenn Du “teilweise Zerlegung” willst, dann definiere exakt welche drei Komponenten entstehen und was im Orchestrator bleibt. Sonst explodiert die Dateizahl und Du verlierst Geschwindigkeit.\n\nDB Bibliothek Entscheidung mit Pooling Aussage.\nEntweder: “kein Pooling, weil Prozess kurzlebig, Last gering, Connection pro Request ok”.\nOder: “Pooling, dann eigene minimale Pool Implementierung oder anderes Paket”.\nOhne diesen Satz ist Entscheidung 1 fachlich unvollständig.\n\nSchritt 3: Empfohlene korrigierte Reihenfolge der Pipeline\n\nPhase 0: Naming und Packaging Fundament\n\nOrdner umbenennen auf gültige Package Namen.\n\npyproject.toml so anpassen, dass exakt diese Namen enthalten sind.\n\nImports innerhalb des Repos auf Package Imports umstellen.\n\nAlle bisherigen sys.path.insert eliminieren.\n\nPhase 1: Shared Foundation, aber mit korrigierten Interfaces\n\nshared\/config_base.py mit klarer Trennung App DB und Log DB.\n\nshared\/infrastructure\/db_connection.py akzeptiert eine DSN Struktur, nicht den gesamten Server Config Monolith.\n\nshared\/infrastructure\/protokoll_logger.py nutzt ausschließlich Log DB DSN.\n\nshared\/server_factory.py nimmt env_path entgegen.\n\nTests: Unit Tests für Connection Wrapper, Logger Format, Env Loading Verhalten.\n\nPhase 2: Migration der Server in der von Dir genannten Reihenfolge\nDas ist sinnvoll, weil Du zuerst an den einfachsten Servern das neue Fundament validierst.\nErgänzung: pro Server ein “Tool Signature Snapshot” Test, der die Tool Namen und Parameter formal vergleicht.\n\nPhase 3: ContractValidator Refactor gemäß finaler Entscheidung\nWenn teilweise Zerlegung, dann zum Beispiel:\n\nscope_resolver.py\n\nrules_engine.py als Kombi für Parsing plus Regelanwendung\n\nresult_builder.py\nDer Orchestrator bleibt unter 100 Zeilen und macht nur Koordination.\n\nPhase 4: Repository Split nur bei nachgewiesenem Nutzen\nDas ist korrekt als optional markiert. Ich würde zusätzlich ein hartes Kriterium setzen: Split nur, wenn ein Repository mehr als zwei fachliche Aggregate oder mehr als eine Query Kategorie enthält.\n\nSchritt 4: Entscheidungen bewerten und präzisieren\nEntscheidung 1: Datenbank Bibliothek\n\nDeine Empfehlung “pymysql für alle” ist nur dann tragfähig, wenn Du Pooling bewusst nicht brauchst oder bewusst ersetzt.\nWenn Pooling benötigt wird, ist “pymysql ohne Pooling” kein gleichwertiger Ersatz. Dann ist die Empfehlung fachlich nicht abgeschlossen.\n\nEntscheidung 2: Singleton Pattern\n\nlru_cache ist nur dann eine gute Wahl, wenn alle Parameter hashbar sind und der Cache Key stabil ist. Das ist aktuell nicht gegeben.\nIch würde hier als strikte Regel festhalten: Singleton Factory darf nur primitive Parameter akzeptieren.\n\nEntscheidung 3: ContractValidator Refactoring\n\nAktuell ist das Dokument widersprüchlich. Du musst festlegen, ob Du die vollständige Rule Klassen Landschaft willst oder eine schlanke Teilzerlegung.\nFür Geschwindigkeit und Abnahmefähigkeit ist Teilzerlegung meistens besser, aber nur wenn Du die Grenzen sauber definierst.\n\nKonkrete Abnahmekriterien, die im Plan noch fehlen und die ich ergänzen würde\n\nImport Abnahme: Kein sys.path.insert existiert mehr im Repo.\n\nEnv Abnahme: Jeder Server lädt exakt seine .env und kein anderer Server überschreibt diese Werte.\n\nLogger Abnahme: Logger Fehler dürfen den Tool Call niemals fehlschlagen lassen. Das willst Du bereits, aber es braucht einen Test.\n\nDB Abnahme: Transaktionsverhalten identisch, insbesondere Commit und Rollback Bedingungen.\n\nTool Abnahme: Tool Namen, Argumente, Return Shapes bleiben identisch. Snapshot Test verpflichtend.\n\nWenn Du diese Korrekturen übernimmst, ist die Grundrichtung Deines Plans logisch. Ohne Phase 0, ohne Env Pfad Fix und ohne saubere Logger Cache Regel ist das Refactoring dagegen mit hoher Wahrscheinlichkeit instabil. <-- was davon ist legitim, was muss reflektiert werden kontextuell?"
}