Teams

Team-Speicherarchitektur und Preview-Status

Teams ist eine Funktion des Business-Plans. In der Produktion ist die Teamerstellung standardmäßig deaktiviert, bis der Business-Plan startet; die aktuelle Laufzeit arbeitet bei unautorisierten Anfragen im reinen Verweigerungsmodus (deny-only). Raumadministratoren verwalten Arbeitsbereichsgrenzen und Mandantenbereitstellung auf der Verwaltungsebene des Arbeitsbereichs, während der Agenten-Speicherzugriff durch Sitzplätze auf der Datenebene mit mandantenisolierten kryptografischen Raumbindungen geregelt wird.

• Preview-Status: In der Memory Console unter https://xmemo.dev/me#teams ist die Teamverwaltung mit dem Preview-Badge gekennzeichnet.
• Kontext des Konsolen-Arbeitsbereichs: Die Kopfzeile der Teamverwaltung kündigt an: "One workspace for members and invitations.", wo Administratoren aktive Mitglieder und ausstehende Einladungen verwalten.
• Raumnavigation: Mitwirkende wechseln über den expliziten Raum-Parameter in einen Teamraum (https://xmemo.dev/me?space=<team_id>#memory) oder prüfen geteiltes Wissen (https://xmemo.dev/me?space=<team_id>#knowledge) und Skills (https://xmemo.dev/me?space=<team_id>#skills).
• Kollaborative Isolation: Team-Arbeitsbereiche bieten einen gemeinsamen Multi-Agenten-Kontext, der von den persönlichen Speicherräumen einzelner Benutzer (/me#memory) isoliert ist.

Team-Berechtigung, Erstellungsvoraussetzungen und Abonnementgrenzen

Die Teamerstellung erfordert ein berechtigtes Business-Abonnement mit mindestens 2 erworbenen Sitzplätzen. Da der Business-Plan derzeit nicht zum Kauf freigegeben ist, ist die Self-Service-Teamerstellung für allgemeine Konten standardmäßig deaktiviert. Die öffentliche Dokumentation stellt den Kauf von Sitzplätzen niemals als verfügbare Aktion dar.

• Erstellungshaltung: Die Self-Service-Teamerstellung ist in Produktionsumgebungen standardmäßig deaktiviert, bis der Business-Plan startet.
• Berechtigungsanforderung: Die Konsole prüft die Organisationsberechtigung, bevor die Teamerstellung freigegeben wird. Falls nicht berechtigt, zeigt die Benutzeroberfläche an: "A Business subscription with at least 2 purchased seats is required to create a team."
• Grund für Preview-Einschränkung: Wenn einem Konto die Allowlist-Freigabe fehlt, zeigt die Konsole an: "Team creation is currently limited to preview accounts."
• Grund für allgemeine Nichtverfügbarkeit: Für nicht bereitgestellte Konten gibt die Konsole an: "Team creation is not available for this account yet."
• Kommerzieller Status: Das Business-Abonnement kann derzeit nicht erworben werden. Das Hinzufügen von Sitzplätzen und Plan-Upgrades per Self-Service sind deaktiviert.
• Erstellungsmodal: In freigeschalteten Preview-Konten öffnet das Klicken auf Create team ein Modal mit dem Text: "Enter your company name. This will become the team name inside XMemo." mit dem Eingabefeld "Company name" (Platzhalter "e.g. Acme Corp").

Vierstufige RBAC-Hierarchie und Obergrenzen für die Anmeldedaten-Ausstellung

Berechtigungen für Team-Mitgliedschaften und Obergrenzen für die Ausstellung von Anmeldedaten werden von persönlichen Konsolendiensten durchgesetzt. Aktive Mitglieder mit den Rollen Owner, Admin oder Member können teamgebundene Anmeldedaten innerhalb rollenspezifischer Scope-Obergrenzen ausstellen, während Viewer strikt lesend sind und keine Token-Ausstellung gestattet ist. Das nachfolgende Rollenschema ist eine illustrative Zusammenfassung (keine API-Antwort):

• Rollenhierarchie: Illustrative Zusammenfassung (keine API-Antwort), die Arbeitsbereichsrollen Berechtigungsstufen und Obergrenzen für die Token-Ausstellung zuordnet.
• owner (Stufe 3): Ersteller des Arbeitsbereichs, fest an das Abrechnungskonto gebunden. Kann Mitglieder mit den Rollen Admin, Member oder Viewer einladen; kann Rollen von Nicht-Owner-Mitgliedern ändern (zwischen Admin, Member und Viewer); kann Nicht-Owner-Mitglieder entfernen und Einladungen widerrufen. Kann teamgebundene Anmeldedaten mit beliebigen Self-Service-Bereichen ausstellen, einschließlich Datenebenen-Speicher-, Ledger-, Knowledge- und Audit-Bereichen (memory:read, memory:write, memory:restore, read:memories, write:memories, delete:memories, ledger:read, ledger:write, knowledge:read, knowledge:write und read:audit).
• admin (Stufe 2): Arbeitsbereichsadministrator. Kann Mitglieder mit den Rollen Member oder Viewer einladen (kann keine Admins einladen); kann Nicht-Owner-Mitglieder entfernen und ausstehende Einladungen widerrufen; kann Mitgliederrollen nicht ändern. Kann teamgebundene Anmeldedaten mit beliebigen Self-Service-Bereichen ausstellen, einschließlich Datenebenen-Speicher-, Ledger-, Knowledge- und Audit-Bereichen (memory:read, memory:write, memory:restore, read:memories, write:memories, delete:memories, ledger:read, ledger:write, knowledge:read, knowledge:write und read:audit).
• member (Stufe 1): Standard-Arbeitsbereichs-Mitarbeiter. Lese-, Schreib- und Wiederherstellungszugriff auf geteilte Team-Speicherplätze, Team-Knowledge-Einträge und Team-Cloud-Skills. Kann persönliche teamgebundene Anmeldedaten ausstellen, die auf Team-Mitgliedsbereiche beschränkt sind (memory:read, memory:write, memory:restore, read:memories und write:memories); kann keine erweiterten Ledger- oder Knowledge-Bereiche ausstellen und keine Arbeitsbereichsmitglieder oder Einstellungen verwalten.
• viewer (Stufe 0): Schreibgeschützter Speicherzugriff in der Konsole (memory:read) und Einsicht in geteiltes Wissen. Keine Ausstellung von Anmeldedaten erlaubt; das Schreiben von Speicherdaten, Aktualisieren des Zustands oder Ausstellen von Team-Anmeldedaten ist untersagt.
• Einschränkung für alleinige Eigentümer: Ein alleiniger Eigentümer, der das Team verlassen möchte, erhält den Hinweis: "Cannot leave team as the sole owner. Transfer ownership or delete the team first." (mit Tooltip: "Sole owner must transfer ownership before leaving").

{
  "roles": {
    "owner": {
      "level": 3,
      "token_issuance_cap": [
        "memory:read",
        "memory:write",
        "memory:restore",
        "read:memories",
        "write:memories",
        "delete:memories",
        "ledger:read",
        "ledger:write",
        "knowledge:read",
        "knowledge:write",
        "read:audit"
      ]
    },
    "admin": {
      "level": 2,
      "token_issuance_cap": [
        "memory:read",
        "memory:write",
        "memory:restore",
        "read:memories",
        "write:memories",
        "delete:memories",
        "ledger:read",
        "ledger:write",
        "knowledge:read",
        "knowledge:write",
        "read:audit"
      ]
    },
    "member": {
      "level": 1,
      "token_issuance_cap": [
        "memory:read",
        "memory:write",
        "memory:restore",
        "read:memories",
        "write:memories"
      ]
    },
    "viewer": {
      "level": 0,
      "token_issuance_cap": []
    }
  }
}

Server-autoritative Raumbindung und dynamischer Widerruf

Multi-Tenant-Isolation wird serverseitig durch kryptografische Raumbindungen durchgesetzt. Jeder API-Schlüssel mit Team-Scope enthält unveränderliche Claims (bound_team_id, membership_id_at_issue, space_binding_version), die von Client-Anfragen weder geändert noch bereitgestellt werden können. Anfragen, die auf ein falsches Team abzielen, schlagen sofort mit HTTP 403 token_space_mismatch fehl (fail closed).

• Autoritative Raumprüfung: Anfragen, die auf ein nicht übereinstimmendes Team abzielen, schlagen sofort mit HTTP 403 token_space_mismatch fehl (fail closed).
• Anti-Spoofing-Garantie: Anfragen mit gefälschten oder widersprüchlichen Team-Headern werden am Edge abgewiesen, bevor auf Datenbankpools zugegriffen wird.
• Epochenbasierter dynamischer Widerruf: Die Mitgliedschaftsvalidierung prüft bei jeder authentifizierten Anfrage die aktuelle membership_id-Epoche und garantiert, dass entfernte Mitglieder sofort nach der Epochenaktualisierung den Zugriff verlieren, ohne auf den Token-Ablauf zu warten.

Sitzplatzverwaltung, Einladungslebenszyklus und Lebenszyklusgrenzen

Die Kapazität des Arbeitsbereichs wird qualitativ über aktive Mitgliedschaften und ausstehende Einladungen hinweg erfasst. Betriebsgrenzen regeln die Ausstellung von Einladungen, den Ablauf und die Konsolenfunktionen:

• Qualitative Sitzplatzzählung: Belegte Sitzplätze bestehen aus aktiven Mitgliedern plus nicht abgelaufenen ausstehenden Einladungen, in der Konsolen-Kopfzeile angezeigt als "Seats {used} / {limit} used, {members} members, {pending} pending".
• Technischer Einladungsablauf: Team-Einladungen laufen 7 Tage nach Ausstellung ab (teams_service.py:1184-1188). Abgelaufene Einladungen geben ihre Reservierung frei und zählen nicht mehr zu den belegten Sitzplätzen.
• Sitzplatz-Kapazitätsgrenze: Wenn alle verfügbaren Sitzplätze belegt sind, warnt das Modal Add member: "Team seat limit reached. Upgrade or remove a member or pending invitation to send more invitations."
• Status des Einladungs-Workflows: Das Senden einer Einladung generiert einen sicheren 7-Tage-Token-Link. Die Einladungsannahme hat heute jedoch keinen Konsumenten in der Konsolenoberfläche; der vollständige Workflow zur Einladungsannahme ist in der Konsole noch nicht verfügbar.
• Keine Teamlöschung oder Eigentumsübertragung: Die Konsole bietet keine Routen oder UI-Bedienelemente zum Löschen eines Team-Arbeitsbereichs oder zum Übertragen des Team-Eigentums. Diese Aktionen sind im Self-Service nicht verfügbar.

Geteilte Ressourcen, Agentenzugriff und Datenexportgrenzen

Die Teams-Funktion führt null Änderungen an der Oberfläche des Model Context Protocol (MCP) ein. Agenten greifen transparent auf geteilten Team-Speicher über Standard-Tools (remember, recall, recall_context, search usw.) zu, indem sie sich einfach mit einem teamgebundenen Token authentifizieren.

• Geteilter Team-Speicher: Verbundene Agenten, die sich mit einem teamgebundenen Token authentifizieren, lesen und schreiben in den gemeinsamen Team-Speicherraum.
• Geteiltes Team-Knowledge: Dokumentensammlungen, die unter dem Teamraum (?space=<team_id>#knowledge) veröffentlicht wurden, können von Team-Agenten und Team-Mitgliedern mit knowledge:read-Bereich abgerufen werden.
• Geteilte Team-Cloud-Skills: Prozedurale Skills, die im Teamraum (?space=<team_id>#skills) erstellt wurden, unterliegen Teamrollen. Die Veröffentlichung in einem Teamraum erstellt eine PROPOSED-Revision, die die Genehmigung durch einen Admin oder Owner erfordert.
• Grenze für persönliche Projekte: Projekt-Arbeitsbereiche bleiben heute strikt ausschließlich persönlich (services/personal_console.py:7222). Das Erstellen eines Projekt-Arbeitsbereichs mit team_id wird vom Backend abgelehnt.
• Datenexportgrenze: Der persönliche Datenexport (/api/v1/export oder /me#memory) exportiert exakt persönliche Speicherdaten und schließt geteilte Team-Speichereinträge strikt aus.
• Eingefrorene Tool-Oberfläche: Es werden keine Teamverwaltungs-Tools (wie Teamerstellung oder Einladungsverwaltung) zu MCP hinzugefügt.
• Universelle Client-Kompatibilität: Claude Desktop, ChatGPT, Codex, Cursor und Gemini CLI interagieren ohne clientseitige Konfigurationsänderungen mit dem Team-Speicher.
• Gezielte Isolation: Von Agenten in einem Teamraum geschriebene Speicherdaten werden automatisch mit Team-Attribution versehen und vom persönlichen Benutzerspeicher isoliert.

Explizite Grenzen und nicht verifizierte Funktionen

Um eine Dokumentationsabweichung vor der Auslieferung des Codes zu verhindern, sind folgende Funktionen explizit nicht verfügbar und liegen außerhalb des Umfangs der aktuellen Version:

• Business-Plan erforderlich: Die Teams-Funktion gehört zum Business-Plan, der derzeit noch nicht für den öffentlichen Erwerb geöffnet ist.
• Produktionserstellung deaktiviert: Die allgemeine Self-Service-Teamerstellung ist in Produktionsumgebungen deaktiviert, bis der Business-Plan startet.
• Keine automatisierte SCIM- / SAML-Synchronisierung: Die Verzeichnissynchronisierung für Enterprise-Identitätsanbieter wird nicht unterstützt.
• Keine Cloud-übergreifende oder mandantenübergreifende Datenreplikation: Team-Daten verbleiben in einer einzelnen regionalen Mandantenpartition.
• Keine MCP-Mutations-Tools: Teams können nicht über MCP-Tool-Aufrufe erstellt, geändert oder gelöscht werden.
• Reiner Verweigerungsmodus zur Laufzeit: Die aktuelle Laufzeit arbeitet bei unberechtigten Anfragen im reinen Verweigerungsmodus (deny-only), bis der Business-Plan startet.
• Keine unbegründeten Leistungsmetriken: Widerrufs- und Abfragezeiten sind betriebliche Laufzeiteigenschaften, keine festen numerischen Garantien.