103 lines
4.5 KiB
Markdown
103 lines
4.5 KiB
Markdown
## Wie alles zusammenhängt
|
|
|
|
```
|
|
Workspace (z. B. eine Abteilung)
|
|
└── Projekt (z. B. ein Team oder ein Vorhaben)
|
|
├── Einträge ← das eigentliche Wissen
|
|
└── Zugänge ← API-Keys mit Rolle
|
|
```
|
|
|
|
## Die Begriffe
|
|
|
|
**Workspace**
|
|
Ein Bereich für eine Abteilung oder eine größere Gruppe von Teams. Jeder
|
|
Workspace liegt in einer eigenen Datenbankdatei. Workspaces sehen sich
|
|
gegenseitig nie: Die Trennung ist technisch erzwungen, nicht nur eine
|
|
Filtereinstellung. Mit einem Projekt-Key bist du immer in genau einem Workspace.
|
|
Du musst ihn nicht auswählen.
|
|
|
|
**Projekt**
|
|
Die Einheit, in der Wissen geteilt wird, meist ein Team oder ein Vorhaben. Jedes
|
|
Projekt hat eigene Einträge, eigene Zugänge und eine eigene Suche. Projekte
|
|
sehen sich gegenseitig nicht, auch nicht innerhalb desselben Workspace.
|
|
|
|
**Eintrag**
|
|
Ein Stück Wissen: Titel, Inhalt in Markdown, Schlagworte. Ein guter Eintrag
|
|
beantwortet genau eine Frage, etwa „Wie läuft das Deployment?“ oder „Warum
|
|
nutzen wir SQLite?“.
|
|
|
|
**Bezeichner** (slug)
|
|
Der kurze, dauerhafte Name eines Eintrags, zum Beispiel `deployment-prozess`.
|
|
Er steht in der Adresse und dient als Schlüssel gegen Dubletten: Wer zweimal
|
|
mit demselben Bezeichner schreibt, **aktualisiert** den Eintrag, statt einen
|
|
zweiten anzulegen. Erlaubt sind `a-z`, `0-9`, `-` und `_`.
|
|
|
|
**Schlagworte** (tags)
|
|
Ordnen Einträge thematisch ein, zum Beispiel `ops` oder `sicherheit`. Es gibt
|
|
keine Ordner. Wo etwas „hingehört“, ist selten eindeutig, deshalb kann ein
|
|
Eintrag mehrere Schlagworte tragen. Besser wenige, einheitliche Schlagworte als
|
|
viele leicht verschiedene.
|
|
|
|
**Verweis**
|
|
`[[bezeichner]]` im Inhalt verlinkt auf einen anderen Eintrag. Die Gegenrichtung
|
|
entsteht automatisch: Jeder Eintrag zeigt, welche anderen auf ihn verweisen.
|
|
Ein Verweis darf auch auf einen Eintrag zeigen, den es noch nicht gibt. Das
|
|
markiert eine Lücke, die jemand füllen sollte.
|
|
|
|
**Fassung** (version)
|
|
Zählt bei jeder Änderung eines Eintrags hoch. Die vorherigen Fassungen bleiben
|
|
erhalten und lassen sich über *Verlauf ansehen* vergleichen. Ein gelöschter
|
|
Eintrag behält seinen Verlauf, solange er im Papierkorb liegt.
|
|
|
|
**Papierkorb**
|
|
Gelöschte Einträge liegen dort 30 Tage, bevor sie endgültig verschwinden. Für
|
|
Agenten und die Suche sind sie sofort unsichtbar; Menschen mit Schreibrecht
|
|
können sie zurückholen.
|
|
|
|
**Herkunft**
|
|
Jeder Eintrag vermerkt, ob zuletzt ein **Mensch** (über die Weboberfläche) oder
|
|
ein **Agent** (über MCP) geschrieben hat, und unter welchem Zugangsnamen.
|
|
|
|
**Kuratiert**
|
|
Ein Haken, den ein Mensch setzt, wenn er einen Eintrag geprüft hat. Einträge
|
|
ohne diesen Haken sind Beobachtungen, keine bestätigten Fakten. Agenten sehen
|
|
den Haken und können danach filtern; in der Suche stehen kuratierte Einträge
|
|
bei sonst gleicher Relevanz weiter vorn. Ein Agent ändert einen kuratierten
|
|
Eintrag nur mit Begründung. Dabei fällt der Haken weg, und der Eintrag steht
|
|
auf der Nutzungsseite zur Prüfung, bis ein Mensch ihn wieder setzt.
|
|
|
|
**API-Key** (Zugang)
|
|
Ein Schlüssel, der mit `wk_` beginnt und genau zu einem Projekt gehört. Er
|
|
dient zur Anmeldung im Browser und im KI-Werkzeug. Munin speichert nur eine
|
|
Prüfsumme, daher wird der Key beim Anlegen ein einziges Mal angezeigt.
|
|
|
|
**Protokoll**
|
|
Hält fest, wer wann etwas geschrieben oder gelöscht hat, wer sich angemeldet hat
|
|
(auch Fehlversuche) und wann Zugänge angelegt oder zurückgezogen wurden. Lesen
|
|
und Suchen stehen nicht darin. Protokolleinträge werden nach 90 Tagen
|
|
automatisch gelöscht.
|
|
|
|
**Suchprotokoll**
|
|
Hält getrennt davon fest, was Agenten mit `recall` gesucht haben und ob sie
|
|
etwas gefunden haben, ohne Adresse. Die Nutzungsseite wertet es aus. Weil
|
|
Anfragen Inhalt sind, wird es nach 30 Tagen gelöscht und verschwindet mit dem
|
|
Projekt.
|
|
|
|
## Rollen
|
|
|
|
Jeder Key hat genau eine Rolle.
|
|
|
|
| Rolle | Darf | Gedacht für |
|
|
|---|---|---|
|
|
| `read` | lesen und suchen | Agenten, die nur Auskunft geben sollen |
|
|
| `write` | zusätzlich schreiben und löschen | der Normalfall für Menschen und beaufsichtigte Agenten |
|
|
| `admin` | zusätzlich die Zugänge des Projekts verwalten | Menschen, die für das Projekt verantwortlich sind |
|
|
|
|
Darüber stehen zwei Verwaltungszugänge, die nicht an ein Projekt gebunden
|
|
sind und nur für die Weboberfläche gelten:
|
|
|
|
- Der **Workspace-Admin** verwaltet in genau einem Workspace die Projekte und
|
|
ihre Zugänge und kann alle Projekte dort lesen (siehe
|
|
[Zugänge und Sicherheit](/hilfe/zugaenge#workspace-admin)).
|
|
- Der **Plattform-Admin** meldet sich mit einem eigenen Admin-Token an, legt
|
|
Workspaces und Projekte an und kommt an jedes Projekt.
|