DDC Framework: um metamodelo para engenharia assistida por IA

Contexto

Agentes de código produzem saída plausível mais rápido do que um revisor consegue conferir. O modo de falha não é sintaxe errada. É um caminho de arquivo inventado com confiança, uma API de biblioteca da major errada, uma métrica sem fonte. Eu já rodava desenvolvimento assistido por agentes em mais de vinte repositórios, então esse modo de falha se acumulava a cada projeto em vez de ficar contido em um só.

Problema

A qualidade do trabalho do agente era propriedade do prompt, ou seja, de quem por acaso escreveu aquele prompt naquele dia. Não havia como declarar um padrão uma única vez e fazer toda sessão futura obedecê-lo, nem como saber depois se a sessão obedeceu.

Abordagem

Separei a doutrina da ferramenta. `.contexts/` guarda a fonte única de verdade em Markdown puro: 18 rules imperativas, 9 contracts de modelagem, 25 manuais de stack, 6 modelos de arquitetura, 5 práticas, 8 processos e os registros de decisão arquitetural. `.claude/` é a interface compilada que o agente de fato carrega: 55 skills descobertas sob demanda, 21 agentes especializados que declaram cada um quais contextos precisam ler, e 5 scripts de hook ligados a 6 eventos de ciclo de vida (início de sessão, pré-compactação, pré-tool, pós-tool, envio de prompt e parada). Nada é escrito duas vezes; a camada operacional referencia a fonte de verdade por caminho em vez de repeti-la. A própria documentação de harness cobre oito domínios: padrões e arquitetura; frontend e design systems; BFF, APIs e backend; Firebase, Google Cloud e infraestrutura; IA, agents e Vibe Coding; dados e analytics; DevOps e automação; e produto e agilidade.

Decisões não-óbvias

• A doutrina vive em `.contexts/` e a camada voltada ao agente apenas a referencia. Duplicar uma rule dentro de uma skill cria duas versões do padrão, e a que sai do lugar é sempre a cópia.
• As rules se dividem em sempre-ativas e path-scoped. Uma rule sempre-ativa custa tokens em todo turn, então o preço de adicionar uma é deliberadamente alto; uma rule que só vale para um glob carrega quando um arquivo bate com ele.
• Antialucinação é rule, não etapa de revisão. A rule de grounding exige que todo caminho de arquivo, símbolo, versão de biblioteca e variável de ambiente seja confirmado em disco antes de ser citado. Verificação precede geração, que é o inverso de como o modelo quer trabalhar.
• A imposição é mecânica onde pode ser. Um hook de pré-tool rejeita commit que não seja Conventional Commit, um hook de parada alerta sobre afirmações sem grounding e um hook de início de sessão reinjeta a skill de bootstrap após cada compactação, para que perder contexto não zere o padrão em silêncio.
• Todo número publicado sobre o framework é contado em disco na hora de escrever, nunca de memória. A contagem de rules acima é lida do diretório, então o framework se submete à própria rule de grounding, e a suíte de testes do próprio framework reconta em disco cada número publicado a cada execução.

Resultado

O framework é o sistema operacional do meu trabalho assistido por agentes, e esta plataforma é a evidência: especificação, plano, briefs de implementador e revisor por task, um ledger de progresso e um gate de verificação antes de qualquer task poder ser declarada concluída. É também a resposta mais direta que tenho para como conduzir entrega assistida por modelo como processo governado, e não como sequência de prompts de sorte.