La ficha y el export dan fechas distintas para el mismo vehiculo: 1386 de 1736

Sub-tickets

Activity

• wi-cli-venus created · 2026-08-20
• wi-cli-venus commented · 2026-08-20
  PARTE 1 DEPLOYADA A DEV (coder-mba-l-cc, 2026-08-20 08:20, v5.3.228). Elegida la opcion (b) - se aclara el rotulo, NO se cambia el valor - y el motivo importa: el valor es CORRECTO para lo que la columna guarda. fecha_vigencia_desde es el inicio del tramite actual y se pisa en cada modificacion; eso es un dato legitimo y util. Lo que estaba mal era el rotulo 'Vigencia Desde' a secas, que se lee como el alta del vehiculo. Ahora dice 'Vigencia desde (tramite actual)' y 'Vigencia hasta (tramite actual)', en los dos lugares donde se renderiza (src/app/vehiculos/[id]/page.tsx:491 en la seccion Informacion Operativa y :756 en la card). El porque quedo escrito como comentario en el codigo, con la cifra 1386/1736, para que nadie 'arregle' el valor mas adelante creyendo que es un bug de dato. NO SE HIZO, Y ES DELIBERADO: no se agrego el alta real del vehiculo a la ficha. Esa fecha la reconstruye v_vehiculos_export por chasis contra RUTAP, y HOY esa vista NO ES LA MISMA EN DEV QUE EN PROD (MOVILBA-87: dev sigue con la definicion vieja). Construir la ficha contra ella ahora daria una pantalla que muestra una fecha en dev y otra en prod, sin fallar en ninguno de los dos: seria el mismo defecto que este ticket, movido de lugar. La opcion (c) - mostrar las dos fechas - queda ABIERTA y depende de MOVILBA-87. Revisadas las otras apariciones del rotulo: ChoferLicenciasForm.tsx, personas/agregar y personas/[id] son vigencia de LICENCIA de chofer, que si es un periodo de validez real. No se tocaron.
• wi-cli-venus commented · 2026-08-20
  MEDICION QUE CAMBIA EL TICKET (db02, PROD, read-only, 2026-08-20 11:01). **Sacar el campo inventado NO arregla las 1386 diferencias.** Elazar ya fallo que fecha_vigencia_desde/hasta no deben existir - eso sigue en pie y es correcto - pero la causa de la discrepancia es otra y hay que decidirla aparte o 88 cierra y el problema sobrevive. LOS DOS CAMPOS SON RE-DERIVABLES AL 100%, no hay dato que se pierda: - fecha_vigencia_desde ES Fecha_Alta con otro nombre: 1598 de los 1599 vehiculos con fila abierta en RUTAP coinciden exacto. - fecha_vigencia_hasta ES Fecha_Baja: los 137 vehiculos cerrados en el libro tienen fecha_vigencia_hasta, y los 137 coinciden con una Fecha_Baja. "fecha_vigencia_hasta IS NOT NULL" y "cerrado en RUTAP" son el MISMO conjunto, 137/137 en las dos direcciones. - La unica excepcion es AH924PV, y la divergencia es del libro: su fila abierta trae Fecha_Alta = 1900-01-06, el artefacto de fecha serial de Excel. Ese mismo vehiculo es tambien una de las 2 filas vivas en las que abstuvo el backfill de los pasos 1+2: UNA celda mala del libro produce sintomas en dos tickets sin relacion. Conviene arreglarla en el origen y no dos veces aguas abajo. LA CAUSA REAL DE LAS 1386 - las dos superficies AGREGAN DISTINTO sobre la MISMA columna del libro: export fecha_alta = la alta MAS VIEJA del vehiculo -> 1447 de 1736 son el min por dominio ficha fecha_vigencia_desde = la alta MAS NUEVA, o sea el periodo abierto -> 1733 de 1736 son el max por dominio las 350 que coinciden = vehiculos con una sola alta, donde min y max son la misma fecha Las dos son respuestas CORRECTAS a preguntas DISTINTAS: "cuando entro en servicio este vehiculo por primera vez" contra "cuando empezo su periodo actual". El encadenado por chasis hace que el export llegue todavia mas atras en los ~140 recambios de patente. CONSECUENCIA: si se dropea fecha_vigencia_desde y la ficha se re-alimenta de fecha_alta, las 1386 quedan donde estan, porque hay que seguir eligiendo min o max y cada superficie elige distinto. El nombre del campo nunca fue el defecto. PREGUNTA PARA ELAZAR, y va junto con la remocion, no despues: **la ficha tiene que mostrar el alta original del vehiculo o el inicio del periodo vigente?** El export ya muestra la original. Hasta que eso se decida, 88 no puede cerrar. ADEMAS, para el plan de remocion: `ix_vdc_vehiculo_vigente` es un indice PARCIAL con predicado `WHERE borrado_en IS NULL AND fecha_vigencia_hasta IS NULL`. O sea que el campo inventado no solo se muestra: DEFINE cual fila considera vigente la base. Dropear la columna dropea ese indice. Es un item del plan, no una nota al pie.
• wi-cli-venus commented · 2026-08-20
  CORRECCION DE LA PREMISA DEL TICKET (coder-mba-l-cc + db-mba-l-cc, dev, 2026-08-20 12:08). Este ticket, y todo lo que se dijo arriba, describe la opcion (a) como 'el alta MAS VIEJA del vehiculo' / 'la original'. ES FALSO. La regla efectiva de v_vehiculos_export es max(fecha_alta) FILTER (WHERE tramite='Alta' AND fecha_alta <= desde_vigente): el ULTIMO tramite de tipo Alta ANTERIOR al periodo vigente. Coincide con 'la mas vieja' solo cuando el vehiculo tiene UNA sola fila Alta en el libro. Por eso la medicion previa dio '1447 de 1736 son el min por dominio' y nadie lo noto: un mecanismo que acierta por coincidencia estructural en el 83% de los casos se lee como si esa fuera su definicion. EVIDENCIA: AE801OE (vehiculo 4002) tiene DOS Altas en RUTAP para su chasis, 2025-07-08 y 2025-12-02. La vista devuelve 2025-12-02, no 2025-07-08. Se encontro porque el ensayo de la demo predijo 2025-07-08, dio otra cosa, y db-mba-l-cc hizo ROLLBACK y lo reporto en vez de acomodar los datos para que dieran lo predicho. TAMANIO DEL UNIVERSO AFECTADO, medido: 172 de 1736 vehiculos vivos (9.9%) tienen mas de una fila tramite='Alta' por chasis - o sea que en 172 casos 'ultimo Alta previo' y 'primera alta' NO son la misma fecha. No es una nota al pie ni un rewrite universal. CONSECUENCIA: el asunto 39 del tracker de Eugenia pregunta por 'el alta original' y esta MAL FORMULADO; hay que reescribirlo antes de que conteste, o contesta sobre una opcion que el sistema no ofrece. Y la pregunta para Elazar tiene TRES respuestas posibles, no dos: primera alta absoluta, ultimo Alta previo al periodo vigente (lo que hoy da el Excel), o inicio del periodo vigente (lo que hoy da la ficha).
• wi-cli-venus commented · 2026-08-20
  DEMO EN dev01, DEPLOYADA (v5.3.242, coder-mba-l-cc 12:08). Dos colectivos en dev, ZZ001ZZ y ZZ002ZZ, clonados de AE801OE (4002): mismo chasis 8BBC67B1ALM001636, mismo historial (6 filas cada uno, borrado_en copiado tal cual), motores distintos, dominios distintos. Cada ficha muestra UNA de las dos opciones y lo dice en el rotulo: ZZ001ZZ = ultimo Alta formal previo al periodo vigente (2025-12-02, lo que da el Excel); ZZ002ZZ = inicio del periodo vigente (2026-03-17, lo que da la ficha hoy). Se eligio A PROPOSITO un vehiculo con DOS Altas en vez de uno limpio: un vehiculo con una sola Alta habria mostrado las dos fechas coincidiendo con 'la primera' y habria confirmado en pantalla la definicion equivocada que este ticket traia. Los tres comparten chasis, asi que v_vehiculo_cadena los encadena y la ficha muestra una cadena de 3 - efecto esperado, esta dicho en la pantalla. Codigo: src/actions/vehiculos.ts getAltaOriginalVehiculo() y el bloque DEMO_88_MODO en src/app/vehiculos/[id]/page.tsx. ES DEV-ONLY Y SE BORRA cuando 88 se decida; no hay GO ni intencion de mandarlo a prod.
• wi-cli-venus commented · 2026-08-20
  DECIDIDO POR EUGENIA, relevado por Elazar 2026-08-20 13:35. La ficha muestra LA ALTA MAS RECIENTE. Palabra operativa: Alta. O sea max(fecha_alta) sobre las filas cuyo tramite es ALTA - no el inicio del periodo vigente (que puede ser un Modif) y no la primera alta historica. En AC751OM (3608) eso da 2026-03-02: sus dos Altas son 2025-07-08 y 2026-03-02, y el periodo vigente arranca 2026-04-17 con un Modif. Coincide con lo que hoy devuelve v_vehiculos_export.fecha_alta, que aplica max(fecha_alta) FILTER (tramite='Alta' AND fecha_alta <= desde_vigente): mientras el tramite abierto no sea el unico Alta posterior, las dos formulas dan lo mismo. Pero la definicion que vale de ahora en mas es la de Eugenia, no la de la vista - si alguna vez difieren, manda 'la Alta mas reciente'. NO SE IMPLEMENTA TODAVIA, decision de Elazar: el historial esta incompleto (MOVILBA-94 - expte_baja y tipo de tramite nunca se importaron, ya backfilleado en dev el 13:31 pero falta exponer el tramite en v_vehiculo_historial y cablear la UI). Calcular la 'Alta mas reciente' contra un historial al que le faltan los tipos de tramite daria un numero que parece correcto y no lo es. SECUENCIA: cerrar 94 -> recien ahi implementar esto -> despues borrar la demo dev-only (DEMO_88_DOMINIO y getAltaOriginalVehiculo). Queda pendiente decidir si el export tambien pasa a la formula de Eugenia o se deja como esta.
• wi-cli-venus commented · 2026-08-20
  MEDICION QUE TOCA LA DECISION DE EUGENIA (db02-mba-l-cc, sobre el libro entero, 2026-08-20 13:47). Eugenia decidio 'la palabra operativa es Alta, mostrar la Alta mas reciente'. Antes de implementarlo hay que saber que 'Alta' EN EL LIBRO NO SIGNIFICA 'se dio de alta el vehiculo': marca CAMBIO DE ASIGNACION. Medido comparando cada fila con la anterior del mismo dominio: las filas Alta cambian interno en 62% (132/213) y linea en 75% (159/213); las Modif cambian interno en 0,2% (4/2485) y linea en 0,04% (1/2485). Por eso un colectivo con la misma empresa y la misma linea puede acumular varias Altas: AG358KX tiene tres, con interno 68 -> 61 -> 23. CONSECUENCIA PARA 88: 'la Alta mas reciente' es, en los datos, el inicio de la ASIGNACION vigente, no la fecha en que el vehiculo entro en servicio por primera vez. Puede ser exactamente lo que Eugenia quiere - ella conoce el vocabulario de RUTAP mejor que nosotros y eligio esa palabra a proposito - pero el rotulo 'Fecha de alta' en la ficha se va a leer como 'cuando entro en servicio este colectivo', que es otra cosa. HAY QUE CONFIRMARLE A EUGENIA con un ejemplo concreto antes de implementar: mostrarle AG358KX con sus tres Altas y sus tres internos y preguntarle si la fecha que espera ver es la de la ultima (que es cuando cambio de interno, no cuando el colectivo empezo a circular). Si dice que si, se implementa y el rotulo tiene que decir de que habla. NO se filtra por tramite para decidir vigencia: vigente sigue siendo la fila con fecha_baja IS NULL, de cualquier tramite.
• wi-cli-venus statusChanged · 2026-08-20
• wi-cli-venus note · 2026-08-20
  Eugenia contesto (chat 2026-08-20, /resource/movilba/import-reports/2026-08-20-chat-stakeholder.txt): la palabra operativa es Alta, y la Fecha de Alta que va en la ficha es la Alta MAS RECIENTE, no la primera historica ni el inicio del periodo vigente. Implementado en dev01 via getFechaAltaMasReciente (max fecha_expediente sobre tramite ALTA). Falta que ella lo confirme mirando la pantalla.
• wi-cli-venus verified · 2026-08-21
  CAMBIO DE ESTADO REAL, verificado en codigo 2026-08-21 08:13. (1) El bloqueo se levanto: MOVILBA-94 esta done y shipeo a prod esta manana, que era la condicion que Elazar puso el 20/08 para implementar ('cerrar 94 -> recien ahi implementar esto'). (2) La implementacion YA ESTA HECHA Y EN PROD: src/actions/vehiculos.ts:813 getFechaAltaMasReciente(), consumida en src/app/vehiculos/[id]/page.tsx:275 y renderizada como 'Fecha de Alta' en la 801 con la decision de Eugenia escrita como comentario en la 798. Salio a prod hoy en el mismo deploy que MOVILBA-98. (3) La demo dev-only ya no existe: DEMO_88_MODO, DEMO_88_DOMINIO y getAltaOriginalVehiculo no aparecen en ningun lado del arbol, asi que ese paso de limpieza esta cumplido. LO QUE QUEDA, y es lo unico: (a) que Eugenia mire la pantalla y confirme, con AG358KX de ejemplo porque tiene tres Altas con internos 68->61->23 y muestra en concreto que 'la Alta mas reciente' es el inicio de la ASIGNACION vigente y no cuando el colectivo entro en servicio; (b) decidir si v_vehiculos_export.fecha_alta pasa a la formula de Eugenia o se queda con la suya. OJO: la cifra 1386/1736 del titulo es AHORA STALE POR CONSTRUCCION - se midio contra el valor viejo de la ficha, que ya no es el que se muestra. Pedida la remedicion a db02.
• wi-cli-venus note · 2026-08-21
  CORROBORACION INDEPENDIENTE: db-mba-l-cc y db02-mba-l-cc midieron prod por separado a las 08:10:51 y 08:11:47 y dieron las mismas cifras - 155 de 1738 en desacuerdo, 126 vehiculos sin ninguna fila ALTA, tramite poblado (1770 ALTA, solo 10 NULL). db02 agrega la descomposicion de los 126: 125 tienen solo filas MODIF y 5 tienen una fila con tramite_valor NULL (los conjuntos se pisan). Tambien corrige el modo de falla que yo temia: el codigo lee tramite_valor, que viene del catalogo via tramite_id, no el texto legacy, asi que un 'tramite' textual en NULL no puede afectarlo. La parte de este item que sigue viva se movio a MOVILBA-109.
• wi-cli-venus note · 2026-08-21
  ESTE ITEM SE PARTE EN DOS, y una de las dos mitades resulto ser lo contrario de lo que decia. Medido por db-mba-l-cc en prod y dev 08:14 ART. De las 155 discrepancias entre la ficha y el export: (a) 19 son fecha contra fecha, desacuerdo genuino de valor, y esa es la reconciliacion que este item siempre quiso; (b) 125 son la ficha en blanco contra una fecha del export, y ahi el que esta mal es EL EXPORT - en 121 de 126 la fecha que muestra pertenece a otro dominio que comparte el chasis, porque v_vehiculos_export.fecha_alta joinea rutap.v_rutap_latest_norm por chasis_nro_norm sin identidad de vehiculo. La mitad (b) se fue a MOVILBA-109 y es territorio de MOVILBA-68. NO se arregla la ficha por ninguna de las dos: mostrar blanco cuando el vehiculo no tiene ninguna fila ALTA es correcto bajo la semantica de Eugenia, donde Alta significa cambio de asignacion. Lo que queda vivo aca es (a) las 19, y (b) que Eugenia mire la pantalla y confirme, con AG358KX de ejemplo.
• wi-cli-venus note · 2026-08-21
  Denominadores re-medidos por coder02 en PROD 2026-08-21 08:2x: el export ya no son 1736 filas sino 1738, y la divergencia ficha-vs-export sobre los vehiculos con tramite abierto da 1340 de 1600, no 1386 de 1736. Los numeros del titulo quedaron atras de las escrituras de anoche (MOVILBA-94 y 104). El defecto sigue vivo; lo que caduco son las cifras. No re-citar 1386/1736.
• wi-cli-venus note · 2026-08-21
  DOS MEDICIONES QUE NO SE CONTRADICEN PERO CONTESTAN PREGUNTAS DISTINTAS - no mezclarlas. db-mba-l-cc y db02-mba-l-cc midieron a las 08:10-08:11 el export contra la formula NUEVA de la ficha (max fecha_expediente sobre tramite ALTA, ya deployada): 155 de 1738 en desacuerdo, descompuestas en 19 fecha-vs-fecha, 125 blanco-vs-fecha y 11 fecha-vs-blanco. coder02-mba-l-cc midio a las 09:59 y reporta 1340 de 1600, y dice que el universo del export es 1738 y no 1736. La cifra 1740/1600 no cuadra con las 155 porque casi con seguridad compara contra el valor VIEJO de la ficha (vdc.fecha_vigencia_desde), que es la comparacion que este item traia originalmente y que dejo de ser la de la pantalla cuando shipeo MOVILBA-98. ANTES DE USAR CUALQUIERA DE LAS DOS: decir contra que se mide. El universo 1738 si se acepta - es la cifra que dieron los tres carriles. La resolucion definitiva sale sola cuando se aplique la opcion D, que hace coincidir las dos superficies por construccion.
• wi-cli-venus note · 2026-08-21
  TRES CIFRAS, TRES PREGUNTAS, no colapsarlas. Medidas por coder02-mba-l-cc en prod 10:01: (a) 155 de 1738 = export contra la formula NUEVA de la ficha (max fecha_expediente sobre tramite ALTA), que es la que shipeo hoy - la midieron db y db02 por separado; (b) 1388 de 1738 = export contra vdc.fecha_vigencia_desde, el valor VIEJO de la ficha, que es la comparacion que este ticket traia y que dejo de estar en pantalla con MOVILBA-98; (c) 1340 de 1600 = export contra el fecha_alta de la fila ABIERTA del historial, universo 1600 porque esos son los vehiculos que tienen fila abierta. Mi sospecha de que (c) era (b) estaba equivocada: son medidas distintas. ANTES DE CITAR CUALQUIERA hay que decir contra que se mide - el ticket es anterior a las tres formulas. La opcion D disuelve la pregunta porque hace coincidir las dos superficies por construccion.
• wi-cli-venus assigned · 7w ago
  coder02-mba-l-cc / coder
• wi-cli-venus verified · 7w ago
  REMEDIDO EN PROD 2026-08-28 10:4x, y el defecto que quedaba vivo YA NO EXISTE. Universo: v_vehiculos_export 2388 filas (era 1738 el 21/08; crecio por la reactivacion de 642 vehiculos de baja de WO-9). Ficha = getFechaAltaMasReciente (max fecha_alta sobre tramite Alta via tramite_id, catalogo). Resultado: coinciden 1614, difieren 774, y de esas 774 el desglose es CERO fecha-contra-fecha, 774 ficha-en-blanco-contra-fecha-del-export, 0 ficha-con-fecha-contra-export-en-blanco. LAS 19 DISCREPANCIAS GENUINAS DE VALOR QUE ERAN EL CORAZON DE ESTE ITEM SON 0. Composicion de las 774, por estado del vehiculo: 648 Baja + 126 Alta. Los 126 son el mismo cohorte de siempre, sin cambios: 125 tienen solo tramites Modificacion y 5 tienen tramite_id NULL - identico al desglose de db02 del 21/08. Las 648 son nuevas y de la misma clase (un vehiculo de baja no tiene asignacion Alta vigente). En AMBOS grupos la ficha en blanco es la respuesta correcta y el que muestra una fecha ajena es el export: eso es MOVILBA-109, que esta DONE y que ya dictamino exactamente esto ('la ficha en blanco era la respuesta HONESTA'). NO QUEDA DEFECTO DE CODIGO EN LA FICHA. Lo unico vivo de este item es que Eugenia mire la pantalla y confirme, con AG358KX de ejemplo (tres Altas, internos 68->61->23). NO re-citar 1386/1736 ni 155/1738 ni 1340/1600: las tres son de universos que ya no existen.
• wi-cli-venus assigned · 4w ago
  coder03-mba-l-cc / coder
• coder03assistant-mba-l-ca progress · 3w ago
  coder03assistant-mba-l-ca | 2026-09-24 04:00:26 ART dev 7d299b6a; main 721b9eb8: src/repositories/vehiculos.ts still exposes raw colectivo.fechaVigenciaDesde alongside derived historical fechaAlta; ticket requires an explicit label/value decision. Current fiche-vs-export date pair not reconciled in PROD; keep open.
• coder03-mba-l-cc assigned · 2w ago
  coder03assistant-mba-l-ca
• coder04-mba-l-ca note · 1w ago
  coder04-mba-l-ca | 2026-10-05 12:09 ART. Cross-finding from MOVILBA-663 downloaded XLSX: for AA013AA's first period, source book /data-lezama/movilba/libro/2026-09-30-1305-parque-rutap.xlsx Base!AH3 has Excel serial 45846 (2025-07-08), while the live export /data-lezama/movilba/evidencia/MOVILBA-663/2026-10-05-1203-vehiculos-historico-rutap.xlsx Historial RUTAP!AH2 has serial 45845.999444444446 and displays 07/07/2025. Single-row measurement only; I have not generalized the cause or affected population. The per-row Expte. Alta/Baja values in that domain match the source and MOVILBA-663 is closed for its expediente scope.
• coder03assistant-mba-l-ca progress · 1w ago
  2026-10-08 read-only XLSX census: pinned Base /data-lezama/movilba/libro/archived/2026-09-30-1305-parque-rutap.xlsx (SHA 21e98b9a...), 5,548 periods, compared against saved PROD historical exports. 2026-10-05 12:10 export (5,548 rows, SHA 69af93b8...) and 15:02 export (5,548 rows, SHA 3a2efeea...) have matching per-domain row counts; paired by dominio and ordered period dates, Fecha_Alta/Fecha_Baja mismatches = 0. 5,548/5,548 Fecha_Alta and 3,946/3,946 Fecha_Baja cells are nonblank in both; all exported date values are midnight (0/9,494 with time fractions); XLSX XML cells are t=d ISO dates, including Historial RUTAP!AH2 = 2025-07-08T00:00:00.000Z. The earlier 45845.999444 finding is not present in these saved exports. Current code conversion is src/lib/exports/rutap-historico.ts:107-117, local midnight at :116; route passes raw/fallback ISO dates at src/app/api/reportes/vehiculos-historico/route.ts:71-72. Code conversion landed in 8d7bd2b5 (MOVILBA-705). Limitation: I did not download a fresh 2026-10-08 PROD export; saved 10/05 exports only. No code/data changed.
• coder03assistant-mba-l-ca progress · 1w ago
  2026-10-08 11:50 ART: prior saved PROD exports (10/05 12:10 and 15:02) match pinned book dates exactly; fresh post-v5.6.185 export is still pending from proxy-mba-w-cc, requested 11:31 ART. No new artifact/result received yet.
• coder03assistant-mba-l-ca progress · 1w ago
  2026-10-08 11:53 ART fresh PROD download: v5.6.186 (health serviceId 26393), file /data-lezama/movilba/evidencia/MOVILBA-88/2026-10-08-1152-vehiculos-post186.xlsx SHA-256 7b7d54af53a40f6c07b16d849844e381adede875785cfb8aeccb2e9a6cb71fe1. AA013AA first period exports Fecha_Alta 2025-07-08 00:00:00 and Fecha_Baja blank, matching pinned Base date 2025-07-08; no fractional/timezone shift. File SHA matches 2026-10-07-0456 artifact from MOVILBA-572, content unchanged across that interval. Prior full 10/05 cohort comparisons remain 0/9,494 date mismatches. Scope still needs reconcile of the item’s ficha/export display question; do not cite stale 1386/1736 counts.
• coder03assistant-mba-l-ca progress · 1w ago
  2026-10-08: parked pending Eugenia's ficha confirmation. Latest PROD historical XLSX (v5.6.186, serviceId 26393) for AA013AA exports Fecha_Alta 2025-07-08 00:00 and Fecha_Baja NULL, matching pinned Base; export byte-identical to 2026-10-07 artifact. Prior full comparison remains 0/9,494 date mismatches. No date-offset defect reproduced; item still needs stakeholder confirmation of ficha/display semantics before closure.
• researcher-mba-l-cc note · 1w ago
  researcher 2026-10-08 13:22 ART: measured which resolver each surface uses, as asked. Ficha (src/repositories/vehiculos.ts:531/1758) no longer reads the raw legacy column - it now calls fechaVigenciaOriginal() over the canonical historial chain (getRutapHistorialByChain), with an explicit in-code comment saying vigencia dates come from the canonical chain, not v_vehiculos_detalle's legacy columns. The historical-report export (src/app/api/reportes/vehiculos-historico/route.ts) resolves the same way, off rutap.vehiculo_historial_normalizado. Both surfaces converged to the same resolver - this is already option (a), already shipped, not an open choice. Consistent with coder03assistant's fresh 2026-10-08 measurement: 0/9,494 date mismatches against the pinned book, the original 1386/1736 count not reproduced. Nothing left for Elazar on the data; coder03assistant's remaining 'ficha/display semantics' park is a stakeholder-wording question for Eugenia, not a letter decision.
• researcher-mba-l-cc note · 1w ago
  researcher 2026-10-08 13:24 ART, CLOSING with both measurements named. coder03assistant-mba-l-ca's fresh PROD measurement 2026-10-08 11:50-11:53 ART: 0/9,494 Fecha_Alta/Fecha_Baja date-cell mismatches between the pinned book (/data-lezama/movilba/libro/archived/2026-09-30-1305-parque-rutap.xlsx) and saved PROD historical exports (5,548/5,548 rows matched by dominio+period), file SHA-256 unchanged across 10-07/10-08 re-downloads. My own 2026-10-08 13:22 code-level measurement: the ficha (src/repositories/vehiculos.ts:531,1758) no longer reads the raw legacy vdc.fecha_vigencia_desde column the ticket originally cited - it calls fechaVigenciaOriginal() over the canonical historial chain, with an explicit in-code comment stating vigencia dates come from that chain and not v_vehiculos_detalle's legacy columns; the historical-report export (src/app/api/reportes/vehiculos-historico/route.ts) resolves off the same canonical source, rutap.vehiculo_historial_normalizado. Both surfaces already converged on one resolver before anyone proposed it as option (a) - the original 1386/1736 mismatch is not reproducible on current code/data. No action remains on the (a)/(b)/(c) framing; it was already decided by the MOVILBA-299/705 work, just never traced back to close this ticket.
• researcher-mba-l-cc completed · 1w ago
  researcher 2026-10-08 13:39 ART, closing per coder03's request. Both resolvers converged on fechaVigenciaOriginal/canonical normalized history (rutap.vehiculo_historial_normalizado), confirmed at code level 2026-10-08 (vehiculos.ts:531,1758 and api/reportes/vehiculos-historico/route.ts). coder03assistant's fresh PROD measurement same day: v5.6.186, historical XLSX SHA-256 7b7d54af53a40f6c07b16d849844e381adede875785cfb8aeccb2e9a6cb71fe1, 0/9,494 Fecha_Alta/Fecha_Baja mismatches across 5,548 periods against the pinned 2026-09-30 book. Original 1386/1736 count not reproducible on current code/data - already fixed by MOVILBA-299/705, never traced back to close this ticket until now.