Fences executáveis

COADF P-6: uma barreira que vive em um documento é um conselho; uma barreira que roda na pipeline e bloqueia uma liberação é um fence. Os fences caem em quatro categorias (dados, arquitetura, texto e processo), cada um com um identificador, uma regra e um método de aplicação, e um fence só ganha seu lugar por uma prova de dentes. O COADF não publica o vocabulário sobre o qual seu próprio fence de publicação dispara, porque uma lista do que se vigia é um mapa do que se protege.

A propriedade não é “existe uma verificação”. É que o estado proibido não consegue passar de um determinado ponto, e que alguém o viu ser detido ali.

Todas as outras propriedades deste Companion podem ser implementadas corretamente uma vez e perdidas na mudança seguinte. Um fence é o que mantém uma propriedade verdadeira ao longo de mudanças que ninguém revisou com essa propriedade em mente. A parte difícil raramente é escrever a verificação. É colocá-la no caminho que o estado proibido precisa percorrer, e provar que ela dispara ali, no caminho real, e não num teste unitário da função que verifica.

Superfícies de aplicação

Cada superfície vê algo diferente, e cada uma tem um desvio característico. Um fence pertence à superfície que vê o estado proibido, e só é tão forte quanto o desvio dessa superfície permite.

Três cadeias, cada uma terminando numa transição detida, estão implementadas nos perfis:

• Uma violação de arquitetura faz um teste de arquitetura falhar, e o merge não acontece (Python e FastAPI).
• Uma incompatibilidade de contrato faz uma verificação de contrato falhar, e a liberação não acontece.
• Uma sentinela proibida sintética no site gerado faz o fence de publicação falhar, e a publicação não acontece (Python e FastAPI, Cloud-native).

A integração contínua é uma superfície entre nove, não a definição de um fence. GitHub Actions, GitLab CI e Jenkins podem hospedar um; também podem um verificador de tipos, uma política de admissão ou o build que renderiza um site.

Prova de dentes

• Introduzir um defeito controlado e sintético.
• Exercitar o caminho real de aplicação, não um teste unitário da função que verifica.
• Verificar que falha, e que falha pelo motivo plantado.
• Restaurar exatamente o fixture, e provar isso comparando um digest antes e depois.
• Verificar que volta a passar.

Fazer commit antes de plantar. Restaurar descartando mudanças restaura o último commit, que numa branch de trabalho pode não ser o ponto de partida, e a prova então destrói o trabalho que deveria proteger.

• Hooks de pre-commit. Retorno rápido, e contornáveis na própria máquina de quem desenvolve: conselho, não fence.
• Guardas em tempo de execução. Detêm um estado proibido em produção em vez de antes dela. Necessários onde o estado só existe em tempo de execução.
• Gates manuais. Uma pessoa nomeada executa um procedimento escrito. O COADF informa esse controle honestamente como manual, nunca como imposto.
• Motores de políticas para regras de infraestrutura. ValidatingAdmissionPolicy do Kubernetes dentro do processo, ou Open Policy Agent com Gatekeeper, onde o estado proibido é um objeto de API.

• Um fence de texto não consegue ver um mecanismo expresso por fluxo de controle, identificadores renomeados, fluxo de dados ou a geometria de um diagrama. Guardas automatizados são necessários e não suficientes; a revisão humana continua.
• Um fence detecta o que foi escrito para detectar, e nada mais.
• Fences que passam estabelecem que os fences passaram. Não estabelecem nenhum status regulatório.