Um cérebro central que dá memória persistente, método e gates de engenharia ao agente de programação — test-first obrigatório, nenhuma primeira versão aceita, nenhum "pronto" sem evidência.
> renatao evals # Renatao Evals — 21/21 canarios passaram (100%) ## governanca — 7/7 identidade MCP carrega Segunda Versao checkpoint pre-v2 existe handshake MCP carrega Segunda Versao AGENTS.md carrega Segunda Versao > renatao doctor --deep [OK] evals-canario: 21/21 [OK] indice semantico: 503/503 [OK] servidor MCP importa [OK] circuit breaker: CLOSED Doctor --deep: TUDO VERDE
Cada frase abaixo nasceu de um erro real e virou regra executável. Nenhuma é decoração: todas têm um gate, um checklist ou um teste por trás.
O problema. Ferramentas de IA escrevem código numa velocidade impensável há dois anos. Mas velocidade não é qualidade. O agente entrega a primeira versão que funciona — e quase todo mundo aceita. O resultado é protótipo disfarçado de produto: "funciona na minha máquina", segredo vazado no commit, e o mesmo erro repetido projeto após projeto, porque a IA não lembra do que já foi decidido.
A virada. Disciplina de engenharia não pode depender de força de vontade — ainda mais quando quem escreve o código é uma IA confiante e apressada. Documento se ignora, checklist se pula, boa intenção se esquece. Tem que virar sistema. O Renato nasceu dessa ideia: transformar boas práticas em mecanismos que acontecem sozinhos, não em conselhos que se esquecem.
A tese. Toda prática de engenharia sobe uma escada de enforcement — e só descansa quando vira gate, verificação automática ou métrica no tempo. O trabalho do Renato é empurrar cada regra da casa o mais para a direita possível dessa escada.
Quando a Regra da Segunda Versão foi implantada, a primeira versão da implantação parecia completa — e foi auditada adversarialmente antes do “pronto”. Resultado: 6 caminhos sem a regra, incluindo o principal (o canal MCP que o agente do IDE realmente usa). A v1 foi criticada e reescrita. A regra exigiu a própria segunda versão — e provou o próprio ponto.
O Renato é um cérebro central externo, IDE-first: um servidor MCP + CLI determinística (Python) que se conecta ao agente do seu editor (Antigravity, VS Code, Cursor). A identidade, os checkpoints e os gates chegam dentro da conversa do agente — não dependem de ele abrir arquivo nenhum.
Ele dá ao agente três coisas que faltam: memória que persiste entre sessões e projetos, com recall híbrido (busca textual FTS5 + embeddings semânticos) e colheita automática ao concluir — a IA para de reinventar o que já foi resolvido; um acervo de 1.200+ skills indexadas, servidas sob demanda para não inflar o contexto; e protocolos que cobram método a cada passo do trabalho.
O roteamento é 100% determinístico: a tarefa é classificada por keywords ponderadas — sem LLM no caminho crítico. Mesmo input, mesmos protocolos, sempre. Determinismo aqui é feature: o agente pode ser criativo; o processo, não.
Quando uma tarefa chega, nenhum modelo de linguagem decide o que fazer com ela. A classificação é determinística — e isso é uma escolha de engenharia, não uma limitação.
Mesmo pedido, mesmo processo — sempre. Um roteador probabilístico erraria diferente a cada dia, e ninguém audita palpite: aqui, auditar é ler uma tabela de pesos, não interrogar um modelo. O custo é zero e a latência é desprezível, porque não há chamada de rede no caminho crítico.
A divisão é deliberada: a criatividade fica onde deve ficar — no código que o agente escreve, nas abordagens do torneio, na solução do problema. O processo que cobra teste, evidência e revisão não improvisa. É a mesma lógica de um checklist de aviação: o piloto decide muito; o checklist, nada.
Roteamento, gates, selo e evals são funções puras: entrada → saída, testáveis uma a uma. Chamada de modelo é periférica e opcional (vetores de memória, geração de imagem) — nunca decide o método.
O agente nasce amnésico: fechou a conversa, esqueceu a decisão, o erro e a lição. O Renato mantém um acervo que persiste — e que volta sozinho na hora certa.
O léxico acha o termo exato: "coolify", o nome da função, a flag do comando. O semântico acha o conceito: "app caiu depois do deploy" encontra "healthcheck falhou em produção" sem dividirem uma palavra sequer. O RRF junta as duas listas sem calibração frágil de pesos: quem ranqueia bem nas duas, sobe.
Honestidade sobre os dados: acervo, índice, segredos e backups ficam na máquina. Para gerar o vetor, o texto da memória viaja a uma API de embedding — depois do leak-scan. Sem chave ou sem internet, o recall degrada para busca textual pura: menos esperto, nunca quebrado.
Os gates não são texto que o agente pode ignorar. O task_complete recusa recibo em branco; o ship-check bloqueia deploy com eval falhando; o preflight reprova Dockerfile sem healthcheck. Desobedecer dá trabalho — obedecer é o caminho fácil.
Reescrever do zero repetidas vezes tende a produzir variações da mesma ideia — a IA regride à abordagem mais provável dela. O ganho real vem de pontos de partida diferentes + julgamento explícito: no código crítico, 3 abordagens partindo de ângulos declarados (simplicidade, robustez, performance) são julgadas por tabela — correção, simplicidade, testabilidade, risco — e a vencedora herda o melhor das perdedoras, antes de ainda passar pela crítica e reescrita.
A classificação vem antes de tudo: trivial (typo, texto, config) fica fora da regra; relevante — o default de qualquer lógica — exige a segunda versão; crítico (auth, pagamento, dados) exige o torneio. Na dúvida, é relevante. Reclassificar para baixo depois de pronto é assinatura de falso-feito. Exceções honestas: emergência em produção (conserta primeiro, a v2 vira follow-up imediato registrado) e código vindo do scaffold da casa.
Nenhum código de produção nasce antes do teste: escreve-se o teste → roda-se → confirma-se a falha pelo motivo esperado → só então implementa. O fluxo é cobrado em artefato próprio e verificado na conclusão — o sistema recusa "concluído" sem evidência de execução recente de testes, com janela de tempo: um relatório velho não prova que os testes rodaram para ESTA tarefa.
A primeira versão que funciona ancora o pensamento. Todo código relevante segue v1 → 3 críticas concretas → reescrita v2, com a trilha registrada no recibo de execução. Código crítico (auth, pagamento, dados) exige torneio: 3 abordagens partindo de ângulos distintos declarados antes, julgadas por tabela — a vencedora herda o melhor das perdedoras.
Antes da primeira linha: qual comando vou rodar e que saída espero ver? Ao final, a saída real é colada no recibo — e o task_complete bloqueia conclusão com recibo em branco. "Funciona" é opinião; "esse comando roda e sai isso" é fato.
O agente troca de papel: 3 hipóteses de como o trabalho pode estar quebrado, cada uma testada de verdade; caça às assinaturas de falso-feito (sucesso sem saída colada, teste que não testa, except: pass, v1 entregue sem crítica); lente de produto quando há UI — primeiro uso sem manual, mensagens de erro que ensinam, estado vazio que orienta. Todo deploy aciona automaticamente.
Cada projeto define casos determinísticos comando → saída esperada (EVALS.jsonl). Rodam a cada mudança e bloqueiam o deploy se falharem — o único termômetro honesto de "a ferramenta ainda funciona". O scaffold já cria os primeiros casos na stack detectada.
Preflight que reprova Dockerfile sem HEALTHCHECK; auditoria de dependências (pip-audit / npm audit) contra CVEs conhecidas; smoke pós-deploy batendo no healthcheck real em produção; varredura periódica que transforma app fora do ar em incidente automático no projeto de origem.
Nota A–F determinística por projeto agregando: evals verdes, testes, README, dependências auditadas, segredos fora do código, healthcheck. Com histórico em série temporal e tendência no briefing diário. A nota só sobe com mecanismo, nunca com promessa.
O scaffold gera o projeto com o kit embutido — estrutura canônica, teste smoke passando, evals iniciais, logging estruturado, Dockerfile com healthcheck, .env.example, git iniciado — e se recusa a rodar sem a decisão de stack registrada: avaliação comparativa, nunca dogma. Se PHP for a melhor saída para o caso, PHP vence.
No dia em que o selo e a auditoria de dependências entraram no ar, foram apontados nos projetos reais da casa: 18 vulnerabilidades (3 graves) num frontend que parecia saudável, dois Dockerfiles sem healthcheck e a ausência de evals — com o caminho exato para subir cada nota. Nenhuma promessa: um checklist acionável por projeto.
Conversa evapora; arquivo fica, versiona e audita. Cada gate do Renato lê um artefato — nunca a boa intenção de quem escreveu. Todos são texto puro (markdown/JSON), legíveis por humano e por máquina, dentro do próprio repositório.
Por projeto, o .renatao/ guarda o que pertence àquele código: contratos, recibos, decisões, evals, selo. Quem clona o repositório leva o contexto junto — inclusive um agente novo, de outra ferramenta, meses depois.
Na casa, o cérebro central guarda o que atravessa projetos: memória, skills, protocolos, histórico. A fronteira é deliberada: o que é do projeto viaja com o projeto; o que é da casa (e os segredos) não sai dela.
Seis meses depois, "por que escolhemos isso?" se responde com um arquivo — não com a memória de quem já saiu do projeto. O custo é minutos por tarefa; a alternativa é reconstruir contexto por horas, ou decidir de novo no escuro.
SQLite dentro do container sem volume = banco zerado a cada deploy. Tudo que precisa sobreviver mora fora do container: banco com volume próprio, backup em outro lugar.
1. O que é? (API, site, app, CLI) · 2. Quem usa? · 3. Onde roda? · 4. Que dados guarda? · 5. O que fica DE FORA da primeira versão? — a mais importante: sem escopo negativo, todo projeto incha e nunca termina.
O scaffold entrega o projeto com o kit: estrutura canônica, smoke passando, evals iniciais, Dockerfile com healthcheck, .env.example, git iniciado — e se recusa a rodar sem a decisão de stack registrada.
Uma ferramenta local com acesso a shell e memória persistente exige desconfiança por padrão. Cada risco vira um mecanismo — e o que não dá para proteger de verdade, o sistema recusa em vez de fingir.
Sem a biblioteca de confiabilidade instalada, as ferramentas locais seguem funcionando e avisam — disponibilidade escolhida conscientemente para ferramenta local, com o risco por escrito. Segurança que finge é teatro; aqui, cada exceção tem nome, motivo e log.
> renatao seal --write Nota: C (65/100) ## O Que Falta Para Subir [ ] Definir evals do projeto (+15) [ ] Evals verdes (+20)
É do XP (Extreme Programming) que vêm o test-first/TDD, as iterações curtas com feedback contínuo e a programação em par — aqui, o par é o desenvolvedor e o agente, coordenando e planejando juntos antes de qualquer linha. E com cabeça de MVP: todo trabalho começa declarando o escopo mínimo e, principalmente, o que fica de fora da primeira versão.
A divisão de papéis é deliberada. O humano é dono das decisões — produto, stack, prioridade, o que é crítico. O agente executa com a velocidade que só IA tem. E o Renato coordena: injeta o contexto certo, serve os protocolos da tarefa e cobra os gates — para que o par nunca pule etapa, nem no dia corrido. Nenhum dos três substitui os outros dois.
“A vida é isso: conhecimento só serve se compartilhado.”
O Renato não nasceu para ser meu. Se ele me ajuda a transformar código de IA em software de verdade, por que não ajudaria todo mundo? Os segredos e as chaves ficam em casa — o conhecimento, não. Os protocolos, a arquitetura, o método, as lições (inclusive os erros — foram auditorias adversariais que acharam os melhores bugs): tudo isso é feito para circular. Se uma ideia daqui melhorar o jeito de uma pessoa construir software, o projeto já cumpriu o propósito.
O Renato é a automação do método — mas o método funciona à mão, hoje, sem instalar nada. A escada de adoção que a casa recomenda:
Uma prática por vez — quatro mudanças simultâneas morrem juntas na primeira semana cheia. E cada prática precisa subir a escada de enforcement do time: o aceite vai para o template do PR, os evals vão para o CI, o selo vira uma reunião mensal de 15 minutos com checklist.
Documento que não bloqueia nada volta a ser conselho — e conselho se esquece. A pergunta de cada semana é sempre a mesma: "o que impede, mecanicamente, de pular esta etapa?" Enquanto a resposta for "boa vontade", o trabalho não terminou.
Abertos: os protocolos, a arquitetura, o método e as lições — inclusive os erros. Em casa: segredos, chaves e a memória. Use, adapte, melhore — e repasse. Se uma ideia daqui melhorar o jeito do seu time construir software, o projeto já cumpriu o propósito.
Ele é ótimo em escrever e péssimo em lembrar e se cobrar. O Renato não compete — coordena: memória entre sessões, método e gates que não aceitam "confia".
Qualquer um que fale MCP — Antigravity, VS Code, Cursor. Identidade, memórias e gates chegam dentro da conversa do agente; a CLI determinística cobre o resto, e humanos também podem usá-la direto.
O caminho crítico é local e de custo zero: roteamento sem LLM, memória em SQLite, gates como funções. Chamadas pagas são opcionais — sob teto diário de custo com bloqueio automático.
Acervo, índices, segredos e backups: não. O texto de uma memória viaja só para gerar o vetor — depois do leak-scan — e tudo degrada para busca local pura sem internet.
Tarefa trivial fica fora dos gates. Nas relevantes, o custo é minutos — contra horas de retrabalho. Por construção, desobedecer dá mais trabalho que obedecer.
Reprodutibilidade e auditoria: mesmo pedido, mesmo método, custo zero, latência zero. Auditar é ler uma tabela de pesos — não interrogar um modelo sobre o que ele decidiu ontem.
O agente continua funcionando — o Renato coordena, não executa. Os artefatos ficam no projeto, legíveis sem a ferramenta; o cérebro tem backup verificado de verdade.
Trabalho solo para várias empresas e projetos ao mesmo tempo, e precisava urgente de alguém para me ajudar. Construí o Renato porque queria testar, conhecer, entender e extrair o melhor que a IA podia dar para o meu trabalho de verdade — não em demo, no dia a dia.
Assim nasceu o Espetacular Renato: hoje não só uma IA, mas um parceiro de trabalho.
— Erick
3a157b0 fix: regra em TUDO — MCP, AGENTS 943be05 feat: Segunda Versao + Torneio 3b7a0a5 feat: Selo da Casa — nota A-F 9018d1a feat: scaffold com kit da casa a03e183 feat: revisao adversarial 68c42a3 feat: producao viva + deps 1428f3c feat: evals + gate no ship-check 55fd6de feat: aceite vira contrato
git log ao lado.Construído em português, no Brasil, com método brasileiro:
avaliação em vez de dogma, evidência em vez de juramento — e a porta aberta.