Ausbaustufen verfeinert

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/<projekt>`, 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/<projekt>`), 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.