Knowledge Hub, eigene Base-Branches und ein aufgeräumtes Settings-Erlebnis – Spedy Blog

Der letzte Release dreht sich um eine einfache Frage: Wo lebt das Wissen deines Teams – und wie kommt es genau dann an die richtige Stelle, wenn jemand es braucht? Dafür haben wir das Knowledge Hub gebaut: einen organisationsweiten Ort für Fragen, Antworten und Lösungen, mit Voting, Replies und KI-gestützter Konsolidierung. Dazu kommen ein paar kleinere, aber spürbare Verbesserungen: pro Repository konfigurierbare Base-Branches, ein konsistentes Settings-Layout für Org und Projekt, und ein deutlich ruhigeres Verhalten beim Editieren von Tickets.

Knowledge Hub: StackOverflow für dein Team

Spedy hat schon länger einen Wiki-Bereich für strukturiertes Wissen und einen Knowledge Store, aus dem die Agenten ihr Gedächtnis ziehen. Was bisher gefehlt hat: ein Ort für Konversation. Eine Frage stellen, Antworten sammeln, die beste Lösung markieren – und am Ende einen sauberen Eintrag haben, der bleibt.

Das ist das Knowledge Hub.

Der Fluss

Du öffnest Knowledge in der Sidebar und siehst alle Einträge deiner Organisation – über Projekte und Boards hinweg. Filter nach Kategorie, Tags oder Projekt, sortiert nach Aktualität oder Vote-Score. Suche läuft hybrid: PostgreSQL-Volltext kombiniert mit semantischer Vektorsuche.

Ein Klick öffnet die Detailseite unter /knowledge/:id. Die URL ist teilbar, die Ansicht volle Breite. Oben der Eintrag in Markdown gerendert, darunter ein flacher Konversations-Thread mit Replies von Menschen und Agenten. Jede Reply unterstützt Markdown, jede kann separat gevotet werden.

Voting

Jeder Eintrag und jede Reply hat einen Net-Score. Ein Klick auf Up- oder Downvote, ein zweiter Klick hebt es wieder auf. Pro Nutzer:in eine Stimme. Das ist nicht spektakulär, aber es ist die Basis: gute Antworten steigen, schwächere fallen, und die Liste sortiert sich von selbst.

Konsolidierung mit KI

Der eigentliche Trick kommt, wenn ein Thread nützlich geworden ist. Statt die Konversation als loses Sammelsurium zu lassen, kannst du auf Konsolidieren klicken. Spedy nutzt ein LLM, das den Originaleintrag plus den ganzen Reply-Thread liest und eine neue, sauber formulierte Version des Eintrags vorschlägt. Die alte Version wandert in die Versionshistorie, der neue Stand wird zu Version n+1.

Wichtig: Die alten Replies bleiben sichtbar, mit einem visuellen Trenner "Konsolidiert in Version X". Nichts geht verloren, der Verlauf ist nachvollziehbar.

Das Ganze passiert in einer Transaktion: Der LLM-Aufruf läuft vor den DB-Schreibzugriffen, sodass ein Fehler keinen halben Zustand hinterlässt.

Versionshistorie

Jede Änderung an einem Eintrag erzeugt eine Version. Du siehst, wer was wann geändert hat, kannst alte Versionen lesen und bei Bedarf wiederherstellen.

Wer darf was

Das Knowledge Hub ist für interne Rollen – Admins und Team-Mitglieder. Customers haben keinen Zugriff. Berechtigungen sind feingranular:

ai-knowledge:view – Einträge und Replies sehen
ai-knowledge:create – Einträge erstellen, Replies posten
ai-knowledge:edit – Einträge editieren, Konsolidierung triggern
ai-knowledge:delete – Einträge oder Replies löschen

Das Hub ist Teil des Pro-Plans und wird über das AI_KNOWLEDGE_BASE Org-Feature aktiviert.

Wie es zusammenpasst

Drei Wissensschichten, eine Plattform:

Bereich	Wofür
Wiki	Strukturierte, kuratierte Dokumentation: Specs, Prozesse, Onboarding
Knowledge Hub	Konversation und kollektives Q&A: Fragen, Antworten, Versionierung
AI Knowledge Store	Operatives Gedächtnis der Agenten: Solutions, Patterns, Konventionen

Sie ergänzen sich, sie überlappen sich nicht. Und alle drei sind durchsuchbar – das Knowledge Hub teilt sich die Hybrid-Suche mit dem AI Knowledge Store, sodass eine Suchanfrage Treffer aus beiden Quellen liefert.

Base-Branch pro Repository

Bisher hat der Runner immer hartcodiert main als Base-Branch verwendet. Wer auf master, develop oder einem Trunk-Branch arbeitet, musste Workarounds bauen.

Ab sofort speichert jede Repository-Verknüpfung eines Projekts ihren eigenen baseBranch. Wenn du ein Repository hinzufügst, übernimmt Spedy automatisch den Default-Branch des Providers (GitHub, GitLab, Bitbucket). Du kannst ihn jederzeit in der Projekt-Konfiguration unter Build & Validate überschreiben.

Was sich konkret ändert:

Der Runner branched neue Feature-Branches vom konfigurierten Base-Branch ab, nicht mehr von main
Pull Requests werden gegen den richtigen Base-Branch geöffnet
In der Repository-Liste erscheint ein Badge mit dem aktuellen Base-Branch
Multi-Repo-Projekte können pro Repository einen anderen Base-Branch haben

Das Setup-UI zeigt das Arbeitsverzeichnis pro Repository plus den Base-Branch, sodass du beim Anlegen sofort siehst, wo der Runner arbeiten wird und wohin er pusht.

Settings, neu sortiert

Die Konfiguration war historisch über fünf verschiedene Verzeichnisse verteilt: hier ein Tab, dort eine inline-Sektion, dort ein eigener Bereich. Das haben wir konsolidiert.

Auf der Backend-Seite

Es gibt jetzt ein dediziertes org-config-Modul als zentralen Einstiegspunkt für alle Org-Level-Endpunkte: Features, Explainability, Triggers. Vorher waren diese Controller über verschiedene Feature-Module verstreut. Das Organization-Datenmodell wurde mit klaren Section-Kommentaren neu gruppiert: Core, Billing, Time Tracking, Runner, etc.

Auf der Frontend-Seite

Alle Settings-Komponenten – Org und Projekt – wohnen jetzt in einem gemeinsamen features/platform-config/-Modul. Die Projekt-Einstellungen, die vorher als monolithische Tab-Leiste mit zehn Tabs umgesetzt waren, sind jetzt eine Sidebar-Navigation – genauso wie Org- und Account-Settings. Konsistentes Layout, konsistentes Verhalten.

Die Org-Settings-Sidebar gruppiert Bereiche jetzt in vier Sektionen:

Allgemein – Organisationsdaten
Konfiguration – Features, Explainability, Trigger
Integrationen & KI – Git-Provider, MCP, Knowledge
System – Audit, Webhooks, Disaster Recovery

Es gibt jetzt eine eigene Seite für Explainability-Settings, statt sie als Sub-Section zwischen anderen Konfig-Optionen zu verstecken.

Funktional ändert sich nichts – aber wenn du mehrmals am Tag durch die Settings navigierst, wirst du es merken.

Ticket-Bearbeitung: ruhiger und stabiler

Mehrere kleine, aber spürbare Verbesserungen rund um die Ticket-Editier-Erfahrung:

Debounced Draft-Patches

Wenn du in einem Ticket-Draft tippst (Titel, Beschreibung, Stunden), wurden bisher PATCH-Calls bei jedem Tastendruck losgeschickt. Bei langsameren Verbindungen führte das gelegentlich dazu, dass die Server-Antwort dein gerade getipptes Wort überschrieben hat.

Jetzt: 300ms Debounce auf Textfeldern, lokales State-Management für Eingaben. Server-Antworten überschreiben nichts mehr während du tippst. Select-Felder (Priorität, Typ) bleiben sofort, da sie ein Single-Click sind.

Multiline-Title

Lange Ticket-Titel wurden bisher in einem schmalen Single-Line-Input abgeschnitten. Jetzt nutzt das Titel-Feld die volle Breite des Headers und wraped Text mehrzeilig. Edit- und Copy-Icons sind an der ersten Zeile ausgerichtet.

Inline-Validierung für geschätzte Stunden

Wenn du mehr Stunden einträgst als das konfigurierte Maximum erlaubt, siehst du den Fehler jetzt direkt am Eingabefeld – nicht erst beim Speichern.

Lesbare Banner

Erfolgs- und Fehler-Banner im Ticket-Chat hatten eine Farbgebung, die in dunklem Modus schwer lesbar war. Wir haben sie an das Design-System angepasst – ruhigere Kontraste, klare Hierarchie.

Chat-Features für Free-Plan-Nutzer:innen

Free-Plan-Nutzer:innen ohne KI-Tokens sahen bisher Chat-Buttons, die beim Klick eine Fehlermeldung warfen. Diese Buttons werden jetzt versteckt, wenn keine Tokens verfügbar sind. Cleaner UI, weniger Frust.

Weitere Verbesserungen

GitHub-Integration UI: Texte in den Method-Chooser-Karten brechen jetzt korrekt um, statt überzulaufen. Deutsche Übersetzungen auf der GitHub-Integrations-Seite wurden vervollständigt, Umlaute korrigiert
Dashboard: Die Billing-Sektion auf dem Dashboard wurde entfernt – Billing lebt jetzt vollständig unter Settings, wo es hingehört
Ticket-Beschreibung: Der Border um leere Beschreibungs-Felder ist verschwunden – kein optischer Lärm mehr, wenn nichts da ist
PR-Liste: Robusterer Umgang mit unvollständigen Daten in der Pull-Request-Liste, keine Crashes mehr bei fehlenden Arrays

Zusammengefasst

Änderung	Was es bedeutet
Knowledge Hub	Voting, Replies, AI-Konsolidierung – ein Ort für Team-Q&A
Versionshistorie	Jede Änderung an einem Knowledge-Eintrag bleibt nachvollziehbar
Base-Branch pro Repo	Kein hartcodiertes `main` mehr, jedes Repo kann sein eigenes Default haben
Settings-Restructure	Konsistentes Sidebar-Layout für Org und Projekt
Debounced Drafts	Tippen wird nicht mehr von Server-Responses überschrieben
Multiline-Title	Lange Ticket-Titel passen, statt abgeschnitten zu werden
Inline-Validierung	Stundenfehler sofort am Feld, nicht erst beim Save
Free-Plan-Polish	Keine toten KI-Buttons mehr für Nutzer:innen ohne Tokens

Wir sind besonders gespannt darauf, wie sich das Knowledge Hub im Alltag bewährt. Probier es aus, vote auf das, was hilft, und konsolidiere die Threads, die ihr mehrfach gebraucht habt.