bifroest/app/help/pages/workspace-admin.md

Für Workspace-Admins

Als Workspace-Admin richtest du einen Workspace ein und verantwortest ihn: wer Mitglied ist, welche Daten die KI sieht, welche Aktionen eine Freigabe brauchen und was es kostet.

Workspace anlegen

Unter Workspaces → Workspace anlegen einen Namen und eine Beschreibung eingeben und das Team wählen. Möglich ist das für Teams, in denen du Mitglied bist. Du wirst automatisch Admin des neuen Workspace.

Die KI sieht Name und Beschreibung als Kontext; eine gute Beschreibung („Backend des Bestellsystems, Python/FastAPI“) verbessert die Antworten.

Workspace startklar machen

Nach dem Anlegen in dieser Reihenfolge. Was davon zur Verfügung steht, hängt davon ab, was der Plattform-Admin eingerichtet hat.

1. Mitglieder aufnehmen (Einstellungen → Mitglieder), mindestens eine Person als Freigeber oder zweiten Admin.
2. Daten verbinden (Daten → Verbinden): Git-Repository, Dateien, Ordner oder Datenbank. Klappt, wenn die Quelle „ok“ bzw. „verbunden“ zeigt.
3. Pull Requests: An einer Git-Quelle unter Pull Requests „Bitbucket Data Center“ wählen, wenn Änderungen der KI als Pull Request zurückgehen sollen. Der Zugang braucht Schreibrechte auf Branches ai/*. Klappt, wenn unter Änderungen „Pull Request erstellen“ geht.
4. Gedächtnis: Munin unter Einstellungen → MCP-Server → Zentrale Server mit dem Munin-Key eures Projekts freischalten. Klappt, wenn nach „Merk dir …“ ein Eintrag unter Gedächtnis steht.
5. Pakete aus Hugin: unter Einstellungen → Hugin den Integrations-Key eintragen, Pakete wählen, Abgleichen, Übernehmen. Klappt, wenn im Chat / eure Befehle vorschlägt.
6. Webhook für Teams oder Slack unter Einstellungen → Allgemein → Benachrichtigungen, wenn Freigaben auch dort ankommen sollen.
7. Beispielfragen unter Einstellungen → Allgemein, damit Neue sehen, was hier geht.
8. Ausprobieren: eine Beispielfrage stellen und die Tool-Schritte unter der Antwort ansehen.

Mitglieder und Rollen

Unter Einstellungen → Mitglieder fügst du Personen aus dem Team hinzu und änderst ihre Rolle direkt:

Rolle	Rechte
Mitglied	Chatten, Dateien hochladen, Branches pushen und Pull Requests erstellen
Freigeber	Zusätzlich Freigabeanträge des Workspace entscheiden und dazu benachrichtigt werden
Admin	Alles: Einstellungen, Mitglieder, Datenquellen, Tools und Regeln, Freigaben

Es muss immer mindestens ein Admin bleiben. Freigeber lohnen sich, damit Anträge auch entschieden werden, wenn kein Admin da ist.

Datenquellen

Datenquellen verbindest, testest und bearbeitest nur du als Admin, unter Daten. Der Chat steht erst bereit, wenn eine Quelle erfolgreich getestet oder eine Datei hochgeladen wurde, außer du schaltest Ohne Datenquellen chatten ein.

Beim Verbinden bestätigst du, dass alle Mitglieder die Inhalte der Quelle über die KI sehen dürfen. Der Zugriff erfolgt mit einem technischen Zugang, nicht mit den Rechten der einzelnen Mitglieder.

Git-Repository verbinden

• URL: nur https:// zu freigegebenen Hosts, ohne Zugangsdaten in der URL.
• Ziel-Branch: z. B. main oder develop. Standard für alles, was die KI liest, wovon ihre Chat-Branches abzweigen und wohin Pull Requests gehen. Andere Branches bleiben nutzbar: unter Repository ansehen oder einen Chat auf einem bestehenden Branch starten. Nach einer Änderung wird die Quelle neu getestet; offene Chat-Branches behalten ihr bisheriges Ziel.
• Token des technischen Accounts: wird verschlüsselt gespeichert und nie wieder angezeigt. Zum Lesen reichen Leserechte.
• Nutzername (optional): leer für Bitbucket Data Center (das Token geht als Bearer mit). Für andere Git-Server, etwa Gitea, Forgejo oder einen klassischen HTTPS-Server, den Nutzernamen des technischen Accounts eintragen; GitLab: oauth2, GitHub: x-access-token. Das Token gilt dann als Passwort. Lesen, Commits der KI und Branch pushen funktionieren so mit jedem HTTPS-Git-Server; Pull Requests aus dem Chat gibt es nur mit Bitbucket Data Center, sonst legt ihr sie im Git-Server an.
• Pull Requests: Bitbucket Data Center, wenn Mitglieder Pull Requests aus dem Chat erstellen sollen. Das Token braucht dann Schreibrechte. Beschränke sie per Branch Permission auf ai/*, damit die Plattform nur auf diese Branches schreiben kann.
• Branch nach Merge oder Ablehnung löschen (Standard an): Die Plattform räumt abgeschlossene ai/*-Branches im Git-Server auf, aber nur, wenn dort noch der zuletzt übertragene Stand liegt. Commits von außen bleiben erhalten. Dafür braucht der technische Account das Recht, ai/*-Branches zu löschen. In der Plattform bleiben Commits und Diff sichtbar.

Für ai/*-Branches sollte eure CI keine Secrets bekommen, weil der Code von der KI stammt.

Datenbank verbinden

Datenbanken sind MCP-Verbindungen des Workspace: Einstellungen → MCP-Server → Datenbank hinzufügen. Dort Datenbanktyp (die Treiber, die der Plattform-Admin bereitstellt, z. B. PostgreSQL oder Oracle), Kurzname, Host, Port, Datenbank (bei Oracle der Service-Name, z. B. ORCLPDB1), Nutzer und Passwort angeben. Der Kurzname ist der Präfix der Tools (shop__query) und über alle Workspaces eindeutig. Der Host muss vom Betrieb freigegeben sein. Die Zugangsdaten liegen verschlüsselt in Bifröst; die KI sieht sie nie. Lege einen Nutzer nur mit SELECT-Rechten an; der Verbindungstest meldet, wenn er schreiben darf (bei Oracle auch systemweite Rechte wie INSERT ANY TABLE). Abfragen laufen ohnehin schreibgeschützt, mit Zeit- und Zeilenlimit.

Dateien zur Analyse

Hochladen dürfen alle Mitglieder. Dateien zählen gegen das Speicherkontingent des Workspace (Standard 500 MB); die Seite Daten zeigt die Belegung. Mehr Platz vergibt ein Plattform-Admin.

Abgeglichene Ordner

Ordner verbinden dürfen alle Mitglieder (siehe Ordner abgleichen). Private Ordner („nur ich“) sieht auch ein Workspace-Admin nicht, und er kann sie nicht löschen; Ordner für den ganzen Workspace kann er löschen. Der ausgelesene Text zählt aufs Speicherkontingent. Die Tools docs_* lassen sich wie andere unter Einstellungen → Tools verschärfen.

Beispielfragen

Unter Einstellungen → Allgemein → Beispielfragen bis zu acht Fragen, eine je Zeile. Sie erscheinen in der Übersicht unter Ausprobieren und in neuen Chats; ein Klick stellt die Frage. Gute Beispielfragen zeigen, was der Workspace kann, etwa je eine zum Repository, zu den Daten und zu den Dokumenten.

Ohne Datenquellen chatten

Unter Einstellungen → Allgemein lässt sich der Chat auch ohne verbundene Quelle erlauben. Die KI antwortet dann nur aus allgemeinem Wissen: Texte formulieren, Begriffe erklären, Code-Beispiele schreiben. Fragt jemand nach internen Systemen, Verträgen oder Zahlen, sagt sie, dass sie diese hier nicht einsehen kann. Gedacht für reine Chat-Workspaces oder um den Unterschied zu Workspaces mit Daten zu zeigen. Verbindest du später eine Quelle, nutzt die KI sie wie gewohnt. Ein- und Ausschalten steht im Audit-Log.

Modell

Unter Einstellungen → Allgemein → Modell wählst du das Modell des Workspace aus den freigegebenen Modellen. Ohne Auswahl gilt das Standardmodell der Plattform.

Antworten: Tool-Schritte

Unter Einstellungen → Allgemein → Antworten stellst du ein, wie viele Tool-Schritte eine Antwort nutzen darf (4 bis 40, Standard 12). Mehr Schritte erlauben größere Aufgaben in einer Antwort, kosten aber mehr. Ist das Limit erreicht, fasst die KI zusammen, und es geht mit Weiterarbeiten weiter.

Tools und Regeln

Der Plattform-Admin stuft jedes Tool zentral ein. Unter Einstellungen → Tools und Regeln kannst du für deinen Workspace nur verschärfen:

• ein erlaubtes Tool auf Freigabe nötig oder gesperrt stellen,
• Tools einer bestimmten Datenbank verschärfen, z. B. prod__query nur mit Freigabe, während test__query erlaubt bleibt (jede Datenbank hat eigene Tools),
• Regeln je Quelle für Repositories setzen, z. B. commit_change auf einem bestimmten Repository nur mit Freigabe,
• Vier Augen verlangen.

Lockern kannst du die zentrale Einstufung nicht. Auch lesende Tools können eine Freigabe verlangen; die KI erhält das Ergebnis dann erst nach der Entscheidung.

Freigaben

Unter Einstellungen → Allgemein → Freigaben wählst du den Modus:

• Nach Einstufung (Standard): Eine Freigabe braucht, was auf Freigabe nötig steht.
• Jede Schreibaktion in ein Fremdsystem (Modus B): Tools der Klasse write_external (z. B. schreibende MCP-Tools) brauchen immer eine Freigabe, auch wenn sie erlaubt sind. Commits auf den Chat-Branch und Einträge ins Gedächtnis sind ausgenommen, weil sie in der Plattform bleiben.

Freigaben entscheiden Admins und Freigeber (siehe Für Freigeber und Prüfer). Bei unklarem Ergebnis einer Ausführung startest du als Admin den Abgleich.

MCP-Server und Gedächtnis

Unter Einstellungen → MCP-Server gibt es drei Bereiche:

• Zentrale Server: vom Plattform-Admin registriert. Du schaltest sie für deinen Workspace frei, ggf. mit einem eigenen Schlüssel des Dienstes.
• Eigene Verbindungen: MCP-Server hinzufügen mit Kurzname, URL, Token und weiteren Headern (z. B. X-Api-Key: …, verschlüsselt gespeichert). Nutzt die Plattform die Adresse schon, ist die Verbindung sofort aktiv. Sonst wartet sie auf die Freigabe eines Plattform-Admins.
• Datenbanken: siehe Datenbank verbinden.

Die Tools erscheinen für die KI, sofern sie eingestuft sind. Gleiche Tools desselben Dienstes übernehmen eine vorhandene Einstufung; neue Tools bleiben gesperrt, bis der Plattform-Admin sie einstuft. Verbindungen gibt es nur in deinem Workspace.

Gedächtnis (Munin): Mit dem Munin-Key eures Projekts freischalten. Die KI merkt sich dann Wichtiges über Chats hinweg. Unter Gedächtnis sehen alle Mitglieder die Einträge; löschen kannst nur du als Admin. Das Löschen durch die KI ist gesperrt.

Pakete aus Hugin

Hugin ist das Register für geprüfte KI-Erweiterungen. Unter Einstellungen → Hugin wählst du Pakete für deinen Workspace. Voraussetzung: Der Plattform-Admin hat den Hugin-Host eingetragen.

Zugang: Trage unter Zugang den Integrations-Key (hi_…) eures Tenants ein; ihr legt ihn in Hugin unter Integrationen mit den Rollen Lesen und Ausliefern an. Bifröst prüft ihn gleich und zeigt Tenant und Key-Name. Der Tenant bestimmt, welche Pakete und Pflichtpakete in deinem Workspace gelten; ein Wechsel steht im Audit-Log. Der Key liegt verschlüsselt in Bifröst. Nach dem Entfernen gelten festgeschriebene Pakete weiter, Abgleichen und Rückmeldungen gehen nicht mehr.

1. Wählen: im Katalog oder direkt als <id> bzw. <id>@stable, @test, @^1 oder @1.2.3 (wie in .hugin.yaml).
2. Abgleichen: zeigt, was Hugin jetzt liefern würde: neu, Update verfügbar, entfällt. Dabei ändert sich nichts.
3. Übernehmen: lädt neue Versionen, prüft ihre Prüfsumme und schreibt sie fest. Erst dann gelten sie in Chats. Neue Versionen kommen nie von selbst.

Übernommene Pakete liegen als geprüfte Kopie in Bifröst. Chats nutzen nur diese Kopie und laufen auch weiter, wenn Hugin nicht erreichbar ist.

Abgleich im Hintergrund: Bifröst gleicht einmal am Tag selbst ab und übernimmt dabei nichts. Gibt es Updates, veraltete Pakete, neue oder entfallene Pflichtpakete oder eine neue Hauptversion, steht das oben im Reiter, und die Admins des Workspace bekommen eine E-Mail (und der Webhook eine Nachricht, falls eingerichtet).

Aus .hugin.yaml: Hat ein verbundenes Repository eine .hugin.yaml (wie für hugin sync), übernimmst du deren Pakete mit Aus .hugin.yaml als Vorschlag in die Auswahl. Die Datei selbst wirkt nicht von allein.

Pflichtpakete eures Tenants kommen immer mit und lassen sich nicht abwählen. So wirken Pakete in Bifröst:

• Regeln gehen in jeder Antwort in den System-Prompt, nach den Regeln der Plattform.
• Skills: Die KI sieht Name und Beschreibung und lädt den Inhalt bei Bedarf (load_skill, read_skill_file).
• Befehle ruft man im Chat mit /name argumente auf; an die KI geht der ausgeschriebene Text.

Nicht angeboten werden Skills mit Skripten oder Rechten, Befehle mit Shell-Einbettung (!`…`) und andere Arten (Subagents, MCP, Hooks). Sie stehen mit Grund unter Festgeschrieben. Inhalte aus Hugin verleihen keine Rechte; alle Tools bleiben eingestuft und freigabepflichtig wie sonst. Mit hugin_feedback meldet die KI unklare oder falsche Anweisungen an die Autoren in Hugin, sofern das Tool eingestuft ist.

Benachrichtigungen per Webhook

Unter Einstellungen → Allgemein kannst du einen Teams- oder Slack-Webhook eintragen. Dorthin gehen offene Freigabeanträge und Ereignisse von Pull Requests (Merge, Ablehnung), zusätzlich zu den E-Mails.

Nutzung, Runs und Audit-Log

Für deinen Workspace siehst du:

• Nutzung und Kosten: Tokens und Kosten je Modell, Nutzer oder Tag. Darunter die Rückmeldungen der Mitglieder zu Antworten: Anteil hilfreich, je Modell und die Kommentare mit Link zur Antwort; Als CSV herunterladen für die Auswertung.
• Runs: jede Antwort mit Status, Dauer und Verbrauch. Hier findest du auch fehlgeschlagene oder wartende Antworten.
• Audit-Log: wer wann was getan hat (Einstellungen, Freigaben, Pushes, Pull Requests, Abgleiche), mit Filtern und CSV-Export.

Der Verbrauch bleibt erhalten, auch wenn Chats gelöscht werden.

Workspace löschen

Unter Einstellungen → Allgemein → Workspace löschen, mit Eingabe des Namens. Der Workspace kommt in den Papierkorb: Er ist für alle unsichtbar und lässt sich auf der Workspace-Übersicht einige Tage lang wiederherstellen oder sofort endgültig löschen.

Endgültig entfernt werden Quellen mit Zugangsdaten und Git-Klon, Chats, Runs, Freigabeanträge, Uploads, Tool-Vorgaben und MCP-Freischaltungen. Audit-Log und Verbrauch bleiben. Solange Antworten laufen oder auf Freigabe warten, ist Löschen nicht möglich.