Workspaces und Organisationen

SupaCloud verwendet einen Begriff für eine Bedeutung — einheitlich über Datenbank, API und UI hinweg. Das Wort Team war früher mehrfach belegt; heute ist es ausschließlich der Agent-Domäne vorbehalten.

Die Hierarchie

• Organisation — der oberste Mandant. Sie besitzt Abrechnung/Sitze, SSO und Einladungen. Jeder Nutzer gehört zu genau einer Organisation. Bei der Anmeldung wird automatisch eine persönliche Organisation bereitgestellt.
• Workspace — der Ressourcen-Container unterhalb einer Organisation. Projekte, Tasks, Runs, Workflows, Zeitpläne, Secrets und Connectors leben allesamt in einem Workspace. Die Mitgliedschaft erfolgt pro Nutzer.
• Project / Task / Run / Workflow / Connector — Ressourcen innerhalb eines Workspaces.

Der Server leitet die aktive Organisation aus dem aktiven Workspace ab — es gibt keinen Organisationswechsler.

Einen Link über Workspaces hinweg teilen

Weil jede Ressource in einem Workspace liegt, ist ein Link wie /tasks/{id} nur die halbe Adresse: er benennt das Objekt, aber nicht den Mandanten, zu dem es gehört. Die fehlende Hälfte wurde bisher still aus dem Workspace ergänzt, den der Empfänger gerade offen hatte — ein Kollege, der einen geteilten Task-Link aus einem anderen aktiven Workspace öffnete, sah deshalb „nicht gefunden”, obwohl Mitgliedschaft und Rechte stimmten.

Zwei Dinge lösen das jetzt, und der Unterschied zwischen ihnen ist der Kern:

• Links, die SupaCloud verschickt, tragen ihren Workspace. Chat-Digests, Benachrichtigungen und Suchergebnisse hängen den Workspace an den Link, sodass der Empfänger ohne Zutun am richtigen Ort landet.
• Ein Link ohne Workspace wird über die Mitgliedschaft aufgelöst. Öffnest du einen unqualifizierten Link auf etwas in einem deiner anderen Workspaces, bietet die Seite den Wechsel an: Das liegt in einem anderen Workspace — Zu X wechseln / Hier bleiben. Es ist ein Angebot, kein Sprung, denn ein Wechsel lädt die Seite neu und würde nicht gespeicherte Arbeit verwerfen.

Warum es ein Angebot ist und keine Auskunft

Diese Wechsel-Aufforderung erscheint nur, wenn du wirklich Mitglied des Workspace bist, der die Ressource hält. Für alle anderen kommt genau das „nicht gefunden”, das die Ressource selbst gibt — Byte für Byte dieselbe Antwort wie für eine Id, die es nie gab. Sonst wäre die freundlichere Meldung selbst das Leck: sie würde bestätigen, dass ein fremder Task, Run oder Projekt existiert. Die Mitgliedschaft wird als Teil derselben Datenbankabfrage geprüft, die die Ressource sucht — eine Auskunft über einen Workspace, in dem du nicht bist, ist also gar nicht darstellbar.

Ein aktiver Workspace — überall

Dein aktiver Workspace ist eine Eigenschaft von dir, nicht des Fensters, in das du gerade schaust. Wechselst du ihn im Web-Umschalter, im Web-Terminal, in Telegram oder in Discord, wechselt er überall — und auch auf deinen anderen Geräten. Die Wahl liegt auf dem Server.

Das zählt vor allem dort, wo es früher wehtat: Ein workspace switch im Chat konnte so aussehen, als hätte er funktioniert, und dabei nichts ändern — weil die Wahl an einem Telegram-Chat hing. Wer Telegram nie verknüpft hatte oder aus Discord arbeitete, hatte keinen Ort, an den sie geschrieben werden konnte. Zwei Personen konnten dann denselben Namen auf dem Schirm haben und in verschiedenen Workspaces handeln, ohne dass einer von beiden einen Fehler sah.

Zwei bewusste Ausnahmen:

• Ein ?ws=-Link ist ein Abstecher für diese eine Navigation, keine Entscheidung. Ein Link, der einen Workspace mitbringt, zeigt dir diesen Workspace, ohne deine gespeicherte Wahl zu verschieben. Tab zu — und du bist wieder, wo du warst.
• Aktivieren kannst du nur einen Workspace, in dem du Mitglied bist. Die Prüfung läuft auf dem Server, auf jeder Oberfläche, und eine Ablehnung ändert nichts — ein abgelehnter Versuch kann also keinen veralteten Zeiger hinterlassen. Verlierst du den Zugang zu einem Workspace, den du aktiv hattest, fällt es schlicht auf deinen eigenen Standard zurück; die veraltete Vorliebe wird nie honoriert.

Warum nicht “Team”?

Team und Teammates sind der Agent-Domäne vorbehalten — einer Multi-Agent-Gruppe, die für einen einzelnen Task gestartet wird. Der Mandant ist immer ein Workspace; der oberste Mandant ist immer eine Organisation.

Regel der einheitlichen Sprache

Verwende “Team” niemals für den Mandanten. Diese Regel wird in der CI durch einen Architektur-Test erzwungen (keine neue team_id-Mandantenspalte) sowie durch eine Frontend-i18n-Lint-Regel (keine neue nutzersichtbare “Team”-Zeichenkette außerhalb der Agent- und Delivery-Board-Namespaces).

Entitlements

Was ein Workspace tun darf, wird nach dem Prinzip des ersten Nicht-Null-Werts aufgelöst: Nutzer-Override → Sitztyp → Workspace-Override → Organisationsplan → Standard, zusammengesetzt unter der Deployment-Edition. Ein Sitz kann niemals ein editionsgebundenes Feature freischalten.

Dieses Vokabular ist Gegenstand von ADR 0040, und das Mandantenmodell der Organisation ist ADR 0035.