Framein - nem cockpit, nem proxy, nem harness: a camada de estado de trabalho abaixo dos agentes de codificação com IA

Hoje em dia faço a maior parte da programação junto com agentes de terminal. Deixo Claude Code, Codex e Gemini CLI abertos lado a lado dentro do VS Code, delego a implementação básica ao Claude e peço ao Codex para revisar quando preciso de um olhar externo, como em segurança ou regressão. Mas, sempre que eu trocava de modelo, precisava explicar de novo qual era o objetivo, o que não podia quebrar e o que o modelo anterior tinha tentado sem sucesso. No fim, eu tinha virado uma espécie de área de transferência humana ligando três terminais.

Procurando ferramentas parecidas, vi que já existiam muitas. Desde cockpits que colocam vários agentes numa só janela (como Claude Squad e a linha Orch term), até proxies que permitem chamar outros modelos a partir de um único harness (como opencodex e oh-my-free-models), e orquestradores que dividem papéis e distribuem o trabalho (como Oh My OpenCode). Mas o problema que eu realmente estava enfrentando — fazer com que o próprio trabalho não seja interrompido quando se troca de modelo — surpreendentemente era pouco tratado de frente. A maioria seguia na direção de “fazer handoffs melhores”.

O Framein escolheu outro caminho: em vez de melhorar o handoff, tornar desnecessário que ele exista como etapa separada. Não é uma nova IDE, nem cockpit, nem proxy, nem mais um harness. É uma camada local e fina de estado de trabalho (work-state) que fica abaixo dos agentes que você já usa. Como os três agentes leem juntos, dentro do repositório, o mesmo contrato de trabalho, o mesmo histórico de decisões e os mesmos resultados de verificação, o próprio ato de “passar adiante” deixa de ser uma etapa separada. O próximo modelo não lê um resumo feito por mim, e sim os próprios fatos.

O loop tem quatro verbos. Aqui, lead se refere ao modelo que está efetivamente responsável pela implementação naquele momento. É uma forma de distingui-lo do modelo encarregado da revisão.

• start : fixa a solicitação como um contrato de trabalho (objetivo, critérios de aceitação, áreas protegidas e non-goal) antes que a implementação comece a oscilar.
• challenge : pede a outro modelo uma contraposição de escopo estreito, deixa o lead responder uma única vez e então eu decido. É o momento em que, quando um modelo diz com confiança “concluí toda a implementação”, outro modelo que leu o mesmo contrato e o mesmo diff pergunta “qual risco ficou de fora deste plano?”.
• capsule : prepara os fatos que o próximo lead deve ler (contrato, diff, verificação, ADR e ledger).
• ship : não encerra o trabalho porque o modelo disse “terminei”, e sim porque ele passou de fato pelos gates de build/teste/risco.

Também é possível chamar tudo diretamente pelo terminal; dentro do Claude/Gemini, por comandos slash /fr:*; no Codex, por skills $fr-*. Não importa de onde seja chamado: tudo lê e grava no mesmo motor local e no mesmo estado. A estrutura preserva harnesses, skill packs e personas já existentes, adicionando apenas contrato, ledger e gates por baixo deles.

Alguns pontos receberam atenção especial no design.

• O histórico de decisões (ADR) é append-only. Em vez de editar ou apagar, ele só pode ser substituído por um novo registro. Entendi que um histórico de decisões que pode ser reescrito silenciosamente perde o valor no instante em que um segundo modelo decide confiar nele.
• O sistema não coleta credenciais. Também não faz retransmissão de tokens, pooling de assinaturas nem scraping de entrada e saída do terminal. A autenticação permanece com cada CLI oficial, e o sistema apenas a chama localmente quando necessário. (Por isso, está em uma camada diferente da linha de ferramentas de proxy.)
• A dependência de runtime é zero. Ele usa apenas node:sqlite embutido no Node 22 e o test runner nativo. O store em SQLite é cache, e a fonte canônica são snapshots JSON amigáveis ao git, então não há risco de a instalação quebrar daqui a seis meses por causa de mudanças em dependências.

No momento está em pre-release v0.0.6, e o core já foi implementado: store, projeção de CLAUDE.md/AGENTS.md/GEMINI.md, contrato de trabalho, gates verify/risk/ship, wrappers /fr:* e $fr-*, além do servidor MCP. No estado atual, passa em 249 testes. O que ainda está sendo refinado inclui o caminho de assinatura de código no Windows, distribuição de executáveis assinados e notarizados, validação de instalação em máquinas limpas e workflow para múltiplos desenvolvedores.

Pode ser instalado com npm install -g framein (requer Node 22.5+) e é licenciado sob MIT. O nome vem de um termo do cinema. Quando o assunto sai do enquadramento, é “frame out”; trazê-lo de volta para dentro da tela é “frame in”. O nome foi escolhido com a ideia de trazer três agentes dispersos para dentro de um mesmo quadro.

Mesmo para quem já usa cockpit, proxy ou harness, se você sente que o estado do trabalho continua vazando por baixo dessas ferramentas, ou se alterna entre dois ou mais agentes de codificação, gostaria muito de receber feedback sobre se o Framein preenche essa lacuna.

Website : https://www.framein.dev/ko
GitHub : https://github.com/framein-dev/framein
Notas do desenvolvedor (por que foi criado) : https://www.framein.dev/ko/why