La ficha YA muestra el historial pre-handoff: nada filtra borrado_en en el camino de usuario
HALLAZGO QUE INVALIDA LA PREMISA DEL BLOQUEO DE MOVILBA-169. Medido por coder02-mba-l-cc contra PROD 2026-08-31, SELECT. db03-mba-l-ca y coder-mba-l-ca bloquearon el des-escondido (169 parte 1.1) porque "expondria en el historial de usuario los cambios pre-handoff del Excel que el stakeholder rechazo". YA ESTAN EXPUESTOS. El bloqueo protege algo que no esta protegido. CADENA COMPLETA, VERIFICADA PASO POR PASO: 1. v_vehiculo_historial - la vista que lee la ficha - NO filtra vehiculo_historial.borrado_en. Su unico filtro de borrado es sobre el JOIN a vehiculos: "JOIN vehiculos v ON vh.vehiculo_id = v.id AND v.borrado_en IS NULL". Filtra vehiculos borrados, no FILAS DE HISTORIAL borradas. 2. La vista devuelve 4225 filas, o sea el 100% de vehiculo_historial, incluidas las 2485 con borrado_en. 3. Peor: la vista TRATA borrado_en COMO FIN DE PERIODO a proposito. Expone la columna y calcula "periodo_hasta = COALESCE(vh.fecha_baja, vh.borrado_en::date)". O sea que el modelo defectuoso que encontro db02 no esta solo en el dato, esta escrito adentro de la vista de usuario. 4. La action getVehiculoHistorial (src/actions/vehiculos.ts:245) lee esa vista y no agrega filtro de borrado. 5. Ni el componente ni el helper filtran: grep de borradoEn en ExpedienteForm.tsx, en la ficha y en src/lib/historial-vehiculo.ts no devuelve ningun filtro. EVIDENCIA DIRECTA, filas que un usuario ve hoy en la ficha: AE922FX 7 filas, 6 de ellas borradas AE971FF 7 filas, 6 borradas AF041MJ 6 filas, 5 borradas AH561CW 6 filas, 5 borradas CONSECUENCIAS, en orden de importancia: A. EL CONTRATO DE HANDOFF YA ESTA INCUMPLIDO HOY, sin que nadie toque nada. "Historial de usuario en cero al handoff" no se sostiene: la ficha muestra la historia completa del libro. Esto es independiente de 169 y no lo causa ningun cambio propuesto. B. El bloqueo de 1.1 sobre esa base no se sostiene TAL COMO ESTA REDACTADO. Des-esconder no cambiaria NADA de lo que el usuario ve en la tarjeta de historial, porque ya ve todo. Lo unico que cambia es que fila elige v_vehiculos_hist_ultimo, y eso esta medido: 3 vehiculos de 1740, linea 0, entidad 0. C. 1.1b (filtrar lo pre-handoff en la vista de usuario) pasa a ser URGENTE POR SI MISMO, y deja de ser el candado de 1.1a. Hace falta para cumplir el contrato de handoff, exista o no el des-escondido. RELACION CON LA OTRA MEDICION: 4224 de 4225 filas las escribio un importador o una migracion; una sola vino de la app. O sea que una vista de usuario correcta al handoff mostraria UNA fila en toda la flota. El corte se puede hacer por creado_en anterior al timestamp del handoff, sin columna de provenance nueva y sin depender de MOVILBA-125. DECISION QUE FALTA Y ES DE ELAZAR: la ficha muestra periodos pre-handoff o el libro RUTAP es el unico lugar donde un usuario los lee. Hoy la app contesta que si los muestra, y nadie lo decidio - salio del defecto, no de un diseño. NO PROPONE ESCRITURAS. Es lectura y trazado de codigo.
Activity
-
parent=#3172
-
DECIDIDO por Elazar 2026-09-02, opcion (a): la tarjeta de historial de la ficha NO muestra nada hasta que el vehiculo tenga un cambio hecho DENTRO de MovilBA. La historia importada del libro deja de verse en el camino de usuario. Esto cierra la pregunta abierta desde el 08-31 y confirma el contrato de handoff: historial de usuario en CERO al arrancar. QUE HAY QUE CAMBIAR (medido el 08-31 contra PROD): - v_vehiculo_historial hoy devuelve 4225 filas, el 100% de vehiculo_historial, incluidas las 2485 con borrado_en. No filtra nada por el camino de usuario. - La vista ademas trata borrado_en como fin de periodo: periodo_hasta = COALESCE(vh.fecha_baja, vh.borrado_en::date). O sea que el modelo viejo esta escrito adentro de la vista que consume la ficha. - getVehiculoHistorial (src/actions/vehiculos.ts:245) lee esa vista sin filtro adicional; ni el componente ni src/lib/historial-vehiculo.ts filtran. EL CRITERIO TIENE QUE SER 'ORIGEN', NO 'FECHA': un filtro por fecha de corte deja pasar cualquier fila importada cuya fecha de negocio caiga despues del corte, y las fechas del libro llegan hasta 2026. Lo que distingue las filas es QUIEN las escribio: import contra usuario de la app. creado_por sirve para eso, pero OJO - no es vocabulario controlado (system_import, import-rutap-2026-08-14-prod, import-2026-06-29, import-2026-08-05, ids desnudos '37' y '16'), asi que el predicado se arma sobre el conjunto de valores de import realmente presentes, verificado contra la base, no adivinado. NO se borra ni se esconde nada en la base: es un filtro del camino de USUARIO. El historial completo sigue existiendo y sigue disponible para reportes y auditoria. Ver MOVILBA-169 (des-esconder borrado_en) y MOVILBA-178 (la tarjeta ademas solo detecta 4 campos).
-
Decidido (a) por Elazar el 2026-09-02. Listo para implementar.
-
RESPUESTA, sin necesidad de la pantalla (2026-09-04, coder02 + coder-mba-l-ca, solo lectura). **SI: la ficha muestra periodos previos al handoff, en el 82% de los vehiculos de PROD.** Camino trazado por coder-mba-l-ca: `ExpedienteForm(readOnly)` -> `getVehiculoHistorial` -> `v_vehiculo_historial`. El componente renderiza TODAS las filas que recibe y la vista NO filtra `vh.borrado_en`. Con eso la pregunta se vuelve aritmetica. MEDIDO, los dos entornos: - PROD: **2485 filas** de periodo cerrado devueltas por la vista, sobre **1435 de 1740** vehiculos. Peor ficha: 6 filas cerradas. - DEV: 2573 filas sobre 1508 de 1821. Peor ficha: 6. Una captura de pantalla confirmaria el mismo hecho de a un vehiculo por vez; **el denominador es lo que lo convierte en hallazgo**. LO QUE QUEDA ABIERTO Y ES OTRA PREGUNTA: como se VEN esas filas. `periodo_hasta = COALESCE(vh.fecha_baja, vh.borrado_en::date)`, asi que un periodo cerrado sin `fecha_baja` muestra **la marca de soft-delete como si fuera fecha de negocio** - una columna de auditoria renderizada como hecho de negocio, que es regla dura del proyecto (reference_audit_columns_are_not_business_dates). Si el usuario ve una fecha plausible-pero-falsa o un blanco evidente no se puede derivar del codigo: hace falta una sesion autenticada en dev01. Va con MOVILBA-231; una credencial destraba las dos. NO EJERCITADO: ninguna pantalla se abrio. La afirmacion es sobre lo que la vista DEVUELVE y lo que el componente hace con lo que recibe, no sobre pixeles.
-
LA CADENA DE CODIGO DE ESTE ITEM ESTA VENCIDA DESDE EL CUTOVER DE MOVILBA-204 (09-03). Re-medido por coder02 el 2026-09-05 contra dev/dev y DEV. LO QUE YA NO APLICA, punto por punto de la descripcion: - Pasos 1 a 5 describian `v_vehiculo_historial` -> `getVehiculoHistorial` -> ficha. Hoy `getVehiculoHistorial` (src/actions/vehiculos.ts:207) llama a `getRutapHistorialByChain` en la linea 228, o sea la tabla ANCHA `rutap.vehiculo_historial_normalizado`, y NO la vista. - Con eso, todo el hallazgo de `borrado_en` queda MUDO para la ficha: la tabla ancha no tiene columna `borrado_en`. No hay filtro faltante porque no hay nada que filtrar. - Los cuatro dominios de evidencia (AE922FX, AE971FF, AF041MJ, AH561CW, "6 de 7 filas borradas") ya no describen lo que la ficha lee. Esas cifras son de `public.vehiculo_historial`, que la ficha dejo de consultar. - `v_vehiculo_historial` SIGUE viva pero para otra cosa: `getFechaAltaMasReciente` (:768) la usa para UNA fecha (MOVILBA-88/109), no para la tarjeta de historial. El defecto de la vista - exponer `borrado_en` como fin de periodo y ordenar por `creado_en` - es MOVILBA-225, que ya existe y es donde vive. LO QUE SIGUE SIENDO CIERTO, y por un mecanismo distinto: LA FICHA MUESTRA LA HISTORIA COMPLETA DEL LIBRO. No por un filtro olvidado sino por diseño de 204 - la tarjeta es el espejo del libro RUTAP, una fila por linea del Excel, para toda la cadena de chasis. Medido en DEV, snapshot vigente: 5370 filas sobre 2406 vehiculos, altas desde 2025-06-19 hasta 2026-09-03, y 5064 de las 5370 tienen `fecha_alta` anterior al 2026-08-01. O sea que lo que la ficha muestra es abrumadoramente pre-handoff, y ahora es intencional. ASI QUE LA CONSECUENCIA A SE MANTIENE Y LAS OTRAS DOS CAMBIAN DE DUEÑO: - A) El contrato "historial de usuario en cero al handoff" sigue incumplido hoy. Cambio el porque: antes era un filtro ausente, ahora es la decision de 204 de mostrar el libro. - B) El bloqueo de 169 parte 1.1 ya no se puede argumentar desde esta cadena EN NINGUNA DIRECCION: des-esconder filas de `vehiculo_historial` no toca lo que la ficha lee, porque la ficha no lee esa tabla. - C) "Filtrar lo pre-handoff en la vista de usuario" dejo de ser un cambio de vista. Si se quiere, el corte va en el lector de la tabla ancha, y el criterio ya no puede ser `creado_en` - la tabla ancha es un espejo de snapshot, no un ledger, y no tiene fecha de escritura de negocio. Seria por `fecha_alta`. LA DECISION SIGUE SIENDO DE ELAZAR Y AHORA ES MAS NITIDA: la ficha muestra periodos pre-handoff, o el libro RUTAP es el unico lugar donde un usuario los lee. La diferencia con el 08-31 es que hoy eso NO salio de un defecto: salio de MOVILBA-204, que se shipeo a proposito. Si la respuesta es que si los muestra, este item se cierra sin codigo. Si es que no, es un item nuevo contra el lector de la tabla ancha, no contra una vista. NO EJERCITADO: no abri la ficha. Esto es lectura de codigo sobre `dev/dev` mas conteos en DEV; no verifique en pantalla que las 5370 filas se rendericen, solo que el camino que las trae es el de la tabla ancha.
-
Resolved by the adopted SSOT rule: MovilBA displays the RUTAP snapshot as-is, including pre-handoff history. Since MOVILBA-204 intentionally reads the normalized snapshot and no longer uses borrado_en for this card, no code change remains.