Celdas con el literal '0' en el snapshot vigente: 5308 id_canbus, 2974 id_adas, 1128 id_mdvr, 18 motor_nro - verificar contra el libro antes de decidir si es fidelidad o defecto nuestro
Medido por db03 el 2026-10-08 censando MOVILBA-731, en el snapshot de la punta: 5308 celdas de id_canbus, 2974 de id_adas, 1128 de id_mdvr y 18 de motor_nro valen el literal '0'. No es latente - son filas del libro vigente. LO PRIMERO ES CONTRA EL LIBRO, NO CONTRA LA BASE. La regla de fidelidad dice que cuando un valor se ve mal hay que verificar primero que este REALMENTE en el libro y no sea un error de lectura, transformacion o import nuestro. Entonces el orden es: abrir el libro vigente por su digest pinneado, mirar esas celdas, y decidir cual de las dos cosas es. a) Si el libro trae '0' en esas celdas, se importa como esta - corregir el dato de Eugenia no es nuestra tarea ni un prerequisito. Se le nota con cortesia en el tracker y se le pregunta si ese manejo le sirve, SIN frenar el import. No es una decision para Elazar. b) Si el libro trae vacio y el '0' lo pone nuestro pipeline, es un defecto nuestro y el arreglo es la rama que lo escribe, mas una re-proyeccion. Ahi si hay que medir cuantas filas quedan afectadas y por que funcion - acordarse de que proyectar lee normalizado y materializar lee el CRUDO, asi que arreglar una sola deja volver el valor. Un '0' en un campo de identificador no es lo mismo que un blanco: un consumidor que lo muestre imprime cero donde no hay dato, y uno que lo compare lo trata como un id valido. Por eso no se deja sin veredicto aunque sea 'solo un literal'. Separado de 731, que es paridad de cuerpos de vista: esto es contenido de filas y comparte con 731 nada mas que la corrida del censo.
Activity
-
db03-mba-l-cc, host date -u 2026-10-08T21:3xZ - exact stamp below. VERDICT: BRANCH (a). THE BOOK SAYS 0. It is fidelity, not a defect of ours, and nothing about the import changes. SOURCE, not the base. Read the pinned workbook itself: /data-lezama/movilba/libro/2026-10-06-1140-parque-rutap.xlsx, md5 eb2e2683ccdd16a33be4a34b7b56088b, which is byte-identical to the digest rutap.snapshots records for the installed snapshot (PROD id 11, DEV id 21, archivo 2026-10-06-1140-parque-rutap.xlsx, hoja Base, filas 5558). Read-only, openpyxl read_only + data_only. THE HEADER IS ON ROW 2, NOT ROW 1. Row 1 of hoja Base is entirely empty and the 40 labels live on row 2, so a reader that takes row 1 as the header sees 52 unnamed columns and counts 5559 data rows. My first pass did exactly that and matched no column by name. With the header on row 2 the data rows are 5558, equal to rutap.snapshots.filas, and 0 rows have an empty Nro_dominio. COUNTS IN THE BOOK vs COUNTS IN THE BASE, four columns, exact: | book column | numeric 0 | text '0' | book total | base count | |---|---|---|---|---| | ID CANBUS (col 24) | 5279 | 29 | 5308 | 5308 | | ID ADAS (col 26) | 2963 | 11 | 2974 | 2974 | | ID MDVR (col 28) | 1128 | 0 | 1128 | 1128 | | Motor Nro (col 16) | 18 | 0 | 18 | 18 | Four independent numbers agreeing digit for digit between the workbook and rutap.rutap_rows at the tip snapshot. The predicate discriminates rather than matching everything: the 'otro' bucket is 250 for ID CANBUS, 2584 for ID ADAS, 4430 for ID MDVR and 5540 for Motor Nro. Note the cell TYPE: in the book these are mostly NUMERIC zeros, not the text '0' - the import stringifies them, which is why the base sees '0'. Both representations appear in the source for ID CANBUS and ID ADAS, and the import counts both into one number. SO: no pipeline defect on these four columns. Neither the projector nor the materializer invents the value - the source carries it. The second half of the item's instruction (check both writers because one reads normalized and the other reads raw) does not apply to a value the book states. WHAT THE 0 DOES REACH, measured, because this is where the item touches MOVILBA-731. The published export surface emits the literal '0' in BOTH bases: public.v_vehiculos_export has id_canbus = '0' in 2262 of 2424 rows in PROD and 2288 of 2469 in DEV, id_adas 963 / 967, id_mdvr 216 / 216, and id_canbus IS NULL in 0 rows in PROD. So the NULLIF('0') that only PROD's rutap.v_rutap_latest_norm carries does NOT reach the export - consistent with 191's own header calling it a derived COMPARISON view. The PROD/DEV divergence of 731 §3.2 is therefore real in the comparison layer and NOT visible on the export surface; I am narrowing my own 731 wording accordingly in a note there. FOR EUGENIA, as a fact and not a task, and it holds nothing: in the book a device id of 0 means the vehicle has no such device, and MovilBA stores and exports it as the book has it. The question for her is only whether showing 0 rather than an empty cell on those three id columns is what she wants. Pending: whether the tracker already carries this question - not to be asked twice. NOT EXERCISED: only the four columns of this item; the rest of the book's numeric-0 columns (Consumo, Asientos, Camaras_ADAS, Camaras_Internas, Pantallas and the Tipo/Piso codes) were NOT counted. No comparison against any earlier snapshot - rutap.snapshots keeps one row. I did not walk the consumers of v_rutap_latest_norm beyond the export: a reconciler or the chassis resolution reading NULL in PROD where DEV reads '0' is possible and unmeasured.
-
Header stamp correction on the note above: it reads 21:3xZ because I wrote it before reading the clock. The server stamped the event itself; Thu Oct 8 09:30:25 PM UTC 2026 at the moment of sending returned 2026-10-08T21:30:10Z. Content unchanged.
-
CLOSING MEASUREMENT: there is NOTHING to ask Eugenia, because the meaning of 0 in these columns is already answered in the tracker. Checked before writing a cell, per the rule that a sheet for asking does not carry what has already been answered. Read the tracker mirror (/data-lezama/movilba/import-reports/todo-rutap-tracker-current.sqlite, copied out before reading): - resueltos row 115, MOVILBA-633, to Elazar, status Solucionado: 'ADAS: Si Camaras_ADAS distinto de cero y/o ID ADAS distinto de cero implica que ADAS = Si'. - resueltos row 124, MOVILBA-634, to Eugenia, status Solucionado, plus the live row 10 of the same item to Elazar, status Parcial: the same rule for MDVR and ID MDVR. So 0 in those id columns already means 'no device' by a rule that was asked and answered, and the import stores it as the book states. By the tracker protocol this is a REPORT and not a QUESTION in any case - it blocks no row and we can import it faithfully - and the tracker's maintainer is the coder lane, not this one, so I am not writing a cell. The only tracker-worthy residue is that the existing MOVILBA-634 row is still 'Parcial' for the MDVR half; that belongs to 634, not here. ITEM DONE from this lane's side, with the branch named: (a) fidelity. The book carries the zeros - 5308 ID CANBUS, 2974 ID ADAS, 1128 ID MDVR, 18 Motor Nro, matching the base digit for digit against the pinned digest eb2e2683 - so there is no pipeline defect and neither the projector nor the materializer needs checking for these four columns. Audit to verify; I do not write the verdict on my own measurement. What I did NOT do, stated so the close is not read as wider than it is: no cell was written to the tracker, the other numeric-0 columns of the book were not counted, and the consumers of rutap.v_rutap_latest_norm beyond the export were not walked.