movilba
MOVILBA-278
Filas de prueba vivas en DEV que solo el libro delata: ZZ001ZZ y ZZ002ZZ llevan el chasis de un colectivo real y salen en su cadena
Done high
dmdb02-mba-l-cc
MEDIDO por db02-mba-l-cc el 2026-09-05 en DEV (270, 276) y por coder02 en el codigo. Es la forma que aparecio en dos items distintos el mismo dia. HAY FILAS DE PRUEBA VIVAS EN DEV Y NADA EN LA TABLA LAS DISTINGUE DE LAS REALES. Las conocidas hasta ahora: ZZ001ZZ (6067) y ZZ002ZZ (6068), que llevan el numero de chasis 8BBC67B1ALM001636 de un colectivo REAL, AE801OE (4002); y DHU474, cuya fila VIVA tiene numero_serie_chasis 'ASDASD55A55'. Ninguno de esos dominios existe en rutap.v_rutap_latest. LA UNICA FORMA DE RECONOCERLAS ES PREGUNTARLE AL LIBRO. No hay columna, ni flag, ni patron de nombre confiable - 'ZZ' lo es por casualidad, 'DHU474' no lo es. Es la misma carencia que MOVILBA-224 describe para la procedencia: la tabla no contesta sola una pregunta que hay que hacerle todo el tiempo. CONSECUENCIA CONCRETA Y DE CARA AL USUARIO, medida en el codigo por coder02: getVehiculoCadena (src/actions/vehiculos.ts:162) lee v_vehiculo_cadena, que agrupa por numero_serie_chasis y devuelve TODOS los eslabones. Esta bien disenada - una cadena de re-patentadas debe traer todos - pero por eso mismo la ficha de AE801OE muestra a ZZ001ZZ y ZZ002ZZ como eslabones de su cadena, o sea un colectivo real que figura re-patentado a dos dominios de prueba. No hace falta ningun defecto extra: la vista hace lo correcto sobre datos sucios. QUE HACE FALTA: (1) barrer la CLASE, no estos tres - cuantas filas vivas de vehiculos tienen un dominio que el libro vigente no trae, en DEV y en PROD por separado; (2) decidir que se hace con ellas, y no es un borrado por defecto - 'baja' es un estado, nunca una eliminacion, y el criterio de vivo es estado_id, no borrado_en; (3) si se retiran, el estado previo se vuelca antes, a /data-lezama. OJO: 'el libro no lo trae' NO alcanza como prueba de que una fila es de prueba. Un dato ausente del libro se importa igual (regla permanente); lo que hace sospechosas a estas tres es el CONTENIDO - 'ASDASD55A55', 'ZZ001ZZ' - mas la ausencia. Las dos condiciones juntas, nunca la ausencia sola. NO EJERCITADO: no se barrio la clase; PROD no medido para esto; no se miro numero_serie_motor, que puede tener la misma forma.
Activity
-
db02 2026-09-05, LA CLASE BARRIDA EN LOS DOS ENTORNOS. Todo SELECT. CRITERIO Y SU LIMITE, primero, porque es lo que hace util el numero: ausencia del libro NO es evidencia de que una fila sea de prueba - una fila que el libro no trae se importa igual, es regla permanente, y usar la ausencia como criterio de borrado sacaria vehiculos reales. Se midio la ausencia SOLA para ver el tamano de la poblacion, y despues se miro el CONTENIDO de cada una. El tamano es lo que salva al criterio aca. DEV: 2412 filas vivas de vehiculos, 5 cuyo dominio el libro vigente (snapshot 11, 5388 filas / 2407 dominios) NO trae. Las cinco, con su contenido: - 6623 AA111EE, chasis 'ASDASF09', motor 'MM9QAS50076', anio 2010, creada 2026-09-03 - 6621 DHU474, chasis 'ASDASD55A55', motor 'AS5D558A5D5', anio 2026, creada 2026-08-31 - 6061 PAN219, chasis '213213', motor '10082026', sin anio, creada 2026-08-10 - 6067 ZZ001ZZ, chasis '8BBC67B1ALM001636', motor '36672420-ZZ001ZZ', anio 2021, creada 2026-08-20 - 6068 ZZ002ZZ, chasis '8BBC67B1ALM001636', motor '36672420-ZZ002ZZ', anio 2021, creada 2026-08-20 LAS CINCO CUMPLEN LAS DOS CONDICIONES, no solo la ausencia: 'ASDASF09', 'ASDASD55A55', '213213', y un numero de motor que lleva el dominio de test adentro ('36672420-ZZ001ZZ'). Ninguna es un vehiculo real que el libro se haya olvidado. Y el tamano de la poblacion es la prueba de que el criterio no esta mal: si la ausencia sola hubiera devuelto decenas, habria significado que el criterio es malo; devolvio 5 y las 5 son basura por contenido. PROD: 2388 filas vivas, CERO ausentes del libro. El libro en PROD es el mismo snapshot 11 (5388 filas / 2407 dominios). No es un cero de un instrumento vacio: si la vista estuviera vacia el NOT EXISTS habria devuelto las 2388. Las filas de prueba son EXCLUSIVAMENTE de DEV. DANO CONCRETO, que es lo que faltaba: ZZ001ZZ y ZZ002ZZ llevan el numero de chasis de un colectivo REAL (8BBC67B1ALM001636, que es el de AE801OE y el libro se lo confirma en 6 filas). getVehiculoCadena agrupa por numero_serie_chasis y devuelve todos los eslabones a proposito, asi que la ficha de AE801OE dibuja una cadena de repatentamiento hacia dos dominios de test. La vista hace lo correcto sobre datos sucios. DHU474 ademas es una de las dos filas de las que cuelga la deuda de rendiciones.deudas_dominios en DEV (MOVILBA-270, MOVILBA-272). NO ES UN BORRADO Y NO PIDO GO PARA UNO. Se reporta la poblacion; la disposicion es de Elazar. Lo que si es evidente es que la tabla no puede contestar sola "esta fila es de prueba": hizo falta el libro MAS el contenido. Esa es la misma forma de MOVILBA-224. NO EJERCITADO: no se miro creado_por ni audit_log para ver quien las creo; no se busco la misma forma en entidades, lineas ni validadoras; no se midio numero_serie_motor como clase (puede tener la forma de MOVILBA-276); no se toco nada.
-
db02-mba-l-cc 2026-09-08 00:52 ART, SELECT only, DEV re-measured against the CURRENT book (snapshot 12, 5388 rows / 2407 dominios) and PROD (snapshot 11). DEV: 2416 live vehiculos, 9 absent from the book (was 5 on 09-05 against snapshot 11): the known five - 6061 PAN219 (chassis '213213'), 6067 ZZ001ZZ and 6068 ZZ002ZZ (chassis 8BBC67B1ALM001636 = AE801OE's, created by 'demo-movilba-88' 08-20, 9 and 6 legacy history rows, 0 normalizado rows), 6621 DHU474 ('ASDASD55A55'), 6623 AA111EE ('ASDASF09') - plus four from 2026-09-07: 6720 ZZ999XX, 6721 ZZ998YY, 6722 ZZ997WW (TESTCHASIS-/TESTMOTOR-<dominio>, ficha 117, created by a coder test account; 331/336/337 evidence rows, 6720 explicitly NOT to be repaired) and 6723 FB444EP (created 15:39 by the proxy lane's user account via the create path, realistic 17-char chassis 8BBC59B1ARM006598, 4 app history rows, tonight's 338 test subject). FB444EP shows the limit of the content criterion: absent from the book AND realistic content; only the creator/context says test. Chassis-length sweep (live, length <> 17): 8 on DEV = the 6 test rows above plus AG986KF (16 chars) and KYN233 (16 chars) which ARE in the book - book data to report to Eugenia, not test rows; PROD has the same 2 and 0 book-absent vehicles - test rows remain DEV-only. numero_serie_motor sweep (zz|asd|test|prueba): only the 4 ZZ rows. rendiciones.deudas_dominios: 0 for all nine (DHU474's deuda from 270/272 is gone). Audit trail: 6061/6621/6623 CREATE+UPDATE by human accounts (08-10, 08-31, 09-03); 6067/6068 have no CREATE in audit_log (script 'demo-movilba-88'), only 281/287 verification UPDATEs. PROPOSAL, no write, Elazar decides: (1) retire the 8 fixture rows (6061, 6067, 6068, 6621, 6623, 6720, 6721, 6722) from DEV in ONE script after dumping vehiculos + vehiculos_datos_colectivos + both history tables for them to /data-lezama; retirement = borrado_en (they are fixtures, not business bajas - 'baja es un estado' applies to real vehicles); 6720/6721/6722 only after 331/336/337 close, they are evidence. (2) FB444EP: ask proxy-mba-w-cc whether it is a test create; if yes it joins the list, if no it is a real vehicle missing from the book and goes to Eugenia. (3) AG986KF/KYN233: 16-char chassis in the book itself, both environments - a book contradiction to REPORT, never to edit. (4) Class-level: DEV needs a fixture marker the table can answer (e.g. creado_por prefix convention 'demo-'/'fixture-' + a DEV-only check that test dominios never reach a chain view); PROD needs nothing today. NOT exercised: entidades/lineas/validadoras fixtures; the legacy public.vehiculo_historial rows of the 5 older fixtures were counted, not read.
-
proxy-mba-w-cc 2026-09-08 00:50: FB444EP (6723) is a test vehicle it created on DEV via /vehiculos/agregar/colectivo on 09-07 ~15:39 (chassis typed to look realistic, not sourced). Joins the fixture list: 9 of 9 book-absent live vehicles on DEV are fixtures. Hold: it is the 338 app-born specimen - retire only after 338's follow-ups close (audit closed 338 tonight but coder02's do-not-clean hold on ZZ997WW/ZZ998YY/ZZ999XX stands), dump-first either way. Disposition of all 9 remains Elazar's call; no write.
-
db03-mba-l-cc, 2026-09-18, ejecutado bajo carril db02, SELECT only, DEV+PROD por separado. Criterio: estado_id resuelve ALTA (nunca borrado_en) Y dominio ausente del snapshot vigente del libro, mas flag de contenido (prefijo ZZ, tokens test/prueba/demo/fixture/asd, serial numerico corto, o el propio dominio incrustado en su chasis/motor). PROD: 0 filas vivas ausentes del libro. DEV: 17 filas vivas ausentes del libro (ids 6725-6747, creadas 09-08 a 09-14) - mas grandes y MAS NUEVAS que las 9 del evento 09-08; ninguno de esos ids viejos (6061/6067/6068/6621/6623/6720-23) aparece en esta pasada. 10 de 17 con flag de contenido; hallazgo notable: FGG123/DHU474/EG111AA comparten el MISMO chasis 'ASDASD55A55' (reuso TRIPLE, no doble como ZZ001ZZ/ZZ002ZZ). numero_serie_motor revisado en la misma pasada (item sin ejercitar del ticket) - sin hits adicionales mas alla de lo que el chasis ya marco. ABIERTO: creado_por mezcla un id repetido no-CUIT (4 filas, 09-08) con varios ids con forma de CUIT distintos entre 09-08 y 09-14 - no es un lote de fixture de un solo script obvio como el hallazgo anterior; db03 recomienda confirmar con coder antes de asumir que son de prueba. Evidencia: /data-lezama/movilba/evidencia/MOVILBA-278/2026-09-18-278-dev-book-absent-live.csv + sweep-notes.md. Ninguna escritura.
-
coder03-mba-l-cc, 2026-09-18, lectura del lado app: NO GO para retirar. Las 17 NO son filas sinteticas de seed. Las 17 tienen origen='app' en rutap.vehiculo_historial_normalizado, normalizado_por='app-create-colectivo' seguido de eventos 'app-editar-colectivo' con texto libre en castellano escrito a mano ('se modifica numero de interno a pedido de la empresa', etc) en intervalos irregulares - no es la forma de un script de seed. creado_por resuelto contra public.users: 4 filas (6725-6728) las creo una cuenta QA sintetica ('QA Editor DEV', 09-08) pero luego fueron editadas por personal real; las otras 13 las crearon cuentas reales @buenosaires.gob.ar, INCLUIDA Eugenia Grosclaude (creo 6745 PR149II y 6747 JM111NA). O sea 13 vehiculos vivos cargados por personal real via la app que el libro no trae - es una DISCREPANCIA libro-vs-app, exactamente lo que este proyecto mide, no un candidato de limpieza. Va a Eugenia como hecho+pregunta via el tracker xlsx, nunca como tarea o veredicto - responsabilidad de coder03, no de db02. El chasis compartido 'ASDASD55A55' (FGG123/DHU474/EG111AA) SI es basura: las tres las creo la misma cuenta (Ricci) y 6734 tiene observaciones='PRUEBA' literal - es un dato de prueba mal tipeado, no una colision de identidad de flota como ZZ001ZZ/ZZ002ZZ; no juntar los dos casos. TICKET SIGUE EN BACKLOG. Nada retirado, nada escrito.
-
Elazar, CLI directo, 2026-09-18: correccion sobre la lectura de coder03. Textual: 'anything entered in dev is junk. only ssot is excel file snapshot we import into movilba. App is not live, when it is live, only data that we need to protect is in prod.' Las 13 filas cargadas por personal real de GCABA en DEV NO son una discrepancia libro-vs-app a reportarle a Eugenia - quien las cargo y que tan genuino se vea el texto no cambia nada, porque DEV no es el lado que cuenta hasta el go-live. Segunda correccion, mismo turno: 'we dont need to delete data from dev either, that is why dev is there' - tampoco se borran. Conclusion final: NO REPORTAR a Eugenia, NO BORRAR, no requiere accion de nadie. TICKET CERRADO por esta razon, no por falta de hallazgo.
-
Cerrado por regla de Elazar 2026-09-18: nada en DEV es discrepancia a reportar ni candidato de limpieza hasta el go-live.
bug
5w ago by wi-cli-venus
4w ago
2026-09-18 07:01