Backlog de correcciones

Bajo. El guard solo bloquea usuarios ya marcados inactivos; no afecta el path de usuarios activos ni la creación de sesión. Cuidar únicamente: (1) que no exista ningún flujo legítimo que dependa de que un inactivo obtenga token (no lo hay en este handler); (2) actualizar/añadir tests unitarios del handler para el caso Active=false (hoy no cubierto, por eso pasó a E2E); (3) confirmar el status code del mapeo si UX espera 401.

Bug de BACK confirmado por lectura de código, no comportamiento intencional: la infraestructura para rechazarlo (propiedad Active + error InactiveCredentials) ya está construida pero desconectada, lo que indica un chequeo olvidado, no una decisión. Existe además un Errors.User.UserInactive (Errors.User.cs:86) como alternativa, pero InactiveCredentials es el correcto por dominio (Authentication) y por estar ya localizado. La validación no puede delegarse a LDAP porque Active es estado a nivel aplicación, no del directorio. VERIFICADO EN QA (2026-07-13, post-deploy): FV (sonda API): login de «test» (Active=0) → 400 «Inactive Credentials»; F01 re-corrido OK, 0 hallazgos.

Bajo. Los dos únicos consumidores del front usan HttpClient con Bearer, así que restaurar auth no rompe el flujo de la UI. Antes de mergear, confirmar que no exista un consumidor anónimo legítimo fuera del front (deep-links en emails de notificación, webhooks de SharePoint, o el visor PDF cargando la URL directo en un iframe/img sin headers) — no se detectó ninguno en el repo front, pero conviene validarlo en QA. La autorización sigue sin verificar que el archivo pertenezca al claim del usuario (IDOR entre usuarios autenticados); eso es una mejora aparte, no bloquea este fix.

No es comportamiento intencional: el comentario en LocalFileRepositoryProvider.cs:242 reconoce explícitamente que "decodificar no es, por sí solo, una frontera de seguridad" porque el endpoint es [AllowAnonymous] — el hardening anti-traversal existente asume justamente que el endpoint queda expuesto. La opacidad del id (base64url en dev, drive-item en prod) reduce la probabilidad de adivinación pero es seguridad por oscuridad, no un control de acceso. El endpoint hermano [HttpPost("upload")] sí está protegido con [Authorize(Roles="Analyst,Supervisor")], reforzando que el AllowAnonymous del GET es una inconsistencia, no una decisión de diseño. VERIFICADO EN QA (2026-07-13, post-deploy): FV (sonda API): GET /File/{path} sin token → 401; sonda defensiva de F10 en verde.

La corrección de datos es de bajo riesgo pero cuidar: el analista debe quedar vinculado SOLO al/los banco(s) que corresponda (la relación Banks segrega la asignación por banco); no vincular un analista de prueba a bancos que no debe operar. Para el hardening de código: es puramente defensivo (mueve el fallo de excepción a DomainError controlado) y no cambia el happy-path, pero conviene alinear el mensaje/tipo de error con lo que el front espera mostrar.

El mensaje reportado en el hallazgo ("No hay usuarios disponibles para asignar Claims") es literal de RoundRobinAssigner.cs:42, lo que confirma la cadena. No es comportamiento intencional deseable: la validación de línea 222-227 fue escrita con la intención de cubrir el caso "sin analistas", pero es inefectiva porque compara contra null cuando EF devuelve lista vacía. Severidad alto correcta: bloquea por completo la carga de siniestros de cualquier banco que quede sin analista activo vinculado (no solo Ecofuturo). Recomiendo además una verificación de datos preventiva en QA/PROD para todos los bancos activos: cada banco operativo debe tener >=1 analista activo vinculado. VERIFICADO EN QA (2026-07-13, post-deploy): Verificado en sesión previa: tras vincular analista activo a Ecofuturo, el ciclo FB-ECO corrió completo (Excel→cierre).

Bajo el fix en sí (semántica estándar de igualdad). OJO: código que hoy dependa accidentalmente de la semántica rota (p.ej. una rama `if (x != null)` que nunca corre) puede cambiar de comportamiento al arreglarse — correr la suite completa.

No proviene de un flujo E2E sino del TDD del fix H16 (PR #83). Evidencia con tablas de verdad adjunta al WI #1271 (hijo del Feature #1268). FIX (2026-07-13): PR #85 back MERGEADO — Entity.== con ReferenceEquals (null==null true) y ValueObject.!= como negación exacta del ==; 15 tests de tabla de verdad; regresión completa 311 unit + 219 functional en verde. WI #1271 Resolved. VERIFICADO EN QA (2026-07-13, post-deploy): FV (sonda API): POST group-claims con ULID inexistente → 400 «Claims not found» (error de dominio, ya no 500/NPE).

Bajo. Cambio puramente aditivo de visibilidad UI, idéntico al patrón ya usado por los tres lápices hermanos; no afecta otros roles (Analyst sigue viéndolo porque roleActual !== 'Medical'). Nota de defensa en profundidad: este guard es solo UI; conviene confirmar que el endpoint que respalda EditarAnalistaComponent también rechace el rol Medical en el backend, ya que un lápiz oculto no impide invocar la API directamente.

editarAnalista() (caso-page.component.ts:261) abre EditarAnalistaComponent con {id, claimNumber, responsibleId}. roleActual se setea en l.538 vía authService.getRole(). El bug es una inconsistencia de guard, no comportamiento intencional: los tres lápices análogos evidencian que Medical NO debe editar estos campos. Podría reclasificarse como 'seguridad' si el back no valida el rol, pero como hallazgo de front es una fuga de acción no autorizada en la UI. FIX (2026-07-13): PR #86 front MERGEADO — *ngIf de rol en el lápiz de analista responsable; back ya rechazaba a Medical en /assign-responsible. Validado E2E (auditor.medico1 sin lápiz / analista.extra4 con lápiz, capturas en el WI). WI #1256 Resolved. VERIFICADO EN QA (2026-07-13, post-deploy): F06: auditor.medico1 ya no ve ningún lápiz de edición en caso-page (la sonda condicional no disparó).

bajo. Es un cambio de nombre de propiedad puramente en el front; no toca backend ni contrato. Cuidar solo que `claimNumber` esté efectivamente presente en la respuesta (confirmado en el DTO) y que si se habilitara strictTemplates el HTML ya usa `claimNumber`/`siseNumber` que hoy no están en la interface — conviene actualizar la interface igual para evitar warnings futuros.

El bug afecta a los TRES toasts del médico, no solo al de informe médico. El hallazgo lo reportó como campo "casenumber", pero el nombre real en el JSON es `claimNumber` (camelCase). No es comportamiento intencional: es un desalineamiento interface-vs-contrato que TypeScript no detecta porque la interface está mal tipada. Severidad medio: es cosmético (no rompe el flujo funcional, la acción se ejecuta bien), pero degrada la confianza del usuario al mostrar "undefined". FIX (2026-07-13): PR #87 front MERGEADO — element.claimNumber en handleAction ×3 + interface Case alineada al contrato (claimNumber+siseNumber). WI #1257 Resolved. VERIFICADO EN QA (2026-07-13, post-deploy): F06: el toast de informe médico dice «…para el caso 1062» — número real, no «undefined».

Bajo. Usar `this.dataSource.data = ...` es el patrón canónico de Angular Material y además preserva el `filterPredicate` seteado en applyFilter(), que con la reasignación actual también se perdía en cada recarga. Verificar que ningún otro lugar dependa de recibir una instancia nueva de dataSource (no lo hay en este componente). Si se opta por la alternativa de reasignar `.paginator`, hacerlo antes de que Angular corra el change detection para evitar ExpressionChangedAfterItHasBeenChecked.

Hallazgo real y reproducible, pero la causa NO es "falta [length]" sino la reasignación de la instancia de dataSource que desconecta el paginador. El array ELEMENT_DATA hardcodeado (líneas 293-318) es data muerta no usada. La severidad reportada era "bajo"; la subo a "medio" porque la paginación queda totalmente inoperante (no recorta filas) y el contador es incorrecto, no es solo cosmético. AMPLIACIÓN (2026-07-13, comentario en el WI #1258): el mismo defecto está replicado en 8 componentes más (casos-en-pronunciamiento :198/:298, casos-en-proceso :317/:277, casos-en-gestion-medica :240/:388, casos-en-aceptacion-del-tomador :68/:128, casos-en-tesoreria :103/:197, agrupados-en-tesoreria :88/:225, casos-por-cerrar :92/:162, tesorery-home-page :56/:154). Patrón correcto de referencia: casos-por-gestionar.component.ts:326-329. Corregir los 9 en el mismo PR. FIX (2026-07-13): PR #84 front MERGEADO — rebind de dataSource.paginator tras las 11 reasignaciones en los 9 componentes; 5 specs de regresión; validado E2E contra QA (bandejas con total real). WI #1258 Resolved. VERIFICADO EN QA (2026-07-13, post-deploy): Sonda UI: paginator de «En proceso» muestra «1 - 2 de 2» — total real tras el rebind del dataSource.

Bajo/acotado. El armado de actions es local a este handler (ClaimRepoListRequestHandler), no compartido: no impacta otras vistas (caso-page, gestión, etc. arman sus acciones por otro lado). Antes de implementar conviene CONFIRMAR con negocio la regla exacta: (a) ¿bloquear ambas acciones o sólo Reassign? Reasignar un caso cerrado casi nunca tiene sentido; Eliminar podría querer conservarse para corrección administrativa. (b) Verificar que no exista un requisito de "reabrir/corregir" cerrados que dependa de estas acciones. Además, si se quiere defensa en profundidad, evaluar validar el estado también en ReassignCommandHandler y en el handler de Delete, ya que ocultar el botón no impide un POST directo.

Podría argumentarse comportamiento intencional (supervisor con poder total), pero la evidencia del código contradice eso: el handler YA calcula la `condition` cerrada por caso y no la aplica a las acciones, lo que delata que el gating por estado se omitió, no que se decidió permitirlo. El front no filtra nada (confía 100% en actions[] del back), así que la corrección DEBE ir en el back; tocar sólo el front dejaría la puerta abierta vía API. No existe un estado plano "Closed" en ClaimStatusEnum: los cerrados son ClosedApproved y ClosedRejected (Desgravamen.Shared/Enums/ClaimStatusEnum.cs:93,98). FIX (2026-07-13): PR #88 back MERGEADO a develop (pipeline 2604 verde: build, unit, integration, smoke y functional) — acciones por caso en ClaimRepoListRequestHandler: view siempre, reassign/delete solo supervisor con caso abierto; 5 unit tests. WI #1259 Resolved. VERIFICADO EN QA (2026-07-13, post-deploy): FV (sonda API): GET /Claims/Repository como supervisora — todos los casos cerrados exponen únicamente actions=[view].

Bajo si el fix es targeteado (SpecifyKind solo en la proyección de comentarios). NO aplicar un ValueConverter global DateTime->Utc en EF ni un converter global de JSON sin auditar: hay fechas que ya son UTC (DateTimeProvider hace ToUniversalTime) y forzar Kind global podría doble-corregir. El front-only con offset '-0400' sobre un string SIN 'Z' no corrige nada (el parseo naive ya salió mal); requiere primero normalizar a UTC. La misma clase de bug aplica a los comentarios de tesorería (ViewCommentsCommandHandler / ClaimTreasuryCommentDto, mismo patrón CreationDate UTC sin 'Z'): si se arregla acá, alinear allá para no dejar dos criterios distintos.

Bug real, no comportamiento intencional: no hay config de timezone deliberada, es el default de System.Text.Json chocando con Kind=Unspecified de EF y el parseo local del pipe. Severidad medio confirmada: correctness de display (engaña al analista sobre CUÁNDO se dejó un comentario, 4h de desfase) sin corrupción de datos. El hallazgo lo tipeó como "front"; el pipe sin timezone es el punto visible pero la causa raíz es back (timestamp UTC enviado sin marca de zona), por eso lo clasifico back. Fix de menor blast-radius: SpecifyKind(Utc) en el DTO. Bolivia no tiene horario de verano, UTC-4 es fijo, sin preocupación por DST. FIX (2026-07-13): PR #89 back MERGEADO a develop (pipeline 2606 verde: build, unit, integration, smoke y functional) — DateTime.SpecifyKind(Utc) en las proyecciones de comentarios (caso y tesorería); 2 unit tests. WI #1260 Resolved. VERIFICADO EN QA (2026-07-13, post-deploy): FV (sonda API): date de comments llega «2026-07-13T16:57:42…Z» — UTC con marca de zona; el front ya convierte a hora local.

Bajo. Es puramente presentacional (no toca la decisión de guardar ni el backend). Cuidar: (1) truncar/limitar la lista si hay muchos campos para no romper el layout del toast; (2) respetar el criterio OR existente (allValid || allvalidAtributes) al decidir qué marcar como faltante, para que el mensaje no contradiga el gate real; (3) usar displayName con fallback a name porque algunos atributos podrían no tener displayName.

No es comportamiento intencional: la genericidad viene de que mostrarMensaje() no recibe parámetros, no de una decisión de diseño. Severidad medio es adecuada: no bloquea la operación pero degrada UX y alarga el ciclo de corrección del analista (prueba y error). Existe mostrarMensajeError(text) (1280-1284) que ya acepta texto — se puede reutilizar ese patrón en vez de crear otro método. checkAllDocumentsValid no guardea contra arreglo vacío (el comentario 'Retorna false si el arreglo está vacío' miente: every([]) === true), pero eso no afecta este bug. FIX (2026-07-13): PR #90 front MERGEADO — detalleFaltantes() agrupa por documento los atributos sin validar y el toast nombra qué falta; 2 tests. WI #1261 Resolved. VERIFICADO EN QA (2026-07-13, post-deploy): F02: al aprobar con la Hoja de Riesgo incompleta el toast nombró documento y campos exactos («Complete o verifique: PaymentRisk: InterestRate, LastPaymentDate, …»).

Bajo. Solo agrega una validación previa y un toast; no altera el camino feliz. Cuidar de no romper el else existente que ya mostraba error cuando falta fileName (mantener ese mensaje). Es un fix puramente de front, sin impacto en back ni en otros flujos.

Hallazgos colaterales detectados al verificar (fuera del alcance de H14, pero conviene registrarlos): (1) BUG LATENTE de MIME: downloadBase64File (508-535), que es el helper usado para descargar documentos, arma el Blob con type 'application/vnd.openxmlformats-officedocument.spreadsheetml.sheet' (XLSX), mientras que existe un downloadBase64File2 (476-505) con MIME 'application/pdf' que NO se usa (código muerto). Los documentos del caso son PDFs, así que la descarga real puede salir con MIME incorrecto. (2) El anchor link no se hace document.body.appendChild antes del click ni se libera con URL.revokeObjectURL — funciona en Chrome pero es frágil. El scope de ambiente (archivos no restaurados en QA que producen base64 vacío) es correcto: el defecto de front es la falta de validación+feedback, y está confirmado en código. VERIFICADO EN QA (2026-07-13, post-deploy): Repro dirigida: con base64 completo la descarga se concreta (informe médico, 684 KB); el camino de base64 vacío queda cubierto por el guard + toast (specs del PR #91).

Medio-bajo. Validación aditiva; confirmar que el front solo agrupa desde la bandeja Pronunciamiento (no hay flujo legítimo agrupando desde otros estados).

CAUSA DEL 400 CONFIRMADA (2026-07-13, repro API): el cliente E2E enviaba {description, comments} en vez del campo requerido 'considerations' → validación de model binding rechazaba la carta; statement-rejected caía en cascada (RejectedLetterNotFound). Corregido ciclo_api → carta 200 (PDF), rechazo 200, el caso aparece en state/Statement como StatementRejected y el badge cuenta bien. El bug de este WI (group-claims sin validación) es INDEPENDIENTE y quedó re-reproducido en la misma repro (caso 1297: InProcess → agrupado → Close sin pronunciamiento). Colateral: el runner E2E ahora vuelca los 4xx de ciclo_api como hallazgos y fuerza estado CON HALLAZGOS. FIX EN CURSO (2026-07-13): PR #83 (fix/1270-group-claims-state-validation) con validación en dos pasadas + 6 unit tests + 1 functional test negativo. PR #83 MERGEADO a develop con merge commit (pipeline 2596 verde); WI #1270 Resolved. Validación final en develop consolidado: build Release + 324 unit + 220 functional, 0 fallos. VERIFICADO EN QA (2026-07-13, post-deploy): FV (sonda API): POST group-claims con caso InProcess → 400 «…is not in Statement state…cannot be grouped…»; el caso no muta.

Antes de borrar: (1) verificar con `rg "routerLink|navigate.*(crm|ecommerce-page|settings|internal-error|not-found)"` en `src/app` que ninguna pantalla LBC enlace a esas rutas; (2) `internal-error`/`not-found` podrían usarse por un interceptor/handler de errores que navegue a `/#/internal-error` — si es así, conservar SOLO esas dos rutas (con o sin guard según el caso) y borrar el resto; (3) borrar la ruta NO borra el componente: los componentes UI compartidos que las pantallas LBC importan directamente (no vía router) no se ven afectados. Recompilar y correr el smoke de Playwright del login tras el cambio.

Severidad real BAJA, no media: son pantallas demo con data hardcodeada del template, no exponen siniestros ni datos reales del negocio (no hay fuga de PII/claims). El impacto es higiene/superficie de ataque y peso de bundle en prod (código muerto eager-loaded), más que una vulnerabilidad de datos. NO es comportamiento intencional: es residuo del scaffolding daxa que nunca se limpió. Detalle a favor de que es bug y no feature: la ruta `''` está duplicada (218 y 313), señal clara de merge sin limpieza. Tratarlo como deuda técnica/limpieza de release más que como hotfix de seguridad. FIX (2026-07-13): PR #92 front MERGEADO — bloque legacy daxa eliminado (437 líneas, 173 imports muertos); authentication/my-profile/settings conservadas (las dos últimas con privateGuard); spec de higiene de rutas nuevo. WI #1263 Resolved. VERIFICADO EN QA (2026-07-13, post-deploy): F10: /#/crm → página 404 (bloque legacy eliminado del router); /#/ecommerce-page redirige al login. Sin pantallas demo accesibles.

Bajo. Cambio de texto puro en un solo template, sin impacto en lógica ni en el backend. Único cuidado: `number` viene tipado como `any` y podría llegar `undefined` si algún caller abre el dialog sin pasarlo; el único caller actual (medical-home-page) sí lo pasa, así que en la práctica no aplica. Opcionalmente usar `{{ data.number || '' }}` para blindar el caso vacío.

Hay un segundo ComentarioComponent en pages/caso-page/comentario/ que NO tiene este texto ni recibe `data` (constructor sin MAT_DIALOG_DATA) — no confundir. El afectado es exclusivamente el de medical-home-page. Además de la coma suelta, la oración original es gramaticalmente rara aun con el número; al corregir conviene eliminar la coma. Verificable también con Playwright disparando la acción y aserción sobre el texto del h2. FIX (2026-07-13): PR #93 front MERGEADO — interpolación de {{ data.number }} en la confirmación de devolver caso. WI #1264 Resolved. VERIFICADO EN QA (2026-07-13, post-deploy): F06: la confirmación de devolver caso interpola el número (la sonda de la coma suelta no disparó).

Bajo. Cambio puramente de presentación en un único binding. Solo cuidar de mantener coherencia entre las tres apariciones de hora del componente (elegir 12h `hh:mm a` en las tres, o 24h `HH:mm` en las tres) para no dejar mezcla de formatos. El espaciado "p. m." (con espacios) viene del locale es y es correcto, no tocarlo.

La misma línea concatena `'dd/MM/yyyy' + " "` como truco para el separador — funciona (el `+ " "` es concatenación de string sobre el argumento del pipe), no requiere cambio. Las otras dos horas del file (líneas 46 y 83, línea de tiempo de estados) ya usan el patrón correcto `hh:mm a`, lo que confirma que el `HH...a` de la línea 104 es un descuido aislado. Defecto cosmético, no bloqueante. FIX (2026-07-13): PR #94 front MERGEADO — patrón 'hh:mm a' en la columna Fecha y Hora del historial; spec nuevo. WI #1265 Resolved. VERIFICADO EN QA (2026-07-13, post-deploy): Sonda UI: columna Fecha y Hora del historial en 12h con meridiano («05:21 p. m.»), sin mezcla 24h+a.m./p.m.

Bajo. Es aditivo sobre el happy-path; el botón ya se auto-deshabilita tras el clic ([disabled]="!isEnabled", isEnabled=false en saveAnalysisCases ts:1319) evitando doble submit, y no se toca backend. Cuidar: (1) ubicar la confirmación DESPUÉS de la validación (dentro del if de allValid en ts:1261), NO envolviendo verificarDocumento() completo, para no confirmar antes de que corran las validaciones ni sobre un estado inválido; (2) al cancelar, dejar el botón habilitado (no setear isEnabled=false hasta confirmar); (3) reutilizar MatDialog ya presente en la app (no agregar SweetAlert ni confirm() nativo, romperían consistencia visual).

Podría argumentarse que "Aprobar" es la CTA principal/feliz de la pantalla y por eso se omitió el confirm intencionalmente; aun así la inconsistencia con el resto del sistema es real y la acción cambia la etapa del caso. Severidad reportada (bajo) es adecuada: no hay pérdida de datos silenciosa ni riesgo de seguridad, solo posibilidad de avanzar el caso por clic accidental. Verificado que no hay MatDialog/confirm/SweetAlert en el flujo de gestion-page para esta acción (la única confirmación relacionada en el proyecto vive en shared/dialogs/* y páginas de home-page/tesoreria/medical, no en gestion-page). FIX (2026-07-13): PR #95 front MERGEADO — ConfirmacionComponent compartido nuevo + confirmación tras validar en verificarDocumento(); 6 tests. WI #1266 Resolved. VERIFICADO EN QA (2026-07-13, post-deploy): F02: capturado el diálogo «¿Confirma que desea aprobar y enviar el caso a la etapa En Proceso?» (Cancelar/Aceptar) tras validar; al aceptar ejecuta la transición.

bajo. Es solo un string de UI. Ojo: la ruta /repositorio-page es compartida por Analyst, default y Supervisor; si en vez del label se cambia el título de la pantalla (Opción B), impacta la vista de TODOS los roles, no solo Supervisor. El array de links está triplicado en checkLinks() (code smell aparte): si se estandariza el nombre, verificar que no haya otros lugares que muestren el label.

No es un bug funcional: la navegación funciona y la ruta es correcta; es puramente nomenclatura/UX. Podría ser intencional (renombrar el menú por rol) pero al chocar con el título hardcodeado genera disonancia. Decisión de producto sobre el término canónico ("Repositorio" vs "Gestión de casos"). El título del <h2> no es i18n (ngx-translate) sino texto plano hardcodeado, coherente con el resto de la pantalla. FIX (2026-07-13): PR #96 front MERGEADO — label del Supervisor unificado a «Repositorio»; test de consistencia por rol. WI #1267 Resolved. VERIFICADO EN QA (2026-07-13, post-deploy): F09: el sidebar del Supervisor dice «Repositorio», consistente con el título de la pantalla; flujo en verde con el label nuevo.