diff --git a/AUSBAUSTUFEN.md b/AUSBAUSTUFEN.md index 4b5144d..1fe247c 100644 --- a/AUSBAUSTUFEN.md +++ b/AUSBAUSTUFEN.md @@ -753,6 +753,95 @@ eine eigene Key-Art ohne Projektbindung. Beides zusammen entscheiden, nicht **Aufwand:** hoch. +### 4.9 Zugriff über ein Projekt hinaus — aufgeschoben + +Zwei verwandte Wünsche, besprochen am 2026-09-25 und bewusst aufgeschoben: + +- **Öffentliches Projekt:** Ein Projekt, das jeder gültige Key lesen darf, + auch aus anderen Workspaces. Etwa für firmenweite Richtlinien. +- **Workspace-Zugang:** Ein Key für alle Projekte eines Workspace, mit einem + MCP-Server statt einem je Projekt. Für Teams, die projektübergreifend + arbeiten und Wissen aus mehreren Projekten brauchen. + +**Stand heute:** Ein Key gehört zu genau einem Projekt, und jedes Projekt hat +einen eigenen MCP-Server, dessen Werkzeuge fest an dieses Projekt gebunden +sind. Wer mehrere Projekte braucht, trägt mehrere Server ein, je einen Key pro +Projekt. Das Routing Key → Workspace in der Kontroll-Datenbank (4.4) kennt +dagegen schon keine Projektbindung. + +**Geht schon heute, ohne Code:** Für ein „öffentliches“ Projekt bekommt jedes +Team einen `read`-Key und trägt das Projekt als zweiten Server ein. Das kostet +Verwaltung, aber keine Entwicklung, und das Protokoll zeigt je Team, wer liest. + +#### Öffentliches Projekt + +| | Idee | Aufwand | +|---|---|---| +| **A** (empfohlen) | Eigener Endpunkt `/mcp/public/`, jeder gültige Key darf lesen (`recall`, `get`, `list`, `related`), schreiben nur mit Keys des Projekts. Schalter nur für den Plattform-Admin. | 2½–3½ Tage | +| **B** | `recall` sucht automatisch zusätzlich im öffentlichen Projekt | 4–6 Tage, ändert den MCP-Vertrag | +| Lesen in der Oberfläche | Menschen aus anderen Projekten sehen es im Browser | +2–3 Tage | + +Von Schreibrecht für alle wird abgeraten: Das Schreibbudget (3.8) gälte für +die ganze Firma zusammen, und niemand fühlte sich für die Qualität zuständig. + +#### Workspace-Zugang + +**Nötige Änderungen:** Workspace-Keys ohne Projektbindung (`api_keys.project_id` +ist heute `NOT NULL`, bei SQLite heißt das Tabelle neu aufbauen), +`Session.CanAccessProject` erweitern, Verwaltung unter `/admin/workspaces`, und +auf der MCP-Seite eine von zwei Stufen: + +| | Idee | Aufwand gesamt | +|---|---|---| +| **Stufe 1** | Projekt wählbar über den Pfad (`/mcp/`), ein Key für alle. Löst den Zugriff, der Agent muss aber weiter wissen, wo er sucht. | 4½–6 Tage | +| **Stufe 2** | Ein Server je Workspace, `recall` über alle Projekte, jeder Treffer nennt sein Projekt, `get`/`related`/`remember` bekommen einen Parameter `project`. | 7½–10 Tage | + +**Risiken:** + +- *Sicherheit:* Ein verlorener Workspace-Key öffnet alle Projekte statt einem. + Die Grenze zwischen Workspaces bleibt strukturell dicht (eigene Datei je + Workspace). Innerhalb eines Workspace wird die Projektgrenze aber zu einer + Bedingung in der Abfrage statt einer Closure. Das größte Risiko ist, dass + Projekt-Keys versehentlich über denselben Codepfad laufen und mehr sehen als + heute. Deshalb Projekt-Keys unverändert auf dem heutigen Weg lassen und den + Workspace-Server getrennt aufbauen. +- *Last:* Ein workspace-weites `recall` lädt beim ersten Aufruf die + Suchindizes *aller* Projekte in den Speicher (~65 MB und ~170 ms je 10.000 + Einträge, siehe 1.1). Heute nur die, die jemand benutzt. SQLite wird nicht + stärker belastet, alle Projekte eines Workspace liegen schon in einer Datei. +- *Schreibbudget:* Es zählt je Projekt. Ein durchdrehender Agent mit + Workspace-Key könnte in *jedem* Projekt bis zur Grenze schreiben. Dagegen + hilft nur ein zusätzliches Budget je Key oder Workspace, oder kein + Schreibrecht für Workspace-Keys. +- *Qualität:* Agenten schreiben ins falsche Projekt (deshalb keine + Standardangabe für `project` bei `remember`), vermischen Wissen verschiedener + Projekte, legen Dubletten über Projektgrenzen an. Außerdem sind BM25-Werte + getrennter Indizes nicht direkt vergleichbar, das Mischen der Treffer + braucht eigene Logik. +- *Wartung:* zwei Anschlussarten statt einer. Mit Keycloak (4.3) wird aus dem + Workspace-*Key* ein Workspace-*Recht* einer Person, der Rechte-Teil wird dann + umgebaut. + +**Warum aufgeschoben:** Keycloak ist absehbar, aber nicht sofort. Mit wenigen +Projekten je Team (etwa zwei) ist ein Server je Projekt stabil und die +Schwäche nur Komfort. Die Risiken oben wiegen das noch nicht auf. + +**Auslöser:** + +- Teams arbeiten regelmäßig mit vier bis fünf oder mehr Projekten zugleich + (Werkzeuge vervielfachen sich im Kontext des Agenten) +- Die Verteilung von `read`-Keys für gemeinsam genutzte Projekte wird zur + spürbaren Last +- Die Entscheidung zu 4.3 und 4.8 steht an. Dann zusammen entscheiden, nicht + vorher Workspace-Keys bauen und später umbauen. + +**Wenn es so weit ist, vorsichtig beginnen:** Workspace-Keys nur `read`, +projektübergreifend `recall`/`get`/`list`/`related`, schreiben weiter über +die Projekt-Server, vorher Speicher und Kaltstart mit echten Projektgrößen +messen. Innerhalb eines Workspace erledigt ein solcher `read`-Key nebenbei +auch das öffentliche Projekt. Übrig bliebe nur „öffentlich über +Workspaces hinweg“ (Variante A oben). + --- ## Teil 5 — Oberfläche @@ -974,5 +1063,6 @@ Zusätzlich vorgezogen und erledigt 2026-09-25: **Verwandte Einträge** (3.7), Alles darüber hinaus erst, wenn der Betrieb zeigt, dass es gebraucht wird. **Was ausdrücklich nicht auf dieser Liste steht:** FTS5, getrennte Datenbanken, -semantische Suche. Alle drei sind gute Ideen für den Fall, dass ihre Auslöser -eintreten — und drei gute Wege, Zeit in Probleme zu stecken, die es noch nicht gibt. +semantische Suche, Zugriff über ein Projekt hinaus (4.9). Alle vier sind gute +Ideen für den Fall, dass ihre Auslöser eintreten — und vier gute Wege, Zeit in +Probleme zu stecken, die es noch nicht gibt.