{
"event": "UserPromptSubmit",
"prompt": "erstelle einen neuen task:# PROMPT: Systematische Umsetzung der Domänenentscheidung\n\n## Kontext\nDu arbeitest an einem bestehenden PHP-Projekt.\n\nEs existiert eine **verbindliche Architekturentscheidung**:\n\n> Der Domänenkern wird auf **immutable Value Objects plus explizite Zustandsmodelle** umgestellt. \n> **Entities existieren nur dort**, wo fachliche Identität über Zeit notwendig ist. \n> **Arrays sind im Domänenkern nicht mehr zulässig.**\n\nDeine Aufgabe ist **keine Optimierung nach Geschmack**, sondern die **konsequente, nachvollziehbare Umsetzung dieser Entscheidung im gesamten Projekt**.\n\n---\n\n## 1. Ziel\nÜberführe das Projekt von einem hybriden Domänenmodell in ein **kohärentes, überprüfbares Domänenmodell**, \nohne Funktionalität zu verlieren und ohne verdeckte Semantikänderungen.\n\n---\n\n## 2. Arbeitsauftrag in zwingender Reihenfolge\n\n### Schritt 1: Domäneninventar\nIdentifiziere **alle fachlichen Konzepte**, die aktuell existieren als:\n- Arrays\n- DTOs\n- Entities\n- implizite Strukturen (Payloads, Assoc Arrays, freie Strings)\n\nOrdne jedes Konzept **eindeutig genau einer Kategorie** zu:\n- Entity\n- Value Object\n- DTO\n- Infrastrukturstruktur\n\nFür jedes Objekt:\n- kurze Begründung der Zuordnung\n- Hinweis, wo es aktuell verwendet wird\n\n**Ergebnis:** Vollständige Inventarliste.\n\n---\n\n### Schritt 2: Grenzziehung\nBestimme für jedes Objekt:\n- gehört es in den **Domänenkern** oder an eine **Systemgrenze**?\n\nSystemgrenzen sind:\n- HTTP Requests und Responses\n- Datenbanken\n- Qdrant\n- externe APIs\n- Views\n\n**Regel:** \nValue Objects existieren nur im Domänenkern. \nDTOs existieren nur an Grenzen.\n\n**Ergebnis:** Klare Trennung Kern vs. Grenze.\n\n---\n\n### Schritt 3: Invariantenanalyse\nFür jedes Objekt im Domänenkern:\n- Welche Eigenschaften müssen **immer** gelten?\n- Welche Kombinationen sind fachlich **ungültig**?\n- Welche Zustände dürfen **nicht existieren**?\n\nDokumentiere:\n- implizite Annahmen\n- aktuell mögliche illegale Zustände\n\n**Ergebnis:** Liste erzwingbarer Invarianten.\n\n---\n\n### Schritt 4: Zustandsmodellierung\nIdentifiziere alle fachlichen Status:\n- Task Status\n- Content Status\n- Retrieval Zustände\n- Verarbeitungsphasen\n\nErsetze:\n- freie Strings\n- DB Enums\n- implizite Statusfelder\n\ndurch:\n- explizite Zustandsobjekte\n- klar benannte Übergänge\n\n**Regel:** \nKeine Flags. \nKeine freien Status Strings. \nJeder Zustand ist ein Typ.\n\n**Ergebnis:** Explizite Zustandsmodelle.\n\n---\n\n### Schritt 5: Umstellung der Domänenlogik\nErsetze im Domänenkern:\n- Array Zugriff\n- defensive `??` Logik\n- Schema Fallbacks\n\ndurch:\n- Konstruktor validierte Value Objects\n- explizite Übergabestrukturen\n\n**Regel:** \nUngültige Objekte dürfen nicht erzeugbar sein.\n\n**Ergebnis:** Domänenkern ohne defensive Programmierung.\n\n---\n\n### Schritt 6: DTO Anpassung an Grenzen\nFür jede Systemgrenze:\n- definiere explizite DTOs\n- mappe DTO → Value Object beim Eintritt\n- mappe Value Object → DTO beim Austritt\n\n**Regel:** \nKein Domänenobjekt verlässt den Kern ungeprüft.\n\n**Ergebnis:** Saubere IO-Grenzen.\n\n---\n\n### Schritt 7: Konsistenzprüfung\nPrüfe abschließend:\n- existieren Arrays im Domänenkern?\n- existieren mutierbare Value Objects?\n- existieren Status Strings?\n- existieren implizite Schemas?\n\nDokumentiere jede Abweichung.\n\n**Ergebnis:** Abnahmefähiger Statusbericht.\n\n---\n\n## 3. Bewertungsmaßstab\n- Keine Pattern-Namen als Begründung\n- Keine Stilargumente\n- Keine Optimierungsvorschläge ohne Zwang\n\nJede Änderung muss begründbar sein durch:\n- Eliminierung illegaler Zustände\n- Eliminierung impliziter Annahmen\n- Erhöhung struktureller Konsistenz\n\n---\n\n## 4. Explizite Verbote\n- Keine parallelen Modelle\n- Keine Hybridlösungen\n- Keine „Übergangslösungen“\n- Keine stillschweigende Semantikänderung\n\nDu arbeitest deterministisch, schrittweise und überprüfbar.\n"
}
{
"assistant_response": "**Task #324 erstellt** ✅\n\n| Feld | Wert |\n|------|------|\n| ID | 324 |\n| Titel | Systematische Umsetzung der Domänenentscheidung: Immutable Value Objects |\n| Typ | ai_task |\n| Status | pending |\n| Referenz | Task #318 (System-Ist-Analyse) |\n\n**7 Schritte definiert:**\n\n1. **Domäneninventar** → Kategorisierung aller Konzepte\n2. **Grenzziehung** → Kern vs. Systemgrenze\n3. **Invariantenanalyse** → Erzwingbare Regeln\n4. **Zustandsmodellierung** → Explizite State Machines\n5. **Umstellung Domänenlogik** → Konstruktor-Validierung\n6. **DTO-Anpassung** → Saubere IO-Grenzen\n7. **Konsistenzprüfung** → Abnahmebericht"
}