{
"tool_response": [
{
"type": "text",
"text": "{\n \"success\": true,\n \"tasks\": [\n {\n \"id\": 221,\n \"uuid\": \"28f175a5-706f-41dd-b771-085012b103c1\",\n \"title\": \"Architektur-Refactoring: Masterplan aus Supervision\",\n \"description\": \"## Kontext\\nExterne Supervision hat 10 strukturelle Probleme im src\/-Verzeichnis identifiziert.\\nDieser Parent-Task koordiniert alle Subtasks zur Behebung.\\n\\n## Identifizierte Probleme\\n1. Controller greifen direkt auf PDO\/SQL zu\\n2. Uneinheitlicher Datenbankzugriff (DatabaseFactory vs. PDO)\\n3. Controller enthalten Geschäfts-\/Workflow-Logik\\n4. Read\/Write-Logik vermischt\\n5. Präsentationslogik im Controller\\n6. Inkonsistente Response-Strategien\\n7. Verteilte\/doppelte Validierungslogik\\n8. Controller bauen Abhängigkeiten selbst (new Repository)\\n9. Fehlende explizite Zustandslogik\\n10. Audit\/Logging nicht systematisch\\n\\n## Zielarchitektur\\n- Controller = reine Transport-Schicht\\n- Application Layer mit Services\\n- Konsequente Repository-Nutzung\\n- Commands\/Queries Pattern\\n- Zentrale Validierung\\n- Explizite State Machines\\n- Systematisches Audit-Logging\\n\\n## Akzeptanzkriterien\\n- [ ] Alle Subtasks erfolgreich abgeschlossen\\n- [ ] contracts_validate() zeigt 0 critical violations\\n- [ ] Kein PDO in Controllern\\n- [ ] Alle Controller < 300 LOC\",\n \"type\": \"ai_task\",\n \"status\": \"pending\",\n \"created_by\": \"mcp-tasks\",\n \"created_by_type\": \"ai\",\n \"parent_task_id\": null,\n \"due_date\": null,\n \"created_at\": \"2025-12-22T09:55:54.413946\",\n \"updated_at\": \"2025-12-22T09:55:54.413949\",\n \"completed_at\": null,\n \"metadata\": {}\n },\n {\n \"id\": 219,\n \"uuid\": \"a8fa4b71-9b82-4b82-91e3-1b1e7612f63a\",\n \"title\": \"Weitere Controller mit direktem DB-Zugriff refactoren\",\n \"description\": \"## Problem\\nNeben ChatController haben weitere Controller direkten PDO-Zugriff:\\n\\n| Controller | PDO-Zugriffe | LOC |\\n|------------|--------------|-----|\\n| ConfigController | 13 | 338 |\\n| CriticsController | 12 | 289 |\\n| PromptsController | 10 | 256 |\\n| ProtokollController | 7 | 163 |\\n| Api\/ChatController | 6 | ? |\\n| Api\/ExplorerController | 10 | ? |\\n\\n## Aufgabe\\nNach ChatController-Refactoring (Task #216) die gleichen Patterns anwenden:\\n\\n### Priorität 1 (> 10 PDO-Zugriffe)\\n- ConfigController → ConfigRepository\\n- CriticsController → CriticsRepository\\n- PromptsController → PromptsRepository\\n- Api\/ExplorerController → ExplorerRepository\\n\\n### Priorität 2 (< 10 PDO-Zugriffe)\\n- ProtokollController → bereits teilweise migriert\\n- Api\/ChatController → nutzt ChatSessionRepository\\n\\n## Akzeptanzkriterien\\n- [ ] Kein Controller hat direkten PDO-Zugriff\\n- [ ] Alle Repositories implementieren Interfaces\\n- [ ] PHPStan Level 7 ohne neue Fehler\\n- [ ] Contract `code-quality-standards` validiert ohne Violations\",\n \"type\": \"ai_task\",\n \"status\": \"pending\",\n \"created_by\": \"mcp-tasks\",\n \"created_by_type\": \"ai\",\n \"parent_task_id\": 209,\n \"due_date\": null,\n \"created_at\": \"2025-12-22T09:32:11.739974\",\n \"updated_at\": \"2025-12-22T09:32:11.739975\",\n \"completed_at\": null,\n \"metadata\": {}\n },\n {\n \"id\": 218,\n \"uuid\": \"1cb4039f-1d7a-41cb-ad91-7c82faa847c3\",\n \"title\": \"Dokumentation: Enforcement-System beschreiben\",\n \"description\": \"## Problem\\nDas neue Enforcement-System muss dokumentiert werden, damit es nachhaltig genutzt wird.\\n\\n## Aufgabe\\nDokumentation erstellen:\\n\\n### 1. Architektur-Übersicht\\n- Diagramm: Contracts → Validator → Hooks → Workflow\\n- Erklärung der Komponenten\\n\\n### 2. Contract-Authoring Guide\\n- Meta-Schema Referenz\\n- Beispiel-Contracts\\n- Best Practices\\n\\n### 3. Hook-Konfiguration\\n- Welche Hooks existieren\\n- Wie werden sie konfiguriert\\n- Wie werden sie erweitert\\n\\n### 4. Troubleshooting\\n- \\\"Mein Code wird blockiert\\\" → Prüfe welcher Contract\\n- \\\"Contract-Validierung findet nichts\\\" → Prüfe Schema-Format\\n- \\\"Hook läuft nicht\\\" → Prüfe Konfiguration\\n\\n## Dateien\\n- `\/var\/www\/dev.campus.systemische-tools.de\/docs\/architecture\/enforcement-system.md`\\n- Update: `\/var\/www\/dev.campus.systemische-tools.de\/CLAUDE.md`\\n\\n## Akzeptanzkriterien\\n- [ ] Dokumentation in docs_create() erstellt\\n- [ ] CLAUDE.md referenziert Enforcement-System\\n- [ ] Beispiele sind lauffähig\",\n \"type\": \"ai_task\",\n \"status\": \"pending\",\n \"created_by\": \"mcp-tasks\",\n \"created_by_type\": \"ai\",\n \"parent_task_id\": 209,\n \"due_date\": null,\n \"created_at\": \"2025-12-22T09:31:56.173745\",\n \"updated_at\": \"2025-12-22T09:31:56.173747\",\n \"completed_at\": null,\n \"metadata\": {}\n },\n {\n \"id\": 217,\n \"uuid\": \"4343797b-3e34-426f-95f3-4bd0bbc2197d\",\n \"title\": \"Validierung: Alle Contracts gegen Codebase prüfen\",\n \"description\": \"## Problem\\nNach Implementation des neuen Enforcement-Systems muss validiert werden, dass es funktioniert.\\n\\n## Aufgabe\\nVollständige Validierung aller Contracts gegen aktuelle Codebase:\\n\\n### 1. Automatische Validierung\\n```bash\\nfor contract in $(contracts_list --compact | jq -r '.contracts[].name'); do\\n contracts_validate --name=\\\"$contract\\\"\\ndone\\n```\\n\\n### 2. Ergebnis-Dokumentation\\n| Contract | Status | Critical | Major | Minor |\\n|----------|--------|----------|-------|-------|\\n| code-quality-standards | ? | ? | ? | ? |\\n| layered-architecture | ? | ? | ? | ? |\\n| ... | ... | ... | ... | ... |\\n\\n### 3. Violations analysieren\\n- Welche sind Legacy (akzeptiert in Baseline)?\\n- Welche müssen gefixt werden?\\n- Welche zeigen Contract-Fehler?\\n\\n### 4. Baseline erstellen\\nFür Legacy-Violations die nicht sofort gefixt werden:\\n- `contract_baseline.yaml` mit akzeptierten Violations\\n- Neue Violations müssen 0 sein\\n\\n## Akzeptanzkriterien\\n- [ ] Alle 9 Contracts wurden validiert\\n- [ ] Ergebnis-Tabelle ist dokumentiert\\n- [ ] Baseline für Legacy-Violations existiert\\n- [ ] Neue Code-Änderungen werden gegen Contracts geprüft\",\n \"type\": \"ai_task\",\n \"status\": \"pending\",\n \"created_by\": \"mcp-tasks\",\n \"created_by_type\": \"ai\",\n \"parent_task_id\": 209,\n \"due_date\": null,\n \"created_at\": \"2025-12-22T09:31:55.759049\",\n \"updated_at\": \"2025-12-22T09:31:55.759051\",\n \"completed_at\": null,\n \"metadata\": {}\n },\n {\n \"id\": 216,\n \"uuid\": \"b3fee2a3-054a-461d-8528-bd20d5a81767\",\n \"title\": \"ChatController refactoren (Proof-of-Concept)\",\n \"description\": \"## Problem\\nChatController ist das Paradebeispiel für ein \\\"God Object\\\":\\n- 711 LOC (Contract erlaubt 500)\\n- 12 direkte PDO-Zugriffe\\n- 8+ Verantwortlichkeiten vermischt\\n\\n## Aufgabe\\nChatController nach neuen Architektur-Regeln refactoren:\\n\\n### 1. Services extrahieren\\n- `ChatSessionService`: create, get, update, delete Sessions\\n- `ChatMessageService`: getMessages, Formatierung\\n- `ChatConfigService`: AuthorProfiles, SystemPrompts\\n- `MarkdownRenderer`: formatAnswer, formatLists\\n\\n### 2. Repository Pattern\\n- `ChatSessionRepository`: Alle Session-DB-Operationen\\n- `ChatMessageRepository`: Alle Message-DB-Operationen\\n- `ContentConfigRepository`: AuthorProfiles, SystemPrompts\\n\\n### 3. Controller schlank halten\\n- Nur Request-Handling\\n- UseCase-Aufrufe\\n- Response-Rendering\\n\\n## Ziel-Struktur\\n```\\nsrc\/\\n├── Controller\/\\n│ └── ChatController.php # < 200 LOC\\n├── Domain\/\\n│ └── Repository\/\\n│ ├── ChatSessionRepositoryInterface.php\\n│ └── ChatMessageRepositoryInterface.php\\n├── Infrastructure\/\\n│ ├── Persistence\/\\n│ │ ├── ChatSessionRepository.php\\n│ │ └── ChatMessageRepository.php\\n│ └── Rendering\/\\n│ └── MarkdownRenderer.php\\n└── UseCases\/\\n └── Chat\/\\n └── SendChatMessageUseCase.php # Existiert bereits\\n```\\n\\n## Akzeptanzkriterien\\n- [ ] ChatController < 250 LOC\\n- [ ] Kein PDO\/SQL im Controller\\n- [ ] Alle Tests passieren\\n- [ ] PHPStan Level 7 ohne neue Fehler\\n- [ ] Contract-Validierung besteht\",\n \"type\": \"ai_task\",\n \"status\": \"pending\",\n \"created_by\": \"mcp-tasks\",\n \"created_by_type\": \"ai\",\n \"parent_task_id\": 209,\n \"due_date\": null,\n \"created_at\": \"2025-12-22T09:31:55.349303\",\n \"updated_at\": \"2025-12-22T09:31:55.349306\",\n \"completed_at\": null,\n \"metadata\": {}\n },\n {\n \"id\": 215,\n \"uuid\": \"d5b57724-83ff-416c-af8f-a34eb04b869f\",\n \"title\": \"PostToolUse Hook für Code-Review implementieren\",\n \"description\": \"## Problem\\nNach Code-Änderungen gibt es keine automatische Prüfung. Der Architecture-Guard (PreToolUse) verhindert grobe Fehler, aber ein PostToolUse Hook könnte subtilere Probleme erkennen.\\n\\n## Aufgabe\\nPostToolUse Hook der nach `Write`\/`Edit` auf PHP-Dateien:\\n\\n1. **Statistiken sammelt**:\\n - Geänderte Dateien\\n - Neue LOC-Zählung\\n - Neue Methoden-Anzahl\\n\\n2. **Warnungen generiert**:\\n - \\\"Controller nähert sich LOC-Limit (480\/500)\\\"\\n - \\\"Neue private Methode - prüfe ob Service-Extraktion sinnvoll\\\"\\n - \\\"Neue Dependency - prüfe Layer-Verletzung\\\"\\n\\n3. **In Session-Context speichert**:\\n - Cumulative Changes Tracking\\n - Bei > 100 LOC Änderung: Critic-Review triggern\\n\\n## Dateien\\n- Neu: `\/var\/www\/tools\/ki-protokoll\/claude-hook\/code_review_post.py`\\n\\n## Akzeptanzkriterien\\n- [ ] Hook läuft nach jeder PHP-Änderung\\n- [ ] Warnungen erscheinen im Claude-Output\\n- [ ] Cumulative Tracking funktioniert über Session\",\n \"type\": \"ai_task\",\n \"status\": \"pending\",\n \"created_by\": \"mcp-tasks\",\n \"created_by_type\": \"ai\",\n \"parent_task_id\": 209,\n \"due_date\": null,\n \"created_at\": \"2025-12-22T09:31:19.674580\",\n \"updated_at\": \"2025-12-22T09:31:19.674583\",\n \"completed_at\": null,\n \"metadata\": {}\n },\n {\n \"id\": 214,\n \"uuid\": \"5b5deb28-09a3-4c3c-9775-ceb54411bc1e\",\n \"title\": \"Critic-Workflow Contract erstellen\",\n \"description\": \"## Problem\\nEs gibt keinen systematischen Review-Prozess. Code wird geschrieben ohne dass jemand prüft ob Contracts eingehalten werden.\\n\\n## Aufgabe\\nFormalen Critic-Workflow als Contract defi... [TRUNCATED-01cc4bc47fc14c4d]"
}
]
}