O sistema operacional para desenvolvimento com IA.

Chat VISION AI COMMAND conectado ao backend. Fallback chain Groq → Gemini → OpenRouter. Respostas em português com análise técnica real.

Register, login, status e Bearer header funcionando. Token JWT no body JSON (length=116). sessionStorage no frontend. Fallback register→login automático.

Todos os endpoints de produção verificados via worker. Auth, billing, go-core PASS GOLD, webhook Stripe, CF Pages CORS — tudo passando.

Interpretação de pedidos em linguagem natural, classificação via IA real (Groq/Cerebras/Gemini), matching contra 120 specs estruturados, com fallback para perguntas quando confiança baixa.

15 agentes (Backend, Database, Auth, Security e outros) detectam automaticamente quando o assunto da conversa é da especialidade deles — por palavra-chave — e mostram um selo visual no chat indicando quem respondeu. Modos OFF/AUTO/ON configuráveis por agente.

Quando o chat diagnostica um bug, agora existe um botão "Aplicar no Vision Agent Local" além de baixar o arquivo corrigido: ele enfileira o patch, o Vision Agent que já roda na máquina do usuário aplica no disco real com backup automático, valida a sintaxe (Aegis) e comita no git — ou reverte sozinho se a validação falhar. O usuário aprova o push manualmente depois.

O painel EXECUTAR MISSÃO (Vision Core Standard Method) agora tem o mesmo botão "Aplicar no Vision Agent Local" que o chat já tinha desde o §105. A lógica de polling foi extraída para vcQueueApplyPatchViaAgent() e compartilhada pelos dois painéis — sem duplicação de código. Zero mudanças de backend.

O Hermes agora consulta o histórico de baixa confiança antes de tentar providers. Se o payload atual lembra um caso que já precisou escalar, o provider que falhou naquele caso vai para o final da fila — nunca é removido, só deprioritizado. Matching por similaridade de Jaccard sobre tokens, sem embeddings nem rede.

O painel "MÉTRICAS DOS AGENTES" era 100% estático com custos fictícios e badge "UI LOCAL". Agora busca dados reais de 4 endpoints (agents, summary, dora-metrics, metrics/memory). Se backend responder, badge vira "DADOS REAIS" e blocos de runtime/DORA/memory layer aparecem. Fallback estático preservado quando offline.

Novo tipo apply_patch_multi: uma única missão pode tocar N arquivos com garantia tudo-ou-nada. Se qualquer patch falhar (busca não encontrada) ou qualquer arquivo reprovar na validação Aegis de sintaxe, TODOS os arquivos da missão voltam ao estado do HEAD via git checkout — nenhuma alteração parcial fica no repositório. No caminho feliz, é exatamente 1 commit cobrindo todos os arquivos juntos.

Pra um repositório explicitamente apontado pelo usuário (nunca o próprio vision-core), a Factory agora lê o código real, diagnostica de verdade via a mesma infraestrutura Hermes do chat, e simula o patch inteiramente em memória — o arquivo do projeto-alvo fica bit-a-bit idêntico ao original, e nenhum commit é criado. Um firewall de 4 camadas independentes (caminho, pasta-pai, remote git, fingerprint de arquivos) bloqueia qualquer tentativa de apontar isso pra si mesma.

A fila de missões do Vision Agent Local e os resultados de missões executadas viviam inteiramente em memória — perdidos a cada restart periódico do servidor no EB (cfn-hup, a cada 15-90min). Agora persistem em SQLite, sobrevivendo a restarts reais sem mudar nada na forma como o agente ou o chat conversam com o backend.

O dry-run real em repositório externo (card acima) já existia por completo, mas só era acionável chamando a API direto — sem nenhum botão na interface. Agora tem um ponto de entrada visual na sidebar ("🔬 DRY-RUN EXTERNO") que abre um painel no próprio chat: campo pro caminho do projeto, descrição do problema, e o resultado renderizado com diff antes/depois quando há sucesso. Backend e Vision Agent Local não foram tocados — era só a porta de entrada que faltava construir, fechando a Etapa A por completo.

apply_patch_multi (card acima) estava testado de ponta a ponta desde a V2.9.13+, mas o chat nunca tinha um jeito de chegar até ele — o prompt do LLM só devolvia 1 arquivo por resposta. Agora o modelo pode devolver um formato files[] quando o fix genuinamente abrange mais de 1 arquivo, e o botão "Aplicar no Vision Agent Local" (no chat e no EXECUTAR MISSÃO) reconhece isso e dispara a missão atômica certa. No caminho, dois bugs pré-existentes foram corrigidos: o painel de sucesso aparecia mesmo numa missão que falhou e revertia tudo; e uma variável nunca definida crashava o processo toda vez que todos os provedores de IA falhavam ao mesmo tempo.

O dry-run real (cards acima) sempre simulou só 1 arquivo por missão, mesmo batendo na mesma infraestrutura que o apply_patch_multi usa pra aplicação de verdade. Agora, quando o diagnóstico do LLM abrange 2+ arquivos, o Vision Agent Local simula cada um em memória com a mesma garantia tudo-ou-nada: se qualquer arquivo falhar, a leva inteira é descartada — sem nunca escrever no disco do projeto-alvo e sem nunca expor um diff parcial como se fosse válido. backend/server.js não precisou de nenhuma mudança.