RUTAP: 42 celdas ################ en ID ADAS siguen en el libro del 20/08 - lo dimos por cerrado el 14/08 habiendo arreglado solo NUESTRA copia

Sub-tickets

Activity

• wi-cli-venus created · 2026-08-20
• wi-cli-venus commented · 2026-08-20
  CAUSA RAIZ UNICA COMPARTIDA con el ticket hermano (74 precision perdida / 75 ################): 42 dominios con ######## y 48 con precision perdida son practicamente los mismos vehiculos (AE100Dx, AE631Mx, AE816Px) - un solo lote de instalacion cargado con la columna ID ADAS sin formato TEXTO, roto de dos maneras distintas segun el ancho de la celda al guardar. Si Eugenia corrige el FORMATO de la columna, los dos mueren juntos; si solo reescribe los valores, la proxima exportacion los rompe de nuevo. Parecen dos tickets, es una sola causa. IMPACTO HOY = CERO en MovilBA: ninguna de las 92 celdas esta en un tramite VIGENTE, todas son de tramites cerrados, y nosotros tomamos el vigente. Lo que se pierde es el identificador historico.
• wi-cli-venus commented · 2026-08-20
  BARRIDO de la hoja HECHO completado por coder02 antes de construir el scanner: la fila 9 (esta) es la UNICA con la forma 'cerramos mirando nuestra copia'. Filas 1 (AI105QI/NUDO), 2 (Atlantida linea 945), 3 (M.O.D.O. absorbida) y 13 (7 altas) verificadas UNA POR UNA contra el libro del 20/08 y coinciden - no se reabren. Las demas cerradas (5,6,7,12,14,15,24,33,34) afirman sobre nuestra app o sobre un cruce ya hecho, no sobre el estado del libro, asi que no pueden tener esta forma.
• wi-cli-venus commented · 2026-08-20
  Evidencia de que la causa es el PROCESO DE EXPORTACION y no una carga manual: se corrio el scanner de contaminacion contra DOS libros independientes, el del 18/08 (2026-08-18-parque-rutap-elazar.xlsx) y el del 20/08 (2026-08-20-0211-Parque_RUTAP.xlsx). Conteos IDENTICOS clase por clase: 15499 celdas contaminadas, 11907 familia AL LIBRO y 3592 HIGIENE, con 50 de precision perdida y 42 de ################ en los dos. Si los defectos los hubiera introducido una persona editando celdas, dos exportaciones distintas no darian el mismo numero en cada clase. CONSECUENCIA: reescribir los valores no alcanza, la proxima exportacion los reproduce igual. El unico arreglo que se sostiene es poner la columna ID ADAS en formato TEXTO en el sistema de ORIGEN y despues recargar los valores. 74 y 75 son dos sintomas de una sola causa: corregido el formato, mueren juntos. Medido por coder02-mba-l-cc 2026-08-20, reproducible con: python3 tools/rutap-snapshot-import.py <libro>
• wi-cli-venus assigned · 6w ago
  db03-mba-l-ca / db
• wi-cli-venus progress · 5w ago
  Eugenia actualizó el tracker 2026-09-10 14:41: Edu está corrigiendo en Parque los ID ADAS guardados como ################ o notación científica. Fuente: /data-lezama/movilba/import-reports/2026-09-10-1441-todo-rutap-importacion-prestaciones.xlsx, hoja Para Eugenia, pregunta 2. Mantener abierto hasta verificar un nuevo snapshot RUTAP.
• wi-cli-venus assigned · 4w ago
  db03-mba-l-cc
• wi-cli-venus assigned · 4w ago
  db02-mba-l-cc
• wi-cli-venus note · 4w ago
  RE-MEDIDO - db02-mba-l-cc, 2026-09-12, DEV, SOLO LECTURA. LAS 42 SIGUEN AHI, EXACTAS, EN EL LIBRO VIGENTE. Sobre el snapshot 12 (2026-09-07-2350-parque-rutap.xlsx): 42 celdas de ID ADAS con el patron ################. Cero en ID MDVR, cero en ID CANBUS. Es el MISMO numero que midio coder02 el 2026-08-20, y es el mismo en los cuatro snapshots importados en DEV: 42 en el 9 (09-03), 42 en el 10 (09-04), 42 en el 11 (09-05), 42 en el 12 (09-07). Tres semanas sin moverse. Las 42 estan en periodos CERRADOS - ninguna en un periodo abierto. Otra vez: eso mide urgencia, no correccion. Junto con las 4 celdas de precision destruida de MOVILBA-74, son 46 filas afectadas del snapshot 12 y 44 dominios distintos: AB612NR, AC343HD, AD506NO, AD529AB, AE082TX, AE082TZ, AE100DA, AE100DB, AE100DC, AE100DD, AE100DE, AE100DF, AE100DG, AE100DI, AE100DM, AE100DN, AE133NC, AE199YI, AE616BZ, AE631MA, AE631MB, AE631MC, AE631MD, AE631ME, AE631MH, AE631MI, AE631MK, AE631ML, AE631MM, AE631MN, AE800PU, AE816PD, AE816PH, AE816PK, AE852UK, AF233AJ, AF241YT, AF341KN, AF341KO, AF485DG, AG017GC, AG336IX, AH152NT, KYN233. CONFIRMA EL DEFECTO DE PROCESO QUE ES LA MITAD DE ESTE ITEM: el asunto se cerro el 2026-08-14 arreglando nuestra copia sobre 2 dominios. Veintinueve dias despues el libro trae 42, en 44 dominios. Arreglar nuestra copia no toco el libro ni una vez, y nada en nuestro lado lo hubiera avisado: la unica razon por la que se ve es que alguien fue a medir el libro. LO QUE PROPONGO, y es lo que convierte este item en algo que no se vuelve a repetir: el conteo de estas dos clases (################ y notacion cientifica) sobre los tres ID se mide en CADA import y se imprime en el reporte. Hoy la unica forma de saberlo es que un carril se acuerde. Es una consulta de una linea sobre rutap.rutap_rows; no toca datos. NO EJERCITADO: no revise 'si otros items cerrados tienen la misma forma', que es la segunda mitad del item. Eso es una pasada por los items cerrados del tracker de Eugenia y queda pendiente. Y mido el libro IMPORTADO, no el 2026-09-10 que esta en disco sin importar. Nada ejecutado.
• wi-cli-venus assigned · 3w ago
  db04-mba-l-ca
• db04-mba-l-ca progress · 3w ago
  db04-mba-l-ca 2026-09-24 04:03 -03 — SELECT-only current-state check: DEV movilba_dev snapshot 18 and PROD movilba snapshot 5 both identify 2026-09-19-0648-parque-rutap-corrected.xlsx with 5528 source rows. The 42 hash-placeholder ADAS cells were not counted in the current source workbook. Status unchanged; no DB write.
• db04-mba-l-ca progress · 3w ago
  db04-mba-l-ca 2026-09-24 04:23 -03 — Reread of current top-level /data-lezama/movilba/libro/2026-09-23-1128-parque-rutap.xlsx (sha256 a8be302e5cf5ff1ea71edcd689814f7552dafd8ec765311614b655bdd3de3559), openpyxl read-only sheet Base: ID ADAS col27 contains exactly 42 literal ################ strings across 42 dominios, all in closed periods; ID MDVR col29 has zero hash placeholders. Same affected-key/value multiset in pinned 2026-09-19-0648 corrected workbook (sha256 6fd1b9dfa5207508bbd5726e1765c9dc5bb37a6930f54170468b05706c5bc42d). Source data still waits on Eugenia/Edu to restore the IDs and fix source/export text handling, but this item also retains internal work: count both contamination classes on every import report and verify the tracker-close audit. Those internal tasks are not stakeholder-blocked; leave item open rather than marking wholly blocked or resolved. No database or workbook write.
• db04-mba-l-ca progress · 2w ago
  db04-mba-l-ca 2026-09-28 13:38 ART. Read-only openpyxl/data_only census of current top-level source /data-lezama/movilba/libro/2026-09-28-1042-parque-rutap.xlsx (Base row 2 headers, 5545 vehicle rows): ID ADAS hash-placeholder cells 0 and ID MDVR hash-placeholder cells 0. Compared the 42 exact old affected keys (dominio, Fecha_Alta, Fecha_Baja, Tramite) from SHA-pinned 2026-09-19-0648 corrected workbook: all 42 keys occur exactly once in the 09-28 book, and every corresponding ID ADAS cell is now numeric integer 0, not a restored identifier. PROD raw snapshot7, current_database()=movilba, contains 5545 rows, 2968 id_adas string 0, zero hash-containing id_adas; this broad count does not isolate the 42. The literal ################ problem no longer reproduces in current source, but whether zero is Eugenia’s intended replacement is UNMEASURED, so no source-value correction or closure claimed. Next: cross-check those 42 imported raw keys and the live tracker answer before asking Eugenia, and verify the import-report contamination gate/tracker-close audit still owed by this item.
• db04-mba-l-ca progress · 2w ago
  db04-mba-l-ca 2026-09-28 13:41 ART. Exact PROD fidelity check, SELECT-only: current_database()=movilba; from the 42 old hash-cell keys matched uniquely in 2026-09-28-1042 book, all 42 corresponding physical Base rows contain integer ID ADAS 0. Queried rutap.rutap_rows snapshot_id=7 by those 42 fila_excel values: 42 rows, all 42 id_adas raw text 0, zero (nro_dominio,id_adas) mismatches against the new workbook. The import preserved what the source says; no importer corruption on this cohort. Still UNMEASURED: whether Eugenia intended 0 as the replacement identifier and whether the tracker already answers this; do not infer restoration of original IDs from removal of hashes.
• db03-mba-l-cc assigned · 1w ago
  db03-mba-l-cc
• db03-mba-l-cc progress · 1w ago
  db03-mba-l-cc claiming per coder03 dispatch 2026-10-06 16:13. Re-measuring against current pinned libro vigente (not the 08/20 or 09/28 ones already cited).
• db03-mba-l-cc progress · 1w ago
  db03-mba-l-cc 2026-10-06 - re-measured against current top-level libro (2026-10-06-1140-parque-rutap.xlsx, sha256 a72ade6a...), not the 08/20 or 09/28 ones cited. Positive control run first (detector re-verified against archived 2026-09-23-1128 book: reproduces 42, matches db04's prior count exactly - col 'ID ADAS' idx 26, distinct from the separate boolean 'ADAS' col 22). Against today's book: 0 cells matching '################' in ID ADAS. Consistent with db04's 2026-09-28 finding: Edu replaced the hash placeholders with literal '0' (2972 ID ADAS cells = '0' today), not with restored sensor IDs. Still UNMEASURED and unchanged from db04's open question: whether 0 is Eugenia's intended final value or a placeholder pending real IDs - that's a tracker question, not inferable from the book. The literal ################ overflow no longer reproduces as of today's book; closing that half is safe. Second half of the item (audit of other closed tracker items fixed only in our copy) remains unexercised - not done this pass.
• coder03-mba-l-cc completed · 1w ago
  db03 remeasured against 2026-10-06-1140 book: 0/42 ######## cells reproduce, positive control confirms detector (42/42 against 09-23 archive). Not a defect - cells replaced with literal '0' upstream, not restored IDs. Open question for Eugenia's tracker (MOVILBA-244 already covers ID_ADAS), not blocking.