Teams

Arquitetura de memória do Teams e status Preview

Teams é um recurso do plano Business. Em produção, a criação de equipes fica desativada por padrão até o lançamento do plano Business; o runtime atual opera em modo somente negação (deny-only) para solicitações não autorizadas. Os administradores de espaço gerenciam os limites do espaço de trabalho e o provisionamento de locatários no plano de gerenciamento do espaço de trabalho, enquanto o acesso dos agentes à memória é governado por assentos no plano de dados com vínculos criptográficos de espaço isolados por locatário.

• Status Preview: No Memory Console em https://xmemo.dev/me#teams, o Team Management está marcado com o selo Preview.
• Contexto do espaço de trabalho do console: O cabeçalho do Team Management anuncia "One workspace for members and invitations." onde administradores gerenciam membros ativos e convites pendentes.
• Navegação no espaço: Colaboradores alternam para um espaço de equipe usando o parâmetro explícito de espaço (https://xmemo.dev/me?space=<team_id>#memory) ou inspecionam conhecimento compartilhado (https://xmemo.dev/me?space=<team_id>#knowledge) e habilidades (https://xmemo.dev/me?space=<team_id>#skills).
• Isolamento colaborativo: Espaços de trabalho de equipe fornecem contexto compartilhado para múltiplos agentes isolado dos espaços de memória pessoal de usuários individuais (/me#memory).

Elegibilidade da equipe, requisitos de criação e limites de assinatura

A criação de equipe requer uma assinatura Business elegível com pelo menos 2 assentos adquiridos. Como o plano Business não está aberto para compra atualmente, a criação de equipe em autoatendimento é desativada por padrão para contas gerais. A documentação pública nunca apresenta a compra de assentos como uma ação disponível.

• Postura de criação: A criação de equipe em autoatendimento fica desativada por padrão em ambientes de produção até que o plano Business seja lançado.
• Requisito de elegibilidade: O console verifica a autorização da organização antes de abrir a criação de equipe. Se inelegível, a interface exibe: "A Business subscription with at least 2 purchased seats is required to create a team."
• Motivo de limitação de Preview: Se uma conta não tiver liberação na lista de permissões, o console exibirá: "Team creation is currently limited to preview accounts."
• Motivo de indisponibilidade geral: Para contas não provisionadas, o console declara: "Team creation is not available for this account yet."
• Status comercial: A assinatura Business não pode ser adquirida atualmente. Adições de assentos em autoatendimento e upgrades de plano estão desativados.
• Modal de criação: Em contas de prévia autorizadas, clicar em Create team abre um modal dizendo: "Enter your company name. This will become the team name inside XMemo." com o campo de entrada "Company name" (espaço reservado "e.g. Acme Corp").

Hierarquia RBAC de quatro níveis e limites de emissão de credenciais

Permissões de associação de equipe e limites de emissão de credenciais são aplicados pelos serviços de console pessoal. Membros ativos com as funções owner, admin ou member podem emitir credenciais vinculadas à equipe dentro dos limites de escopo específicos da função, enquanto viewers são estritamente somente leitura e têm a emissão de tokens negada. O esquema de funções abaixo é um resumo ilustrativo (não uma resposta de API):

• Hierarquia de funções: Resumo ilustrativo (não uma resposta de API) mapeando funções do espaço de trabalho para níveis de permissão e limites de emissão de tokens.
• owner (nível 3): Criador do espaço de trabalho fixado à conta de faturamento. Pode convidar membros com as funções Admin, Member ou Viewer; pode atualizar funções de membros não proprietários (entre Admin, Member e Viewer); pode remover membros não proprietários e revogar convites. Pode emitir credenciais vinculadas à equipe com qualquer escopo de autoatendimento, incluindo escopos de memória no plano de dados, ledger, conhecimento e auditoria (memory:read, memory:write, memory:restore, read:memories, write:memories, delete:memories, ledger:read, ledger:write, knowledge:read, knowledge:write e read:audit).
• admin (nível 2): Administrador do espaço de trabalho. Pode convidar membros com as funções Member ou Viewer (não pode convidar Admins); pode remover membros não proprietários e revogar convites pendentes; não pode modificar funções de membros. Pode emitir credenciais vinculadas à equipe com qualquer escopo de autoatendimento, incluindo escopos de memória no plano de dados, ledger, conhecimento e auditoria (memory:read, memory:write, memory:restore, read:memories, write:memories, delete:memories, ledger:read, ledger:write, knowledge:read, knowledge:write e read:audit).
• member (nível 1): Colaborador padrão do espaço de trabalho. Acesso de leitura, gravação e restauração a assentos de memória de equipe compartilhados, itens de conhecimento da equipe e Cloud Skills da equipe. Pode emitir credenciais pessoais vinculadas à equipe limitadas aos escopos de membro da equipe (memory:read, memory:write, memory:restore, read:memories e write:memories); não pode emitir escopos elevados de ledger ou conhecimento e não pode gerenciar membros ou configurações do espaço de trabalho.
• viewer (nível 0): Acesso à memória somente leitura no console (memory:read) e inspeção de conhecimento compartilhado. Nenhuma emissão de credencial permitida; proibido de gravar memória, atualizar estado ou emitir credenciais de equipe.
• Restrição de proprietário único: Um proprietário único tentando sair da equipe recebe o aviso: "Cannot leave team as the sole owner. Transfer ownership or delete the team first." (com dica de ferramenta: "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": []
    }
  }
}

Vinculação de espaço autoritativa no servidor e revogação dinâmica

O isolamento multilocatário é aplicado no servidor por meio de vínculos criptográficos de espaço. Cada chave de API delimitada por equipe contém reivindicações imutáveis (bound_team_id, membership_id_at_issue, space_binding_version) que não podem ser alteradas ou fornecidas por solicitações de cliente. As solicitações direcionadas a uma equipe incompatível falham de forma fechada imediatamente com HTTP 403 token_space_mismatch.

• Verificação de espaço autoritativa: Solicitações direcionadas a uma equipe incompatível falham de forma fechada imediatamente com HTTP 403 token_space_mismatch.
• Garantia anti-spoofing: Solicitações com cabeçalhos de equipe forjados ou conflitantes são rejeitadas na borda antes de acessar pools de banco de dados.
• Revogação dinâmica baseada em época: A validação de associação verifica a época de membership_id ativa em cada solicitação autenticada, garantindo que membros removidos percam o acesso imediatamente após a atualização da época sem esperar pela expiração do token.

Gerenciamento de assentos, ciclo de vida de convites e limites operacionais

A capacidade do espaço de trabalho é acompanhada qualitativamente entre associações ativas e convites pendentes. Os limites operacionais regem a emissão de convites, a expiração e os recursos do console:

• Contagem qualitativa de assentos: Assentos ocupados consistem em membros ativos mais convites pendentes não expirados, exibidos no cabeçalho do console como "Seats {used} / {limit} used, {members} members, {pending} pending".
• Expiração técnica de convites: Convites de equipe expiram 7 dias após a emissão (teams_service.py:1184-1188). Convites expirados liberam sua reserva e não contam mais para os assentos ocupados.
• Limite de capacidade de assentos: Quando todos os assentos disponíveis estiverem ocupados, o modal Add member avisará: "Team seat limit reached. Upgrade or remove a member or pending invitation to send more invitations."
• Status do fluxo de trabalho de convite: O envio de um convite gera um link de token seguro de 7 dias. No entanto, a aceitação do convite não tem consumidor na interface do console hoje; o fluxo de trabalho completo de aceitação de convite ainda não está disponível no console.
• Sem exclusão de equipe ou transferência de propriedade: O console não fornece rotas ou controles de interface de usuário para excluir um espaço de trabalho de equipe ou transferir a propriedade da equipe. Essas ações não estão disponíveis em autoatendimento.

Recursos compartilhados, acesso de agentes e limites de exportação de dados

O recurso Teams não introduz alterações na superfície do Model Context Protocol (MCP). Os agentes acessam a memória compartilhada da equipe de forma transparente usando ferramentas padrão (remember, recall, recall_context, search, etc.) simplesmente autenticando com um token vinculado à equipe.

• Memória compartilhada da equipe: Agentes conectados autenticando com um token vinculado à equipe leem e gravam no espaço de memória compartilhada da equipe.
• Conhecimento de equipe compartilhado: Coleções de documentos publicadas no espaço da equipe (?space=<team_id>#knowledge) podem ser recuperadas por agentes da equipe e membros da equipe com escopo knowledge:read.
• Cloud Skills de equipe compartilhadas: Habilidades procedimentais criadas no espaço da equipe (?space=<team_id>#skills) são governadas por funções de equipe. A publicação em um espaço de equipe cria uma revisão PROPOSED que exige aprovação de Admin ou Owner.
• Limite de projetos pessoais: Espaços de trabalho de projeto permanecem estritamente pessoais apenas hoje (services/personal_console.py:7222). A criação de um espaço de trabalho de projeto com team_id é rejeitada pelo backend.
• Limite de exportação de dados: A exportação de dados pessoais (/api/v1/export ou /me#memory) exporta exatamente memórias pessoais e exclui estritamente registros de memória compartilhada da equipe.
• Superfície de ferramentas congelada: Nenhuma ferramenta de gerenciamento de equipe (como criação de equipe ou gerenciamento de convites) é adicionada ao MCP.
• Compatibilidade universal com clientes: Claude Desktop, ChatGPT, Codex, Cursor e Gemini CLI interagem com a memória da equipe sem alterações de configuração no lado do cliente.
• Isolamento com escopo: Memórias gravadas por agentes em um espaço de equipe são automaticamente marcadas com a atribuição da equipe e isoladas da memória pessoal do usuário.

Limites explícitos e recursos não verificados

Para evitar divergências na documentação antes do código enviado, os seguintes recursos não estão explicitamente disponíveis e estão fora do escopo da versão atual:

• Plano Business necessário: O recurso Teams pertence ao plano Business, que atualmente ainda não está aberto para compra pública.
• Criação em produção desativada: A criação geral de equipes em autoatendimento está desativada em ambientes de produção até que o plano Business seja lançado.
• Sem sincronização automatizada SCIM / SAML: A sincronização de diretórios de provedores de identidade corporativos não é suportada.
• Sem replicação de dados entre nuvens ou várias regiões: Os dados da equipe residem em uma única partição regional de locatário.
• Sem ferramentas de mutação do MCP: As equipes não podem ser criadas, modificadas ou excluídas por meio de chamadas de ferramentas do MCP.
• Modo de runtime somente negação: O runtime atual opera em modo somente negação para solicitações não autorizadas até que o plano Business seja lançado.
• Sem métricas de desempenho infundadas: Os tempos de revogação e de consulta são propriedades operacionais de tempo de execução, não garantias numéricas fixas.