Agent Orch — um "Lovable" self-hosted em construção

🚧 Em construção — o loop principal já funciona de ponta a ponta em self-hosted; multi-LLM, multi-usuário e deploy público são as próximas fases.

Ferramentas como Lovable e v0 provaram o conceito: descrever um app em linguagem natural e vê-lo nascer na tela. O Agent Orch é a minha versão self-hosted e open-source (em progresso) dessa ideia — você conversa, um container Docker isolado é provisionado, um agente de IA escreve o código lá dentro, e o preview sobe ao vivo num subdomínio próprio. Seu hardware, suas chaves, seu código.

O loop completo

Descreva o que quer construir (app novo do zero, ou clone de um repo GitHub existente).
Plano com gate de aprovação: em modo Plan/Smart, um modelo forte propõe o plano e a tarefa trava até você aprovar (com loop de refinamento). No modo Smart, um modelo rápido faz a triagem de quando o plano vale a pena.
Implementação: o agente (Claude Code CLI) roda dentro do container do workspace, com streaming dos eventos pra UI em tempo real.
Checkpoint automático: cada turno vira um commit git — reverter uma conversa inteira é um clique (reset --hard no checkpoint + soft-delete das tarefas posteriores).
Preview ao vivo: o dev server sobe no container e o Caddy roteia app.preview.localhost dinamicamente via Admin API.
Entrega: commit + push + PR automáticos (mensagem de commit sugerida por IA), diff por turno, editor Monaco no browser e dashboard de custo por chamada de modelo.

Arquitetura

A regra de ouro do design: o orquestrador planeja e roteia, mas nunca executa código gerado. Quem executa é um daemon minúsculo (compilado em Native AOT, sem runtime .NET na imagem) dentro de cada container de workspace — isolado com limites de CPU/memória e usuário não-root.

Visão de componentes e infraestrutura:

Fluxo de uma tarefa:

Decisões técnicas que valem a pena contar

Assinatura em vez de tokens de API. Geração de código consome MUITO token. O orquestrador monta a config local do Claude (~/.claude) dentro do container e deliberadamente não injeta chave de API — o agente roda no modo assinatura (Pro/Max), enquanto a chave de API fica reservada às chamadas estruturadas e baratas do próprio orquestrador (manifesto do repo, planejamento, mensagem de commit). Cada chamada é logada com tokens e custo calculado.

O agente sobrevive ao F5. Um refresh no meio do streaming não pode abandonar (nem duplicar) o agente. A execução roda desacoplada do request HTTP — o stream é drenado até o fim para o checkpoint sempre acontecer, e um gate de "já está rodando" responde 409 a dispatches duplicados. Um worker de hibernação ainda para containers ociosos após 10 minutos e marca tarefas travadas como falhas.

Preview atrás de proxy vs. Vite moderno. O Vite 6+ recusa hostnames desconhecidos (403). A rota de preview criada via Admin API do Caddy reescreve o header Host na passagem — o Vite pensa que é localhost, o usuário vê meuapp.preview.localhost.

Matar a árvore inteira do dev server. Re-expor um projeto deixava a porta presa por processos-filhos (sh → node → vite → esbuild). A solução caminha /proc/<pid>/stat coletando descendentes por PPid e derruba a árvore completa antes de subir o novo servidor.

Regenerar manifesto sem orfanar nada. O manifesto do repo (linguagem, comandos, portas — gerado por IA e cacheado) reescrevia os projetos com IDs novos, quebrando perfis e subdomínios. O regen virou upsert pelo path — identidade estável, customizações preservadas.

Stack

.NET 9 (ASP.NET Core Minimal APIs) · WorkspaceDaemon em Native AOT · Docker.DotNet · EF Core + PostgreSQL · Caddy 2 (proxy + Admin API) · React 18 + Vite + Monaco + ReactFlow · SDK Anthropic · Claude Code CLI como runtime de agente.

Status

🚧 O loop de dogfood local funciona inteiro: scaffold/clone, chat multi-turno, plano+aprovação, codegen, preview, checkpoints/revert, git/PR, serviços de dados por workspace e custos. Próximas fases: runners de outros LLMs (a interface IAgentRunner já existe como costura), autenticação OAuth e multi-usuário, e deploy público com HTTPS.