Nach der Implementierung der FAL-Lese-Tools (MCP3) und dem CreateFolder-Tool (Session E) stößt die KI
auf eine Lücke: Sie kann Dateien hochladen und Metadaten setzen, aber wenn sie einen
tt_content-Record mit einem Bild-Feld anlegt, kann
WriteTableTool keine sys_file_reference-Einträge erzeugen. Das blockiert den kompletten
Use-Case "AI generiert Bild → lädt es hoch → erstellt Content-Element mit Bild".
Diese Session ist die komplexeste des MCP-Projekts: Copilot muss drei bestehende Dateien modifizieren (TableAccessService, ReadTableTool, WriteTableTool), neue Methoden hinzufügen und eine eigene Testklasse erstellen – alles auf Basis eines einzigen Prompts auf Deutsch.
Prompt auf Deutsch. Jens wechselt hier ins Deutsche ("Das writeTableTool kann keine file_referenzen erstellen..."). Copilot antwortet konsequent auf Deutsch – Sprachwechsel im Verlauf einer Coding-Session ist unproblematisch, solange die technischen Begriffe konsistent bleiben.
sys_file_reference ist als eingeschränkte Tabelle markiert (Zeile 450 in TableAccessService). Schauen wir wie type=file aktuell geblockt wird...type=file-Felder komplett (Zeile 602–606) und sys_file_reference ist als eingeschränkte Tabelle gelistet.type=file Felder freischalten (return false Block entfernen). sys_file_reference bleibt als eingeschränkte Tabelle – nur intern verwendbar.processFileReferences() – Tabelle, Feldname, Parent-UID, PID, File-UIDs-Array → erzeugt sys_file_reference-Records via DataHandlerextractFileFields() – erkennt type=file Felder, extrahiert sie; akzeptiert [5, 12] (UIDs) oder [{fileUid: 5, title: "..."}] (mit Overrides)processFileReferences() aufrufenvalidateRecordData() anpassen – File-Feld-Block entfernen, eigene Validierung via ResourceFactory→getFileObject()'image' => [5, 12] und 'image' => [{fileUid: 5, title: "..."}]WriteTableFileReferenceTest.php.
[5, 12] UND Objekte mit Metadaten-Overrides [{fileUid: 5, title: "..."}]. Das macht die API sowohl einfach als auch mächtig.includeFileReferences() hinzugefügt.uniqid('', true). Warnung auf Zeile 290 ist bestehender Code. ✓ False Positive.canAccessField(): return false-Block für type=file entfernt → File-Felder sind jetzt zugänglich. sys_file_reference bleibt als eingeschränkte Tabelle.
includeFileReferences(); includeRelations() um type=file-Branch erweitert; Connection-Import hinzugefügt.
validateFileFieldValue(), extractFileFields(), processFileReferences(); createRecord() + updateRecord() erweitert; ResourceFactory + FileDoesNotExistException importiert.
Diese Session ist die technisch anspruchsvollste des Projekts. Copilot modifiziert drei bestehende Dateien gleichzeitig, findet dabei eine unerwartete Lücke im ReadTableTool und löst sie eigenständig. Der Plan ist präzise genug, um die Implementierung fehlerfrei zu leiten.
Besonders bemerkenswert: Copilot identifiziert und korrigiert einen Dokumentations-Fehler (veralteter Workspace-Hinweis in InlineRelations.md) – ohne dazu aufgefordert zu werden. Das zeigt, dass eine gute Codebase-Analyse in Austausch 1 auch implizite Qualitätsprobleme aufdeckt.
Das EA-Linter-Problem ist ein Lernmoment: IDE-Linter können False Positives produzieren, besonders bei komplexen Methoden. Copilot klassifiziert den Fehler korrekt – kein unnötiges Code-Umschreiben.
"Die AI kann bis jetzt X... Sie soll in der Lage sein Y zu tun" ist ein starkes Prompt-Muster. Es erklärt nicht nur was fehlt, sondern warum es fehlt und was der gewünschte Zustand ist. Copilot kann so die Lücke präzise verstehen und schließen.
Wenn Copilot offene Fragen in "Further Considerations" stellt (DataHandler-Ansatz?, separate Testklasse?), kann man mit "setze die Empfehlungen um" alle Entscheidungen an Copilot delegieren. Das funktioniert gut, wenn man den Empfehlungen vertraut – und spart Prompt-Aufwand.
Copilot sucht nach dem type=file Handler in ReadTableTool – und findet, dass es ihn gar nicht gibt. Dieser Bug wäre bei einer normalen Code-Review vielleicht übersehen worden. Tiefe Analyse-Prompts ("understand the full codebase first") haben Mehrwert auch für nicht beauftragte Verbesserungen.
Der EA-Linter meldet einen Fehler auf Zeile 882 ("more_entropy fehlt"). Copilot prüft den Code und stellt fest: (a) der eigene Code auf Zeile 1035 ist korrekt, (b) die Linter-Zeilennummer ist falsch. Blindes "Fix all linter errors" hätte hier korrekte Stellen kaputt gemacht.
Die Entscheidung, sys_file_reference als eingeschränkte Tabelle zu belassen (KI hat keinen Direktzugriff) ist ein wichtiges Sicherheitsdesign. File-Referenzen entstehen nur intern durch processFileReferences(). Das verhindert, dass die KI unkontrolliert Relationen anlegen kann.
Die API akzeptiert sowohl [5, 12] (nur UIDs, einfach) als auch [{fileUid: 5, title: "..."}] (mit Metadaten-Overrides, mächtig). Dieses Muster – einfaches Format für den Normalfall, erweitertes für Sonderfälle – ist ideal für KI-konsumierte APIs.
| Element | Qualität | Anmerkung |
|---|---|---|
| Austausch 1 – Prompt | ✓ Sehr gut | Problem-Kontext + Use-Case + drei CRUD-Operationen + API-Constraints |
| Austausch 1 – Antwort | ✓ Exzellent | Präzise Zeilennummern, Sicherheits-Design (sys_file_reference intern), Zweiformat-API, Workspace-Hinweis |
| Austausch 2 – Prompt | ✓ Gut | "Setze die Empfehlungen um" – elegante Delegierung offener Fragen |
| Austausch 2 – Antwort | ✓ Exzellent | ReadTable-Bug eigenständig gefunden, Docs-Fehler korrigiert, False Positive korrekt klassifiziert, 3 Dateien sauber modifiziert |