
Validação automática de fixtures — quando o teste aprende com o banco
Como o Estudos criou um sistema que valida fixtures contra o schema real do banco, evitando que testes passem por engano por nove dias.
21 posts

Como o Estudos criou um sistema que valida fixtures contra o schema real do banco, evitando que testes passem por engano por nove dias.

O Resume Tailor voltou da árvore, mas cada currículo personalizado ainda é obra manual: abrir o site, descrever a vaga, revisar, salvar, enviar. O plano tem uma Fase 5 desenhada desde agosto — um pipeline semi-automático que transforma uma vaga crua em PDF pronto — e ela ainda não saiu do papel. Sobre a diferença entre lançar uma ferramenta e lançar um hábito.

Nove bibliotecas, um runner de testes em versão major e uma action do GitHub atualizadas num único dia. Como foi integrar 11 pull requests de dependências no Portifólio sem quebrar os testes — e o que quase virou falso alarme.

O alarme caça, o portão bloqueia, o cão ataca. Mas existe uma quarta camada na minha segurança que ninguém escreveu: a fila de atualização de dependências. Em 31 de agosto, o bot entregou cinco propostas de correção. Três dias depois, todas as cinco continuam abertas. A fila virou a superfície.

Depois do alarme e do portão, faltava o terceiro vigilante: alguém que atacasse a própria casa de verdade, de forma autorizada, uma vez por semana, e entregasse um relatório de penetração honesto. O red team agêntico nasceu para isso — e o primeiro drill provou que a sentinela acorda quando alguém mexe no que não deve.

Dez dias depois de automatizar a caça ativa, eu percebi que o problema não era encontrar falha — era garantir que ninguém entregasse código sem passar pela revisão de segurança. O security gate nasceu não como ferramenta, mas como regra de processo: antes de entregar, o loop de testes precisa passar. E o loop inclui um revisor de segurança.

Um botao Recusar no /ocultos que escreve uma nota, cria uma Issue no GitHub, salva um arquivo no repo, e um cron de 15min refaz o post sozinho. A historia de como o feedback humano virou pipeline.

Todo site público tem uma porta da frente: o formulário de contato e o download do currículo. São dois endpoints que aceitam entrada de estranhos na internet — e eu os tratei como tal. Rate limit, escape de HTML, um arquivo de contato para quem acha falhas e um scanner que vigia tudo em silêncio.

Os AGENTS.md de cada projeto eram as instruções oficiais do ecossistema, mas viviam fora da memória do Yurumi — o ingest só rodava quando alguém lembrava. A solução foi um watcher por assinatura (mtime+size) que re-ingere só o que mudou. No caminho, um first_run que rodava ingest completo todo dia, um stat que travava quando o WSL wedgava e a lição de nunca confiar em junction.

Depois de mapear o inventário de portas, o próximo passo foi plantar iscas: serviços falsos, com aparência propositalmente defasada, que se passam por alvos fáceis. Um watcher classifica cada toque no log, e o dispatcher central decide quando o alerta vira notificação.

Uma das camadas mais subestimadas de segurança é saber o que está aberto. O watchdog mantém um inventário vivo de portas, serviços e bindings — mapeado contra o que é intencional — para que qualquer porta nova pareça anormal em segundos.

O watchdog de capas que eu construí para garantir imagens boas no blog descobriu um problema que eu não esperava: as capas geradas por IA vinham no formato errado. O browser rejeitava, e eu só descobri porque o próprio watchdog reclamou.

O watchdog de segurança parou de alimentar um kanban que ninguém lia e passou a publicar findings no lugar certo: direto na memória persistente e no canal do grupo. Menos cerimônia, mais caça ativa, zero cards.

Navegação preditiva no Arachne: o agente recebe uma imagem da página, prevê em cadeia os próximos passos e executa de ponta a ponta. Cascata de fallback D→C→B→A, driver real no browser_agent, elo de scraping e broadcast WebSocket no Cockpit.

O Security Agent cruza os findings de dois caçadores — o Bug Hunter do Dogwalk e o Security Hunter do watchdog — e entrega um único alarme deduplicado. Health gate pra filtrar falso-positivo de infra, padrões de erro de rede descartados, dedup por estado local, e o contrato no_agent: silêncio quando está tudo saudável.

Um post que subiu com capa escura me fez construir um sistema de garantia: geração de imagem com fallback em duas camadas e um watchdog silencioso que troca capa ruim sozinho. A história de como o blog parou de depender de um único caminho.

Depois de achar 28 textos PT hardcoded espalhados pelo Portfólio (botões, aria-labels, modais, tracking), criei um teste de auditoria que varre os componentes e falha o CI se qualquer texto português aparecer fora do t(). A lição: os testes antigos estavam ancorados no bug — buscavam o texto PT literal em vez do contrato i18n.

Automatizar posts narrativos parecia simples: um cron, um script, um preview. No mesmo dia, o pipeline esbarrou em 4 paredes — pnpm bloqueado pelo guard do gateway, MDX quebrando build com '<', capa de 0 bytes e sessão interrompida. Cada parede virou uma regra.

Estabelecendo a frequência de postagens diárias e resolvendo o pipeline de geração de capas por IA com Cloudflare Workers + FLUX.1 Schnell.

Com 3 projetos rodando, a infraestrutura precisava ser robusta. Backups automáticos, security hardening, e o Hermes Agent como cérebro do ecossistema.

Como os testes end-to-end transformaram a qualidade e confiança no desenvolvimento do Dogwalk — a história real de uma stack que aprendeu a se testar sozinha.