cf35c3f5db
- 3.7: MCP-Werkzeug "related" liefert Nachbarn im Verweisgraphen in beide
Richtungen, bis zur zweiten Reihe (store.RelatedEntries).
- 3.5: Einträge, die seit über einem Jahr unverändert sind, tragen in
recall/get/list/related "stale": true; get und recall geben einen
Hinweis, die Eintragsseite eine Marke. instructions erklären das Feld.
- 3.2: Import von Markdown-Dateien als ZIP unter /p/{projekt}/import
(Rolle admin), mit Vorschau, überspringen/überschreiben, Erkennung von
Unverändertem und Papierkorb. Neue Einträge behalten Autor, Herkunft,
Prüfvermerk und Zeitstempel aus dem Export.
Nebenbei behoben: Das 1-MB-Body-Limit für Formulare lag über dem ganzen
Mux und begrenzte damit auch /mcp auf 1 MB statt MAX_API_BODY_BYTES.
LimitBodies wählt die Grenze jetzt einmal außen je Route.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
60 lines
2.8 KiB
Markdown
60 lines
2.8 KiB
Markdown
## 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.
|
|
|
|
## 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.
|
|
|
|
**Löschen** entfernt die Datenbankdatei des Workspace 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.
|
|
|
|
## 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. 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.
|
|
|
|
## Sicherung und Export
|
|
|
|
Die eigentliche Sicherung läuft außerhalb der Oberfläche über
|
|
`scripts/backup.sh`. Das Skript sichert jede Workspace-Datei einzeln, 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.
|
|
|
|
Zurück kommt ein Export über den [Import](/hilfe/weboberflaeche#import) im
|
|
jeweiligen Projekt: den Projektordner aus dem Export als ZIP-Archiv packen und
|
|
hochladen. So lässt sich auch ein einzelnes Projekt wiederherstellen, ohne
|
|
die ganze Workspace-Datei zurückzuspielen.
|