Orchester
Extensão do VS Code que orquestra agentes de IA (CLIs) por um canvas de nós: um orquestrador fixo delega tarefas a subagentes que você desenha, configura e executa — com loop, limites de segurança e aprovação de ações.
Motores suportados hoje: Claude Code e Codex (OpenCode: próximo marco). Cada agente escolhe o seu motor, então um fluxo pode misturar os dois.
Usar
- Tenha instalado e autenticado o motor que vai usar:
claude (Claude Code; ou orchester.claudePath) e/ou codex (npm i -g @openai/codex + codex login; ou orchester.codexPath).
- Abra uma pasta no VS Code. O ícone Orchester aparece na barra de atividades: é o chat. (Para ele ficar à direita, como o chat do Copilot, arraste o ícone para a barra lateral secundária.)
- Configurar agentes (botão ⚙ no chat, ou
Cmd+Shift+P → Orchester: Configurar agentes) abre o canvas numa janela própria: adicione subagentes, defina função, motor, modelo e permissão, ligue o loop. Desligue com orchester.openConfigInNewWindow se preferir uma aba comum.
- No chat, peça o que quiser: cada mensagem roda o fluxo (orquestrador → subagentes), com passos recolhíveis, pedidos de aprovação inline, resposta final, arquivos alterados e evidências. Mensagens seguintes recebem o contexto das últimas conversas. Parar encerra tudo em < 2 s; Nova limpa a conversa (se houver execução em andamento, pergunta e a interrompe).
Na janela de configuração, as divisórias entre canvas, painel de edição e log são arrastáveis (duplo clique restaura o padrão; com foco, use as setas; o tamanho fica salvo).
O fluxo fica em .orchester/flow.json, o histórico do chat em .orchester/chat.json e os logs de cada execução em .orchester/runs/<data>/.
Permissões por agente
- Somente leitura: só lê arquivos.
- Edita com aprovação: pausa e pede aprovar/negar antes de editar ou rodar comandos.
- Edita automaticamente: sem perguntar (primeira execução exige confirmação).
Caminhos fora da pasta do workspace são sempre bloqueados. Não é um sandbox de SO: comandos de shell são checados por heurística; confie apenas em instruções de agentes que você controla.
Motor Codex
No editor do agente, Motor → Codex. Diferenças em relação ao Claude Code:
- Permissões: o shell do Codex roda num sandbox de SO (somente leitura ou só a pasta do workspace, com rede liberada para servidores locais e
curl). Além disso, todo comando e todo apply_patch passam pelas mesmas regras do Orchester (aprovação do usuário, caminhos fora do workspace, .orchester) por um hook que a extensão instala só nas execuções dela; a configuração do seu ~/.codex não é usada. Comandos que apenas inspecionam (ls, cat, rg, git status…) não pedem aprovação, porque o Codex lê arquivos pelo shell.
- Custo: o Codex não informa custo em dólar, então o limite de custo não se aplica a agentes Codex (iterações e tempo continuam valendo). O custo exibido fica em $0.
- Modelos: a lista do editor traz os modelos atuais;
default usa o da CLI.
- Se o orquestrador (Codex) concluir antes de um subagente terminar, a extensão espera o subagente e anexa o resultado à resposta.
Agentes padrão: Design, Dev e QA
Na janela de configuração, + Agente Design, + Agente Dev e + Agente QA adicionam agentes prontos (editáveis; Restaurar padrão volta ao original). O Design define a interface (estrutura, estados vazio/erro/carregando, textos, responsivo, acessibilidade WCAG AA) reaproveitando o design que o projeto já tem, e entrega uma especificação que o orquestrador repassa ao Dev e, como critérios de aceite visuais, ao QA. O Dev implementa a demanda com mudança mínima, migration versionada, testes rodados e uma entrega objetiva; não faz commit nem push. Com os três no fluxo, a ordem é Design → Dev → QA (demandas sem interface pulam o Design).
+ Agente QA adiciona um subagente de testes pronto. Edite à vontade (nome, função, modelo, permissão) e use Restaurar padrão para voltar ao original. A regra dele: toda validação gera evidência, gravada em .orchester/evidence/<execução>/:
- Front: um print por requisito (botão alterado → print do botão; tela nova → print da tela; fluxo → um print por etapa), via Playwright/Cypress do projeto ou Chrome headless.
- Back: o response real da API, um arquivo por cenário.
- Banco:
banco-mapa.md (tabelas, colunas, chaves, índices, diagrama mermaid, o que mudou) obtido do banco real.
evidencias.md liga requisito → evidência → PASS/FAIL/NÃO VERIFICADO. Sem ferramenta para provar, ele registra "NÃO VERIFICADO" em vez de inventar.
Com um QA no canvas, o orquestrador é instruído a delegar a validação a ele antes de concluir. Ao fim da execução, a lista de evidências aparece no log.
Loop
Ligue Loop e informe a condição de parada (texto avaliado pelo orquestrador, comando de shell com exit 0, ou os dois — ambos precisam valer) e pelo menos um limite (iterações, tempo, custo). Duas iterações seguidas idênticas, sem mudança em arquivos, param o loop por possível travamento.
Desenvolvimento
npm install
npm run compile # typecheck + bundle (esbuild) em dist/
npm test # testes do núcleo (node:test)
npm run test:vscode # abre um VS Code real (perfil temporário) e valida a extensão ponta a ponta com Claude de verdade
node scripts/drive-vscode.mjs scripts/steps-run.mjs # VS Code real controlado por CDP: cliques reais, screenshots da janela (veja scripts/steps-*.mjs)
npm run harness # UI no navegador com host simulado (.dev/)
npx tsx scripts/e2e-real.ts approve|deny|loop|stop # integração real com Claude (haiku, centavos)
Abra a pasta no VS Code e aperte F5 (Extension Development Host).
Arquitetura e decisões: .specs/features/orchestrator-mvp/design.md.
Publicação
Publicação automatizada e segura (Microsoft Entra ID, sem PAT): veja docs/publicacao-automatizada.md.
Empacotar
npm run package # gera um .vsix
