Espaços de trabalho

Um espaço de trabalho é o nível acima dos escopos: espaço de trabalho › escopo › item. Ele reúne escopos, e os itens neles, para um time ou grupo, de modo que uma instância possa atender vários. Todo escopo pertence a exatamente um espaço de trabalho, escolhido quando o escopo é criado, e o espaço de trabalho de um item é o do seu escopo.

global › @platform › @platform/code-reviewer
acme   › @acme-infra › @acme/acme-infra/deploy

Fora do global, o espaço de trabalho faz parte do nome de um item: @acme/acme-infra/deploy. O nome de um escopo é único dentro do seu espaço de trabalho, então dois espaços de trabalho podem ter um escopo de mesmo nome (veja Regras de nomes). Um espaço de trabalho e um escopo podem ter o mesmo nome.

• No catálogo e na página de um item, o item mostra o nome completo, como @acme/acme-infra/deploy, e o endereço da página também diz o espaço de trabalho: /workspaces/acme/items/acme-infra/deploy. Abaixo do nome, cada cartão e a página do item também dizem o espaço de trabalho dele, um link para a página do espaço de trabalho, e o escopo, o global incluído. Instale-o pelo nome completo: rmk install @acme/acme-infra/deploy.
• Quando você vê um espaço de trabalho além de global, os Filters do catálogo oferecem Workspace, com os espaços de trabalho que você vê.
• Um espaço de trabalho é público ou privado. Todos que estão logados veem os escopos e os itens de um espaço de trabalho público, e instalam e dependem deles; os de um privado só são vistos pelos membros dele e pelo root. Em ambos os casos, os membros dele são quem envia e revisa ali.

Toda instância tem um espaço de trabalho chamado global, descrito como “Everyone on this instance”. Ele é público e não pode ser renomeado, editado nem excluído. Os escopos que existiam antes dos espaços de trabalho estão nele, e um escopo novo vai para ele, a menos que outro espaço de trabalho seja escolhido.

Todos, menos o root, são membros de global, e ninguém sai dele: um novo usuário começa ali como user. O papel dele ali pode mudar, e ele também pode ser adicionado a outros espaços de trabalho.

O nome global é reservado para ele: nenhum outro espaço de trabalho pode usá-lo, embora um escopo possa.

Todo mundo tem um espaço de trabalho só seu, criado junto com a conta: um lugar para construir itens para você, instalá-los e testá-los, sem pedir nada a ninguém. Ele é privado, sempre, e só seu: ninguém pode ser adicionado a ele nem pedir para entrar.

• O nome vem do seu e-mail, a parte antes do @: [email protected] fica com ana-silva (ou ana-silva-2 quando esse já existe). Os itens dele têm nomes como os de qualquer espaço fora do global: @ana-silva/tools/lint. Você pode renomeá-lo.
• Workspaces, na barra lateral, o lista primeiro, como Personal, com Manage. A página dele tem os escopos, com Create scope, e Rename e Edit description: sem membros, sem pedidos, sem visibilidade para mudar, e ele nunca é excluído. O seletor de espaços de trabalho, no alto da barra lateral, o mostra e abre a página dele. Você é o admin dele, mas isso não lhe dá Users, Audit log e Settings, que são do root.
• New item, o filtro Workspace do catálogo e o rmk export o listam primeiro, como Personal.

Lançado sem revisão

Só você e o root podem ver ou instalar o que está nele, então um segundo par de olhos não protegeria ninguém. O que você envia ali é aprovado na hora: o botão diz Submit, não Submit for review, e a página da submissão diz “Approved by you: personal workspaces aren't reviewed.”, com o que ele pode fazer listado abaixo, como um revisor teria visto. Lance quando quiser. Ele nunca chega à fila de revisão, e as versões dele ficam marcadas como não revisadas: a página do item diz “Released without review.”

Quem vê

• Qualquer outra pessoa recebe o mesmo que um nome que não existe: os itens, a página e o link para entrar respondem como desconhecidos.
• O root vê todo espaço pessoal e os itens dele, e pode renomeá-lo, editar a descrição ou criar um escopo nele, mas não é membro. O catálogo, a busca e o marketplace de plugins do root deixam de fora os espaços pessoais de outras pessoas, a não ser que o filtro Workspace nomeie um; a página Workspaces do root os lista na aba Personal, com os donos.
• Os itens dele podem depender dos próprios itens e dos itens de espaços públicos, e nada de fora depende deles.
• Para compartilhar um escopo, mova-o para um espaço de trabalho de time (veja Mover um escopo). Depois que você tiver lançado versões nele, outra pessoa aprova a transferência, e isso as revisa.

O seletor de espaços de trabalho, no alto da barra lateral (no Menu, no celular ou no tablet), escolhe o espaço de trabalho em que você está trabalhando. Ele começa em All workspaces.

• Ele lista All workspaces e os espaços de trabalho dos quais você faz parte, o seu espaço pessoal primeiro; aquele em que você está fica marcado. Cada um também tem uma seta que abre a página dele, e Manage workspaces abre a lista Workspaces.
• Depois que você escolhe um, o Catalogue, Reviews (todas as abas) e My submissions mostram só esse espaço de trabalho, com Showing acme only · Show all abaixo do título, e New item começa no primeiro escopo dele. Show all volta para todos os espaços de trabalho.
• Ele continua escolhido em todas as páginas, neste navegador, até você escolher outro ou clicar em Show all.
• O filtro Workspace do próprio Catalogue, em Filters, define o mesmo ?workspace= e também lista os espaços de trabalho públicos dos quais você não faz parte. Ele muda só o que essa página mostra: a escolha do seletor continua, e Show all limpa as duas.
• O endereço diz qual é: essas páginas levam ?workspace=acme, então um link que você enviar mostra o mesmo espaço de trabalho a quem o abrir, dentro do que essa pessoa pode ver. ?workspace= sem nada depois mostra todos os espaços de trabalho.
• É um filtro, não uma permissão: muda o que você vê, nunca o que você pode fazer. Os números ao lado de Reviews e Requests na barra lateral continuam contando todos os espaços de trabalho, para que nada que esteja esperando em outro lugar passe despercebido. Nada mais é filtrado: Home, Workspaces, as páginas dos itens e Requests continuam iguais.
• Um espaço de trabalho que você não pode ver não mostra nada: o Catalogue diz “No workspace acme you can see”, o mesmo que para um nome que nenhum espaço de trabalho tenha.
• O rmk, o servidor MCP e a API não têm espaço de trabalho atual: use o nome completo do item, ou --workspace nos comandos que aceitam essa opção.

Todo espaço de trabalho é público ou privado. global é sempre público, e os espaços pessoais são sempre privados.

• Público: todos que estão logados veem os escopos e os itens dele, instalam esses itens e dependem deles.
• Privado: só os membros dele, em qualquer papel, e o root veem os escopos, os itens e as submissões dele. Os itens dele mostram um cadeado e Private ao lado do espaço de trabalho, no catálogo e na página do item; os de um espaço pessoal dizem (personal).

Para todos os outros, ele não existe

Quem não é membro recebe exatamente o que receberia por um nome que não existe, nunca “proibido”, então ninguém consegue descobrir o que um espaço de trabalho privado contém testando nomes:

• O catálogo, a busca e a página inicial deixam os itens dele de fora, e o filtro Workspace deixa o espaço de trabalho de fora. A página de um item e as versões dele respondem “não encontrado”.
• O rmk e as ferramentas MCP respondem como para um item desconhecido, como @acme/acme-infra/deploy isn't a published item. (veja Instalar). O mesmo vale para a API do registro, os downloads de tarballs e os marketplaces de plugins.
• Um rascunho em um dos escopos dele diz “There's no scope @acme/acme-infra you can use. Root and a workspace's admins create scopes.”, o mesmo que para um escopo que não existe. O Used by de um item público não lista os itens privados que dependem dele.

Dependências

Os itens de um espaço de trabalho privado só podem ser dependências de itens do mesmo espaço de trabalho. Um item pode depender dos itens do seu próprio espaço de trabalho e dos públicos (veja Dependências). Assim, um item nunca deixa de instalar para quem não consegue ver aquilo de que ele precisa.

Escolha e mudança

• New workspace pede a visibilidade, com Public já escolhido.
• O root a muda na página do espaço de trabalho, com Make private ou Make public. Os admins de um espaço de trabalho não podem: isso muda o que todos os outros veem e aquilo de que dependem.
• Make private primeiro lista o que encontra. Enquanto houver itens lançados fora do espaço de trabalho que dependam dos itens dele, a mudança é recusada, com esses itens listados: lance-os sem a dependência primeiro. Submissões abertas de fora que dependam dele são só um aviso: elas vão falhar no lançamento.
• Make public pergunta antes. As duas mudanças ficam no log de auditoria, como “Made workspace acme private”, e valem a partir da próxima requisição.

Perda de acesso

Quando alguém é removido de um espaço de trabalho privado, ou um público passa a ser privado, essa pessoa deixa de ver os itens dele a partir da próxima requisição: instalar ou atualizar um deles diz que ele não foi encontrado, e ele sai do marketplace de plugins dela. Nada do que ela já instalou é alterado.

O que privado não faz

• Não é criptografia: o banco de dados e o armazenamento guardam os itens de todos os espaços de trabalho juntos, e quem administra a instância pode lê-los. O root vê todos os espaços de trabalho.
• Um nome já escrito em algum lugar continua lá: em um lockfile, em um espelho git gerado com --workspace, ou na versão de um item de fora que dependia dele antes de o espaço de trabalho passar a ser privado e que foi retirada. O log de auditoria, que só o root lê, também cita os itens privados.

Cada espaço de trabalho tem membros, e cada membro tem um papel ali: user, moderator ou admin (veja Quem pode fazer o quê). Alguém pode comandar um espaço de trabalho como admin e ser um usuário comum em outro. Todo mundo é membro de global. O root trabalha em todos os espaços de trabalho sem ser membro de nenhum.

• Os usuários criam rascunhos, propõem mudanças e enviam itens nos escopos do espaço de trabalho, comentam nos seus e lançam os seus depois de aprovados. O formulário de novo rascunho e o rmk export listam só os escopos dos seus espaços de trabalho.
• Os moderadores também revisam, aprovam e lançam as submissões do espaço de trabalho, cuidam das versões dos seus itens e aprovam ou recusam os pedidos para entrar nele. Reviews mostra as submissões dos espaços de trabalho que você modera; ele aparece na barra lateral assim que você modera um, e o seletor de espaços de trabalho mostra um espaço de trabalho de cada vez.
• Os admins fazem tudo o que um moderador faz ali, e comandam o espaço de trabalho: adicionam e removem os membros dele, mudam os papéis deles (admins incluídos), criam os escopos dele e editam a descrição dele. Ao aprovar um pedido para entrar, eles podem fazer da pessoa um moderador em vez de um usuário. Eles fazem tudo isso na página do espaço de trabalho; Users, Audit log e Settings são do root.
• Os demais que estão logados navegam, instalam e dependem dos itens de um espaço de trabalho público, e não veem os de um privado. Criar um rascunho, propor ou enviar ali diz “You aren't a member of the acme workspace. Ask to join acme to propose changes.”, com um link Ask to join acme (veja Como entrar em um espaço de trabalho).

Quem gerencia os membros: o root, em todos os espaços de trabalho, e os admins de cada espaço de trabalho, no deles. Na página de um espaço de trabalho, a aba Members os lista; Add members encontra pessoas por e-mail ou nome e dá a elas um papel; o papel de cada membro pode ser mudado, e Remove o tira depois de uma confirmação. O root também define todos os espaços de trabalho de uma pessoa de uma vez em Users (veja Administração). Toda mudança fica no log de auditoria.

• Ninguém muda nem remove a própria participação, então um admin não pode tirar o próprio acesso por engano: outro admin ou o root faz isso.
• Ninguém é removido de global; o papel ali ainda pode mudar.
• O root não é membro e não pode ser adicionado: o root trabalha em todo lugar. Um usuário desativado mantém as suas participações.

Quem sai de um espaço de trabalho mantém os seus rascunhos e submissões abertas ali: pode lê-los e retirá-los, mas não alterar, enviar nem lançar, e os moderadores e admins do espaço de trabalho ainda podem decidi-los.

Qualquer pessoa logada pode pedir para entrar em um espaço de trabalho do qual não faz parte, e o root ou os moderadores e admins do espaço de trabalho respondem. O link para entrar é o endereço da instância seguido de /workspaces/<name>/join.

Como pedir

• Workspaces, na barra lateral depois de Catalogue, lista os espaços de trabalho que você vê: global (“Everyone”), os públicos e os privados dos quais você faz parte, com o seu papel em cada um. Um público do qual você não faz parte oferece Ask to join: se quiser, escreva uma mensagem de até 500 caracteres para quem for responder, e envie.
• Um espaço de trabalho privado não aparece na lista. O root ou os moderadores ou admins dele enviam a você o link para entrar, /workspaces/<name>/join, que mostra o nome e o mesmo formulário. O link não guarda nenhum segredo: ele só permite pedir, e uma pessoa decide. Ele é igual para um espaço de trabalho privado e para um nome que nenhum espaço de trabalho tem, antes e depois de você pedir, então não confirma que um nome existe.
• O seu pedido aparece como Requested, com Cancel, na página Workspaces e no link. Os que você fez a partir de um link ficam listados em Your other requests, pelo nome.
• Uma recusa por “não ser membro” leva ao mesmo formulário: abaixo de Propose a change na página de um item, em um rascunho que você não pode mais alterar e nos resultados de Submit selected.

Como responder

• O root e os moderadores e admins do espaço de trabalho veem Requests na barra lateral, com quantos pedidos esperam, enquanto houver algum (para o root e os admins, as transferências de escopo que esperam por eles também contam, e a página as lista em Scope moves). Essa opção abre Requests to join: todos os pedidos que eles podem responder, do mais antigo ao mais recente, com o espaço de trabalho e a mensagem de cada um. O root e os admins de um espaço de trabalho também encontram os pedidos dele na aba Requests, na página do espaço de trabalho.
• Approve adiciona a pessoa como user; o root e os admins do espaço de trabalho podem escolher moderator em vez disso. Decline pode dar um motivo, que a pessoa vê. Quando duas pessoas respondem ao mesmo tempo, vale a primeira resposta, e a outra recebe “Already answered.”

Depois da resposta

• Se for aprovado, o espaço de trabalho aparece na sua página Workspaces com o seu papel. Se for recusado, você vê a data e o motivo, e pode pedir de novo 7 dias depois, ou na hora se tiver sido adicionado ao espaço de trabalho ou removido dele desde então.
• Um pedido aberto por espaço de trabalho, e no máximo 10 abertos ao mesmo tempo. Adicionar você diretamente ao espaço de trabalho aprova o seu pedido; desativar a sua conta cancela os seus pedidos.
• Cada etapa (pedido, aprovação, recusa, cancelamento) fica no log de auditoria; a mensagem e o motivo, não.

Tudo sobre espaços de trabalho fica em Workspaces, na barra lateral (o seletor no alto dela também abre os espaços dos quais você faz parte). Ali estão os espaços de trabalho que você vê, e o nome de cada um abre a página dele. A lista do root tem todos, com o global primeiro, a descrição, a visibilidade, o número de escopos e de moderadores de cada um, admins incluídos (“None” quando só o root revisa ali); busque por parte de um nome ou descrição, e ordene por nome ou data de criação. Duas abas acima dela, Shared e Personal, dizem cada uma quantos correspondem à busca; Personal lista os espaços pessoais de todos, cada um com o e-mail do dono (a busca também o encontra).

A página de um espaço de trabalho é de todos que veem o espaço de trabalho: a descrição, a visibilidade, o seu papel ali (ou Ask to join) e os escopos dele. O que você pode fazer ali só aparece se você puder: os admins dele e o root veem mais.

• Scopes (a aba padrão): Create scope cria um escopo nesse espaço de trabalho, e os ícones de cada escopo editam a descrição dele ou o movem (veja Mover um escopo), para o root e os admins dele. A transferência de um escopo aparece embaixo da descrição dele.
• Members, para o root e os admins dele, lista nome, e-mail, papel e quando cada um foi adicionado, por nome ou por data de adição, 50 por página; busque por e-mail ou nome e filtre por papel. Add members encontra pessoas por e-mail ou nome (não as que já estão nele, nem o root, nem usuários desativados), deixa escolher várias e dá a elas um papel. O papel de um membro muda assim que você escolhe outro, e Remove pergunta antes. A sua própria linha não pode ser mudada, e ninguém é removido do global.
• Requests, para quem os responde, lista os pedidos para entrar abertos, do mais antigo ao mais recente, com a mensagem de cada um, e, para o root e os admins dele, as transferências de escopo para ele que esperam resposta.

Users, Audit log e Settings são só do root: os admins de um espaço de trabalho gerenciam o espaço pela página dele, e o endereço antigo dele em /admin abre essa página.

• New workspace, do root, em Workspaces: um nome e uma descrição. O nome segue as regras dos escopos (letras minúsculas, dígitos e hífens, até 64 caracteres, sem começar nem terminar com hífen), os nomes reservados dos escopos e global estão indisponíveis; o root e os admins dele podem renomeá-lo depois. Ele também pergunta se o espaço de trabalho é público ou privado, com público já escolhido; o root pode mudar isso depois.
• Edit description, na página de um espaço de trabalho, é para o root e os admins dele. Make private ou Make public, do root, muda quem o vê: Make private lista os itens de fora que dependem dele, e é recusado enquanto houver algum. A página do global não tem nenhum desses, nem Rename nem Delete; a de um espaço pessoal tem só Rename e Edit description.
• Rename, na página de um espaço de trabalho, é para o root e os admins dele; o global mantém o nome. O nome novo segue as mesmas regras e não pode ser o de outro espaço de trabalho. Os itens dele passam a usá-lo: @acme/team/lint vira @acme-platform/team/lint. Os nomes antigos continuam funcionando para instalações, lockfiles e dependências, e o rmk passa os projetos para os nomes novos à medida que eles atualizam; no Claude Code eles aparecem como plugins novos. Os rascunhos e as submissões ainda não lançados também passam aos nomes novos. Os links para o espaço de trabalho (a página dele e o link para pedir para entrar) deixam de funcionar, assim como o nome antigo em rmk search --workspace, rmk feed build --workspace e nos workflows de CI que o citam: o nome antigo passa a ser um nome que nenhum espaço de trabalho tem, e outro espaço de trabalho pode usá-lo. Os membros, os escopos e os pedidos dele continuam.
• Delete é do root, e só funciona enquanto o espaço de trabalho não tem escopos (fica desativado com “Move or remove its scopes first.”): mova-os antes (veja Mover um escopo). Os pedidos para mover um escopo para ele são fechados junto.
• Criar um escopo: na página de um espaço de trabalho, Create scope cria um nesse espaço de trabalho, para o root e os admins dele; não há outro lugar para criar um. Um escopo pode ser movido para outro espaço de trabalho depois (veja Mover um escopo).

Criar um espaço de trabalho, mudar a descrição ou a visibilidade dele, renomeá-lo, excluí-lo, e adicionar, mudar e remover os membros dele ficam registrados no log de auditoria.

Um escopo passa para outro espaço de trabalho com todos os itens dele: um time assume um escopo, algo construído num espaço pessoal vira de um time, ou algo comprovado num time vai para o global, para todo mundo. Na página de um espaço de trabalho, cada escopo tem Move… para o root e os admins do espaço de trabalho (num espaço pessoal, o dono).

Quem precisa concordar

• O root move na hora, depois de duas confirmações: a segunda pede o nome do escopo, digitado.
• Um admin do global movendo para o global move na hora do mesmo jeito. Qualquer outra pessoa movendo para o global pede, e só o root responde.
• Um admin do espaço de trabalho de destino, ou quem move para o próprio espaço pessoal, move na hora depois de uma confirmação.
• Qualquer outra pessoa pede para mover, com uma mensagem opcional: os admins do destino ou o root respondem. Ninguém move um escopo para o espaço pessoal de outra pessoa.
• Não revisadas: um escopo cujas versões lançadas não foram revisadas (vindas de um espaço pessoal) sempre pede, e quem responde é alguém que não seja você: o root, ou um admin do destino (só o root para o global). Aprovar a transferência revisa essas versões, em nome dessa pessoa.

A caixa de diálogo Move

Escolha para onde, e o nome do escopo lá: o mesmo, a não ser que o espaço de trabalho já tenha um escopo com esse nome (“acme already has a scope called infra: pick another name for it there”). Ao escolher, ela diz o que muda: o novo nome de cada item (@infra/deploy → @acme/infra/deploy), quem vai ver e revisar os itens, trabalho aberto de pessoas que não são membros do destino (elas podem ler e retirar, não mudar), versões não revisadas, e o que impede a transferência. O que está num espaço de trabalho que você não vê é contado, nunca nomeado. O botão diz o que acontece: Move scope ou Ask to move.

O que impede uma transferência

• Itens lançados fora de um destino privado que dependem dos itens do escopo: deixariam de ser instalados por quem não vê o destino.
• Versões lançadas ou submissões do próprio escopo que dependem de itens de outro espaço de trabalho privado, de que não poderiam depender lá.
• Um novo nome que é o nome antigo de outro item, ou um nome de escopo já usado lá.

Cada um é verificado quando você pede e de novo quando alguém aprova, e então o pedido fica aberto com a lista do que o impede. Submissões abertas de fora que dependam do escopo são só um aviso: elas vão falhar no lançamento.

Como responder

Os pedidos esperam na página Requests, em Scope moves, e na aba Requests do destino: o escopo e seus itens, de onde e para onde, o nome dele lá, quem pediu, a mensagem, e o que o impediria agora. Approve verifica de novo e move; Decline pode dar um motivo, mostrado na linha do escopo. Até lá a linha diz “Moving to acme”, com Cancel para quem pediu e os admins do espaço de trabalho. Só uma transferência por escopo espera de cada vez. Se, quando o pedido for aprovado, quem pediu não for mais admin do espaço de trabalho do escopo, o pedido é cancelado.

Depois da transferência

• Os itens têm os nomes do destino. Os nomes antigos continuam funcionando para instalações, lockfiles e dependências, e o rmk passa os projetos para os novos conforme eles atualizam; no Claude Code eles aparecem como plugins novos. Movido de volta, um escopo retoma os nomes de antes.
• Quem os vê segue o destino, a partir da próxima requisição: quem não vê o destino recebe “não encontrado”, e as instalações dessas pessoas deixam de atualizar. Os moderadores e admins do destino revisam as submissões abertas, que passam a nomear os itens pelos nomes novos.
• Versões, tags e contagens de downloads não mudam. Cada etapa fica no log de auditoria.