Escribir una regla lleva minutos. Aplicarla es lo delicado
Si algún camino de tu aplicación emite la query que la regla prohíbe, el proxy la rechaza en producción. Un motor determinístico da siempre el mismo veredicto, pero eso no lo hace infalible: el simulador responde, antes de aplicar, qué de tu propio tráfico habría bloqueado el cambio.
Cómo funciona
- Un cambio candidato combina hasta 20 elementos: reglas custom nuevas o editadas, reglas custom desactivadas y reglas estándar activadas, desactivadas o con otra severidad.
- Las queries registradas por el proxy TCP y la API de runtime se agrupan por flujo: el texto con los literales reemplazados.
- Cada sentencia se evalúa con el motor de hoy, con tus reglas actuales y con las candidatas. La diferencia es el efecto de tu cambio; la deriva por una versión nueva del motor se reporta aparte.
- Nada se ejecuta contra tu base de datos, nada se bloquea y nada se escribe en el historial de queries ni en tu cuota.
El reporte
Un veredicto (PASS, WARN, FAIL o INCONCLUSIVE), una frase lista para pegar en el PR y cada flujo afectado, con sus ejecuciones, identidades y muestras con los literales reemplazados. Un flujo es legítimo cuando todas sus ejecuciones pasaron, corrió al menos 3 veces en al menos 2 días y viene sobre todo de las identidades de tu aplicación.
Desde el dashboard o desde CI
En el editor de reglas custom, «Simular contra producción» simula la regla que estás escribiendo, sin guardarla. Desde CI, una API key con el scope rules:simulate inicia la simulación y el job falla cuando el veredicto es FAIL.
curl -s -X POST https://api.vericto.com/api/v1/ci/rules/simulate \
-H "X-API-Key: $VERICTO_SIM_KEY" \
-H "Content-Type: application/json" \
-d '{ "days": 30, "candidates": [ ... ], "thresholds": { "fail_on_break": 0 } }'Hasta 30 días de historial en Builder, 90 en Team y según contrato (hasta 180) en Enterprise, sin superar la retención de tu plan. Una simulación a la vez por workspace: hasta 10 por día en Builder y 30 en Team y Enterprise.