Verificación de correcciones post-deploy
Sondas API que confirman, contra el ambiente QA ya actualizado, que cada fix de backend de los hallazgos E2E está activo: login de usuarios inactivos, protección del servidor de archivos, acciones de casos cerrados, zona horaria de comentarios, validación de estado al agrupar y semántica de null en el dominio.
📁 Evidencias
Este flujo no descargó archivos. Sus 7 capturas están en la carpeta FV-verificacion-fixes/; hacé clic en cualquiera para ampliarla.
✅ Sin hallazgos
El flujo se completó sin errores de consola, sin respuestas HTTP con error y sin comportamientos anómalos.
Sesiones de prueba abiertas
Se loguean por API el analista (analista.extra4) y la supervisora (reina.santi). Ambos 200: las credenciales activas siguen entrando con normalidad tras el fix de H01.
H01 — El usuario dado de baja ya NO puede iniciar sesión
POST login con «test» (Active=0 en la tabla User) → HTTP 400. El backend responde «Inactive Credentials»: el guard sobre User.Active del WI #1253 está activo. Antes de este fix el usuario inactivo recibía token y sesión.
H02 — El servidor de archivos exige sesión
GET /v1/app/File/{path} SIN token → HTTP 401. El endpoint quedó bajo [Authorize] (WI #1254): sin token no entrega documentos. Antes respondía 200 con el binario en base64.
H08 — Los casos cerrados ya no ofrecen Reasignar/Eliminar
GET /Claims/Repository como supervisora → 1081 casos, 1014 cerrados (ClosedApproved/ClosedRejected). Los 1014 casos cerrados exponen solo ['view']: el gating por estado del WI #1259 está activo.
H09 — Las fechas de comentarios viajan en UTC con la marca 'Z'
Se agrega un comentario al caso 01K487AZ78JMEBWB2E5RA6AP0E y se relee: el campo date llega como «2026-07-13T16:57:42.2276703Z». El sufijo 'Z' indica que el backend serializa la fecha como UTC (DateTime.SpecifyKind del WI #1260): el pipe date del front ya puede convertirla a la hora local de Bolivia (UTC-4) sin el desfase de +4h.
H16 — Un caso sin pronunciamiento ya NO se puede agrupar
POST group-claims con el caso 01K487AZ78JMEBWB2E5RA6AP0E (etapa En Proceso, sin pronunciamiento) → HTTP 400. El backend lo rechaza con «…is not in Statement state…cannot be grouped for policyholder acceptance» (WI #1270): se cerró el camino por el que un caso sin pronunciarse llegaba a cerrarse como ClosedRejected.
H17 — Un ID inexistente devuelve error de dominio, no 500
POST group-claims con un ULID que no existe → HTTP 400 («{"type":"https://tools.ietf.org/html/rfc9110#section-15.5.1","title":"Bad Reques…»). Antes del fix de Entity.== (WI #1271) el guard «claim == null» no atajaba y el handler reventaba con NullReferenceException (HTTP 500). El 4xx confirma la semántica de igualdad corregida.