Colaboração em equipe

O AWR permite que várias pessoas — e os Agentes com quem elas trabalham — se coordenem em um projeto compartilhado: todos veem as mesmas tarefas, fazem claim do trabalho que estão executando, reportam progresso ao longo do caminho e entregam o trabalho concluído a um revisor independente. Você conduz tudo isso da sua conversa normal com o Agente; não precisa ficar copiando IDs de tarefas em um navegador.

Disponibilidade: este artigo descreve o serviço de Equipe, que ainda está em desenvolvimento. Ele não faz parte do servidor MCP pessoal 0.5.0 publicado. As capacidades abaixo se aplicam a um projeto de equipe hospedado pelo administrador do seu projeto, não a uma configuração local pessoal.

Para as ideias de base (itens de trabalho, contratos, evidências, sessões), leia Conceitos primeiro. Para o ciclo do dia a dia de uma pessoa só, veja Seu fluxo de trabalho diário.

O modelo de colaboração em resumo

Quatro ideias sustentam todo o modelo:

• Workstreams e trabalho compartilhado. O projeto remoto é a autoridade de trabalho compartilhada — o único lugar onde tarefas, dependências, progresso e resultados vivem. O seu checkout local é apenas para código e testes; não inicialize um segundo ledger de tarefas local para substituir o projeto remoto.
• Claim. Antes de um Agente começar o trabalho de execução, ele faz um claim ativo da tarefa, sob a sua sessão. O claim ativo de outra pessoa não deve ser substituído, de modo que dois Agentes não podem trabalhar silenciosamente na mesma coisa.
• Revisão. Entrega e aceitação são fatos separados. Uma pessoa autorizada e independente revisa o trabalho enviado antes de ele ser aceito. Um segundo Agente seu não é um revisor independente.
• Handoff. As sessões são duráveis: sobrevivem a reconexões MCP, carregam checkpoints e estado de recuperação e podem ser retomadas — por você depois de uma pausa, ou inspecionadas por um colega de equipe — sem perder contexto.

Conecte uma vez

Peça ao administrador do seu projeto uma URL MCP de projeto e a sua credencial individual. Cada participante usa a sua própria credencial, e as permissões do repositório ficam separadas das permissões do AWR — entrar no projeto AWR não concede acesso ao Git, e vice-versa.

Nos bastidores, um administrador autorizado abre Members no Inspector, adiciona você, escolhe o seu papel no projeto e os seus workstreams e copia uma instrução de conexão pessoal de uso único contendo o endpoint e a sua credencial. Você a recebe por um canal privado. O administrador não consegue recuperar o texto em claro depois de limpar o painel de emissão; se você perder a credencial, ela pode ser substituída explicitamente.

Adicione o servidor MCP remoto em qualquer cliente de Agente que suporte MCP remoto via Streamable HTTP com autenticação Bearer:

Essas são configurações de conexão, não um formato de arquivo de configuração nem um comando de shell; cada cliente tem as suas próprias configurações e requisitos de versão. Se o seu cliente suporta apenas MCP stdio local, essa URL não pode ser usada diretamente — use uma versão de cliente ou integração que suporte o transporte remoto.

Algumas regras de segurança para a credencial:

• Use as configurações de segredos suportadas pelo seu cliente ou uma entrada de Agente privada e confiável.
• Nunca coloque a credencial em uma URL, em uma conversa compartilhada ou no repositório.
• Reconecte depois de mudar a configuração e depois abra o seu checkout local de código no Agente.

Dê o resultado ao seu Agente

Você trabalha na mesma conversa que usa para desenvolver. Descreva o resultado e deixe o Agente coordenar, por exemplo:

Use o projeto AWR Team conectado para implementar a API de issues. Atualize as tarefas atuais e retome o meu trabalho existente, ou faça claim de uma tarefa elegível que corresponda a este pedido. Leia o contrato, as dependências e o checkpoint mais recente antes de editar. Mantenha o progresso e as evidências no AWR, envie a mudança testada como um PR e solicite revisão independente.

O Agente lê o trabalho compartilhado, faz claim de uma tarefa elegível e mantém o projeto atualizado enquanto desenvolve localmente. Se ele encontrar um conflito real de permissão, dependência ou posse, ele reporta isso a você em vez de contornar o problema.

O que o Agente faz por você

O Agente fala com o serviço de Equipe por meio de duas ferramentas MCP descobertas, awr_team_query para leituras e awr_team_command para escritas. Toda consulta e comando reverifica as suas permissões atuais, então uma mudança de papel entra em vigor sem que ninguém edite a configuração local.

Uma sessão típica flui assim:

1. Iniciar ou reconectar. O Agente consulta capabilities para confirmar a sua identidade e permissões, depois work.next para retomar as suas próprias sessões ou descobrir trabalho visível inacabado, seguindo o next_query retornado. (Em servidores mais antigos sem work.next, ele recorre a workstreams.list e a work.list / work.search com escopo.)
2. Preparar. Para uma tarefa selecionada, work.prepare retorna o contrato atual, as especificações exigidas, as dependências, o estado de recuperação e um hash de contexto — um snapshot que o Agente precisa realmente consumir antes de editar. work.prepare e work.observe também podem retornar um item curto de guidance (a sua condição, base factual, próxima ação e gatilho de reavaliação); é um conselho, não um direito de execução.
3. Claim. O Agente inspeciona os claims existentes com claim.inspect e depois adquire ou renova um claim ativo sob a sua sessão.
4. Executar. Com execution.prepare e uma resposta nova de execution.start carregando execution_authorized=true, o Agente pode realizar uma execução dentro do escopo declarado. A sua máquina roda o código e as ferramentas — o serviço nunca executa nada sozinho. Um claim sozinho não é admissão de execução.
5. Reportar progresso. O Agente envia session.checkpoint com o hash de contexto consumido, a próxima ação, os pontos em aberto e um resumo curto de progress, agrupando atualizações quando uma fase ou teste é concluído, um bloqueio muda, a sua entrada é necessária ou a entrega está pronta — não a cada chamada de ferramenta. Lembre-se de que os resumos de checkpoint são compartilhados com leitores autorizados do trabalho, então logs sensíveis brutos não pertencem a eles.
6. Concluir ou parar. execution.report registra um resultado terminal com evidência vinculada a versão. Os claims são liberados e as sessões encerradas somente depois que o trabalho ativo e os resultados desconhecidos estão resolvidos.

Revisão e aceitação

Quando o trabalho está pronto, o Agente envia evidências e solicita revisão por meio de delivery.submit_and_request_review ou review.open. Uma pessoa autorizada e independente revisa a entrega, e a finalização autorizada segue a política de aceitação do projeto.

Mantenha estes como fatos separados: implementação, verificação, o merge no GitHub e a aceitação no AWR. Fazer merge de um PR não é o mesmo que o AWR aceitar a tarefa, e o seu próprio segundo Agente não conta como revisor independente.

Handoff e recuperação

O handoff funciona porque as sessões e os checkpoints vivem no projeto compartilhado, não no histórico de chat de uma pessoa:

• Reconectar o MCP não encerra uma sessão de trabalho durável nem renova o seu lease.
• O estado de recuperação e as entregas registradas têm precedência sobre instruções de checkpoints antigos, então um Agente que retorna confia no que realmente aconteceu.
• Se uma escrita expirar, o Agente inspeciona o resultado do comando original antes de tentar exatamente de novo; recibos reproduzidos são fatos históricos, não permissão para executar efeitos novamente.
• Se os efeitos de uma execução são desconhecidos (uma interrupção no meio da tarefa), eles exigem inspeção e reconciliação autorizada. Criar uma nova sessão não contorna esse requisito.

Dois limites práticos a conhecer: o AWR não consegue acordar um Agente ocioso (a renovação de lease usa o agendamento do seu host, separado dos checkpoints), e uma fase bloqueada ou em espera é um relatório — ela não cria um item de espera nem renova um claim por si mesma.

Inspector: a view opcional de workspace

O Inspector é uma view web sobre o mesmo projeto. Entrar ou fazer claim por um site não é pré-requisito para nada do que está acima — o Agente continua sendo a superfície de coordenação. Use o Inspector quando você quiser:

• Inspecionar relações entre tarefas, posse, progresso e resultados registrados.
• Copiar configurações MCP neutras quanto a cliente e uma instrução de projeto em Connect Agent, ou um brief por tarefa (copiar texto não cria sessão nem claim).
• Como administrador, gerenciar membros e credenciais com escopo de projeto em Members.
• Revisar Activity, que separa registros de acesso autenticado do histórico de desenvolvimento confirmado. Membros comuns veem a sua própria atividade autorizada; auditores de projeto podem filtrar por membro ou tarefa. Os registros de auditoria excluem valores de credenciais, conversas e entradas/saídas arbitrárias de ferramentas, e os metadados de requisição têm retenção limitada — não é um arquivo permanente de conformidade.

As permissões de administrador e de revisão são aplicadas pelo serviço central independentemente do cliente que você usa, então as regras valem tanto se alguém trabalha por um Agente, pelo Inspector ou por ambos.

Próximos passos

• Novo no AWR? Comece com O que é o AWR e o Quickstart.
• Conecte as suas próprias ferramentas via MCP: MCP.
• Trabalhando com Agentes no dia a dia: Agentes e Seu fluxo de trabalho diário.
• Algo não está funcionando? Veja Solução de problemas.