OpenFoundry

Estúdio local de software de IA com ferramentas de missão, aprovação e QA de autocorreção por meio de um servidor MCP stdio em Python.

GitHub

Documentação

OpenFoundry

Se um agente de IA é um freelancer, o OpenFoundry é a sua empresa autônoma de software e pesquisa — com um departamento de QA integrado que testa e auto-corrige o próprio código.

Dê a ele um objetivo. Observe cinco departamentos pesquisarem, planejarem, construírem, detectarem um defeito, repararem e prepararem rascunhos de lançamento em uma War Room ao vivo. Revise a especificação antes de a Engenharia executar.

Experimente a demonstração · Adicione um departamento · 25 tickets para contribuidores · Configuração do MCP · Roadmap

Início Rápido em 60 Segundos (Sem Necessidade de Chave de API)

A demonstração não precisa de chave OpenAI, Gemini ou Anthropic, nem de servidor Ollama, nem de chamadas pagas. Após a instalação das dependências, iniciar e aprovar leva cerca de um minuto; a primeira instalação de dependências ou o build do Docker pode demorar mais.

Local: Python + Node

Pré-requisitos: Python 3.11+, uv, Node 22.12+ (Node 22 LTS recomendado), npm e Git. Execute estes comandos em um shell:

git clone https://github.com/MrMha/openfoundry.git
cd openfoundry
uv sync --frozen --extra dev
(cd frontend && npm ci && npm run build)
uv run --frozen openfoundry

Abra http://127.0.0.1:8000. O FastAPI serve a UI e a API compiladas juntas; reinicie o servidor se você compilar a UI após iniciá-lo. O acesso via loopback não precisa de token de operador, a menos que você defina OPENFOUNDRY_API_TOKEN.

Docker Compose: um serviço unificado

A partir do repositório clonado, com Docker Engine/Desktop e Compose v2 instalados:

export OPENFOUNDRY_API_TOKEN="$(openssl rand -hex 32)"
docker compose up --build

Abra http://127.0.0.1:8000, escolha Connect backend, insira o token de operador do seu shell e conecte-se. Para exibir o token de operador local gerado, execute printf '%s\n' "$OPENFOUNDRY_API_TOKEN"; mantenha-o privado. Este token protege o OpenFoundry; ele é separado das chaves de API dos provedores. openssl é necessário apenas para gerar esse token aleatório; um token de operador forte e seguro para URL também funciona.

O Compose publica a porta 8000 no loopback do host, executa como UID 10001, verifica /health e mantém o SQLite/memória compartilhada em foundry_data e os arquivos gerados em workspaces. docker compose down preserva esses volumes; adicionar --volumes os exclui. Nenhuma chave de provedor é necessária para a demonstração. Consulte detalhes de implantação para limites de sandbox e dados.

Execute a missão real de auto-correção

Clique em ⚡ Run Self-Healing Demo (No API Key).
Revise SPEC.md no portão da Engenharia e clique em Approve & Continue.
Observe Bug Detected → Patching → Verified. Inspecione a verificação falha, o patch commitado, as verificações aprovadas e os arquivos de lançamento gerados.

A demonstração determinística atual conclui 5 departamentos → 1 reparo → 29 artefatos registrados → custo de $0,00 em tokens de API. As respostas do provedor e a fonte de pesquisa são fixtures; agendamento, SQLite, commits Git, subprocessos de teste, verificações ASGI/DOM, artefatos e eventos são executados de verdade. Um frame de fallback é visivelmente rotulado como diagnóstico de DOM. Isso é evidência reproduzível do fluxo de trabalho, não uma afirmação de que aplicativos arbitrários sempre se corrigem com sucesso.

O que sua empresa pode fazer

Recurso	Comportamento implementado
5 Departamentos Autônomos	`chief_of_staff` escreve `SPEC.md`/`STATE.md` e valida um DAG; `researcher` salva evidências citadas; `engineer` faz commit de código modular; `qa_self_healer` verifica e repara; `growth_career` elabora rascunhos de lançamento ou pacotes de carreira.
Loop de QA com Auto-Correção	pytest/Ruff mais verificações ASGI/HTTP e DOM; relatórios estruturados de causa raiz; no máximo 3 rodadas de reparo após a verificação inicial. Os testes de aceitação originais e o escopo de verificação são protegidos contra edições de reparo.
MCP Bidirecional	`openfoundry mcp` expõe ferramentas de missão/demonstração/status/departamento/blueprint/aprovação por meio do SDK oficial. Departamentos confiáveis podem descobrir e invocar ferramentas externas stdio ou Streamable HTTP explicitamente concedidas.
BYOK + Ollama local	Roteamento OpenAI → Gemini → Anthropic → Ollama, respostas validadas por esquema, um registro durável de uso/custo e reservas orçamentárias atômicas; o teto padrão da missão é $2,00.
Sandbox medido	`auto` testa o Bubblewrap e recorre à execução protegida e com lista de permissões quando namespaces não estão disponíveis; `strict` falha de forma fechada. Os comandos têm no máximo 60 segundos de timeout.
War Room ao vivo	Eventos WebSocket tipados e reproduzíveis; grafo de dependências; pensamentos dos departamentos; portões de aprovação; evidências de QA; diffs de código; inspeção de artefatos e exibição de custos.
Memória compartilhada	Recuperação persistente por missão de palavras-chave + TF-IDF/cosseno para pesquisa, chunks de documentos, decisões de arquitetura e relatórios de bugs.
Blueprints validados	Modelos de MVP SaaS, auto-correção de sites e oportunidades de carreira, carregados de JSON para a API e a barra de comandos com parâmetros editáveis e pré-visualizações de tarefas.

Missões ao vivo usam suas credenciais de provedor no lado do servidor. Publicações de lançamento, mensagens de carreira e divulgação permanecem como rascunhos; o backend atual não publica nem envia.

Arquitetura: uma empresa com um loop de feedback

flowchart TD
    User[Operator / CEO] --> UI[React War Room]
    Editor[Claude Code / Codex / Cursor / OpenClaw] --> MCP[openfoundry mcp: stdio facade]
    UI --> API[FastAPI REST + approval gates]
    MCP --> API
    API --> DAG[MissionOrchestrator: validated DAG]
    DAG --> Chief[Chief of Staff: SPEC.md + STATE.md]
    Chief --> Research[Researcher: sources + documents]
    Research --> Engineer[Engineer: branch + modular code]
    Engineer --> QA[QA: tests + endpoint / DOM checks]
    QA -->|failure: bounded repair| Engineer
    QA -->|verified| Growth[Growth / Career: reviewed drafts]
    DAG <--> Memory[Mission MemoryVault]
    DAG --> Router[LLMRouter: schemas + durable USD caps]
    Router --> Providers[OpenAI / Gemini / Anthropic / Ollama]
    DAG --> Sandbox[WorkspaceSandbox: Bubblewrap or Guarded]
    DAG --> Clients[MCPBridge: explicitly granted external tools]
    DAG --> DB[(SQLite: state + cost ledger + event log)]
    DB --> Events["WebSocket replay: /ws/missions/{mission_id}"]
    Events --> UI

Um coordenador ativo é dono de cada arquivo SQLite. Tarefas pendentes e esperas de aprovação são recuperadas após reinicialização; tarefas em execução interrompidas falham visivelmente em vez de reproduzir silenciosamente efeitos externos. Consulte o guia de backend para detalhes de contabilidade, recuperação e isolamento.

Use seu modelo, mantenha um orçamento de missão

Exporte qualquer chave de provedor suportada no ambiente de processo do backend: OPENAI_API_KEY, GEMINI_API_KEY (ou GOOGLE_API_KEY) ou ANTHROPIC_API_KEY. Para Ollama local, sirva um modelo primeiro:

ollama pull llama3.2
export OLLAMA_BASE_URL=http://127.0.0.1:11434
export OPENFOUNDRY_OLLAMA_MODEL=ollama_chat/llama3.2
export MAX_MISSION_COST_USD=2.00
uv run --frozen openfoundry

O Ollama já deve estar em execução, e uma implantação Docker precisa de uma URL Ollama acessível de dentro do contêiner. A UI seleciona entre provedores/modelos configurados e pode reduzir o orçamento da missão. As chaves do provedor permanecem no backend; a entrada de conexão do navegador aceita apenas um token de operador. A CLI lê variáveis de processo, não arquivos .env; o Compose faz sua própria interpolação de variáveis.

Os custos usam estimativas do catálogo LiteLLM e reservas conservadoras. Preços pagos desconhecidos falham de forma fechada. Falhas ambíguas do provedor mantêm reservas porque uma solicitação pode ter sido cobrada. O uso de tokens de API do Ollama custa $0,00 aqui; hardware, eletricidade e cobranças de serviços MCP externos estão fora desse registro.

Orquestre a partir do seu terminal ou editor

Mantenha a API em execução e configure seu cliente MCP para iniciar este comando stdio a partir do checkout:

uv run --frozen openfoundry mcp --api-url http://127.0.0.1:8000

Ferramentas: start_mission, get_mission_status, run_demo_self_healing_mission, list_departments, list_blueprints, decide_mission_task. A fachada MCP faz proxy da API existente e usa OPENFOUNDRY_API_TOKEN quando necessário. Seu editor deve iniciar o comando; iniciá-lo em um terminal comum apenas aguarda entrada do protocolo MCP. Consulte configuração do cliente e concessões de ferramentas externas.

Construa seu próprio departamento em 20 linhas

Salve este plugin completo como backend/app/departments/readiness.py:

from backend.app.core.memory_vault import MemoryVault
from backend.app.core.workspace_sandbox import WorkspaceSandbox
from backend.app.departments.base_department import (
    BaseDepartment, DepartmentOutput, EventEmitter, register_department,
)
from backend.app.models.mission import TaskNode


@register_department
class ReadinessDepartment(BaseDepartment):
    name = "readiness"
    role_description = "Write a mission readiness note."
    capabilities = ("readiness_note",)

    async def execute_task(
        self, task: TaskNode, sandbox: WorkspaceSandbox,
        memory: MemoryVault, emit_event: EventEmitter,
    ) -> DepartmentOutput:
        await sandbox.write_file("READY.md", "# Ready\n")
        return {"summary": "Ready", "artifacts": [dict(file_path="READY.md", artifact_type="note")]}

Importe-o na inicialização com OPENFOUNDRY_DEPARTMENT_PLUGINS=backend.app.departments.readiness uv run --frozen openfoundry. Ele então aparece em GET /api/plugins e fica disponível para o planejador; ele é executado apenas quando recebe uma tarefa DAG. Arquivos arbitrários no diretório do departamento não são importados automaticamente. Pacotes instalados também podem registrar o grupo de entry-point openfoundry.departments.

Os plugins são executados como código Python confiável do backend. Use self.router para chamadas LLM medidas, a sandbox fornecida para arquivos, memory para contexto compartilhado e emit_event para pensamentos/frames/diffs tipados. O agendador é dono das mudanças de status e aprovações. Siga o guia do contribuidor para requisitos de testes, descoberta e concorrência.

Escolha um blueprint inicial

Modelo	Ponto de partida	Saída
SaaS MVP Builder	Ideia de produto, público, stack	Spec → pesquisa → Engenharia aprovada → QA com auto-correção → kit de lançamento
Website Self-Healer	URL alvo, código-fonte disponível, jornadas críticas	Auditoria/reprodução → fluxo de patch aprovado → evidências de verificação
Career Opportunity Hunter	Funções/empresas alvo e um perfil existente	Pesquisa citada → material de carreira personalizado e rascunhos de divulgação

A barra de comandos obtém esses itens de GET /api/blueprints. Os modelos sugerem um DAG; o Chefe de Gabinete o adapta e o agendador valida o resultado. O reparo de sites precisa de código-fonte editável no espaço de trabalho da missão. A personalização de carreira precisa de um perfil real; forneça arquivos de entrada por meio dos helpers Python WorkspaceSandbox no lado do servidor — ainda não há endpoint REST de upload.

Contribua para o seu próximo departamento de IA

Comece com CONTRIBUTING.md, escolha um dos 25 tickets de contribuidor com escopo e abra uma proposta de departamento ou relatório de bug. Os resumos dos tickets estão prontos para copiar em GitHub Issues; eles não são afirmações de atribuições de issues existentes.

A versão atual é 0.1.0. As futuras aprovações de chat v1.1, PRs de rascunho do GitHub v1.2 e um registro comunitário v1.3 estão especificadas em ROADMAP_SPECS.md. Elas são trabalho planejado, não integrações lançadas ou promessas de datas. Use o kit de lançamento para compartilhar o projeto implementado.

Limites de confiança e implantação

auto relata o modo de execução medido em /api/plugins. A execução protegida não é isolamento de SO: testes gerados são executados com os privilégios de sistema de arquivos/rede da conta de serviço. Use uma conta/contêiner dedicado; escolha OPENFOUNDRY_SANDBOX_MODE=strict quando o isolamento indisponível deve interromper a execução. Plugins e executáveis MCP explicitamente configurados são código de serviço confiável. Pesquisa e saída de modelo permanecem como dados não confiáveis.

Os volumes SQLite são para um host e um coordenador, não um cluster distribuído. Vincule publicamente apenas com um token de operador e um proxy TLS reverso apropriado. REST usa Authorization: Bearer …; WebSockets do navegador usam os subprotocolos openfoundry e bearer.<token>, nunca parâmetros de token na URL. A rejeição de aprovação cancela a missão. Consulte contratos de autenticação e API, comportamento do frontend, limites do MCP e a auditoria de segurança da publicação.

Verificação e licença

Linha de base verificada localmente: 408 testes de backend + 34 testes de frontend + 6 testes E2E Chromium. Os selos de CI refletem as execuções reais de workflow do repositório separadamente. CONTRIBUTING.md lista os comandos exatos, incluindo tipagem estrita, Ruff/Flake8, lint/format do frontend e builds de produção.

Regenere as capturas de tela reais com uv run --frozen python scripts/generate_demo_assets.py após instalar as dependências do frontend e o Chromium; instruções de assets descrevem a substituição do navegador do sistema e as verificações de reprodutibilidade.