munin/internal/help/pages/plattform-admin.md

## Der Ablauf für ein neues Team

1. **Workspace wählen oder anlegen.** Nach der Anmeldung landest du unter
   *Workspaces*. Ein Workspace ist gedacht für eine Abteilung. Beim ersten
   Start gibt es bereits den Workspace „Intern“.
2. **Projekt anlegen** unter *Projekte → Verwalten…*: Name, Bezeichner (erscheint
   in Adressen und in der MCP-Konfiguration) und optional eine Beschreibung.
3. **Ersten Key anlegen:** Im neuen Projekt unter *Zugänge* einen Key mit der
   Rolle `admin` für die verantwortliche Person erzeugen und ihr sicher
   übergeben.
4. **Ab da verwaltet das Team sich selbst:** Die verantwortliche Person legt
   weitere Keys für ihr Team und ihre Agenten an. Der Verweis auf diese Hilfe
   (`{{SERVER}}/hilfe`) reicht als Einstieg.

Deine Anmeldung als Plattform-Admin gilt 12 Stunden, danach fragt Munin
erneut nach dem ADMIN_TOKEN. Das ist Absicht: Anders als ein Key lässt sich
diese Sitzung nicht einzeln widerrufen, und sie kommt an alles. Ein Wechsel des
Workspace verlängert sie nicht.

Soll eine Abteilung ihre Projekte selbst anlegen, reicht es, ihr einen
[Workspace-Admin](#workspace-admins) einzurichten. Die Schritte 2 und 3
übernimmt dann sie.

## Workspaces

| Aktion | Wo |
|---|---|
| Anlegen, wählen | *Workspaces* in der Seitenleiste oder Klick auf den Namen oben in der Kopfleiste |
| Umbenennen, löschen | *Workspaces* → *Bearbeiten* |

Der Name des gerade gewählten Workspace steht immer oben in der Kopfleiste.
Alles, was du unter *Projekte* und *Protokoll (alle)* siehst, bezieht sich nur
auf diesen Workspace.

Unter dem Namen steht blass, wo die Daten des Workspace liegen: mit SQLite die
Datei (`workspaces/<id>.db` im Datenverzeichnis), mit PostgreSQL das Schema
(`munin_ws_<id>`). Damit findest du einen Workspace in der Datenbank wieder,
etwa für eine Sicherung oder in `psql`.

**Löschen** entfernt die Daten des Workspace (Datei bzw. Schema) mit allen Projekten,
Einträgen und Keys. Zur Bestätigung muss der Name eingetippt werden. Rückgängig
machen lässt sich das nur aus einer Sicherung.

## Workspace-Admins

Ein Workspace-Admin legt im eigenen Workspace Projekte an, bearbeitet und
löscht sie und verwaltet deren Zugänge, nur über die Weboberfläche. Was er
genau darf und was nicht, steht unter
[Zugänge und Sicherheit](/hilfe/zugaenge#workspace-admin). Für ihn gibt es
eine eigene Hilfeseite, [Für Workspace-Admins](/hilfe/workspace-admin) — gut
zum Weitergeben zusammen mit dem Token.

**Anlegen:** *Workspaces* → *Bearbeiten* → Abschnitt *Workspace-Admins*. Den
Namen der Person eintragen. Das Token (beginnt mit `wa_`) wird genau einmal
angezeigt und muss der Person sicher übergeben werden. Mit ihm meldet sie sich
an derselben Stelle an wie mit einem Key.

**Zurückziehen:** am selben Ort. Das Token gilt sofort nicht mehr, auch eine
laufende Sitzung endet. Beim Löschen des Workspace verschwinden seine
Workspace-Admins mit.

**Ungenutzte Zugänge:** Wie bei den Keys trägt ein aktiver Workspace-Admin,
der seit über 90 Tagen nicht benutzt wurde, die Marke *ungenutzt*. Die
Übersicht unter *Workspaces* zeigt je Workspace, wie viele Workspace-Admins
aktiv sind und wie viele davon ungenutzt. Ein Klick auf die Marke führt zur
Bearbeitungsseite. Ein vergessenes Token öffnet den ganzen Workspace, deshalb
im Zweifel zurückziehen.

Anlegen und Zurückziehen erscheinen im *Protokoll (alle)* des betroffenen
Workspace, ebenso jede Anmeldung eines Workspace-Admins.

## Projekte

Unter *Projekte → Verwalten…* stehen alle Projekte des Workspace mit
Eintragszahl und dem Stand ihres Schreibbudgets. Über *Bearbeiten* lassen sich
Name, Beschreibung und die **eigene Obergrenze fürs Schreibbudget** ändern.
Dort liegt auch das Löschen.

Das Schreibbudget kann nur der Plattform-Admin ändern, auch ein
Workspace-Admin nicht. Sonst könnte ein Team die Grenze selbst aufheben, die
gerade vor durchdrehenden Agenten schützen soll.

## Protokoll über alle Projekte

*Protokoll (alle)* zeigt die Vorgänge aller Projekte des gewählten Workspace,
auch das Anlegen und Löschen von Projekten. Gefiltert wird wie im Protokoll
eines Projekts (siehe [Zugänge und Sicherheit](/hilfe/zugaenge#protokoll)),
zusätzlich nach Projekt.

## Suche in allen Projekten

*Suche (alle Projekte)* in der Seitenleiste durchsucht alle Projekte des
gewählten Workspace auf einmal, für die Frage „In welchem Projekt stand das
nochmal?“. Die Treffer stehen nach Projekt gruppiert, je Projekt die besten
fünf, das passendste Projekt oben. Über *Weitere Treffer* geht es zur Suche im
jeweiligen Projekt.

Das können der Plattform-Admin und Workspace-Admins, denn beide sehen ohnehin
alle Projekte. Am Zugriff der Keys ändert sich nichts: Ein Key und ein
Agent sehen weiter genau ein Projekt.

## System

*System* (nur Plattform-Admin) zeigt, ob etwas zu tun ist, wie Munin genutzt
wird und worauf es läuft. Von oben nach unten:

- **Zustand:** alles, was Aufmerksamkeit braucht. *Warnungen* sollten behoben
  werden: die Verbindungen werden knapp (ab 80 % der höchstens möglichen
  Workspaces), PostgreSQL sortiert nicht nach `C`, die WAL-Datei eines
  Workspace wächst über 64 MB, der letzte Export ist fehlgeschlagen oder
  überfällig. *Hinweise* sind zur Kenntnis: Keys, die bald ablaufen oder seit
  90 Tagen niemand benutzt hat (je Workspace genannt), oder Anfragen, die seit
  dem letzten Blick auf eine Datenbankverbindung warten mussten. Steht hier
  „Alles in Ordnung“, ist nichts zu tun.
- **Aktivität der letzten 30 Tage:** Schreibvorgänge und Suchen je Tag über
  alle Workspaces. Fährt man mit der Maus über einen Tag, erscheinen die
  genauen Zahlen; *Als Tabelle* zeigt alle. Darunter die aktivsten Projekte
  und die Projekte ganz ohne Aktivität. Wird so ein Projekt noch gebraucht,
  oder fehlt dem Team die Anbindung?
- **Bestand je Workspace:** Projekte, Einträge, ältere Fassungen, Papierkorb,
  gültige Keys und der belegte Platz in der Datenbank.
- **Speicher und Verbindungen:** SQLite oder PostgreSQL samt Ort (nie das
  Passwort), und ob die Datenbank antwortet, wie bei `/ready`. Dazu, wie viele
  Verbindungen gerade offen sind, für die Kontroll-Datenbank und jeden
  geöffneten Workspace. Mit PostgreSQL steht daneben das Budget:
  `max_connections` und die Zahl der Workspaces, die es höchstens erlaubt.
  Darüber startet Munin nicht und lehnt neue Workspaces ab. *Gewartet* zählt,
  wie oft eine Anfrage auf eine freie Verbindung warten musste. Ab und zu ist
  normal; wächst die Zahl stetig, sind die Pools zu klein.
- **Programm:** Fassung (aus Git, falls beim Bauen vorhanden), Go-Fassung,
  Startzeit, Schema-Stand und der letzte Markdown-Export.

Aktivität und Bestand zählt Munin höchstens alle 5 Minuten neu; daneben steht
der Stand. Verbindungen und Zustand der Datenbank sind bei jedem Neuladen
aktuell.

Was die Seite nicht zeigt: ob die Sicherung gelaufen ist. Die läuft außerhalb
von Munin, siehe unten.

Für den gewählten Workspace gibt es außerdem *Überblick (Workspace)*: genau
die Seite, die ein Workspace-Admin sieht — was je Projekt zu tun ist,
Projekte und Aktivität, ohne Technik. Einzelheiten unter
[Für Workspace-Admins](/hilfe/workspace-admin#ueberblick).

## Sicherung und Export

Die eigentliche Sicherung läuft außerhalb der Oberfläche über
`scripts/backup.sh`. Das Skript sichert jeden Workspace einzeln (die Datei
bzw. mit PostgreSQL das Schema), sodass sich auch eine einzelne Abteilung
wiederherstellen lässt.

Ist auf dem Server ein Exportverzeichnis eingerichtet, schreibt Munin einmal
täglich alle Einträge aller Workspaces als Markdown-Dateien dorthin, als
zusätzliche, lesbare Sicherung, etwa für ein Git-Repository. Unter *Projekte*
exportiert der Knopf **Jetzt exportieren** sofort den gerade gewählten
Workspace, zum Beispiel vor einer größeren Änderung.

Ohne Exportverzeichnis und ohne Zugriff auf den Server geht es über den
Download: **Alle als ZIP herunterladen** unter *Projekte* liefert alle
Projekte des gewählten Workspace in einem Archiv, *Als ZIP herunterladen* über
der Eintragsliste ein einzelnes Projekt. Beides dürfen auch Workspace-Admins. Jeder
Download steht im Protokoll.

Zurück kommt ein Export über den [Import](/hilfe/weboberflaeche#import) im
jeweiligen Projekt: das ZIP eines Projekts direkt hochladen, oder den
Projektordner aus dem Exportverzeichnis als ZIP-Archiv packen und hochladen. So lässt sich auch ein einzelnes Projekt wiederherstellen, ohne
die ganze Workspace-Datei zurückzuspielen.