Em 2026, uma equipe empresarial construiu um agente que lia tickets de gerenciamento de incidentes, gerava post-mortems deles e criava itens de reparo automaticamente. Um segundo agente da mesma equipe observava novos itens de trabalho e abria rascunhos de PRs para cada um deles para ajudar os desenvolvedores a começar. Um desenvolvedor revisou um desses PRs, achou-o razoável, aprovou-o e ele foi incorporado ao ramo principal.

**O problema é que a mudança foi totalmente fabricada.**

O agente inventou uma solução aparentemente plausível para um problema que não existia da forma como foi descrito. A mudança regrediu um cenário real de produção. Um cliente real percebeu. Houve uma interrupção.

É por isso que existe a Constituição EDD.

A constituição é um arquivo único que rege todas as alterações não triviais na base de código. Ele define a aparência de uma mudança concluída, quais evidências ela deve conter, o que uma auditoria de escopo deve cobrir e como as próprias regras podem evoluir. Cada agente e cada ser humano que acessa o repositório o carrega em todas as sessões. A barra só aumenta.

Esta postagem percorre a constituição passo a passo: o incidente que a motivou, a questão de design que ela responde, como está estruturada, como foi escrita (e o que erramos no início), como as emendas funcionam e como o kit completo se desdobra em um novo repositório.

Passo 1 – O que é

O incidente é a ilustração mais clara possível do modo de falha que o EDD foi projetado para prevenir. O agente não teve alucinações aleatoriamente. Produziu um PR coerente, legível e formatado profissionalmente. O desenvolvedor que o revisou fez o que os desenvolvedores fazem: leram a intenção, consideraram a intenção plausível e aprovaram. A lacuna não era a atenção. A lacuna era a ausência de provas. Nada no processo de revisão exigia que o agente demonstrasse que o problema que pretendia corrigir realmente existia, que a correção abordava o comportamento real ou que a mudança não regrediu em nada.

O EDD responde a essa lacuna com um único requisito difícil: se o agente não puder provar isso, a tarefa não será concluída. A prova não é um resumo. A prova não é uma afirmação de confiança. A prova é um artefato que pode ser verificado de forma independente - um teste com falha, uma saída do scanner, uma captura de tela antes/depois, uma diferença de plano. O PR carrega o artefato ou está incompleto.

A constituição está em `docs/methodology/CONSTITUTION.md`. Cada agente de IA configurado no projeto o carrega em todas as sessões por meio de seu próprio arquivo carregador. O corpo é neutro em termos de agente: sem nomes de ferramentas, sem sintaxe específica de plataforma. Ele define nove princípios fundamentais, restrições rígidas com IDs de slug estáveis, o ciclo de implementação de 10 etapas, dimensões de auditoria, critérios de aceitação de evidências por tipo de mudança, exclusões de trivialidade para trabalhos de baixo risco e a cláusula de alteração.

Cada restrição rígida possui um slug como `[HC-EVIDENCE-BEFORE]` e declara três coisas: a barra (o que deve ser verdadeiro), a verificação (como a aderência é verificada) e a fonte do padrão (cujo arquivo de instrução elabora a orientação de implementação).

O ciclo de 10 etapas é o coração operacional: definir o que foi feito, escrever um teste que comprove a lacuna, observar a falha, capturar as evidências anteriores, implementar, observar a aprovação do teste, capturar as evidências posteriores, verificar os documentos, auditar as dimensões declaradas e, em seguida, revisão humana. As etapas 1 a 4 acontecem antes de qualquer edição de implementação. A ordem é constitucional porque este incidente mostra exatamente o que acontece quando não o é.

Como salvaguarda adicional, o EDD toma emprestado um princípio fundamental do TDD: deve ser comprovado que o cenário falhou antes do início do trabalho. Uma prova aprovada no final de uma mudança não é evidência suficiente por si só - se o teste também passou antes da mudança, o agente pode ter consertado algo que nunca foi quebrado. Este é um modo de falha específico em fluxos de trabalho assistidos por IA: um agente gera uma solução que parece plausível, a verificação é satisfeita e a mudança é enviada como se tivesse resolvido um problema real. Exigir um estado de falha documentado antes do início da implementação preenche essa lacuna. A etapa anterior à evidência não é apenas uma base de comparação – é uma prova de que o problema a ser resolvido era real.

De todas as restrições rígidas que foram implementadas na constituição, duas detectaram mais defeitos do que todas as outras combinadas e são, sem dúvida, a atualização mais importante que o EDD faz em qualquer fluxo de trabalho assistido por IA: `[HC-EVIDENCE]` e `[HC-EVIDENCE-INTEGRITY]`. Ambos são declarados em `.github/copilot-instructions.md` - o arquivo carregado antecipadamente que está no contexto do agente em cada sessão.

`[HC-EVIDENCE]` exige que todo PR contenha artefatos reais antes e depois - não descrições do que os artefatos mostrariam, não resumos do que o agente acredita que aconteceu, mas a saída bruta. `[HC-EVIDENCE-INTEGRITY]` vai mais longe: exige que as provas no PR possam ser rastreadas até ao trabalho que foi realmente realizado. Valida que o PR contém o que diz conter.

Juntas, essas duas restrições detectaram centenas de bugs gerados pela IA antes de serem revisados. O modo de falha contra o qual eles se protegem não é a alucinação no sentido óbvio. É um comportamento mais sutil: o agente marca uma tarefa como concluída, escreve uma descrição confiável de PR e inclui o que parece ser evidência – mas a evidência foi composta, não capturada. O agente descreveu a aparência da saída em vez de executar o comando e incluir a saída real.

`[HC-EVIDENCE-INTEGRITY]` é especificamente eficaz em capturar o que pode ser chamado de padrão "Eu não poderia fazer isso". Um agente que enfrenta uma tarefa difícil ou desconhecida às vezes alega que a tarefa é impossível ou está fora do escopo, em vez de tentar realizá-la. A reivindicação é muitas vezes enquadrada como uma limitação – uma ferramenta que não existe, uma restrição que impede a abordagem, um ambiente que não suporta a operação. `[HC-EVIDENCE-INTEGRITY]` revela isso: se o agente está alegando que uma tarefa não pôde ser realizada, o PR deve mostrar evidências de que a tarefa foi genuinamente tentada e que o obstáculo é real. "Não consegui executar o conjunto de testes" requer uma saída de terminal mostrando a falha, não uma declaração de que a falha ocorreu. Sem esse requisito, a evitação do trabalho difícil por parte do agente é invisível no momento da revisão e a tarefa é enviada incompleta como se tivesse sido concluída.

Passo 2 – Como chegamos aqui

A constituição não é uma acumulação de lições aprendidas. É a resposta a uma questão de design colocada no início: como forçar um agente de IA a provar o seu trabalho todas as vezes, de uma forma que não seja contornada e que não dependa de um ser humano se lembrar de perguntar?

Responder a essa pergunta forçou uma decomposição. A prova requer saber como é a conclusão antes do início da implementação - o que produziu a etapa de documentação. A prova requer um teste que falha antes da mudança e passa depois - que produziu a disciplina de teste com reprovação/aprovação. A prova requer um estado anterior que foi capturado antes que a implementação tocasse em qualquer coisa - que produziu o requisito de evidência anterior. A prova requer uma auditoria independente que capte o que a evidência por mudança não consegue – que produziu as dimensões da auditoria. E a prova tem de sobreviver ao processo de revisão sem ser suavizada – o que produziu a forte restrição de que o revisor humano é a porta final e a única que não pode ser automatizada.

O resultado é o loop de 10 etapas. Cada etapa existe porque removê-la cria um buraco através do qual o trabalho não comprovado pode passar. O loop não é uma lista de verificação. É uma cadeia causal.

A partir daí a questão passou a ser: quais categorias de falha um agente pode produzir e que o loop não detecta por padrão? Isso produziu as duras restrições. O lint de segurança ficou em silêncio enquanto as regras eram rebaixadas, produzindo `[HC-SECURITY-LINT]`. Uma falha na codificação de caracteres em um artefato implantado produziu `[HC-ASCII-PUNCT]`. Cada HC fecha uma classe de falha específica com uma verificação automatizada específica. As regras que não podiam nomear uma verificação foram recusadas: se uma verificação não puder ser automatizada, a regra é aspiracional e não constitucional.

A questão final do desenho foi: quem governa a própria constituição? A resposta é a catraca. A constituição só pode ficar mais rígida. As alterações devem conter provas de que o comportamento do agente melhora ou se mantém. O chão nunca desce. Isto significa que se pode confiar na Constituição ao longo do tempo de uma forma que um guia de estilo de vida não consegue: cada versão é estritamente mais forte do que a anterior.

Passo 3 – Como está estruturado

A constituição segue uma arquitetura de três camadas.

**Camada 1: O corpo canônico.** Um arquivo, `docs/methodology/CONSTITUTION.md`. Esta é a fonte da verdade. É neutro em termos de agente: não faz suposições sobre qual ferramenta de IA está em uso. Define princípios, restrições rígidas, ciclo, dimensões de auditoria, critérios de aceitação de evidências, exclusões de trivialidade e cláusula de autoaperfeiçoamento. Quando o corpo excede aproximadamente 250 linhas, as regras que se aplicam a um padrão de caminho específico são fatoradas em arquivos com escopo de caminho, com um ponteiro de uma linha deixado no corpo.

**Camada 2: Carregadores de agentes.** Cada agente configurado obtém exatamente um arquivo carregador no local que o agente carrega com entusiasmo. Para GitHub Copilot, é `.github/copilot-instructions.md`. Para Claude, é `CLAUDE.md`. O carregador importa ou incorpora o órgão de constituição dependendo do que a plataforma suporta atualmente. O carregador é renderizado mecanicamente a partir do corpo canônico; não é editado manualmente. Se um projeto usar três ferramentas de IA, haverá três arquivos de carregamento, todos renderizando o mesmo conteúdo constitucional.

**Camada 3: regras com escopo de caminho.** Algumas regras se aplicam apenas a tipos de arquivo específicos. As regras de acessibilidade e localização se aplicam a arquivos JSX e CSS, não a modelos de infraestrutura. Essas regras residem em arquivos de instruções com um glob de frontmatter:

O agente carrega esses arquivos somente quando toca em um caminho correspondente. Isso mantém o orçamento de contexto de carregamento rápido apertado (regras básicas sempre presentes, regras especializadas carregadas sob demanda) e evita que orientações de acessibilidade apareçam em uma edição de modelo Bicep.

Os arquivos de suporte completam a estrutura: corpos de comando `/constitute` em `.github/prompts/`, pastas por recurso em `docs/methodology/features/`, cenários de avaliação em `docs/methodology/eval/scenarios/` e `verify-sequence.yaml` na raiz do repositório que define a ordem do gate CI.

Passo 4 – Como escrevemos

**Contexto é tudo. O que não está no contexto está morto para o agente.**

Este é o insight mais importante sobre a redação de uma constituição para o desenvolvimento governado pela IA. Uma regra que existe em um arquivo que o agente nunca carrega não existe. Uma restrição rígida enterrada em um documento que só é carregado quando um caminho de arquivo específico é tocado não é uma restrição rígida para qualquer outro caminho. A constituição deve estar sempre em contexto, e tudo o que sempre deve ser aplicado deve residir nele.

Isso impulsiona três decisões de autoria:

**A otimização do token não é negociável.** O corpo canônico tem como alvo menos de 300 linhas e 8 mil tokens. Cada alteração deve manter ou melhorar a eficiência simbólica – regras detalhadas que realizam o que as concisas conseguem são rejeitadas apenas por esses motivos. Esta não é uma preferência de estilo. É uma restrição de carga. Se a constituição exceder o orçamento, os agentes em janelas de contexto mais pequenas começam a truncá-la, e regras truncadas não são regras.

**Carregamento condicional por meio do frontmatter.** As regras que se aplicam apenas a tipos de arquivo específicos são fatoradas fora do corpo canônico e em arquivos de instrução com escopo de caminho com uma declaração glob do frontmatter. As orientações de acessibilidade e localização são carregadas somente quando o agente toca em JSX ou CSS. A orientação de infraestrutura é carregada somente quando o agente toca o Bicep. O corpo canônico mantém um ponteiro de uma linha. O agente carrega o arquivo com escopo de caminho somente quando for relevante. Isto não é apenas eficiência – evita que as orientações de acessibilidade surjam como uma distração numa edição de infraestrutura, o que treina o agente para ignorá-las.

Este projeto não usa arquivos de regras separados por frontmatter porque a constituição é pequena o suficiente para ser carregada inteiramente no contexto - um único desenvolvedor, um escopo focado, um conjunto de regras enxuto. Para equipes maiores, o cálculo muda. Um projeto de escala empresarial atualmente executando o EDD tem 75 restrições rígidas em termos de segurança, conformidade, acessibilidade e requisitos específicos da plataforma. Incorporar todos os 75 num único arquivo de carga rápida levaria a constituição muito além do orçamento de contexto para a maioria dos agentes. A divisão do Frontmatter mantém o corpo canônico abaixo de 250 linhas - um ponteiro de resumo por domínio - e carrega lentamente os detalhes completos da regra somente quando o agente toca nos caminhos correspondentes. A constituição permanece rápida e enxuta. As regras permanecem completas. O custo do token permanece limitado.

**Emendas como unidades de mudança.** Uma emenda constitucional não é uma mudança de palavra em um arquivo de redução. É um pacote de três artefatos: o delta exato da regra, o mecanismo de verificação que detectará violações futuras e um cenário de avaliação comportamental que prova que o comportamento do agente melhora. Todos os três são enviados juntos no mesmo PR. A emenda é atômica. Emendas parciais que prometem acrescentar a verificação posteriormente são rejeitadas – o posterior não vem, e uma regra inverificável é a decoração.

**Escreva as avaliações e rubricas antes de achar que precisa delas.** A avaliação é a catraca. Sem ela, as alterações são aceites de boa fé e a constituição fica à deriva. A rubrica avalia o comportamento do agente em cenários realistas. Cada nova regra produz pelo menos um cenário. A rubrica produz uma pontuação numérica. A alteração só será aprovada se a pontuação da árvore de trabalho atingir ou exceder a linha de base.

**Documente o que você pode ou não cobrir. Não minta para si mesmo sobre a cobertura.**

No início, a restrição rígida de acessibilidade declarou que as novas superfícies de UI interativas exigiam cobertura e2e a11y usando axe-core. Isso parecia abrangente. Na prática, foi ingênuo. axe-core lida com um subconjunto significativo de WCAG - ele captura rótulos ausentes, estrutura de pontos de referência, ordem de foco e contraste nos casos em que o DOM é totalmente renderizado e as cores são resolvidas. Ele não detecta lógica de anúncio de leitor de tela, padrões de carga cognitiva, contratos complexos de teclado de widget ou problemas de contraste envolvendo gradientes e nós de imagem SVG onde a cor computada não pode ser resolvida.

Ter `[HC-A11Y-GATE]` com axe-core na verificação não significa que os bugs a11y sejam zero. Isso significa que o conjunto de regras específico do núcleo do machado é executado no DOM renderizado. A diferença é enormemente importante nas reivindicações de cobertura de relações públicas.

A solução foi a decomposição. Em vez de "limpeza do núcleo do machado", a verificação foi reescrita para enumerar quais critérios de sucesso das WCAG o conjunto de regras do núcleo do machado cobre deterministicamente (1.1.1 para conteúdo não textual, 1.3.1 para informações e relacionamentos, 1.4.3 para contraste quando resolvível, 4.1.2 para nome/função/valor) e que têm cobertura automatizada zero (1.3.3 características sensoriais, 2.4.6 semântica de títulos e rótulos, todos de 3.x Critérios compreensíveis). A seção de lacunas conhecidas da dimensão de auditoria agora afirma explicitamente: axe-core lida com esses critérios; a digitalização manual é necessária para eles. Os revisores de RP veem a cobertura real, não um resumo de falsa confiança.

O princípio mais amplo: para cada verificação, documente o que detecta e o que não detecta. "Passes de lint de segurança" não significa que a base de código seja segura. "axe-core clean" não significa conformidade com WCAG 2.2 AA. Dê um nome à lacuna. Registre-o na dimensão de auditoria. Exigir digitalização manual da superfície da lacuna. Não deixe que a verificação automatizada substitua o julgamento humano que ela não pode substituir.

Passo 5 – Como redigimos alterações

As alterações quase nunca começam como propostas de alteração. Eles começam como insetos.

Um bug surge. A correção é aplicada. Antes de embarcar, `/reflect` faz uma pergunta: isso é algo pontual ou falta algo na constituição que teria detectado esse tipo de fracasso? Se a resposta for pontual, a correção será enviada e ponto final. Se a resposta for que algo está faltando, é quando `/constitute` é invocado.

**O /reflect -> gap -> caminho de alteração.** `/reflect` examina a correção e a classifica: lacuna de constituição (nenhuma regra cobria esta classe de falha) ou lacuna de verificação (existia uma regra, mas nenhuma verificação automatizada a aplicou). Ambas as rotas levam a `/constituir`. Uma lacuna constitucional produz um novo HC. Uma lacuna de verificação produz uma verificação mais rigorosa em um HC existente – normalmente uma nova subseção de dimensão de auditoria, uma nova regra de scanner ou um novo cenário de avaliação.

**Os três artefatos necessários.** `/constitute` se recusa a prosseguir sem todos os três no mesmo PR:

• **Delta da regra.** A alteração exata do texto, classificada: nova regra, redação alterada, deslocamento (substituir e remover a antiga), substituição (elevar a barra com a antiga como piso) ou remanejamento. Duplicatas são rejeitadas à vista.
• **Mecanismo de verificação.** A porta específica que detectará uma violação futura - um nome de teste, ID de regra de lint, subseção de dimensão de auditoria, verificação de código de saída do scanner ou cenário de avaliação comportamental. Deve existir no momento do commit. Regras sem violações detectáveis ​​são decorativas.
• **Cenário de avaliação.** Armazenado em `docs/methodology/eval/scenarios/<id>.md`. Descreve uma situação realista em que a regra antiga produz um comportamento errado do agente e a nova regra produz a resposta correta passível de pontuação.

**A catraca.** Depois que todos os três artefatos forem aprovados, a alteração será aplicada a uma filial. A avaliação é executada de acordo com as regras do ramo principal e as regras da árvore de trabalho. A rubrica pontua ambos. A passagem requer árvore de trabalho >= main em todos os cenários. A regressão bloqueia a alteração até que a redação seja fixada. A catraca não é opcional para alterações óbvias: elas ainda podem produzir regressões sutis, e o eval é o único mecanismo que as captura antes de pousarem.

**A varredura retroativa.** Uma emenda fixa a regra para o novo código imediatamente: o escopo diff de `/audit` significa que o novo trabalho atende aos novos padrões a partir do momento em que a emenda chega. O código pré-existente que viola a nova regra é tratado por um PR de varredura separado enfileirado em `/rollout`. O site de correção não precisa corrigir todas as instâncias pré-existentes em linha. Isso tornaria as alterações proibitivamente caras. Em vez disso: o novo código atende a nova barra imediatamente, o código antigo está na fila de implementação e o PR de varredura carrega sua própria evidência de que as instâncias pré-existentes foram resolvidas.

Os quatro gatilhos válidos para `/constitute` são: um bug, um incidente, uma autópsia e um novo padrão contratual. Propostas em forma de "provavelmente deveríamos..." sem nenhum dos quatro gatilhos são recusadas e encaminhadas para `/reflect`.

Passo 6 – Como o desenrolamos

O Portable Methodology Kit (`EDD - Portable Methodology Kit.md`) é um documento independente que você entrega a qualquer agente de IA com as instruções para executar `/begin`. O agente inspeciona o repositório, executa um passe de descoberta, confirma os valores detectados com você em uma única tabela, pergunta apenas o que a descoberta não pode responder e emite o andaime mínimo viável para o seu projeto. Uma sessão para sustentar toda a infraestrutura EDD.

Como você o desenrola depende inteiramente de você estar começando do zero ou trazendo-o para uma base de código existente. Os dois caminhos são diferentes o suficiente para serem tratados separadamente.

**Greenfield.** Em um novo projeto, coloque todas as regras que você puder imaginar na constituição desde o primeiro dia. Você não tem nenhum código pré-existente para auditar, nenhuma prática de equipe para proteger, nenhum PR existente para avô. O custo do rigor no primeiro dia é quase zero. Adicione todas as restrições rígidas, todas as dimensões de auditoria, todas as regras com escopo de caminho. Em seguida, execute o loop. O que você descobrirá rapidamente é onde a constituição cria atrito: tempos de construção que aumentam porque cada mudança desencadeia uma auditoria completa, suítes de testes que são lentas porque a barra de cobertura está definida muito alta para a complexidade atual, orçamentos de tokens que são apertados porque o corpo canônico é muito detalhado. O rigor do primeiro dia revela esses problemas no desenvolvimento, não na produção. Aí você otimiza: aperta as portas de construção, ajusta as regras de cobertura, reduz o corpo constitucional ao mínimo. Você estabiliza tudo de uma vez, sem nenhum cliente afetado e nenhuma equipe interrompida. O custo de curto prazo é um primeiro sprint um pouco mais lento. O ganho a longo prazo é uma constituição que foi submetida a testes de resistência desde o primeiro compromisso.

**Brownfield.** Uma base de código existente possui uma equipe existente, práticas existentes e PRs existentes que não seguiram o EDD. O desenrolar aqui é incremental e deve ser aditivo, não perturbador. O objetivo para o primeiro mês não é atualizar todas as decisões anteriores - é começar a gerar as garantias que tornam o EDD confiável: uma dimensão de auditoria que detecte algo real, uma restrição rígida que automatize uma verificação de revisão que a equipe já estava fazendo manualmente, um ciclo de alterações de ponta a ponta. Utilizar os sinais de qualidade existentes na equipe como matéria-prima. Se a equipe já tiver uma regra de segurança para segurança, adicione `[HC-SECURITY-LINT]` e aponte para o portão existente - nada muda para os desenvolvedores, mas agora o registro constitucional reflete o que o portão realmente impõe.

A regra fundamental no brownfield é: ganhar aliados antes de vencer discussões. Não force uma constituição completa que abranja todas as áreas da base de código na primeira semana. Comece com a dimensão com a qual a equipe mais se preocupa – geralmente segurança ou confiabilidade. Mostrar que o processo de alteração preenche uma lacuna real que já tinham visto antes. Deixe a catraca composta a partir daí. Uma equipe que viu o EDD detectar um bug real que escapou do processo existente abrirá espaço para a próxima regra. Uma equipe que encara o EDD como um documento que lhes diz que estão fazendo tudo errado irá contorná-lo.

**O que isso desbloqueia.** A razão para passar pelo desdobramento, seja greenfield ou brownfield, não é o documento de constituição. É o que a Constituição permite quando o mecanismo de verificação está em funcionamento.

A qualidade do código de produção e a velocidade de entrega se combinam de uma forma que é genuinamente contra-intuitiva, caso você ainda não tenha visto. Os engenheiros param a mudança de contexto para depurar regressões que o loop teria capturado. Os ciclos de revisão são encurtados porque os RP trazem evidências em vez de explicações. A auditoria é executada automaticamente e sinaliza os problemas que teriam sido detectados pelo revisor mais experiente, liberando esse revisor para se concentrar nas decisões arquitetônicas que realmente exigem seu julgamento.

A evidência mais clara disso: um novo engenheiro ingressando na equipe, com acesso total à constituição, às especificações do recurso e ao loop, pode fazer uma contribuição de recurso de qualidade de produção verificada no main dentro de 48 horas após o primeiro dia. Não é uma mudança de brinquedo. Não é uma atualização de documentação. Um recurso real, com evidências, passando pela auditoria completa. Não é um acaso e não é um engenheiro particularmente incomum. As proteções possibilitam que qualquer desenvolvedor qualificado opere de acordo com o padrão de qualidade da equipe desde o primeiro dia, porque o padrão de qualidade é escrito, verificável e aplicado automaticamente, em vez de ser transportado como conhecimento institucional nas cabeças de quem está no mercado há mais tempo.

Essa é a forma que ele alcança: uma equipe onde a IA faz o trabalho de verificação, os guardrails capturam as classes de falha que de outra forma escapariam da revisão do código e os engenheiros gastam seu tempo pensando nos problemas que realmente exigem julgamento de engenharia.

Isso foi verificado em diferentes escalas – primeiro em projetos individuais, depois em equipes de médio porte e depois em organizações de escala empresarial. A mecânica se mantém em todos os três. O custo de desdobramento é diferente (um desenvolvedor solo pode ignorar os registros de requisitos e a revisão adversária entre fornecedores; uma equipe corporativa precisa deles). A cadência de alteração é diferente (um projeto solo pode levar semanas entre as invocações `/constitute`; uma equipe empresarial com vários agentes contribuintes as executa semanalmente). Mas o core loop, a catraca e o requisito de evidência se comportam da mesma maneira, independentemente do tamanho da equipe. O nível de qualidade só aumenta e o maquinário de verificação o mantém lá, sem depender de quem for o revisor mais experiente na sala naquela semana.

Ganchos de IA

A constituição rege o comportamento do agente através do contexto carregado. Os ganchos impõem isso no momento da ação, antes que o trabalho já esteja concluído e um PR já esteja aberto. Sem ganchos, uma violação é detectada na revisão: o agente já escreveu o código, o PR existe e corrigi-lo significa refazer o trabalho. Com ganchos, a interceptação acontece antes de qualquer pressionamento de tecla.

**Tanto o Claude Code quanto o GitHub Copilot executam um gancho no envio imediato.** Quando uma nova tarefa chega, o gancho é acionado antes que o agente faça qualquer coisa. Seu trabalho: verificar se a tarefa não é trivial e, em seguida, religar a lista de tarefas no loop `/uau` - a sequência EDD de 10 etapas que o agente deve seguir antes de enviar qualquer coisa.

Um agente que atinge a etapa 5 sem completar as etapas 1 a 4 violou o loop. O gancho estabelece a sequência no início da sessão - não após o fato.

**Claude Code** também dispara um gancho de pré-chamada de ferramenta antes de qualquer gravação de arquivo, comando de terminal ou operação git. Uma confirmação não pode ser tentada se as etapas do loop não tiverem sido satisfeitas.

**GitHub Copilot** também dispara um gancho de criação de relações públicas. Antes que a descrição do PR seja finalizada, o gancho executa `/audit` no modo de auto-revisão - detectando violações de dimensão, evidências faltantes e planos de teste vazios antes que um revisor humano veja o rascunho. O que chega ao revisor já é pré-selecionado.

**Codex e outros agentes** não tinham superfície de gancho nativa no momento desta redação. O substituto é um bot observador de CI que comenta os PRs imediatamente após a criação e sinaliza violações. É um backstop, não um portão de primeira superfície - o trabalho já está concluído no momento do disparo, por isso não impede o retrabalho que os ganchos eliminam.

Em um projeto com ganchos ativos, as violações são corrigidas em linha durante a sessão. O agente capta a lacuna, produz as evidências e as inclui desde o início. O tempo de revisão diminui. O retrabalho desaparece. A constituição passa de um documento que o agente lê para uma restrição dentro da qual o agente opera em tempo real.

Apêndice - A Constituição Completa

O que se segue é o verdadeiro `CONSTITUTION.md` deste projeto - um projeto de desenvolvimento único, totalmente autônomo e assistido por IA. Ele rege todas as alterações não triviais feitas nesta base de código. Este não é um modelo ou uma ilustração. Este é o documento ativo carregado por cada agente em cada sessão.