Observaciones: el export externo lee la nota de VDC y la ficha la del periodo - 101 vehiculos discrepan

Sub-tickets

Activity

• wi-cli-venus created · 4w ago
• wi-cli-venus note · 4w ago
  Correccion de audit (2026-09-17) al alcance: en la FICHA, colectivoData se arma desde el mismo DTO de getVehiculoById (page.tsx:531-565), no desde getColectivoByVehiculoId - ese lector solo lo usa el formulario de edicion (services:742 -> editar/colectivo:373). Asi que la ficha NUNCA mostro la nota de VDC a un vehiculo con fila de periodo; solo lo hubiera hecho en el caso dormido sin fila, cerrado por v5.5.214. Lo que queda en pie de este item: VDC.observaciones != nota del periodo en 101/2430 (DEV); el export externo (v_vehiculos_export:42) manda VDC; el formulario de edicion lee y escribe VDC. Es EXPORT-vs-FICHA, no ficha-mostraba-VDC. La decision de contrato para Elazar no cambia.
• wi-cli-venus note · 4w ago
  2026-09-17 coder03: NOT an Elazar decision - already settled by standing rules. (1) export = libro (PROD = exact snapshot of the book). (2) docs/reference/rutap-transform-rules.md:402: `observaciones` IS the book's Observaciones cell verbatim, per period row, gate 5458/5458. The book has no vehicle-level note, so vehiculos_datos_colectivos.observaciones has no counterpart in the SSOT and the export column that ships it ships something the book does not contain. Resolution: v_vehiculos_export.observaciones reads the current period's observaciones (same source as ficha/PDF since v5.5.213); VDC.observaciones is portar-y-borrar (no second source may survive): drop column, remove writer src/repositories/vehiculos.ts:890 (alta copies VDC note into history) and :1216 (editor write), reader editar/colectivo/page.tsx:373, and the archive copy in fn_archive_vehiculos_datos_colectivos. Order: pg_depend enumeration (db02) -> DEV view migration + app diff -> audit -> DEV apply -> PROD queued in pending-prod-changes.md behind 471. Elazar asked 22:40 ART why this reached him; answer: it should not have.
• wi-cli-venus statusChanged · 4w ago
  coder03 takes it: export observaciones -> period note, VDC.observaciones portar-y-borrar; db02 pg_depend pending
• wi-cli-venus progress · 4w ago
  2026-09-17 22:49 ART db02 (read-only, DEV) impact of the swap v_vehiculos_export.observaciones VDC -> current period: 1806 VDC rows carry non-empty observaciones, 0 lack a period row, 0 lack a current row (nothing lost for want of a fallback). 100/2430 export cells change: 0 lose text, 38 gain text where VDC was empty, 62 hold different text. Of the 62: 41 differ only by the book's spelling "a pedidos de la empresa" vs VDC "a pedido" (the book's own phrase, 41 times: her term, not a typo, per the standing rule that the owner's term is not a defect - not sent to Eugenia); 21 genuinely different text. By origen of the current period row: 66 import-origin (the book correction the rule asks for), 34 app-origin out of 39 vehicles whose current period is an app edit. coder03 decision on the 34: the export row already takes fecha_alta, expedientes and every other period field from that same app-origin current row; observaciones following the same row is the only consistent reading, and the alternative (a per-column fallback to VDC for app rows) is exactly the second-source fallback 470 removed. Several of the 34 are DEV residue ("Prueba juanma no migrar", "NO MIGRAR", "MOVILBA-344 deliberate DEV screen test") - test data, not a spec input. Dependents of vehiculos_datos_colectivos (pg_depend + pg_views + pg_proc): views v_vehiculos_detalle (line 44 selects vdc.observaciones), v_vehiculos_export_vdc (line 24), v_vehiculos_list (does NOT select it); functions fn_archive_vehiculos_datos_colectivos and rutap.proyectar_snapshot mention the column in prosrc (fn_cascade_soft_delete_vehiculo, rutap.materializar_snapshot_raices, rutap.reconciliar_estado_abierto_snapshot do not); triggers trg_archive_vehiculos_datos_colectivos (BEFORE DELETE OR UPDATE, copies OLD.* into vehiculos_datos_colectivos_archive, which also has an observaciones column) and trg_soft_delete_vehiculos_datos_colectivos. v_vehiculos_export_vdc is a flat SELECT DISTINCT ON (vehiculo_id) of 32 VDC columns, ORDER BY vehiculo_id, (borrado_en IS NOT NULL), borrado_en DESC, id DESC; the swap is one column substitution. Portar-y-borrar scope therefore: v_vehiculos_export_vdc + v_vehiculos_detalle (drop the column from the SELECT), v_vehiculos_export (read h.observaciones), fn_archive_vehiculos_datos_colectivos + vehiculos_datos_colectivos_archive.observaciones, rutap.proyectar_snapshot prosrc mention, ALTER TABLE DROP COLUMN, app writers :890/:1216 and reader editar/colectivo/page.tsx:373, drizzle/schema.ts via introspect.sh.
• wi-cli-venus note · 4w ago
  CORRECTION (db02 2026-09-17 22:53): the 100/0/38 above was measured against rutap.v_vehiculo_historial_actual, which v_vehiculos_export does not read. The export resolves its current period through v_vehiculos_hist_ultimo (line 62) -> periodo_veh (line 63). Against that resolver: 2430 rows, 105 change, 0 lose text, 39 gain text. And v_vehiculos_hist_ultimo still picks the app baja-closure row for the 470 seven (33 of the 34 app-origin changes), so 472 is sequenced BEHIND the resolver fix. Scope widened: v_vehiculos_export lines 43-44 also take expediente_alta/expediente_baja from vdc - three VDC-sourced columns, not one. Evidence: /data-lezama/movilba/evidencia/MOVILBA-472/ (installed bodies of v_vehiculos_export, v_vehiculos_export_vdc, v_vehiculos_detalle, fn_archive_vehiculos_datos_colectivos, proyectar_snapshot observaciones lines 31,32,237,255,268,273,292,448).
• wi-cli-venus note · 4w ago
  db02 re-measure DEV against installed export resolver (hist_ultimo -> 474), 2430 rows: observaciones change 100 = gain 38/lose 0/differ 62 (periodo app 34, import 66); expediente_alta change 134 = gain 41/lose 5/differ 88; expediente_baja change 10 = gain 8/lose 2/differ 0. Per-row list: evidencia/MOVILBA-472/2026-09-17-472-vdc-vs-periodo-por-fila-DEV-db02.txt. The 7 lose rows (evidencia .../2026-09-17-472-lose-rows-periodo-vs-libro16-DEV-db02.txt): 2 expediente_baja loses are VDC defects (VDC carries the PRIOR period's baja expte on an open period: AE631MI, PPF407) - periodo correct. 5 expediente_alta loses: current period is a DEV app row (created 09-07..09-12) with no expte at all, ranking above the book's open row by fecha_alta; 3 of the vdc texts are in the book (AA013AA f950, AA033TK f4356, AE801OE f3740), 2 exist only in VDC (LB221PE 'EX-2027-...', LP555EP). The swap exposes those app rows, it does not create them. Open: are those 5 app rows DEV test data (creado_por unresolved).
• wi-cli-venus note · 4w ago
  coder03 2026-09-18, app-side resolution settled by reading the code (record it here so it survives a compact): the editor has TWO distinct note inputs, not one. src/repositories/vehiculos.ts:1218 writes data.colectivoData.observaciones into vehiculos_datos_colectivos (VEHICLE-level, the column being dropped); :1367 writes data.motivoTramite into the NEW period row's observaciones (PERIOD-level, the book's note). The period note therefore already has its own input and needs no replacement. Consequence: the 'Observaciones' textarea at src/app/vehiculos/[dominio]/editar/colectivo/page.tsx:1475-1481 is REMOVED outright, along with formData.observaciones (:93, :156), the read-back at :373, the writer at repositories:1218, the alta copy at :892, and the DTO field at :1076/:1100 where it feeds VDC. It is NOT repointed at the period - repointing would give the period note two inputs in one form, which is the same second-source defect one layer up. Open sub-question for whoever does the edit: :1452/:1496/:1536 also read/write vehiculos_datos_colectivos.observaciones (getColectivoByVehiculoId and a generic update path) and must go in the same diff or the DROP COLUMN fails. Nobody operates the app yet, so removing a form field costs nothing.
• wi-cli-venus note · 3w ago
  Medido por db04-mba-l-ca en PROD 2026-09-23 15:00 ART, y hay un hecho nuevo que cambia el ticket: la columna vehiculos_datos_colectivos.observaciones EXISTE EN PROD Y NO EXISTE EN DEV (pg_attribute tiene los slots dropeados; un SELECT observaciones falla en movilba_dev). O sea que las dos bases no estan de acuerdo en el ESQUEMA, no solo en los datos, y eso es deriva = defecto. PROD: 2413 filas vdc vivas, 1545 con texto no vacio, 868 NULL, 0 solo-espacios. Distintos exactos: ONCE, no mil - 1173 'Se modifican datos a pedido de la empresa', 264 'Se modifica N de dominio a pedido de la empresa', 39 'Se cedio la linea a la empresa NUDO S,A,', y ocho mas que son variantes de puntuacion de las mismas tres frases. Largos min 20 / max 72 / mediana 41, cero por encima de 200. Contra el libro VIGENTE (snapshot 5, 5528 filas de historial, 0 filas crudas faltantes), comparacion byte a byte UTF-8 sobre las 1545: 1234 iguales a la celda Observaciones del periodo canonico de ese dominio y 311 distintas; ampliando a CUALQUIER periodo del MISMO dominio, 1494 iguales (1234 del vigente + 260 de uno anterior) y CINCUENTA Y UNA sin celda igual. De esas 51, una coincide con texto del libro bajo OTRO dominio y CINCUENTA no tienen celda byte-igual en ningun lado del snapshot vigente. Esas 50 son el unico contenido que un DROP destruiria; las otras 1494 son copia del SSOT y se re-importan. La medicion es de IGUALDAD, no de autoria: no prueba que las 50 las haya escrito un operador ni que sean irrecuperables desde una fuente mas vieja, y once cadenas repetidas tampoco prueban por si solas que esto sea un enumerado mal modelado. Dependencias en PROD: vistas que leen la columna directo v_vehiculos_detalle y v_vehiculos_export_vdc; cinco mas por dependencia transitiva de relacion (v_api_status, v_vehiculos_api_public, v_vehiculos_export, v_vehiculos_export_periodo_actual, v_vehiculos_vivos_estado) que NO esta probado que la proyecten; funcion fn_archive_vehiculos_datos_colectivos() que copia OLD.observaciones al archive, con trigger trg_archive BEFORE DELETE OR UPDATE; cero indices sobre 12 y cero constraints sobre 15. En DEV no queda ninguna referencia colgada. Falsos positivos descartados a mano: proyectar_snapshot y reconciliar_snapshot nombran Observaciones del libro, no la de VDC. Evidencia y SQL exacto en /data-lezama/movilba/evidencia/MOVILBA-537/2026-09-23-db04-observaciones*. Yo habia propuesto DROPEAR esta columna y RETIRO la propuesta: la propuse sin medir, con el nombre de tabla equivocado (dije vehiculo_datos_complementarios, que no existe en ninguna de las dos bases), y la medicion muestra que el problema no es la columna sino que DEV ya la tiro y PROD no. Lo que falta decidir es la direccion de convergencia, y antes de eso hay que saber que son esas 50
• coder03assistant-mba-l-ca progress · 3w ago
  coder03assistant-mba-l-ca | 2026-09-24 04:00:26 ART DEV movilba_dev v_vehiculos_export reads periodo_veh observaciones/expte_alta/expte_baja; PROD movilba reads periodo_veh observaciones but expte_alta/baja from vdc, and retains vdc.observaciones column. Source-alignment migration remains incomplete in PROD.
• coder03-mba-l-cc assigned · 2w ago
  coder03assistant-mba-l-ca
• coder03assistant-mba-l-ca parentChanged · 1w ago
  parent=MOVILBA-537
• coder03assistant-mba-l-ca canceled · 1w ago
  Merged into MOVILBA-537 per coder03 wave-2 direction; MOVILBA-537 retains the VDC.observaciones census, data-loss evidence, dependents, and any required decision. No finding discarded.