Caso de uso
Risco de code review
Sinalize diffs que não deveriam fazer merge sem uma passagem de segurança.
O problema
Revisores dão uma olhada rápida. Um comentário "logar a senha para debug" entra no ar na sexta-feira.
O que seu código faz com a resposta
Bloqueie o merge quando `ship` estiver baixo ou o risco estiver no bucket do topo.
Duas perguntas que todo merge deveria pagar
O diff é o state; ship pergunta se isto pode fazer merge sem uma revisão de segurança (sim/não) e risk grada a gravidade ao longo de Cosmetic → Needs follow-up → Blocks the merge. O diff de exemplo — substituir o hash de senha por um helper XOR caseiro e logar plaintext "para debugar" — é o caso canônico: o risk sobe até a faixa de bloquear o merge enquanto ship lê baixo, o que é sobre o que o check da CI age.
A checagem que os revisores querem
Chame da CI em todo PR: bloqueie quando o ship está abaixo da sua linha ou o risk cai no bucket do topo; comente em silêncio no meio; passe o restante. Uma chamada tipada bloqueante poupa a atenção do revisor a 1 crédito e captura o caso do diff feito às pressas que, de outro modo, entra no ar numa sexta-feira. Valide primeiro em cinco diffs reais do seu histórico de merge no playground — protos gerados e churn de lockfile precisam de caminhos isentos antes do gate entrar.
Pitfalls específicos de gates de merge
O gate lê o diff, não o sistema à volta — uma mudança segura isoladamente mas catastrófica em combinação (uma remoção de rate-limit se encontrando com outro PR pendente) precisa desse contexto no state, ou de uma pessoa no loop. Nunca deixe o gate passar silenciosamente um diff sobre o qual ele estava incerto: scores disputados recebem um comentário, não silêncio. O wording dos criteria para "seguro para merge" precisa casar com a sua política real de merge — se caminhos de auth sempre precisam de revisão, diga isso.
O formato da requisição
Esta é a requisição completa que o playground envia para este preset — o mesmo JSON que o seu servidor envia para /v1/systemone com uma chave Bearer.
curl https://jevai.website/api/v1/systemone \
-H "Authorization: Bearer $JEV_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"state": "diff: replace password hashing with a custom XOR \"encrypt\" helper and log the plaintext password \"for debugging\".",
"questions": {
"ship": {
"type": "noul",
"instructions": "Is this change safe to merge without a security review?"
},
"risk": {
"type": "score",
"instructions": "How severe is the security impact?",
"criteria": [
"Cosmetic",
"Needs follow-up",
"Blocks the merge"
]
}
}
}'FAQ sobre este caso de uso
- E falsos positivos em código gerado?
- Aperte os criteria ou isente os caminhos na CI antes da chamada. Um caminho ruidoso é um conserto de config; um modelo ruidoso é uma reescrita de criteria.
- Isto é uma alegação de segurança?
- Não — é um sinal de triagem. Não substitui uma revisão de segurança; ele decide se essa revisão é necessária antes de uma pessoa pagar por ela.
- Rodar também em diffs pequenos?
- Sim, é barato e rápido — mas pule diffs gerados por máquina de procedência conhecida; o gate está lendo mudanças arriscadas, não roteando robôs conhecidos.