A configuração guiada é como o SuperDevSpace fecha essa lacuna. O agente abre o site no navegador do próprio app, faz os cliques que tem permissão para fazer e passa a página para você, com uma indicação e uma frase, exatamente quando o próximo passo é seu.

Por que "deixa o agente fazer" é a resposta errada

A versão fácil deste recurso daria ao agente o navegador inteiro: ler cada campo, digitar em cada caixa, apertar cada botão. Seria rápido, e seria uma má ideia. Um fluxo de configuração está cheio de coisas em que um agente nunca deveria tocar:

• sua senha e o código de uso único do seu celular;
• números de cartão, dados bancários e documentos de identidade;
• os termos que você aceita e o pagamento que você aprova.

Por isso o design começa pela outra ponta. O agente faz o trabalho de rotina — navegar, achar a página certa, preencher um nome de projeto, clicar em Criar — e tudo o que é pessoal ou vinculante fica com você.

Como uma configuração guiada acontece

O ciclo é o mesmo em qualquer site, inclusive naqueles para os quais ninguém escreveu instruções.

No fim, dá para conferir o resultado sem exibir nenhum segredo na tela:

$ grep -o '^PADDLE_[A-Z_]*=' .env
PADDLE_API_KEY=
PADDLE_CLIENT_TOKEN=
PADDLE_WEBHOOK_SECRET=
PADDLE_ENVIRONMENT=

Regras que o app impõe

São verificações dentro do app, e o agente não consegue desligá-las:

• Nenhum segredo entra, nenhum segredo sai. O agente não consegue digitar num campo de senha, cartão, CVC, IBAN, código de uso único ou identidade. Quando ele lê a página ou tira um snapshot, esses valores ficam ocultos e são removidos de qualquer texto que ele leia.
• As capturas de tela são cobertas. Campos sensíveis e todo frame de outra origem — um widget de cartão, uma caixa de "Entrar com o Google" — são cobertos antes que o agente veja uma imagem.
• Sem scripts em páginas sensíveis. Rodar JavaScript na página é recusado em qualquer página que mostre um desses campos.
• Consentimento e pagamento são seus. Clicar numa caixa de termos ou num botão "Pagar" / "Finalizar pedido" é recusado.
• Tudo fica visível. O que o agente faz no painel de navegador aparece para você na faixa do painel, enquanto acontece.
• Segredos ficam fora da conversa. Um valor lido como segredo é marcado como sensível, e o agente é instruído a nunca repeti-lo no chat, em relatórios, em notas de tarefa ou em notificações.

Qualquer site, não uma lista de integrações

A configuração guiada é um ciclo, não uma biblioteca de scripts. Funciona num site para o qual ninguém escreveu dica, porque o agente lê a página que está à frente dele. Para alguns serviços, incluímos arquivos curtos de dicas — por exemplo, o painel sandbox do Paddle e o RevenueCat — que dizem ao agente onde as configurações de desenvolvedor costumam ficar. Os painéis mudam os menus o tempo todo, então as dicas dizem com todas as letras: quando a página e a dica discordarem, confie na página.

Isso importa mais do que parece. O código de integração que um agente escreve é só metade de um recurso; a outra metade é a conta, a chave e o webhook no site de outra pessoa. Com a configuração guiada, as duas metades acontecem na mesma sessão, com o mesmo agente, e você gasta seu tempo só com os passos que só você pode dar.

Onde isso se encaixa

A configuração guiada faz parte do mesmo espaço de trabalho que todo o resto do SuperDevSpace: o agente que escreve sua integração de checkout é o mesmo que te acompanha na criação das chaves dela, num painel de navegador ao lado do terminal dele. Se você chegou agora, por que criamos o SuperDevSpace explica o resto do time em volta.

Experimente

O teste é de 14 dias de Premium, sem cartão. Baixe o SuperDevSpace, peça a um agente para configurar um provedor de pagamentos ou de analytics no seu projeto e deixe que ele te passe a página quando for a sua vez.

O SuperDevSpace roda um manager e vários workers no mesmo repositório ao mesmo tempo. Este post explica o mecanismo que os mantém separados — as git worktrees — e as regras exatas que o app segue em torno delas.

O que é uma git worktree

Um repositório git normalmente tem um único diretório de trabalho. O git worktree permite que um mesmo repositório tenha vários, cada um num branch próprio, todos compartilhando o mesmo banco de objetos. Não há um segundo clone nem uma segunda cópia do histórico: uma worktree nova custa os arquivos de um checkout e nada mais.

Dá para testar à mão em qualquer repositório. Os comandos são os mesmos em todo lugar; só o shell muda:

git worktree add -b agent/frontend-demo ../myrepo-frontend
git worktree list
cd ../myrepo-frontend && git status
cd - && git worktree remove ../myrepo-frontend

git worktree add -b agent/frontend-demo ..\myrepo-frontend
git worktree list
cd ..\myrepo-frontend; git status
cd ..\myrepo; git worktree remove ..\myrepo-frontend

Cada worktree tem o próprio HEAD, o próprio índice e os próprios arquivos. Dois processos podem editar, buildar e testar em duas worktrees ao mesmo tempo sem ver as mudanças pela metade um do outro. É exatamente a propriedade de que um time de agentes precisa.

Como o SuperDevSpace as usa

As regras são simples e iguais para toda organização:

• O manager trabalha no seu checkout principal. Ele planeja, revisa e faz merge; é o único lugar onde os branches se encontram.
• Cada worker ganha a própria worktree no próprio branch. Quando o manager contrata um worker, o app roda git worktree add -b <branch> <caminho> para ele. O branch se chama agent/<nome-do-worker>-<marca>, a menos que você tenha dado um nome a ele.
• As worktrees ficam na pasta de dados do app, em worktrees/<organização>/<worker>, nunca dentro do seu repositório. Sua pasta de projeto não se enche de diretórios de agentes.
• Todo turno vira commit. Quando um worker termina um turno, o app faz commit de tudo o que mudou na worktree dele (agent(<nome>): turn). Nada do que um worker fez fica só num diretório de trabalho sem commit.
• O merge é um squash merge. Quando o manager aceita o relatório de um worker, o branch entra na sua linha com git merge --squash e um único commit. Se o merge der conflito, o app o aborta e deixa o repositório limpo para a próxima operação, em vez de te deixar no meio de um merge conflitante.
• Uma operação git por vez por repositório. Os diretórios das worktrees isolam os arquivos; uma fila por repositório serializa os próprios comandos git, então dois workers que terminam no mesmo instante nunca disputam os metadados do git.

No quadro, isso aparece como várias tarefas em andamento ao mesmo tempo, cada uma de um worker diferente, cada uma com o próprio branch por baixo.

O que torna isso prático

Uma worktree recém-criada só contém o que o git rastreia. Isso geralmente não basta para rodar um projeto: node_modules, um .env local, arquivos gerados. Dois detalhes resolvem.

Um script de setup por repositório

Se o seu repositório tem .super/scripts/setup-worktree.sh, o app o executa dentro de cada worktree nova antes de o worker começar, com SUPERDEV_MAIN_REPO apontando para o seu checkout principal. A saída aparece ao vivo — uma instalação longa não é uma espera às cegas — e você pode cancelar.

#!/usr/bin/env bash
set -euo pipefail
# Copiar arquivos só locais do checkout principal
cp "$SUPERDEV_MAIN_REPO/.env" .env 2>/dev/null || true
# Instalar dependências (o pnpm cria links a partir de um store compartilhado, então é rápido)
pnpm install --frozen-lockfile

Submódulos

O git worktree add deixa os submódulos vazios. Se a worktree nova tem um arquivo .gitmodules, o app roda git submodule update --init --recursive nela, para que nenhum worker builde contra uma dependência que sumiu sem aviso.

Limpando sem perder trabalho

As worktrees se acumulam. O app as recupera, mas com cautela:

Uma worktree com mudanças sem commit, ou com um branch que tem trabalho ainda fora da sua linha, fica onde está. Uma pasta apagada pode ser recriada; trabalho perdido, não. A mesma cautela vale para os branches: o app acompanha os branches que criou e só mexe neles.

O que muda para você

Com cada worker no próprio branch, "rodar quatro agentes de uma vez" deixa de ser uma aposta. Você pode:

• dar ao manager uma diretiva que se divide em tarefas independentes e deixar os workers rodarem em paralelo;
• ler o diff de qualquer worker isoladamente, ao lado da conversa que o produziu;
• rejeitar a mudança de um worker sem atrapalhar os outros;
• continuar usando o seu checkout principal enquanto o time trabalha.

É a mesma disciplina que um time humano usa, aplicada a agentes que não conseguem avisar que estão prestes a pisar no pé um do outro. Se você está se perguntando por que construímos um app inteiro em volta disso, o primeiro post conta essa história.

Experimente

O teste de 14 dias é Premium, sem cartão. Baixe o SuperDevSpace, aponte uma organização nova para um repositório e veja as worktrees aparecerem conforme o manager contrata os primeiros workers.

Foi por essa lacuna que criamos o SuperDevSpace. É um app de desktop que transforma a CLI que você já tem em um pequeno time: um manager que planeja o trabalho e workers que o executam, cada um no seu próprio terminal e na sua própria git worktree.

O problema de um agente num terminal

Trabalhar com um único agente de código é ótimo para uma única tarefa. Desmorona assim que você tem três coisas para fazer no mesmo repositório:

• Você pode abrir um segundo terminal, mas aí os dois agentes editam o mesmo checkout. Um roda a suíte de testes enquanto o outro está no meio de um refactor.
• Você vira o gerente de projeto. É você quem divide o trabalho, lembra qual terminal tinha qual tarefa e copia o contexto de uma sessão para a outra.
• Ninguém registra o que aconteceu. Quando você volta do almoço, o único registro é o scrollback do terminal.

Nada disso é problema do modelo. É um problema de organização — e organização é algo em que software é bom.

O que o SuperDevSpace faz de fato

No SuperDevSpace, cada repositório é uma organização. Cada organização tem um manager: uma sessão real de uma CLI de agentes, num terminal real que você vê e no qual pode digitar. Você dá ao manager uma diretiva em linguagem natural — digitando ou ditando por voz.

Então o manager faz o que um líder faria:

Você pode entrar a qualquer momento. Cada agente tem uma visão de chat e o seu terminal real — uma sessão, dois jeitos de olhar —, e cada mudança aparece como um diff ao lado da conversa que a produziu, para você revisar antes que chegue à sua linha principal.

Sua assinatura, sua máquina, seu código

A decisão de design mais importante é também a mais simples: o SuperDevSpace conduz uma CLI que você já paga. Nunca revendemos acesso a modelos, então nada do que você executa aparece numa cobrança nossa além da própria assinatura do SuperDevSpace.

Essa decisão tem consequências de que gostamos:

• Os agentes rodam como processos locais na sua máquina, nos seus repositórios locais. Seu código-fonte, seus prompts, a saída do terminal e os caminhos de arquivo nunca são enviados aos nossos servidores. Nosso serviço de contas guarda uma conta, um status de assinatura e uma lista de dispositivos.
• Você escolhe a CLI por organização. Claude Code, OpenAI Codex, Gemini CLI, Aider, Qwen Code, Cursor CLI e OpenCode podem ser selecionados. O Claude Code é a CLI que o app domina hoje — hooks, retomada de sessão, ferramentas MCP, respostas a permissões. As outras seis iniciam e rodam; o app as marca como experimentais e avisa quais extras ainda não estão conectados, em vez de falhar em silêncio.
• Nada fica preso na nossa nuvem, porque não há nuvem fazendo o trabalho.

Antes da primeira diretiva, vale conferir se a CLI e o repositório estão onde você espera:

$ claude --version
$ cd ~/code/seu-projeto
$ git status

O que vem em volta do time

Um time precisa de mais do que terminais. Algumas coisas que vêm em todos os planos:

• Um quadro que diz a verdade. Sprints, tarefas, briefs e relatórios. Um relatório diz o que falhou, não só o que passou.
• Inspector. Clique num elemento da sua página web em execução e envie para um agente com o componente, o arquivo e a linha. Funciona com Vite, Next.js e sites estáticos.
• Aprovações pelo celular. Quando um agente precisa de uma decisão, ele pergunta a você. O app do celular mostra o quadro, os agentes e as aprovações pendentes, para você responder a um pedido de permissão longe da mesa.
• Um quadro branco por organização (Excalidraw), que os agentes conseguem ler e no qual conseguem desenhar.

O Premium acrescenta as peças que vão mais longe: um modo de design baseado no Penpot, com um agente Designer que desenha no arquivo; agendamentos que executam diretivas segundo um calendário; e um link entre pares que permite a um manager no seu Mac passar trabalho para um manager no seu PC com Windows. A página de preços tem a comparação completa.

O que não prometemos

Um time de agentes ainda precisa de um chefe: você decide o que é construído e aprova o que chega ao seu branch principal.

Experimente

O teste é de 14 dias de Premium, sem cartão. Sua assinatura da CLI continua sua, e seu código também. Se quiser ver o time trabalhando no seu próprio repositório, baixe o SuperDevSpace e dê ao manager a primeira diretiva.