Preview-Agent: Berechtigungen, Befehle und Auto-PR

Der Coding-Agent in der Live-Preview bekommt klare Leitplanken: Du legst pro Projekt fest, welche Werkzeuge er nutzen darf, was er in den Preview-Containern darf und welche Befehle vor und nach jedem Run laufen. Und jeder erfolgreiche Run endet ab sofort automatisch in einem Pull Request — damit nichts, was der Agent baut, ohne deine Review liegen bleibt.

Berechtigungen: Du bestimmst, was der Agent darf

Unter Projekt → Einstellungen → Agent-Einrichtung gibt es den neuen Abschnitt Preview-Agent. Dort steuerst du, was der Agent während eines Runs in der Preview tun darf:

• Werkzeuge einschränken — Standardmäßig darf der Agent Dateien lesen und bearbeiten. Wenn du es genauer willst, aktivierst du die Einschränkung und wählst das erlaubte Set einzeln aus: Lesen, Bearbeiten, Suchen, Web-Recherche und mehr. Eine Shell steht nie zur Auswahl — der Preview-Agent bekommt grundsätzlich kein Bash.
• Zugriff auf Preview & Container — Drei Schalter legen fest, wie der Agent seine eigenen Änderungen prüfen darf: die Live-Preview per HTTP abrufen (preview_fetch), Befehle in den Preview-Containern ausführen (preview_exec) und Container-Logs lesen (preview_logs). Alle drei sind standardmäßig an, laufen über ein abgesichertes Gateway pro Run und werden protokolliert — ohne Shell-Zugriff und ohne Git-Zugangsdaten.

Das ist die Arbeitsteilung, die wir für richtig halten: Der Agent kann selbstständig prüfen, ob seine Änderung wirklich funktioniert — aber nur innerhalb der Grenzen, die du gezogen hast.

Pre- und Post-Run-Befehle

Manche Projekte brauchen Handgriffe rund um einen Agent-Run: Abhängigkeiten installieren, bevor der Agent loslegt, oder ein Theme neu kompilieren, damit die Änderung in der Preview sichtbar wird. Genau dafür gibt es jetzt Pre-Run- und Post-Run-Befehle — pro Projekt konfigurierbar, direkt im selben Abschnitt:

• Pre-Run-Befehle laufen vor dem Agenten, z. B. npm ci. Schlägt einer fehl, bricht der Run ab, bevor der Agent startet — er arbeitet nie auf einer halb aufgebauten Umgebung.
• Post-Run-Befehle laufen nach dem Agenten, z. B. bin/console theme:compile && bin/console cache:clear bei Shopware. Ein Fehler erzeugt hier nur eine Warnung, der Run bleibt erfolgreich.

Jeder Befehl kann optional einem bestimmten Compose-Service zugewiesen werden — ohne Angabe läuft er im Primär-Container. Einzelne Befehle lassen sich per Schalter deaktivieren, ohne sie zu löschen.

Das ist bewusst die kontrollierte Alternative zu einer Agent-Shell: Statt dem Agenten freie Kommandos zu erlauben, definierst du einmal, was in deinem Projekt nötig ist — und genau das läuft dann bei jedem Run, zuverlässig und nachvollziehbar.

Auto-PR: Jeder Run endet in einem Pull Request

Bisher musstest du nach einem Agent-Run im Ticket selbst auf PR erstellen klicken. Das ändert sich: Nach jedem erfolgreichen Run committet und pusht Spedy die Änderungen und öffnet automatisch einen Pull Request. Existiert für den Branch schon einer, wird er weiterverwendet und im Ticket verlinkt.

Der Gedanke dahinter: Der Pull Request ist dein Kontrollpunkt. Der Agent schlägt vor — gemergt wird erst, wenn du reviewt hast. Mit Auto-PR liegt jeder Vorschlag sofort dort, wo dein Review-Prozess ohnehin stattfindet, statt unbemerkt auf einem Branch zu warten.

Das ist eine Verhaltensänderung mit Standard „an“. Wenn du PRs lieber weiterhin manuell erstellst, deaktiviere in den Berechtigungen des Preview-Agents den Schalter Pull Request automatisch erstellen — der manuelle Button bleibt dann erhalten.

Außerdem neu: Ist für das Projekt ein Runner-Team hinterlegt, gilt dessen System-Prompt samt zugewiesener Skills jetzt auch für Preview-Runs — der Agent verhält sich in der Preview also genauso, wie du ihn für Runner-Jobs konfiguriert hast.

Aufgeräumt: Preview-Stack-Auswahl entfernt

In den Board-Einstellungen gab es bisher einen Preview-Stack-Dropdown. Der ist weg — ersatzlos, und das ist eine gute Nachricht: Previews booten immer den Stack deines eigenen Repos, also deine docker-compose.preview.yml plus .spedy/preview.yml, wie in der Preview-Konfiguration beschrieben. Die Auswahl hatte keine Funktion mehr und konnte im Zweifel nur verwirren. Du musst nichts tun.

Ein einheitliches Design im ganzen Dashboard

Zum Schluss etwas fürs Auge: Das gesamte Web-Frontend wurde auf unser Design-System migriert. Buttons, Eingabefelder, Badges und Statusanzeigen sehen jetzt überall gleich aus — Status wird konsequent über einen dezenten Farbpunkt statt bunter Flächen angezeigt, Flächen sind ruhiger, und der Dark Mode ist in allen Bereichen konsistent. An der Funktionalität ändert sich dadurch nichts; die Oberfläche wirkt einfach aufgeräumter und einheitlicher — vom Zeiterfassungs-Report bis zu den Wiki-Einstellungen.

Alle Änderungen sind ab sofort verfügbar. Fragen oder Feedback? Melde dich über das Kontaktformular.