Zum Abschluss des Abends knüpfte Marcel Moré direkt an die vorherige Diskussion an: Statt den Bildschirm zu beobachten, um zu verstehen, was in einer FileMaker-Lösung passiert, kann ein Agent die Struktur auch direkt aus der Lösung auslesen. Wie das aussieht, zeigte er an zwei neuen Funktionen in FM-Lab.

Die Vorlage: fmCheckMate

Der Anstoß kam aus einem Feature Request zur Frage, ob sich bestimmte Defekte in Layouts automatisch erkennen lassen. Russell Watson, der an diesem Abend leider nicht dabei war, verwies daraufhin auf seine eigene Arbeit: Über viele Jahre hat er sich intensiv mit der Analyse von Benutzeroberflächen beschäftigt – nicht zuletzt, weil eine große Lösung von Classic-Themes auf moderne Themes umgebaut werden musste. Daraus entstand eine umfangreiche Sammlung von mehreren Hundert XSLT-Transformationen, die seit rund acht Jahren auf GitHub liegt und mit fmCheckMate genutzt werden kann.

Das Problem: Die Sammlung ist so kryptisch zu bedienen, dass wohl kaum jemand außer Russell selbst sinnvoll damit arbeitet. XSLT muss erst gegen das XML laufen, danach müssen die Ergebnisse wieder eingelesen werden.

Layout Quality in FM-Lab

Claude hat diese Logik nun als SQL-Abfragen neu interpretiert, die direkt auf der DuckDB-Datenbank von FM-Lab laufen. So entstand eine neue Rubrik in der statischen Code-Analyse: Layout Quality. Noch umfasst sie nicht den kompletten Umfang von Russells Sammlung, aber die wesentlichen Prüfungen sind in 18 Dashboards abgebildet.

Jedes Dashboard ist eine Abfrage auf ein bestimmtes Muster im gesamten Objektkatalog. Der Clou: Ein Klick auf einen Treffer springt direkt ins betroffene Layout und markiert das fehlerhafte Objekt. Russells Sammlung hat damit eine Oberfläche bekommen, mit der man interaktiv arbeiten kann.

Es gibt zwei Wege, die Prüfungen zu nutzen:

  • Über die Dashboards für die gesamte Lösung. Per Run all werden alle Prüfungen über Hunderttausende Objekte ausgeführt, und ein Ampelsystem zeigt, wo man genauer hinschauen sollte.
  • Als Test für ein einzelnes Layout. Die Layout-Tests erhalten farbige Fähnchen – in Ordnung, Warnung oder Problem. Ein Problem lässt sich aufklappen, etwa eine Broken Field Reference, also ein Feld, das in der Tabelle gar nicht mehr existiert.

Neben solchen eindeutigen Fehlern finden die Tests auch Erfahrungswissen, etwa Objekte, die hinter einem Containerfeld oder einem Portal verborgen liegen und im Layout dadurch nicht sichtbar sind.

Layout Geometry Explorer

Ergänzend gibt es den Layout Geometry Explorer. Hier lässt sich ein Bereich per Koordinaten definieren – etwa alles ab 300 Pixeln vom linken Rand –, eingrenzen auf einen Layoutbereich wie den Datenbereich und auf einen Objekttyp wie Eingabefelder oder Tastenleisten. So bricht man die Zigtausenden Objekte einer Lösung datengetrieben auf die relevanten Fundstellen herunter und springt per Klick wieder direkt ins Layout.

Script-Trace

Die zweite Neuerung ist der Trace, der auf der Graph-Analyse von FM-Lab aufbaut. Bisher zeigte die Graph-Ansicht zu einem Skript alle verknüpften Elemente. Sobald man aber in die zweite Ebene ging, wurde es “blitzschnell unübersichtlich”: Kommt ein Skript an einem Layout mit 100 Feldern vorbei, landen alle 100 im Graphen, ob sie im Skript vorkommen oder nicht.

Der Trace geht dagegen rekursiv nur den tatsächlichen Pfad eines Skripts entlang. Marcel zeigte das an einem Skript für den Excel-Export. FM-Lab sammelt dabei alle aufgerufenen Unterskripte, die tatsächlich verwendeten Felder und Variablen sowie die betretenen Layouts – inklusive der dort ausgelösten Layout- und Feld-Trigger, die ein eigenes Symbol erhalten. Wird es zu voll, lassen sich Kategorien wie Felder oder Variablen ausblenden, bis nur noch der reine Skriptverlauf sichtbar ist, auf Wunsch gruppiert über Dateigrenzen hinweg.

Auf Nachfrage, ob er das selbst nutzt, antwortete Marcel: gelegentlich, vor allem bei komplexen Abläufen und dateiübergreifenden Aufrufen. Bei einfachen Skripten lohne es sich meist nicht, bei komplexen durchdringe man den Ablauf damit aber sehr viel schneller.

Hybrid: agentisch analysieren, visuell prüfen

Alle Funktionen stehen auch als Skills für Claude zur Verfügung. In der Demo fand Claude per Anfrage das gesuchte Skript und erklärte, was es tut. Mit dem Skill /fm-show öffnete er es anschließend direkt in der Oberfläche von FM-Lab, /fm-trace visualisiert den rekursiven Ablauf, und /fm-open öffnet die FileMaker-Lösung selbst. Die Idee dahinter ist ein hybrider Ablauf: Der Agent analysiert, und der Mensch kann per Skill jederzeit in die Oberfläche springen und sich das Ergebnis zeigen lassen.

Erfahrungswissen statt Tokens

Bemerkenswert ist, dass die Dashboards selbst gar nichts mit AI zu tun haben. Sie bilden schlicht Erfahrungswissen ab: Was will man in einer Lösung sehen? Ein solches Dashboard lässt sich – ähnlich wie die gespeicherten Berichte bei Matt Navarres Pythia – einmal per Skill /create-custom-dashboard vom Agenten bauen und dann als Schablone auf jede neue Lösung anwenden.

Marcels Überlegung dahinter: Wenn Coding-Agenten solche datengetriebenen Analysen als Skills und Werkzeuge zur Verfügung haben, kommen sie in einer FileMaker-Lösung um ein Vielfaches schneller zurecht, als wenn sie alles über Bildschirmbeobachtung oder lange Erklärungen selbst herausfinden müssen. Das spart Tokens – und macht die Arbeit der Agenten deutlich effizienter.

Weitere Infos

Github: FM-Lab
https://github.com/marcel-more/fm-lab

FM-Lab - Static Code Analysis
https://github.com/marcel-more/fm-lab/blob/main/docs/fm-lab/Wiki/Static%20Code%20Analysis.md

FM-Lab - Skills
https://github.com/marcel-more/fm-lab/blob/main/docs/fm-lab/skills/Skills.md

Github: fmCheckMate-XSLT
https://github.com/mrwatson-de/fmCheckMate-XSLT