Testing y verificación
La red de seguridad de un equipo de uno más agentes (Pest, Playwright, Larastan, el agente auditor sobre el diff) y el gate ejecutable por fase.
Diseño aprobado, aún no implementado: el repo tiene 0 PRs mergeados, así que las suites descritas abajo son las que están planeadas como gate, no tests ya corriendo. La disciplina de gates y del auditor es la estrategia de calidad para un equipo de un engineer + agentes.
Axel se construye AI-native: la mayor parte del código lo generan agentes bajo review humano. Siendo el único revisor senior, la red de seguridad es doble: la suite automatizada más un agente auditor. La evidencia va antes de declarar “hecho”: correr el comando y mostrar el output, no afirmar de memoria.
La suite
Tests del motor (golden con fixtures calculados a mano, sin DB, en cada
commit) y de aislamiento de tenant (TenantIsolationTest, el gate P0). Corre
en el pipeline y local.
Smoke E2E contra Postgres real: login → lista → detalle, 0 errores de consola. En #2 cubre el ciclo completo del contrato en las 12 pantallas de dominio.
Análisis estático en phpstan nivel 7. Atrapa tipos, nullables y llamadas inválidas antes de que corra un test.
Formato de código PHP. Corre en el pipeline para que el diff no tenga ruido de estilo.
Una sola fuente de verdad del pipeline: composer ci:check (Wayfinder → Pint →
Larastan → Pest → pnpm build). El gate local es bin/ci-local.sh + un pre-push
hook. Ver Setup para el detalle.
El agente auditor
Antes de cada merge, un agente auditor (Fable 5, un modelo de IA) pasa sobre el diff. Es la segunda capa de la red de seguridad, orientada a lo que un test no siempre atrapa.
Leaks de datos entre tenants, exposición de datos laborales sensibles (el riesgo #1 del producto), secretos hardcodeados, y anti-patterns de Laravel. Devuelve un resumen con severidad. El CTO lee el resumen + el diff de lo crítico (tenancy, firma, auth, queries con PII se leen completos), no todo el diff línea por línea.
Contract test de SigningService
El punto de integración más delicado se prueba con un contract test que corre
la misma suite contra FakeSigningService y el sandbox real del PSCE: un
reintento idempotente no duplica la firma, el estado failed se propaga, y un
timeout no deja el contrato en estado ambiguo. Así la frontera se comporta igual
con el fake que con el proveedor real. Ver Firma certificada.
Verificación de aislamiento
El aislamiento cross-tenant tiene su propio gate porque es el riesgo #1. No basta con ejercer el global scope: hay que ejercer RLS, y a propósito los casos que saltan el scope.
Casos con DB::table() crudo, job cross-tenant, ruta central. El caso clave:
query crudo sin contexto → 0 filas (fail-closed), no error 500.
La suite corre no solo local sino contra Laravel Cloud real, con el pooler
transaccional activo, para validar que SET LOCAL sobrevive al pooling.
Ver Multi-tenancy para los cinco casos de
TenantIsolationTest en detalle.
El gate por fase
Cada fase del plan termina en un gate de verificación ejecutable. No se avanza sin pasarlo. Si una fase descubre algo que contradice el diseño aprobado, se detiene y se actualiza el spec antes de seguir: no se improvisa en código.
Guía de verificación manual
Al cerrar cada feature se escribe una guía de verificación manual: los pasos de prueba (ruta, qué hacer, qué esperar) más los edge cases no cubiertos por tests automáticos. Complementa la suite: hay cosas (la UI real en el navegador, el flujo completo con un humano) que un test verde no garantiza. La disciplina es correr y mostrar el output, nunca afirmar de memoria.