movilba
MOVILBA-338
Ninguna fila de historial escrita por la app llevo nunca cuit ni las demas columnas de negocio; las de import las llevan todas
Done urgent
cmcoder02-mba-l-cc
Lo vio primero proxy-mba-w-cc el 2026-09-07 23:02 en el panel de historial de AA033TK, y **yo lo descarte como artefacto de display**. Era real. Verificado despues por coder02-mba-l-cc leyendo el codigo, y no es lo mismo que MOVILBA-331. QUE PASA: 1. `rutap.vehiculo_historial_normalizado` es la tabla ANCHA de MOVILBA-299: ~110 columnas, entre ellas `cuit`, `identificador_empresa`, `tipo_servicio`, `linea_numero`, `interno`, `anio_modelo`, `asientos`, `consumo`, `chasis_marca`, `chasis_modelo`, `numero_serie_chasis`, `carroceria_*`, `motor_fabricante`, `numero_serie_motor`, `tipo_motor`, `aire_acondicionado_id`, `piso_id`, y todas las de equipamiento. 2. El insert del periodo sucesor en la edicion (`src/repositories/vehiculos.ts:1120-1134`) escribe **DOCE**: `vehiculoId, dominio, entidadId, lineaId, estadoId, tramiteId, expteAlta, fechaAlta, observaciones, creadoPor, origen, normalizadoPor`. 3. Todas las demas quedan **NULL en la fila**. No es un default, no es un arrastre: no se escriben. CONSECUENCIA: cada edicion hecha por la pantalla agrega un periodo que dice que el vehiculo NO TIENE CUIT, ni asientos, ni numero de chasis, ni motor, ni tipo de servicio. La FICHA conserva la verdad -medido: `vehiculos_datos_colectivos` de 6719 quedo intacto- pero el HISTORIAL, que es el registro por el que nos juzgan como custodios y es lo que Eugenia tiene en su libro, guarda un vehiculo que perdio su identidad en la fecha de la edicion. MEDIDO EN PANTALLA (proxy, AA033TK, mismo page load, dos periodos): - Periodo de alta 04/09 (fila 75742, origen import): "CUIT: Primer valor: 30-54623141-7", "Asientos: Primer valor: 25", "Tipo de servicio: Primer valor: SP". - Periodo sucesor 07/09 (fila 80590, origen app): "CUIT: De: 30-54623141-7 A: (vacio)", "Asientos: De: 25 A: (vacio)", "Tipo de servicio: De: SP A: (vacio)". La diferencia esta en LOS DATOS, no en el renderizado: el panel diffea `SELECT h.*` entre periodos consecutivos (`repositories/rutap-historial.ts:90`, via `lib/historial-vehiculo.ts` y `ExpedienteForm`), asi que una columna que la fila no trae ES un cambio a vacio. POR QUE ME EQUIVOQUE, y va escrito para que no se repita: argumente "artefacto de display" desde "la fila sucesora tiene solo 12 columnas". El dato era CIERTO y la conclusion al reves - que la fila tenga 12 columnas pobladas de 110 es exactamente la causa del vacio, no la prueba de que el vacio sea imaginario. Ademas nunca verifique QUE lee el panel; lo asumi, igual que audit-mba-l-cc asumio que leia `cambios` y que yo asumi que leia `audit_log`. Tres carriles opinando sobre un artefacto que ninguno habia abierto. NO CONFUNDIR: - MOVILBA-331: el sucesor nacia sin `estado_id`. ARREGLADO y verificado. - MOVILBA-335: el sucesor no deberia existir si solo cambio una nota. - ESTE: el sucesor, exista o no, nace sin las ~27 columnas de negocio. QUE HAY QUE DECIDIR ANTES DE ESCRIBIR: 1. De donde sale el valor de cada columna al abrir un periodo. Candidato natural: arrastrar del periodo que se cierra, que es lo que ya se hizo para entidad/linea/estado. NO inventar: si el libro RUTAP tiene el dato por periodo, sale de ahi. 2. Que hacer con las columnas `raw_*`: son la evidencia del import y probablemente NO deben copiarse a un periodo escrito por la app, porque no hubo libro. 3. Enumerar la lista COMPLETA contra `pg_attribute`, no contra `drizzle/schema.ts`, y decidir columna por columna cual arrastra, cual queda NULL a proposito y por que. CONTROL POSITIVO: una edicion sobre un vehiculo con periodo previo poblado, comprobando que el sucesor conserva cuit/asientos/chasis. Hoy falla de forma demostrable sobre la fila 80590, asi que no puede pasar en vacio. ALCANCE MEDIDO: afecta a todo periodo `origen='app'`. La cifra de cuantos hay se re-deriva; lo permanente es la INVARIANTE - el escritor de la app pobla 12 de ~110 columnas.
Activity
-
2026-09-07 23:09 - MEDIDO, y la invariante es mas limpia que cualquier conteo. db02-mba-l-cc sobre DEV; audit-mba-l-cc confirmo el lado del codigo en origin/dev independientemente. LA TABLA TIENE **109 COLUMNAS**. Sobre el vehiculo 6719: la fila 75742 (origen import) tiene **93 pobladas**; la fila 80590 (origen app, la que escribio la edicion de esta noche) tiene **17** - las 12 del insert mas id, creado_en y las columnas que la tabla llena sola. En 80590 estan en NULL: cuit, asientos, interno, tipo_servicio, numero_serie_chasis, motor_fabricante, anio_modelo, chasis_marca y **linea_numero**. Ese ultimo es el detalle feo: la fila lleva linea_id 134 y NO lleva el numero 109. **Sobrevive el id y se pierde el valor legible** - la misma division id/etiqueta que ya nos costo una ronda hoy, aterrizando donde hace daño de verdad. POBLACION, categorica y sin excepciones: - origen='app': **11 filas sobre 6 vehiculos, cuit NULL en 11 de 11**. - origen='import': 16126 filas sobre 2407 vehiculos, cuit POBLADO en 16126 de 16126. INVARIANTE PARA EL ITEM (no el conteo): **el escritor de edicion de la app pobla 12 de 109 columnas, y todo periodo que abrio esta en NULL en las 97 restantes.** El conteo de filas es el falsificador del estado de hoy, no el criterio. HALLAZGO DE AUDIT QUE CAMBIA LA FORMA DEL ARREGLO: **no hay nada para arrastrar, porque el SELECT tambien es angosto.** en selecciona CINCO columnas - id, fechaAlta, entidadId, lineaId, y estadoId desde 59a48dce. Un escritor que quisiera copiar cuit/asientos/chasis del periodo que cierra no tiene el valor en la mano. **Es exactamente la forma de MOVILBA-331 -'el arrastre no estaba roto, el valor no estaba disponible'- multiplicada por 97 columnas.** 331 era UNA instancia de esta clase; la clase es la fila entera. Y ACUMULA: cada edicion cierra un periodo poblado y abre uno pobre, asi que el periodo MAS RECIENTE -el que elige cualquier resolver de 'actual'- es el mas vacio. Una segunda edicion copia NULL desde un predecesor NULL. No se repara solo. POR QUE 315 NO ALCANZA: el resolver con COALESCE que verifique lee entidad/linea por las dos ramas y NO rescata las otras ~90 columnas, ni pretendia hacerlo. v_vehiculos_hist_ultimo esta bien; la historia ancha no.
-
2026-09-07 23:11 - ARREGLO DE UNA LINEA MUTILADA EN EL EVENTO ANTERIOR. Ese evento tiene un hueco: dice "no hay nada para arrastrar, porque el SELECT tambien es angosto. en selecciona CINCO columnas". Se comieron dos referencias porque mande el cuerpo entre comillas dobles con backticks adentro y el shell las EJECUTO como sustitucion de comandos. Es la trampa que ya esta escrita en memoria y la volvi a pisar; los cuerpos largos van por archivo, nunca inline. La frase completa, que es el hallazgo de audit-mba-l-cc y cambia la forma del arreglo: **currentHistorial, en src/repositories/vehiculos.ts:909-915, selecciona CINCO columnas** - id, fechaAlta, entidadId, lineaId, y estadoId (esta ultima agregada en 59a48dce por MOVILBA-331). Un escritor que quisiera copiar cuit / asientos / numero_serie_chasis del periodo que se esta cerrando NO TIENE EL VALOR EN LA MANO. Por que importa para el arreglo: no alcanza con agregar columnas al INSERT. Hay que ensanchar tambien el SELECT del periodo vigente, o traer los valores de otra fuente. Es exactamente la forma de MOVILBA-331 -"el arrastre no estaba roto, el valor no estaba DISPONIBLE para arrastrar"- multiplicada por 97 columnas. 331 era una instancia de esta clase; la clase es la fila entera. CORRECCION DE CREDITO, pedida por proxy-mba-w-cc y correcta: proxy NO predijo que la fila estuviera vacia. Predijo que el ESCRITOR habia computado ~32 campos como cambiando a vacio, y lo infirio de que el panel renderizaba los mismos campos distinto en dos periodos del mismo page load. El mecanismo real -tabla ancha, escritor que pobla 12 columnas- no es el que propuso, y "cambios" resulto ser ["observaciones"], una sola clave, lo que refuta lo que proxy afirmo puntualmente. **Lo que sobrevive es el negativo angosto: el panel NO estaba inventando el vacio.** Queda escrito asi porque "proxy lo predijo" haria ver su razonamiento mejor de lo que fue, y porque el error que importa es el mio: yo tenia el dato correcto -la fila sucesora tiene 12 columnas- y saque la conclusion al reves.
-
2026-09-07 23:13 - DOS NOTAS PARA QUIEN DISEÑE EL ARREGLO. Hallazgo de audit-mba-l-cc. La primera descarta la opcion que parece mas segura, asi que va ANTES de la conversacion de diseño y no despues. 1. "COPIAR EL PERIODO QUE SE CIERRA, ENTERO" ES LA TRAMPA, NO LA SOLUCION. Para los 6 vehiculos ya afectados, el periodo que se esta cerrando YA ES una fila escrita por la app, o sea que ya esta en NULL en 97 columnas. Copiarlo entero PROPAGA EL HUECO HACIA ADELANTE en vez de repararlo. Es identico, palabra por palabra, al hallazgo 6 de audit sobre MOVILBA-331: el fallback a currentHistorial escribia NULL justo sobre las filas que el arreglo existia para reparar. La misma forma, a 97 columnas de ancho. LA REGLA QUE SALE DE LAS DOS: **la fuente de un arrastre tiene que ser el artefacto que TODAVIA TIENE el valor, no el predecesor.** Hoy eso es la ficha (vehiculos_datos_colectivos) mas public.vehiculos, no el periodo anterior. Cualquier diseño de arrastre necesita contestar esa pregunta primero, y la respuesta "del periodo anterior" es la que se cae sola en cuanto el periodo anterior tambien lo escribio la app. Y el corolario de medicion: un control positivo para este arreglo tiene que correrse sobre un vehiculo cuyo periodo previo sea de la APP, no de import. Sobre AA033TK -cuyo predecesor era una fila de import bien poblada- un arrastre desde el predecesor pasa el control y falla en produccion. El sujeto tiene que tener algo que perder por el camino que efectivamente se toma. 2. DECIR "12 ESCRITAS" APARTE DE "17 POBLADAS". La fila 80590 termina con 17 columnas pobladas y el INSERT escribe 12. La diferencia son defaults, el id y lo que llene la tabla sola. Hay que enunciar las dos cosas por separado en la invariante: **el escritor SUMINISTRA 12; la fila QUEDA con 17.** Si no, el proximo que mida va a contar 17 y concluir que el insert es mas ancho de lo que es. Es la misma disciplina que el defecto de `changes` de hace una hora: dos cosas distintas compartiendo un nombre, y el lector no puede saber cual tiene en la mano. Aca son dos numeros distintos midiendo cosas distintas. 3. NO SE REPARA NADA. La fila 80590 queda exactamente como se escribio: es el especimen mas limpio de este defecto y repararlo destruye la evidencia. ZZ997WW y ZZ998YY ya estan en la lista de no-limpiar por la misma razon.
-
2026-09-07 23:15 - CENSO COMPLETO DE LAS 10 FILAS DE LA APP, y corrige dos cifras mias. Medido por db02-mba-l-cc sobre DEV, directo de la tabla - contesta el discriminador que yo habia mandado a resolver por navegador, mejor y sin navegador. | id | dominio | origen | escritor | pobladas | cuit | interno | asientos | linea_numero | tipo_servicio | |---|---|---|---|---|---|---|---|---|---| | 75742 | AA033TK | import | movilba-202 | 93 | 30-54623141-7 | 18 | 25 | 109 | SP | | 80590 | AA033TK | app | editar | 17 | - | - | - | - | - | | 80587 | FB444EP | app | CREATE | 18 | - | - | - | - | - | | 80588 | FB444EP | app | editar | 17 | - | - | - | - | - | | 80589 | FB444EP | app | editar | 16 | - | - | - | - | - | | 80586 | ZZ997WW | app | CREATE | 18 | - | - | - | - | - | | 80585 | ZZ998YY | app | CREATE | 17 | - | - | - | - | - | | 80582 | ZZ999XX | app | CREATE | 18 | - | - | - | - | - | | 80583 | ZZ999XX | app | editar | 15 | - | - | - | - | - | | 80584 | ZZ999XX | app | editar | 15 | - | - | - | - | - | 1. EL ESCRITOR DEL ALTA ES IGUAL DE ANGOSTO QUE EL DE LA EDICION: 17-18 columnas, y cuit / interno / asientos / linea_numero / tipo_servicio en NULL en TODAS las filas de la app, incluidas las de alta. O sea que **un vehiculo nacido en la app nunca tuvo un periodo ancho en ningun momento de su vida.** No es que la edicion "pierda" lo que el alta habia escrito: el alta tampoco lo escribio. 2. ESO PARTE EL ARREGLO EN DOS, y es la respuesta de diseño que faltaba: - Vehiculos de epoca import (AA033TK): el dato ES recuperable del periodo que se cierra, que tiene 93 columnas. - Vehiculos nacidos en la app (FB444EP, ZZ997WW, ZZ998YY, ZZ999XX): no hay ninguna fila anterior que tenga los valores. Solo existen en la ficha, si es que existen. Son DOS reparaciones distintas y solo una es un copy-forward. 3. DOS CORRECCIONES A MIS CIFRAS, y las escribo porque se van a re-leer: - Dije "12 de 109, con 97 en blanco". El insert suministra 12, pero la fila aterriza con **16-18 pobladas** porque la tabla llena sus propias columnas de auditoria. El hueco real es de **~92**, no 97. - Y NO ES CONSTANTE: 80583/80584 quedan en 15, 80589 en 16, las altas en 18. Enunciarlo como "12 de 109" subestima lo presente y exagera el hueco. 4. LA INVARIANTE QUE SOBREVIVE A UNA RE-MEDICION, y es la que va en el item: **ninguna fila origen='app' llevo nunca `cuit`, y todas las de origen='import' lo llevan.** Categorico, falsificable, y no depende de un conteo de columnas que varia fila por fila. El conteo de pobladas es el falsificador del estado de hoy, no el criterio - misma disciplina que MOVILBA-333. 5. NO se repara nada. 80590 sigue siendo el especimen; ZZ997WW/ZZ998YY/ZZ999XX siguen en la lista de no-limpiar.
-
Ninguna fila de historial escrita por la app llevo nunca cuit ni las demas columnas de negocio; las de import las llevan todas
-
2026-09-08 00:05 - CENSO COLUMNA POR COLUMNA, medido por coder02-mba-l-cc sobre DEV (PG 15.17) con pg_attribute + count(col) por origen; PROD (PG 17.6) solo conteo. Archivo: scratchpad census338.out (se re-deriva con census338.sql, \gexec). PROD: origen='import' 5388 filas, origen='app' 0. El defecto no toco prod todavia. DEV: 109 columnas; 16126 import / 11 app (borrado_en null). Clasificacion de las 109 por lo que puede hacer el escritor de la app: A) YA ESCRIBE (12): vehiculo_id, dominio, entidad_id, linea_id, estado_id, tramite_id, expte_alta, fecha_alta, observaciones, creado_por, origen, normalizado_por. La tabla llena sola: id, creado_en, normalizacion_estado, conflictos, elegible_actual, normalizado_en (15-18 pobladas). B) EVIDENCIA DEL IMPORT, quedan NULL a proposito (43): rutap_snapshot_id, rutap_fila, rutap_fila_excel, source_fingerprint, y las 39 raw_*. No hubo libro: escribirlas seria inventar procedencia. C) RESOLUBLES DESDE LA FICHA HOY (44), con el origen medido: - por entidad_id -> entidades: cuit, identificador_empresa (si es la misma cosa; verificar contra entidades) - por linea_id -> lineas.numero_linea: linea_numero - vehiculos: anio_modelo, asientos, vehiculo_subtipo_transporte_id, chasis_modelo, chasis_id, numero_serie_chasis, carroceria_id, motor_fabricante_id, numero_serie_motor - vehiculos_datos_colectivos: interno, consumo, regimen_servicio_modalidad_id, cabina_antivandalica_id, adas_presente_id, mdvr_id, pantallas_id, wifi_id, identidad_id, estandar_emisiones_id, ip_canbus, camaras_adas_cantidad, identificacion_camaras_adas, camaras_internas, ip_mdvr, sube_*/openpass_* (4), expte_baja - por catalogo/join que v_vehiculos_detalle YA arma: tipo_servicio (regimen), unidad_propulsora_id (v.motor_unidad_propulsora_id), piso_id y aire_acondicionado_id (carrocerias), chasis_marca / carroceria_fabricante / motor_fabricante (fabricantes), carroceria_categoria, carroceria_modelo, tipo_motor (estandar_emisiones), conexiones_usb_id (vdc.conexiones_usb) - fecha_baja / tramite: los pone el propio escritor (cierre y tramite_id ya estan) D) SIN FUENTE HOY (2): motivo_id (0/16126 tambien en import), tramite texto (derivable de tramite_id). Lo que v_vehiculos_detalle ya resuelve cubre la mayoria de C: la fuente natural del escritor es UNA lectura de esa vista (o una vista hermana sin el jsonb de historial) en la misma transaccion, antes del INSERT. REPARACION DE LAS 10 FILAS EXISTENTES: 80590 (AA033TK) tiene predecesor import de 93 columnas -> recuperable por copia del predecesor SOLO para las columnas de C que no cambiaron en esa edicion; las 9 restantes (FB444EP x3, ZZ997WW, ZZ998YY, ZZ999XX x3) nacieron angostas: su unica fuente es la ficha de HOY, que dice el estado actual, no el de la fecha del periodo. Son datos de prueba de DEV; no hay caso real que reparar todavia.
-
2026-09-08 00:15 - SINTESIS DEL BLACKBOARD bb-coder02-mba-l-cc-mts23v5o-s05pb6 (coder-mba-l-ca, coder03-mba-l-cc, db02-mba-l-cc, db03-mba-l-ca; todos midieron DEV y PROD, SELECT-only). Elevado a Elazar en CLI. ACUERDO DE LOS CUATRO (338): el escritor de la app abre el periodo desde la FICHA post-update en la misma transaccion (vehiculos + vehiculos_datos_colectivos + carrocerias para piso/aire + entidades/lineas/fabricantes por FK); raw_* (39) y las 4 de procedencia RUTAP quedan NULL a proposito (no hubo libro); nunca copiar de un predecesor app; sin fuente estructurada: carroceria_categoria, tipo_motor, motivo_id. PROD: 0 filas origen='app' (5388 import) -> nada que reparar en prod. DEV: 11 filas app, 3 con ancestro import (AA033TK 1, AE801OE 2), 8 nacidas angostas (ZZ999XX 3, ZZ998YY, ZZ997WW, FB444EP 3); son datos de prueba, no se backfillean como hecho historico (coder-ca, db03). LA UNICA BIFURCACION DE DISEÑO, para Elazar: los gemelos de etiqueta (cuit, linea_numero, tramite, motor_fabricante, carroceria_fabricante...). Medido por coder03: cuit en import = entidades.cuit en 15706/15706, o sea etiqueta congelada de un FK que ya esta en la fila. coder03: NO escribirlas en filas app (feedback_nunca_congelar_la_etiqueta) y hacer que el diff resuelva por id. db02/db03/coder-ca y coder02: SI escribirlas, resueltas por FK al momento de escribir, porque el historial ES el libro y el libro las lleva; el diff y la reconciliacion comparan periodo contra periodo. Recomendacion elevada: escribirlas. ACUERDO DE LOS CUATRO (333): derivar SOLO filas abiertas del ULTIMO snapshot (h.rutap_snapshot_id = max(rutap.snapshots.id)); sin ese filtro coder03 midio 4 filas / 3 vehiculos (AD631QS, AF023VE x2, AE352LD) con ficha BAJA que recibirian ALTA. Forma: SET estado_id = dc.estado_id FROM vehiculos_datos_colectivos dc (db03/coder03), no literal 116; hoy da lo mismo (db02: vdc.estado_id no borrado toma solo 116 x1608 y 117 x808; abiertas ultimo snapshot 1600/1600 ALTA), pero no deriva si aparece un tercer estado. Cerradas quedan NULL y se documenta (una cerrada es modificacion, no baja: solo existen tramites Alta/Modif). El loader aplica la misma regla por snapshot. Control positivo ANTES del write: count candidatas; count FILTER (dc.estado_id <> ALTA via v_opciones) = 0; el predicado SIN filtro de snapshot tiene que mostrar las 4. Sin consumidor en src de v_vehiculos_hist_ultimo.estado_id (parque-movil.ts lee vdc.estado_id). RETIRADO: la afirmacion de coder03 de 4 vehiculos MANTENIMIENTO/TRANSFERENCIA con fila abierta - los 4 (5186, 5187, 5216, 5217) tienen cero filas en la tabla normalizada; retirado por coder03 mismo en DM. ESPERANDO decision de Elazar: A) escribir gemelos si/no; B) GO para el UPDATE en DEV (carril db ejecuta con los controles).
-
Elazar decidio 2026-09-08 00:20 ART (CLI): SI se escriben los gemelos de etiqueta, resueltos por FK al escribir. coder02 implementa el escritor (create + sucesor) desde la ficha en la misma tx; sin reparacion de datos.
-
2026-09-08 00:30 - SHIPPED a dev01 v5.5.54, commit 38ccdf57 en dev (src/repositories/vehiculos.ts). Nuevo columnasDesdeFicha(): una lectura de vehiculos + vehiculos_datos_colectivos + entidades/lineas (por el id del PERIODO) + carrocerias/chasis/fabricantes/regimen_servicio_modalidad/opciones(estandar emisiones), en la misma tx y DESPUES de los UPDATE; se spreadea en los tres inserts de la app (alta :689, sucesor :1122, createHistorialRecord). Gemelos de etiqueta escritos por FK (Elazar SI, 00:20). NULL a proposito: 39 raw_* + 4 de procedencia, carroceria_categoria (sin fuente), chasis_marca sin chasis_id (16076/16126), tramite texto (libro 'Modif' vs catalogo 'Modificacion'). Sin reparacion de filas. VERIFICACION PENDIENTE: proxy edita FB444EP (predecesor app, nacido angosto) y AA033TK; db02 mide columnas pobladas + gemelos vs 75742. No ejercitado: alta por pantalla y createHistorialRecord (cambio de entidad/linea). Diff a audit enviado.
-
2026-09-08 00:05 - AUDIT de 38ccdf57 (audit-mba-l-cc): 2 hallazgos, sin revert. (1) pick de la ficha no determinista -> v5.5.56 6924c07f agrega ORDER BY d.id DESC LIMIT 1; NO se agrega fecha_vigencia_hasta IS NULL como pedia audit: medido en DEV, 805 filas vivas de vehiculos_datos_colectivos la tienen (es la fecha de baja sobre la unica fila del vehiculo, rutap-sync-prod.sql:762) y ningun vehiculo_id tiene >1 fila viva; el filtro dejaria sin ficha a todo vehiculo en BAJA. (2) conexiones_usb -> conexiones_usb_id: medido, es id de opciones (FK fk_conexiones_usb_opciones; 24 SI x425 / 25 NO x1985), mismo dominio que el import escribe (24 x2305 / 25 x13821); no es un conteo. CONTROL POSITIVO EN PANTALLA (proxy, v5.5.54): FB444EP con predecesor APP renderiza Linea 107 donde pre-fix decia 'Sin numero'; AA033TK post-fix sin bloque de cambios junto a la fila 80590 pre-fix con ~32 'A: (vacio)'. Pendiente: lectura de columnas por db02.
-
DEV, v5.5.54 (38ccdf57), measured by db02-mba-l-cc 2026-09-08 00:33 ART after proxy's edits (FB444EP Observaciones-only 23:57:53 -> row 80591; AA033TK 23:58:55 -> row 80592; both origen=app, app-editar-colectivo, open, estado_id 116). Populated columns: 80591 = 54, 80592 = 52 (baseline app rows 80589 = 17, 80590 = 18; import rows = 93). The nine named columns (cuit, identificador_empresa, linea_numero, tipo_servicio, asientos, numero_serie_chasis, motor_fabricante, piso_id, aire_acondicionado_id) are non-NULL on both; on AA033TK each equals import row 75742 and the new snapshot-12 row 91931 (linea 109, asientos 25, piso 28, aire 24, same chasis serial, motor fabricante and cuit). FB444EP: linea 107, asientos 31, piso 28, aire 24. raw_* = 0 on both (by design); carroceria_categoria NULL on both; chasis_marca NULL on AA033TK, present on FB444EP. The invariant 'no origen=app row ever carried cuit' is broken in the intended direction: 80591/80592 are the first app rows with cuit. Not exercised: app-create-colectivo on v5.5.54; the ~40 columns outside the nine named plus raw_*/carroceria_categoria/chasis_marca were counted, not compared by value.
-
2026-09-08 00:33 - LECTURA POR COLUMNA (db02-mba-l-cc, DEV, v5.5.54): filas 80591 FB444EP y 80592 AA033TK (app-editar-colectivo, abiertas, estado 116): 54 y 52 columnas pobladas vs 17/18 de las filas app previas (import 93). cuit, identificador_empresa, linea_numero, tipo_servicio, asientos, numero_serie_chasis, motor_fabricante, piso_id, aire_acondicionado_id: todas no NULL en ambas; en AA033TK cada una IGUAL a la fila import 75742 / 91931 (linea 109, asientos 25, piso 28, aire 24). FB444EP: linea 107, asientos 31, piso 28, aire 24. raw_* 0 por diseño; carroceria_categoria NULL en ambas; chasis_marca NULL en AA033TK. Invariante 'ninguna fila app llevo cuit' rota en la direccion buscada. Audit CIERRA el item con dos lineas de cobertura: +36/+34 no +41 (entre 4 y 7 columnas del Pick resolvieron NULL desde la ficha, ficha incompleta, no el escritor); SIN ejercitar el camino create (app-create-colectivo) y las columnas fuera de las 9+3 nombradas.
bug
5w ago by wi-cli-venus
5w ago
2026-09-08 03:34