Marcel Moré stellte die Neuerungen vor, die in den Wochen seit dem letzten Stammtisch in FM-Lab eingeflossen sind – dem auf DuckDB basierenden Framework, das eine FileMaker-Lösung als strukturierten Objektkatalog für AI-Agenten verfügbar macht. Viele der Änderungen gehen auf Rückmeldungen der Betatester zurück: Aus gemeldeten Bugs und Edge-Cases entstanden immer wieder neue Ideen und daraus schließlich neue Features.

Testprofile aus der statischen Code-Analyse

Die statische Code-Analyse (SCA) war bereits in den Vormonaten Thema: SQL-Abfragen, die per DuckDB direkt auf den Objektkatalog laufen und eine importierte Lösung strukturiert durchleuchten – zunächst ganz ohne AI.

Aus einem Feature-Request heraus ist daraus nun das Konzept der Testprofile entstanden. Der Testkatalog umfasst inzwischen rund 95 Einträge, gegliedert in Rubriken wie Best Practices, Performance, Modernisierung oder Plattformkompatibilität. Ein Test ist dabei nur ein Overlay: Er verweist auf vorhandene Dashboards und Custom Queries und ergänzt sie um Metadaten – Rubrik, betroffene Objekttypen, Schlagwörter und den Scope.

Der Scope ist der entscheidende Punkt: Ein Test lässt sich nicht nur gegen die gesamte Lösung fahren, sondern auch gegen eine einzelne Datei, ein einzelnes Objekt, eine Objektliste oder gegen einen Cluster aus der Graph-Analyse. An jedem Objekt – z.B. einem Script – lässt sich im Frontend ein eigenes Test-Panel öffnen, das alle für diesen Objekt-Typ hinterlegten Tests auf einen Schlag ausführt und ein gesammeltes Ergebnis liefert.

Agentische Tests statt Ad-hoc-Queries

Agentische Analyse mit FM-Lab bedeutete bislang, dass der Agent für jede Frage ad-hoc eine eigene Abfrage baute. Das funktionierte gut, führte in Sonderfällen aber dazu, dass er sich verlief oder nicht auf den Kern der Sache stieß.

Ein neuer Skill /fm-test verbindet die Testprofile nun mit der agentischen Analyse. Im System-Prompt ist hinterlegt, dass der Agent auf Symptombeschreibungen wie hängt, langsam, falsche Ergebnisse oder unerwartetes Verhalten proaktiv reagiert: Er fragt den vorhandenen Testbestand ab, wählt die passenden Tests anhand von Keywords aus und wertet zunächst deren strukturierte Ergebnisse aus, anstatt die Lösung direkt selbst zu durchsuchen. Dadurch erhält er schnell und effizient wertvolle Zusatzinformationen, die für das weitere Vorgehen relevant sein können.

Ergänzt wird der Skill durch eine Sammlung kuratierter Analysis Patterns – dokumentierte Vorgehensweisen, wie ein Entwickler an ein Problem herangehen würde, etwa die Auflösung einer Call Chain, jeweils mit dem passenden SQL-Code. Der Agent arbeitet diese Muster strukturiert ab und gewinnt daraus verlässlichen Input.

Wie ein solcher Test entsteht, zeigte Marcel an einem realen Fall: Ein Entwickler hatte eine Schleife, die laufend neue FileMaker-Fenster für Sessions öffnete, sie aber nicht korrekt wieder schloss – wodurch der Vorgang 12 Stunden lang festhing. Für genau diese Asymmetrie zwischen Fenster öffnen und Fenster schließen lässt sich eine DuckDB-Abfrage formulieren. Der Agent erkennt künftig ein Fensterproblem, fährt diesen Test und hat sofort eine Antwort.

Erweiterbarkeit als Prinzip

Ein wichtiger Punkt der Test-Architektur ist die Ausbaufähigkeit. Patterns, Testprofile, Tests, Dashboards und Custom Queries sind vier frei erweiterbare Bereiche – jeder kann sich seinen eigenen Bestand aufbauen. Neue Dashboards muss man dabei nicht selbst programmieren: Man beschreibt dem Agenten die Fragestellung (“zeig mir alle Layouts, bei denen die Buttons rechts statt links stehen”), er baut die SQL-Query, und das Ergebnis steht sofort zur Verfügung. Diese Regeln lassen sich dann in einem Testpattern zusammenfassen.

Das Fernziel ist eine Community-getriebene Pattern-Library: Wer für seine Nomenklatur oder Architektur ein eigenes Testset entwickelt, kann es als ZIP-Datei exportieren damit andere es von GitHub nachinstallieren können.

Plattformkompatibilität

Aus dieser Idee heraus ist außerdem bereits ein ganzes Testfeld zur Plattformkompatibilität entstanden. Das Schema von FM-Labs Schwesterprojekt fm-spec wurde dafür erweitert: Für jeden Scriptschritt und jede Funktion ist hinterlegt, mit welchen Plattformen und welchen Betriebssystemen sie kompatibel ist – Windows, Mac, iOS, Server, WebDirect – und zusätzlich ob es sich um eine plattform-spezifische Funktion handelt.

Bei den FileMaker-Scriptschritten selbst ist die Ausbeute überschaubar; Betriebssystem-spezifisch sind im Kern nur AppleScript ausführen und DDE ausführen. Interessanter wird es bei der Plattform-Kompatibilität und der Server-Prüfung: FM-Lab erkennt Scripte, die per Script auf Server ausführen bzw. über den neuen Befehl mit Ergebnisrückgabe aufgerufen werden, und liefert dazu die Call Sites – also den aufrufenden Schritt und das Script, das auf dem Server laufen soll. Beides nützliche Kontext-Informationen für die Analyse des Ablaufs.

MBS-Plugin: Mindestversionen automatisch ermitteln

Noch umfangreicher fällt die Auswertung beim MBS-Plugin aus. Christian Schmitz pflegt die Plattform- und Versionsangaben sauber in den Metadaten seiner Dokumentation – FM-Lab macht diese rund 8.000 Funktionen nun maschinenlesbar nutzbar.

Damit lässt sich eine Lösung darauf durchleuchten, welche MBS-Befehle überhaupt verwendet werden und ab welcher Plugin-Version sie unterstützt sind. Das Ergebnis ist eine konkrete Aussage: Welche Mindestversion muss installiert sein, damit die gesamte Lösung läuft? Gegenprobe inklusive – gibt man eine vorhandene Version an, listet der Test die Fundstellen, die damit zu Problemen führen würden.

Die MBS-Dokumentation wird dabei bewusst nicht mitgeliefert – sie ist Eigentum von MonkeyBread Software. Stattdessen gibt es einen Parser, der das frei verfügbare Dash-Docset einliest, maschinenlesbar aufbereitet und auf die eigene Lösung mappt. Somit entsteht ein Datenbank-basierter Cache, der sich lokal abfragen lässt, ohne weiteren Traffic auf der MBS Website zu erzeugen – ein einmaliger Download des Dash-Docsets genügt.

Doppelte UUIDs beim XML-Import

Ein wiederkehrendes Problem betraf den Import großer XML-Dateien mit doppelten UUIDs. Die Ursachen sind unterschiedlich: Zum einen entstehen sie beim Arbeiten mit Datei-Klonen, zum anderen – wie Armin beim letzten Mal erläutert hatte – wenn eine ältere FileMaker-Version eine neuere Datei öffnet, Layoutobjekte kopiert und zurückschreibt, ohne die Objekte korrekt auflösen zu können.

Bisher ließen sich solche Lösungen nicht sauber in den Objektkatalog importieren. Die neue FM-Lab Version bringt dafür eine Auto-Healing-Funktion mit: Bei Duplikaten werden fortlaufend synthetische UUIDs erzeugt und in eine Mapping-Tabelle geschrieben, und zwar stabil, sodass sie mehrere Importe überleben, solange sich die Struktur nicht ändert. Die Lösung wird damit vollständig importiert, alle Referenzen bleiben intakt. Ein eigener Test weist aus, ob es solche UUID-Kollisionen gibt. Wichtig: Geheilt wird ausschließlich der Analysebestand, niemals die Originallösung.

Weitere Neuerungen

  • Multi-Lösungsfähigkeit: Mehrere Lösungen lassen sich parallel laden, unabhängig selektieren, importieren und von mehreren Frontends abfragen.
  • fm-spec Browser: Der Abschnitt in den Einstellungen zeigt zu jedem Scriptschritt die interne Bezeichnung, die Scriptschritt-Nummer, die FileMaker-Version, neuerdings die Plattformzugehörigkeiten, eine Kurzbeschreibung der Parameter sowie die passenden XML-Snippets – sowohl im Snippet- als auch im Patch-Tool-Format.
  • Schlankerer System-Prompt: Die CLAUDE.md ist von einem Sammelbecken auf knapp 150 Zeilen zusammengeschrumpft. Sie enthält nur noch Rollen, Möglichkeiten und die wichtigsten SQL-Queries für die Ad-hoc-Analyse; alles Weitere ist nach docs/ ausgelagert und wird von dort referenziert. Das hält die Struktur flexibel und spart Tokens.

Sneak Peek: FileMaker-Scripte in VS Code

Als Ausblick zeigte Marcel ein noch unveröffentlichtes VS-Code-Plugin, das Linter und Gate enthält und direkt auf die DuckDB Datenbank zugreift – mit dem durchaus ambitionierten Ziel, den FileMaker-Script-Workspace zu ersetzen.

VS Code fungiert dabei als alternatives Frontend zum Objektkatalog: Man wählt eine Datei, navigiert durch den kompletten Scriptbestand und sieht die Scripte im Klartext, live verdrahtet mit dem Objektmodell. Der Linter arbeitet gegen die technisch kodierte fm-spec und kennt damit alle Scriptschritte, Parameter und deren Eigenschaften inkl. Parameter und Sonderformen. Die Autovervollständigung schlägt daher nicht nur Scriptschritte FileMaker-getreu vor, sondern kennt darüberhinaus die Objekte der Lösung: Beim Tippen eines Feldnamens holt sie die tatsächlich existierenden Felder validiert aus dem Objektkatalog. Ebenso werden Referenzen auf andere Objekttypen wie Layouts, Table-Occurences, globale Variablen, etc. sauber aufgelöst und direkt auswählbar gemacht.

Dazu kommen die Bordmittel der IDE: Inline-Chat und Code-Generierung, wahlweise über GitHub Copilot oder das Claude Code-Plugin. Generierter Code läuft anschließend wieder durch den Linter. Damit wird zuverlässige Code-Generierung maßgeschneidert für die vorhandenen FileMaker Lösung möglich.

Wer nicht auf das VS Code Plugin warten möchte, kann bereits heute mit dem Skill /fm-generate-script über den selben Mechanismus maßgeschneiderte FileMaker Scripte erzeugen, die anschließend als XML-Snippet per Clipboard in den FileMaker Script-Workspace übertragen werden können.

Vier Wege zum Code-Generieren

Für das agentische Erzeugen von Code ist FM-Lab auf vier Strategien vorbereitet:

  1. XML-Snippets über die Zwischenablage – siehe [[2026-08_Agentic-Coding-fuer-FileMaker|Erfahrungsbericht von Thomas Hirt zum Agentic Coding]].
  2. fmIDE ActionScript – Russell Watsons Makrosprache zum Erzeugen, Ändern, Duplizieren und Löschen von Scripten und perspektivisch weiteren Objekten. Die Codierung für fmIDE im fmJAML Format steht bereits maschinenlesbar in fm-spec; dieser Layer ist nahezu vollständig vorbereitet.
  3. Claris Patch Tool – Erzeugung von Snippets im SaXML Patch-Format, um eine Lösung direkt darüber zu verändern, inkl. Schema, Layouts, TOs, etc.
  4. Computer Use – der Agent steuert den FileMaker-Script-Editor selbst fern. Noch Zukunftsmusik.

Fazit

Die Strategie von FM-Lab, zunächst das Grundlagen-Verständnis und die Code-Analyse einer FileMaker-Lösung vollständig abzubilden, zahlt sich nun aus. FM-Lab wird zum vollständigen Agent Harness für agentisches FileMaker Coding. Es bringt nicht nur eine technische Pipeline zur Code-Generierung mit, sondern auch zahlreiche Werkzeuge und eine umfangreiche Datenbank-gestützte Spezifikation sowie strukturierte Regeln zum Workflow und zur Überprüfung der Ergebnisse.