Este guia leva um repositório do zero a uma checagem de segurança verde ou vermelha em cada pull request: provisione uma chave de API, adicione o workflow e escolha a regra de reprovação que combina com o modo como o time entrega.
Dez minutos de configuração compram um gate que roda os mesmos testes da plataforma contra o endpoint que o PR está prestes a mudar. As páginas de concept explicam como o gate funciona; esta o coloca de pé.
1. Crie a chave de API
- Abra `/settings/api-keys`, clique em Criar chave e use um nome que identifique o repositório.
- Copie a chave iniciada por `didk_` quando ela for exibida; o valor completo não aparece novamente.
- No GitHub, salve a chave como o segredo `DOESITDEFEND_API_KEY` para não colocá-la no arquivo do fluxo.
Dê à chave o nome do repositório para que um incidente de chave vazada seja rastreado à origem em segundos. O valor raw com prefixo didk_ é exibido uma única vez — se for perdido, revogue e crie outra em vez de guardar um segredo pela metade.
2. Adicione o fluxo de verificação
- Crie `.github/workflows/llm-gate.yml` e use a ação indicada na documentação de integração contínua.
- Informe `endpoint`, `api-key`, o formato da API (`template`) e a regra de reprovação (`fail-on`). Esses campos dizem o que testar e como interpretar o resultado.
- Abra uma solicitação de mudança e confirme que o GitHub registra um check. O tempo depende do alvo e do conjunto de cenários.
O arquivo de workflow é pequeno de propósito: endpoint, chave, template e fail-on são o contrato inteiro. Abra o primeiro pull request e confirme que o check aparece na aba Checks antes de confiar no gate de verdade.
3. Escolha quando a verificação reprova
- Use `fail-on: regression` para reprovar apenas quando o resultado piorar em relação à execução anterior do mesmo alvo. Sem uma execução anterior válida, o primeiro resultado é informativo.
- Use `fail-on: findings` quando qualquer achado aberto deve reprovar, inclusive na primeira execução.
- Use `fail-on: never` durante a adoção para observar resultados sem bloquear mudanças. Um erro operacional continua diferente de um veredito de segurança.
Escolha a regra mais estrita que o time tolera e afrouxe só sob protesto. regression é o padrão honesto quando existe uma referência; never é postura de adoção, não destino — erros operacionais continuam reprovando o build em todos os modos.