Protokoll #1766

{
    "event": "UserPromptSubmit",
    "prompt": "ok, wir brauchen für den user \/ ki_content-Teil mindestens: Autorenprofile, Strukturdateien (z.b. welche struktur hat ein blog\/mail\/social post) und auch organisations-informationen: Bad Words, corporate tone of voice etc. ), aber auch contracts und dann jeweils auch regeln \/ grenzwerte. wie bilden wir das ab: alles in einer tabelle (versionierbar)? mach vorschläge."
}

{
    "assistant_response": "Gute Frage! Hier sind drei Architektur-Optionen:\n\n---\n\n## Option A: Unified Config Table (Empfohlen)\n\nEine Tabelle für alle Konfigurations-Typen mit JSON-Content:\n\n```sql\nCREATE TABLE content_config (\n    id INT PRIMARY KEY AUTO_INCREMENT,\n    type ENUM('author_profile', 'structure', 'organization', 'contract', 'rule') NOT NULL,\n    name VARCHAR(100) NOT NULL,\n    slug VARCHAR(100) NOT NULL,\n    content JSON NOT NULL,           -- Typ-spezifische Daten\n    version VARCHAR(20) DEFAULT '1.0',\n    status ENUM('draft', 'active', 'deprecated') DEFAULT 'draft',\n    parent_id INT NULL,              -- Für Vererbung (z.B. Regel gehört zu Contract)\n    created_at DATETIME DEFAULT NOW(),\n    updated_at DATETIME DEFAULT NOW() ON UPDATE NOW(),\n    \n    UNIQUE KEY (type, slug, version),\n    FOREIGN KEY (parent_id) REFERENCES content_config(id)\n);\n\n-- Versions-Historie\nCREATE TABLE content_config_history (\n    id INT PRIMARY KEY AUTO_INCREMENT,\n    config_id INT NOT NULL,\n    content JSON NOT NULL,\n    version VARCHAR(20) NOT NULL,\n    changed_by VARCHAR(100),\n    change_description TEXT,\n    created_at DATETIME DEFAULT NOW(),\n    \n    FOREIGN KEY (config_id) REFERENCES content_config(id)\n);\n```\n\n**Beispiel-Content pro Typ:**\n\n```json\n\/\/ type: \"author_profile\"\n{\n  \"stimme\": {\"ton\": \"professionell\", \"perspektive\": \"wir\"},\n  \"stil\": {\"fachsprache\": true, \"beispiele\": \"häufig\"},\n  \"tabus\": [\"Clickbait\", \"Übertreibungen\"]\n}\n\n\/\/ type: \"structure\"  \n{\n  \"format\": \"blog\",\n  \"sections\": [\"hook\", \"problem\", \"lösung\", \"cta\"],\n  \"constraints\": {\"min_words\": 800, \"max_words\": 1500}\n}\n\n\/\/ type: \"organization\"\n{\n  \"bad_words\": [\"billig\", \"günstig\", \"mega\"],\n  \"tone_of_voice\": \"systemisch-wertschätzend\",\n  \"brand_terms\": {\"preferred\": [\"Teamentwicklung\"], \"avoid\": [\"Teambuilding\"]}\n}\n\n\/\/ type: \"contract\"\n{\n  \"scope\": \"src\/View\/**\/*.php\",\n  \"rules\": [\"no-inline-styles\", \"semantic-html\"]\n}\n\n\/\/ type: \"rule\"\n{\n  \"check\": \"word_count\",\n  \"operator\": \"between\",\n  \"values\": [800, 1500],\n  \"severity\": \"error\"\n}\n```\n\n**Vorteile:**\n- Eine Tabelle, ein Versionssystem\n- Flexible JSON-Struktur pro Typ\n- Hierarchie durch `parent_id` (Regeln → Contract)\n- Einfache GUI: Eine CRUD-Oberfläche für alles\n\n---\n\n## Option B: Separate Tabellen\n\n```\nauthor_profiles     (existiert)\ncontent_structures  (existiert, 5 Rows)\norganization_config (neu)\ncontent_contracts   (existiert, 0 Rows)\nconfig_rules        (neu)\n```\n\n**Vorteile:** Typisierte Felder, klare Schemas\n**Nachteile:** 5+ Tabellen, separate Versionierung\n\n---\n\n## Option C: EAV (Entity-Attribute-Value)\n\n```sql\nconfig_entities (id, type, name)\nconfig_attributes (entity_id, key, value, version)\n```\n\n**Vorteile:** Maximal flexibel\n**Nachteile:** Komplexe Queries, keine Validierung\n\n---\n\n## Empfehlung: Option A\n\n| Kriterium | Option A | Option B | Option C |\n|-----------|----------|----------|----------|\n| Einfachheit | ⭐⭐⭐ | ⭐⭐ | ⭐ |\n| Flexibilität | ⭐⭐⭐ | ⭐⭐ | ⭐⭐⭐ |\n| Versionierung | ⭐⭐⭐ | ⭐ | ⭐⭐ |\n| GUI-Aufwand | ⭐⭐⭐ | ⭐ | ⭐⭐ |\n| Validierung | ⭐⭐ | ⭐⭐⭐ | ⭐ |\n\n**Nächste Schritte bei Option A:**\n1. Migration: Bestehende `author_profiles` + `content_structures` übernehmen\n2. GUI: `\/config` mit Typ-Filter und JSON-Editor\n3. API: MCP-Server `mcp-config` für Zugriff\n\nWelche Option bevorzugst du?"
}