IA em produção: regras do negócio em um arquivo no root

TL;DR - Um .md no root com regras do negócio vira onboarding das IAs; spec e TDD antes de pedir código. O arquivo segura o contexto; os testes validam e impedem a IA de inventar requisitos.

Quando uso IA para gerar código que vai para produção, preciso de duas coisas: contexto do negócio e contrato do que deve ser implementado. Sem isso, a sessão deriva e a IA começa a tomar decisões que eu não pedi.

O arquivo que âncora o contexto

Uso um arquivo no root do projeto: REGRAS.md ou CONTEXTO.md. A IA lê esse arquivo antes de gerar. Sem ele, em sessões longas ela perde o fio, desvia da arquitetura e inventa comportamento. O arquivo funciona como onboarding permanente: quem (ou o quê) entra no repo já sabe as regras do jogo.

Como estruturo o arquivo

Organizo em três blocos:

O que não pode acontecer. Restrições, limites, o que o sistema não deve fazer. Guardrails.
Como quero que a IA colabore. Padrões de código, exemplos de bom e mau uso, armadilhas conhecidas do projeto. Guidance.
Contexto compartilhado. Decisões de arquitetura, glossário, por que as coisas são como são. Guideline.

Cada ciclo de implementação que revela algo novo vira linha nesse arquivo. Ele cresce com o projeto.

Spec e TDD como contrato

Para o contrato, uso spec-driven com TDD. Defino o comportamento (entradas, saídas, regras daquele trecho), escrevo os testes e só depois peço o código.

Spec primeiro evita escopo vago. Testes primeiro garantem que a implementação atenda ao que foi especificado. A IA não decide o que fazer; ela preenche como a partir do que já está escrito e testado.

flowchart TB
  Root[REGRAS.md no root] --> IA[IA lê contexto]
  IA --> Spec[Spec + comportamento]
  Spec --> Testes[Escreve testes]
  Testes --> Gera[IA gera código]
  Gera --> Valida[Testes validam]
  Valida -->|Falha| Gera
  Valida -->|Passa| Fica[Código fica]
  Fica --> Atualiza[Atualiza REGRAS.md]
  Atualiza --> Root

O fluxo na prática

A IA lê o arquivo de regras.
Eu defino o trecho em spec (comportamento, entradas, saídas) e escrevo os testes.
Só então peço o código. A IA preenche a implementação; os testes decidem se fica.
Se falhar, ajusto o prompt ou o código até passar.
Depois de cada ciclo, atualizo o REGRAS.md com o que aprendi.

Spec-driven mantém o escopo claro. TDD vira o guarda que impede a IA de inventar requisitos ou desviar do contrato. A IA gera; o spec e os testes arbitram.

Resumo

Um arquivo no root (REGRAS.md / CONTEXTO.md) com restrições, padrões e contexto. Onboarding das IAs.
Spec antes do código. Comportamento e contrato escritos; testes escritos em seguida.
Código por último. A IA implementa; os testes validam. Se passar, fica; se não, ajuste.
Atualizar o arquivo após cada ciclo. O que der errado ou der certo vira regra para o próximo.

Com isso, consigo usar IA em produção sem perder o controle do que está sendo entregue.