Caso de uso
Riesgo en revisión de código
Señala los diffs que no deberían fusionarse sin una pasada de seguridad.
El problema
Los revisores hojean. Un comentario de «log de depuración con la contraseña» sale a producción un viernes.
Qué hace tu código con la respuesta
Bloquea la fusión cuando `ship` sea bajo o el riesgo esté en el bucket superior.
Dos preguntas que cada fusión debería pagar
El diff es el estado; ship pregunta si esto puede fusionarse sin revisión de seguridad (sí/no) y risk gradúa la severidad entre Cosmético → Requiere seguimiento → Bloquea la fusión. El diff de muestra — reemplazar el hashing de contraseñas por un helper XOR casero y registrar en claro «para depurar» — es el caso canónico: risk sube hasta el rango de bloquear la fusión mientras ship se lee bajo, que es sobre lo que actúa la comprobación de CI.
La comprobación que los revisores quieren
Llámalo desde CI en cada PR: bloquea cuando ship esté por debajo de tu línea o risk aterrice en el bucket superior; comenta en silencio en medio; deja pasar el resto. Una llamada tipada bloqueante ahorra atención de revisores a 1 crédito y captura el caso del diff-con-prisas que de otro modo sale a producción un viernes. Valida primero con cinco diffs reales de tu historial de fusiones en el playground — los protos generados y el churn de lockfiles necesitan rutas exentas antes de activar la puerta.
Riesgos propios de las puertas de fusión
La puerta lee el diff, no el sistema circundante — un cambio seguro en aislamiento pero catastrófico en combinación (una eliminación de límite de tasa que se encuentra con otro PR pendiente) necesita ese contexto en el estado o un humano en el bucle. Nunca dejes que la puerta pase en silencio un diff sobre el que no estaba segura: las puntuaciones disputadas reciben un comentario, no silencio. La redacción de los criteria para «seguro para fusionar» debe coincidir con tu política real de fusiones — si las rutas de auth siempre necesitan revisión, dilo.
La forma de la solicitud
Esta es la solicitud completa que el playground envía para este preset — el mismo JSON que tu servidor envía a /v1/systemone con una clave 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"
]
}
}
}'Preguntas frecuentes sobre este caso de uso
- ¿Y los falsos positivos en código generado?
- Ajusta las criteria o exonera las rutas en CI antes de la llamada. Una ruta ruidosa es un arreglo de configuración; un modelo ruidoso es una reescritura de criteria.
- ¿Es esto una afirmación de seguridad?
- No — es una señal de triaje. No sustituye a una revisión de seguridad; decide si esa revisión es necesaria antes de que un humano pague por ella.
- ¿Ejecutarlo también en diffs pequeños?
- Sí, es barato y rápido — pero salta los diffs generados por máquinas de procedencia conocida; la puerta lee cambios arriesgados, no enruta robots conocidos.