Protokoll #14683

{
    "event": "UserPromptSubmit",
    "prompt": "das hier ist das ergebnis der externen supervision: Größter Hebel für SRP und KISS: Zerlege die übergroßen Infrastruktur Klassen\n\nFakt: Es gibt mehrere Dateien, die gleichzeitig mehrere fachliche Verantwortungen bündeln und dadurch schwer testbar, schwer erweiterbar und fehleranfällig werden.\n\nKonkrete Kandidaten aus Deinem Codebestand:\n\nsrc\/Infrastructure\/SemanticExplorerRepository.php hat 918 Zeilen und bündelt Dokumente, Chunks, Entitäten, Relationen, Taxonomie, Ontologie in einer Klasse.\n\nsrc\/Infrastructure\/Persistence\/SystemExplorerRepository.php hat 706 Zeilen und wirkt wie ein Sammelbehälter für System Queries.\n\nsrc\/Infrastructure\/Persistence\/CodeAnalysisRepository.php hat 605 Zeilen und mischt Analyse Persistenz und Query Logik.\n\nsrc\/Infrastructure\/Docs\/ChunkSyncService.php hat 541 Zeilen und ist synchronisieren, lesen, schreiben, entscheiden zugleich.\n\nEmpfehlung, deterministisch umsetzbar:\n\nSplitte pro fachlichem Aggregat eine Repository Klasse. Zum Beispiel DocumentRepository, ChunkRepository, EntityRepository, RelationRepository, TaxonomyRepository, OntologyRepository.\n\nLasse jeden UseCase nur das Repository Interface kennen, nicht die Sammelklasse.\n\nExtrahiere Query Bausteine in private Methoden oder Query Objekte, damit jede öffentliche Methode genau einen Zweck hat.\n\nDIP und SOLID: Ziehe Interfaces bis in Controller und Application Schicht durch\n\nFakt: Du hast bereits Domain Repository Interfaces in src\/Domain\/Repository\/* und ein zentrales Wiring in src\/services.php. Das ist die richtige Richtung.\n\nAuffälligkeit: Mehrere Controller importieren konkrete Infrastruktur Klassen statt Interfaces. Beispiel: src\/Controller\/ContentController.php nutzt Infrastructure\\Persistence\\ContentRepository, statt Domain\\Repository\\ContentRepositoryInterface.\n\nKonsequenz: Controller werden an konkrete Persistenz gebunden. Das ist eine klare DIP Verletzung und erschwert Tests und Austauschbarkeit.\n\nEmpfehlung:\n\nController Konstruktoren nur noch gegen Domain Interfaces typisieren.\n\nservices.php bleibt der einzige Ort, der konkrete Implementierungen kennt.\n\nPrüfe zusätzlich Service Klassen, die statische Factories oder globale Zugriffe kapseln und verschiebe das in injected Services, wenn es im Request Pfad liegt.\n\nMVC Trennung: Entferne Geschäftslogik aus Views\n\nFakt: Views enthalten Berechnungen, die fachlich sind, nicht rein Darstellung.\n\nKonkretes Beispiel:\nsrc\/View\/chat\/index.php berechnet Token Summen und Kosten direkt im Template.\n\nKonsequenz: Änderungen an Preislogik oder Token Logik verteilen sich in Templates, sind schwer zu testen und brechen SRP.\n\nEmpfehlung:\n\nErzeuge View Models oder Presenter. Beispiel: ChatSessionListPresenter erzeugt für jede Session bereits totalTokens und totalCost.\n\nViews rendern nur noch Strings und Zahlen, ohne Berechnungen.\n\nAlle Formatierungen und Ableitungen liegen in Formatter Klassen. Du hast bereits Infrastructure\\Formatting\\ChatMessageFormatter, das passt.\n\nDRY: Reduziere SQL Duplikate und uneinheitliche Ergebnisformen\n\nFakt: In großen Repositories stehen viele SQL Strings inline und wiederholen Muster wie Pagination, Count, Status Summen, Joins, Subselects. Das ist in SemanticExplorerRepository und SystemExplorerRepository sehr wahrscheinlich der Fall, weil sie umfangreich sind.\n\nEmpfehlung:\n\nErzeuge eine kleine interne Query Utility Schicht pro Datenbank, zum Beispiel BaseRepository mit prepare, fetchOne, fetchAll, fetchValue, paginate.\n\nExtrahiere häufige WHERE und ORDER BY Teile als private Methoden oder Value Objects, damit Sortierung und Filterung nicht fragmentieren.\n\nMappe Ergebnisse konsequent in DTOs statt rohe Arrays, zumindest an den Grenzen zu UseCases. Du hast DTOs in src\/Domain\/DTO, das ist ein guter Start.\n\nOOP und YAGNI: Entferne tote oder Legacy Strukturen, die nicht genutzt werden\n\nFakten aus Deinem Bestand:\n\nsrc\/Infrastructure\/Persistence\/Connection.php ist als deprecated markiert und wird in src nicht genutzt.\n\nsrc\/Infrastructure\/Container\/ServiceLocator.php ist globaler Zustand und wird in src nicht genutzt.\n\nKonsequenz: Diese Dateien erhöhen Komplexität ohne Nutzen. Das ist ein klassischer YAGNI und Wartungsballast.\n\nEmpfehlung:\n\nLösche ungenutzte Legacy Wrapper und globalen Locator konsequent.\n\nHalte nur einen DI Mechanismus. Dein Framework Container plus services.php reichen.\n\nSRP in Domain Entities: Reduziere Setter Flut und verlagere Defaults aus Entities\n\nFakt: Domain\\Entity\\ChatSession.php hat viele Setter und hält Default Werte für Modell, Tokens, Temperatur und Collections in der Entity selbst.\n\nKonsequenz:\n\nViele Setter machen Objektzustände beliebig. Das erhöht Zustandsraum und Testaufwand.\n\nKonfiguration wie Modellname und Tokenlimits ist eher Policy, nicht Domain Kernzustand.\n\nEmpfehlung:\n\nBevorzuge Konstruktion über benannte Konstruktoren oder Fabriken und nutze wenige, gezielte Methoden für Zustandsänderungen.\n\nLege Konfig Defaults in eine Config oder Policy Klasse, die injected wird, nicht in die Entity.\n\nValidierung von Temperatur, Tokenlimits, Collections sollte zentral stattfinden, nicht verteilt über Controller oder Template.\n\nPSR und Tooling: Nutze vorhandene Grundlage konsequent\n\nFakten:\n\nphpstan.neon ist vorhanden und auf Level 7 konfiguriert.\n\n.php-cs-fixer.dist.php ist vorhanden.\n\ndeclare(strict_types=1) ist in praktisch allen Nicht View Dateien vorhanden.\n\nEmpfehlung:\n\nErzwinge php cs fixer und phpstan in einem festen, reproduzierbaren Ablauf vor jedem Merge oder Release.\n\nErgänze PSR 3 Logging Schnittstelle, falls AuditLogger nicht bereits darauf basiert, damit Infrastruktur austauschbar bleibt.\n\nStelle sicher, dass jede öffentliche Methode in UseCases und Repositories klare Rückgabetypen hat, nicht nur array.\n\nWenn Du den maximalen Nutzen mit minimalem Umbau willst, ist die beste Reihenfolge klar:\n\nSplit der großen Repository und Service Klassen nach Verantwortungen.\n\nDIP durchziehen, Controller nur gegen Interfaces.\n\nPresenter einführen, Logik aus Views entfernen.\n\nTote Dateien löschen und damit Komplexität reduzieren.\n\nDTO Mapping und Repository Basisklasse für DRY.\n\nWenn Du als nächsten Schritt ein konkretes, deterministisches Refactoring Paket willst, nenne mir eine der vier großen Dateien aus Punkt 1, dann liefere ich Dir einen exakten Schnittplan mit neuen Klassen, Interfaces, Methoden Signaturen und Migrationsschritten, ohne Nebenkriegsschauplätze.\n\nnimm zwei der vier dateien\n\nIch nehme diese zwei Dateien, weil sie den größten strukturellen Schaden verursachen und zugleich den höchsten Hebel haben.\n\nsrc\/Infrastructure\/SemanticExplorerRepository.php\n\nsrc\/Infrastructure\/Docs\/ChunkSyncService.php\n\nIch gehe strikt vor. Erst Befund. Dann Zielstruktur. Dann konkrete Schnitte.\n\n────────────────────────\n\nSemanticExplorerRepository.php\n────────────────────────\n\nA. Faktischer Befund\n\nDiese Klasse verletzt gleichzeitig:\n\nSRP, da sie Dokumente, Chunks, Entitäten, Relationen, Taxonomien und Ontologien behandelt.\n\nKISS, da sie über 900 Zeilen Query Logik, Mapping, Filter, Pagination und Aggregation bündelt.\n\nDIP, da UseCases faktisch an eine monolithische Infrastrukturklasse gekoppelt sind.\n\nDRY, da SQL Muster für Filter, Joins und Pagination mehrfach auftreten.\n\nTestbarkeit, da isolierte Tests einzelner fachlicher Aspekte nicht möglich sind.\n\nStrukturell ist das ein God Repository.\n\nB. Zielbild der Modellierung\n\nDie fachlichen Aggregate sind bereits implizit vorhanden. Sie müssen explizit werden.\n\nZielstruktur:\n\nsrc\/Domain\/Repository\/\n\nDocumentRepositoryInterface\n\nChunkRepositoryInterface\n\nEntityRepositoryInterface\n\nRelationRepositoryInterface\n\nTaxonomyRepositoryInterface\n\nOntologyRepositoryInterface\n\nsrc\/Infrastructure\/Persistence\/\n\nDocumentRepository\n\nChunkRepository\n\nEntityRepository\n\nRelationRepository\n\nTaxonomyRepository\n\nOntologyRepository\n\nJede Klasse:\n\nVerantwortet genau ein Aggregat.\n\nEnthält nur Queries, die diesem Aggregat fachlich zugeordnet sind.\n\nGibt DTOs oder Entities zurück, keine strukturlosen Arrays.\n\nC. Konkreter Schnittplan\n\nSchritt 1\nIdentifiziere öffentliche Methoden im SemanticExplorerRepository und ordne sie eindeutig einem Aggregat zu. Beispiel:\n\nMethoden mit document_id, title, source gehören zu DocumentRepository.\n\nMethoden mit chunk_id, embedding, offset gehören zu ChunkRepository.\n\nMethoden mit subject, predicate, object gehören zu RelationRepository.\n\nMethoden mit taxonomy, category, label gehören zu TaxonomyRepository.\n\nSchritt 2\nErzeuge neue Repository Klassen und verschiebe Methoden unverändert dorthin. Kein Refactoring der Logik im ersten Schritt. Nur Verschiebung.\n\nSchritt 3\nErsetze im SemanticExplorerRepository jede Methode durch einen delegierenden Aufruf oder entferne sie vollständig, sobald alle UseCases umgestellt sind.\n\nSchritt 4\nPasse services.php an, sodass Interfaces auf konkrete Repositories gemappt werden.\n\nSchritt 5\nPasse UseCases an, sodass sie mehrere spezialisierte Repositories injizieren statt eines Sammelrepositories.\n\nErgebnis:\n\nJede Klasse unter 200 Zeilen.\n\nKlare fachliche Zuständigkeit.\n\nUnit Tests pro Repository möglich.\n\nSpätere Optimierung einzelner Query Pfade ohne Seiteneffekte.\n\n────────────────────────\n2. ChunkSyncService.php\n────────────────────────\n\nA. Faktischer Befund\n\nDiese Klasse verletzt:\n\nSRP, da sie Synchronisationslogik, IO, Entscheidungslogik und Persistenz mischt.\n\nOOP, da sie prozedural wirkt und viele Seiteneffekte bündelt.\n\nTestbarkeit, da sie keine klaren Schnittstellen für Teilverhalten bietet.\n\nYAGNI, da sie implizite Policies enthält, die nicht explizit modelliert sind.\n\nSie ist gleichzeitig Orchestrator, Entscheider und Worker.\n\nB. Zielbild der Modellierung\n\nChunk Synchronisation ist ein Prozess. Prozesse brauchen Rollen.\n\nZielstruktur:\n\nsrc\/Application\/ChunkSync\/\n\nChunkSyncOrchestrator\n\nChunkChangeDetector\n\nChunkDiffCalculator\n\nChunkPersistenceApplier\n\nsrc\/Domain\/Service\/\n\nChunkIdentityService\n\nChunkHashService\n\nC. Konkreter Schnittplan\n\nSchritt 1\nExtrahiere reine Entscheidungslogik.\n\nAlles was beantwortet:\n\nIst ein Chunk neu?\n\nHat sich der Inha... [TRUNCATED-0b12c28ce74768cd]"
}

-