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.

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](/hilfe/nutzer#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.

## 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](/hilfe/freigeben)). 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](#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.