Boards heißen jetzt Projekte – und Runner lernen aus Code Reviews – Spedy Blog

Manche Änderungen sind klein und technisch. Diese nicht. Boards heißen ab sofort Projekte, Runner bekommen ein vollständiges Analytics-Dashboard, und die Standard-Pipeline kann sich jetzt selbst korrigieren. Außerdem lernen Agenten ab sofort aus PR-Review-Kommentaren -- organisationsweit.

Boards → Projekte

Der Name "Board" war von Anfang an eine Krücke. Was in Spedy passiert, ist Projektarbeit -- nicht das Verschieben von Karten auf einem Kanban-Board. Ab sofort heißt es überall Projekte: in der Navigation, in den URLs (/projects statt /boards), in den Einstellungen und in den Webhook-Events.

Was sich ändert:

Navigation: Der Sidebar-Eintrag heißt jetzt "Projekte"
URLs: /boards/... wird zu /projects/... (alte URLs leiten weiter)
Rollen: Board Admin → Projekt-Admin, Board-Mitglied → Projekt-Mitglied, Board-Betrachter → Projekt-Betrachter
Einstellungen: "Runner Teams" im Org-Bereich heißen jetzt "Agents", die Board-Level Runner-Konfiguration heißt "Build & Validate"
Webhook-Events: board.created → project.created, board.updated → project.updated, boardId → projectId

An der Funktionalität ändert sich nichts. Alle bestehenden Konfigurationen, Rollen und Integrationen bleiben erhalten.

Runner Analytics Dashboard

Bisher war die Frage "Wie gut arbeiten meine Agenten?" schwer zu beantworten. Jetzt gibt es eine Antwort: Das neue Analytics-Dashboard unter Einstellungen → Runner → Analytics.

Was du siehst

Übersichtskarten: Gesamtzahl der Jobs, Erfolgsrate, Gesamtkosten, Token-Verbrauch, durchschnittliche Dauer
Stage-Performance: Wie lange jede Pipeline-Stufe dauert, wie viele Tokens sie verbraucht, wie oft Quality Gates bestanden werden
Modell-Nutzung: Token-Verbrauch aufgeschlüsselt nach Modell (Opus, Sonnet, Haiku)
Tägliche Trends: Balkendiagramm mit Job-Volumen über Zeit

Du kannst zwischen 7, 30 und 90 Tagen filtern. Die Daten werden automatisch bei jedem abgeschlossenen Job aktualisiert -- kein manuelles Tracking nötig.

Warum das wichtig ist

Wenn du mehrere Agenten-Teams betreibst, brauchst du Zahlen. Welches Team hat die höchste Erfolgsrate? Welche Stufe verbraucht die meisten Tokens? Wo lohnt sich ein schnelleres Modell, wo reicht ein günstigeres? Das Dashboard gibt dir die Grundlage für diese Entscheidungen.

Selbstheilende Pipeline

Die Standard-Pipeline hat jetzt drei Stufen statt zwei: Planer → Implementieren → Review. Die neue Review-Stufe (Sonnet 4.6) prüft den Code auf Korrektheit, Sicherheit und Qualität -- und behebt gefundene Probleme direkt.

Validierungsbefehle

Zusätzlich kannst du jetzt Validierungsbefehle pro Pipeline-Stufe konfigurieren. Das sind Shell-Befehle, die nach einer Coding-Stufe automatisch ausgeführt werden -- zum Beispiel npm run lint, npm test oder cargo build.

Wenn ein Befehl fehlschlägt, wiederholt der Agent die Stufe und behebt das Problem. Die maximale Anzahl an Wiederholungen ist konfigurierbar (0-10).

Das Setup zeigt jetzt auch das Arbeitsverzeichnis (/workspace/{repoName}) für jedes Repository an, damit du weißt, wo deine Befehle ausgeführt werden.

Gefährliche Befehle werden blockiert

Validierungsbefehle werden serverseitig geprüft. Shell-Injection-Patterns (Semikola, Pipes, Backticks, Redirects) werden automatisch abgelehnt. Nur sichere Einzelbefehle sind erlaubt.

Agenten lernen aus PR-Reviews

Wenn ein Reviewer "Changes Requested" auf einem PR klickt und der Runner den PR überarbeitet, passiert jetzt mehr als nur die Korrektur: Jeder Review-Kommentar wird als Wissenseintrag gespeichert -- mit Dateipfad, Diff-Kontext und Reviewer-Kommentar.

Diese Einträge sind organisationsweit verfügbar. Wenn ein Reviewer auf Projekt A eine Konvention korrigiert, wissen Agenten auf Projekt B beim nächsten Mal Bescheid. Evergreen-Einträge mit hoher Konfidenz (≥ 0.7) werden automatisch geteilt.

Das ist kein Feature, das man aktivieren muss. Es passiert automatisch, sobald PR-Reviews getriggert werden.

Ehrlich gesagt

Das ist eine der Änderungen, bei denen wir selbst gespannt sind, wie sie sich in der Praxis bewährt. Die Idee ist stark: Ein echter Feedback-Loop, bei dem jede Code-Review die nächste Generation von Agent-Runs verbessert. Aber ob die gelernten Konventionen in jedem Kontext passen, wird die Zeit zeigen. Wir beobachten das genau.

Neue Team-Presets: Review Team & Full-Stack Team

Neben den bestehenden Presets "Code Runner" und "Board Agent" gibt es jetzt zwei neue:

Review Team: Zwei KI-Reviewer (Security + Quality) arbeiten parallel, ein Review Lead fasst zusammen und verifiziert
Full-Stack Team: Backend- und Frontend-Agent arbeiten parallel, ein Integration Validator prüft die Zusammenarbeit

Beide Presets sind beim Erstellen eines neuen Teams als Ein-Klick-Option verfügbar. Die konfigurierten Agenten mit Rollen, Modellen und Abhängigkeiten werden direkt in den Team-Einstellungen angezeigt.

Letzte Runs auf dem Dashboard

Der Dashboard-Bereich "Aktive Runner" zeigt jetzt nicht nur laufende Jobs, sondern auch die letzten 5 abgeschlossenen Runs. Du siehst Status, Ticket, Kosten, Branch und relative Zeit. Ein Klick öffnet das Ticket-Seitenpanel auf dem Runs-Tab.

Das spart den Umweg über die Job-Liste, wenn du schnell wissen willst, was gerade fertig geworden ist.

Tickets zurück ins Backlog

Bisher war der Weg aus dem Backlog eine Einbahnstraße. Jetzt kannst du Tickets wieder zurück in den Backlog-Status verschieben -- etwa wenn sich Anforderungen geändert haben oder ein Ticket doch nicht bereit war. Die Statusübergangslogik erlaubt jetzt explizit den Rückweg.

Intelligentere Follow-ups

Wenn ein Agent einen Follow-up-Job auf einem bereits gemergten oder geschlossenen PR erstellt, erkennt Spedy das automatisch. Statt den alten Branch zu aktualisieren, wird ein frischer Branch von main erstellt und ein neuer PR geöffnet. Follow-up-Jobs werden außerdem korrekt unter dem gleichen Root-Run gruppiert -- auch wenn die Session-Zuordnung fehlschlägt.

Sicherheit

Wie bei jedem Update haben wir unter der Haube an der Tenant-Isolation gearbeitet:

Member-Updates prüfen jetzt auf soft-deleted Records
Wiki-Zugriff filtert zusätzlich nach Organisation
Runner-Ticket-Lookups validieren die Organisations-Zugehörigkeit

Keine Features, die man sieht. Aber notwendig für ein Produkt, auf das sich Teams verlassen.

Zusammengefasst

Änderung	Was es bedeutet
Boards → Projekte	Einheitliche Benennung überall
Analytics-Dashboard	Runner-Performance auf einen Blick
3-Stufen-Pipeline	Plan → Implement → Review als Standard
Validierungsbefehle	Automatische Tests nach Coding-Stufen
PR-Review-Learning	Agenten lernen aus Reviewer-Feedback
Team-Presets	Review Team & Full-Stack Team als Schnellstart
Letzte Runs im Dashboard	Abgeschlossene Jobs direkt sichtbar
Tickets ins Backlog	Rückweg jetzt erlaubt
Smarte Follow-ups	Merged-PRs werden erkannt, frischer Branch