Retirar el jsonb: una sola historia ancha y tipada, con export del libro que hace round-trip

Sub-tickets

Activity

• wi-cli-venus created · 5w ago
  parent=#3027
• wi-cli-venus note · 5w ago
  Paso 2 es mas grande que un swap de vistas - medido por coder-mba-l-ca. public.vehiculo_historial no solo se LEE desde 11 vistas: la app le ESCRIBE. Inserts directos en src/actions/vehiculos.ts y src/repositories/vehiculos.ts (incluyendo la columna cambios), lecturas directas en las rutas API de historial de entidad y linea, lecturas de repositorio/servicio, y las definiciones en drizzle/schema.ts. Consecuencia sobre el orden: el DROP del paso 5 rompe compilacion y runtime salvo que ANTES exista un contrato de escritura de reemplazo contra rutap.vehiculo_historial_normalizado. El paso 2 pasa a ser: (a) DDL de las 11 vistas (db03), (b) reemplazo del camino de ESCRITURA de la app (coder-mba-l-ca), (c) regenerar schema.ts por introspect.sh, nunca a mano.
• wi-cli-venus note · 5w ago
  Tipo_Servicio 'PP' NO es un valor sin catalogo - el reporte de gap lo midio contra el catalogo equivocado (v_opciones/transporte.tipo_servicio). Tipo_Servicio no vive en opciones: resuelve contra public.regimen_servicio_modalidad por modalidad_codigo, que es lo que el loader YA hace (2026-09-04-movilba-203-wide-refresh-snapshot10-DEV.sql:161 y los imports de 08-14/08-21), y el export emite rsm.descripcion. El mapeo esta escrito y verificado desde 2026-06-24: SP->1 PP->3 SE->4 (docs/reconciliation/2026-06-24-staging-ssot-mirror.md:27, entre los campos a 0-diff contra el SSOT). Consecuencia: NO hay nada pendiente de Elazar en catalogos, y las 17 columnas del libro resuelven. db03 re-mide esa linea contra rsm. MOVILBA-269 paso 1 hecho y verificado independientemente por db02 con el mismo gate (md5 f10aab606310d0c2e4f29f836df4f4ae): snapshots 9/10/11 cargados, 16126 filas, 2407 dominios en el libro 11 contra 2407 en la ancha, 0 faltantes 0 sobrantes, control positivo discrimina los tres libros. PERO rutap.v_vehiculo_historial_actual hardcodea WHERE rutap_snapshot_id = 11: es 269 reproducido una capa mas arriba, correcto hoy y silenciosamente viejo cuando entre el libro 12. Se reemplaza por (SELECT max(id) FROM rutap.snapshots) ANTES de escribir las 11 vistas, y toda vista repuntada lleva el filtro re-derivado, nunca un digito.
• wi-cli-venus note · 5w ago
  Paso 2 se PARTE en dos migraciones, medido por db02 desde pg_depend a nivel columna. Las 11 vistas leen 17 columnas distintas de public.vehiculo_historial. La vista rutap.v_vehiculo_historial_actual es 2407 filas / 2407 vehiculos - UNA fila corriente por vehiculo - mientras la tabla legacy tiene 5491 filas vivas / 2414 vehiculos. 2A: v_vehiculo_historial, v_vehiculo_cadena y v_vehiculos_hist_ultimo necesitan la HISTORIA y van a rutap.vehiculo_historial_normalizado directo con el filtro de snapshot re-derivado; repuntarlas a la vista corriente colapsaria cada historia a una fila y la falla se veria como datos limpios. 2B: v_vehiculos_detalle, v_vehiculos_export y v_monitor_historial_anomalias van a la vista. Columnas: estado_id NO es un rename de estado_derivado (uno es estado tipeado por la app, el otro se computa del libro); estado_id y motivo_id pasan a ser columnas tipadas propias escritas solo por el camino de app con origen='app'. Las cuatro de auditoria (creado_en, creado_por, borrado_en, borrado_por) se conservan: v_db_users_footprint_detalle es superficie de seguridad y lee los dos _por. cambios es la UNICA de las 17 que se descarta a proposito. Los 7 vehiculos que la tabla legacy cuenta y el libro 11 no son un DESCARTE de la decision MIRROR, no un defecto: se enumeran por dominio a /data-lezama/movilba/2026-09-06-gate-269/ con CUIT enmascarado, porque un descarte que nadie puede listar no se distingue de una perdida. Trampa de instrumento registrada: pg_get_viewdef guarda max(snapshots.id), asi que un grep de 'max(id)' da limpio sobre una vista correcta - es un gate que solo puede pasar.
• wi-cli-venus note · 5w ago
  Paso 3 HECHO (coder03): rutap.v_export_libro aplicada en DEV, round-trip export->re-import->diff VACIO en los tres libros (9: 5368, 10: 5370, 11: 5388, 53 columnas identicas). Control NEGATIVO discrimina: exportar el libro 11 contra el 10 deja 5328/5346 filas sin par. Archivos: docs/migrations/2026-09-06-rutap-v-export-libro.sql y tools/rutap-export-libro.py, rama movilba-97-subtype-ui (018d28af, 56e0113b). Dos hallazgos que solo aparecieron al CORRERLO: (1) el libro tiene 53 columnas, no 39 - despues de tramite hay 14 con encabezado VACIO, enteramente NULL en los tres libros, pero el loader compara el encabezado contra rutap.rutap_rows y ABORTA si faltan, asi que un export de 39 columnas NO es re-importable; la vista queda en 39 raw_* y el exportador emite las 14 vacias. (2) El export tiene que ser xlsx, no csv: el camino csv del loader exige dd/mm/yyyy en fecha_alta/fecha_baja y hace sys.exit() con cualquier otra cosa, mientras rutap.rutap_rows las guarda en ISO. El formato es una restriccion, no una preferencia. v_export_libro NO lleva filtro de snapshot A PROPOSITO y no es el defecto de v_vehiculo_historial_actual: es un export parametrizado, rutap_snapshot_id es su primera columna, y leerla sin WHERE devuelve 16126 en vez de 5388 - equivocado y VISIBLE, no plausible y equivocado. El exportador filtra siempre y aborta si el snapshot da cero filas. GAP del gate, abierto: todas las filas round-tripeadas eran origen=import. Un evento de app lleva todos los raw_* en NULL, asi que la vista emite 39 NULLs y el round trip lo pierde EN SILENCIO - la misma forma que el hallazgo de las 14 columnas vacias. Se re-corre con una fila sintetica origen='app' y tiene que FALLAR primero. Paso 2 DDL aplicada por db03 en DEV: origen text NOT NULL DEFAULT 'import' CHECK import|app, rutap_snapshot_id/fila/fila_excel/source_fingerprint nullables, motivo_id FK opciones, y las cuatro de auditoria. Las 16126 filas existentes quedan origen=import. El writer del import borra y reconstruye SOLO origen='import'. Sin gate todavia: fila_excel no hace round-trip y se excluye, Hoja2/rutap_expedientes no se exporta, y el gate no dice nada sobre si las columnas normalizadas no-raw son correctas.
• wi-cli-venus note · 5w ago
  DECISION de diseno: DOS exports, no uno solo sobrecargado. Medido por coder03 (no era mi prediccion): una fila origen='app' NO es un problema de NULLs en el render. vh_norm_raw_fk es (rutap_snapshot_id, rutap_fila_excel) REFERENCES rutap.rutap_rows MATCH FULL, y MATCH FULL prohibe mezclar null y no-null en la clave, asi que una fila que no viene de ninguna fila de libro tiene AMBAS en NULL. v_export_libro filtra por rutap_snapshot_id = N, de modo que la fila de app no es seleccionable por NINGUN snapshot: no entra al SELECT. Con una fila de app presente el gate da 5388 exportadas, 5388 re-importadas, cero diferencias - PASA y no hay nada que ver. Hoy es latente (16126 filas, todas origen=import) y se vuelve real el dia que entre el camino de escritura de la app. 1. rutap.v_export_libro queda como esta: LIBRO N VERBATIM. No se ensancha, no se le saca el filtro de snapshot, no se le ensena que existen filas de app. Su valor entero es que export -> re-import -> diff vacio prueba que podemos reproducir un libro que nos dieron. Un evento de app nunca estuvo en ese libro y meterlo ahi haria que el export afirme que el libro decia algo que nunca dijo. 2. rutap.v_export_estado_actual (NUEVA, coder03, no es trabajo de esta noche y no bloquea el paso 5): sobre rutap.v_vehiculo_historial_actual, TODOS los origenes, sin literal de snapshot. Es el export que Elazar pidio para jubilar el Excel - estado actual corregido y normalizado, con los eventos de app adentro. Formas RECHAZADAS, para que nadie las vuelva a proponer: unir filas de app dentro de v_export_libro (un export de libro con filas que ningun libro tuvo) y sacarle el filtro de snapshot (entonces no puede emitir un libro viejo, que es lo unico que TIENE que poder hacer). La frase que va al archivo: el export de LIBRO contesta 'que nos mando RUTAP'; el export de ESTADO contesta 'que tenemos ahora'. Difieren exactamente en nuestras correcciones y nuestros eventos de app, y esa divergencia es el producto, no un error. Para el paso 5: rutap.rutap_rows es NO DROPEABLE y no podable, junto con respaldo.m248_wide, m248_legacy y m255_pares. Es el testigo de fidelidad - sin el ningun gate de export se puede volver a correr, y ademas el CASCADE lo vuelve el mecanismo real de borrado de la tabla ancha (medido: borrar una fila de rutap_rows saco la fila ancha 52389 sin ejecutar ningun delete contra la tabla ancha).
• wi-cli-venus note · 5w ago
  Contrato de LECTURA del paso 2, medido por coder03 con pg_depend a nivel refobjsubid (lo que lee la regla de reescritura, no lo que parece el texto de la vista). Las 11 vistas necesitan en union: id, vehiculo_id, entidad_id, linea_id, estado_id, motivo_id, tramite_id, expte_alta, expte_baja, fecha_alta, fecha_baja, observaciones, cambios, creado_en, creado_por, borrado_en, borrado_por. TODAS existen en rutap.vehiculo_historial_normalizado MENOS cambios, y solo dos vistas la leen (v_vehiculo_historial y v_vehiculos_detalle): ese es el costo entero del DROP del lado de la app. Las otras nueve repuntan por nombre de columna. DECISION FIRME: cambios NO se recrea. La app escribe los campos cambiados como columnas tipadas y deja de producir el blob; no se migra, no se espeja, no se guarda por las dudas. Misma forma que el clasificador de MOVILBA-97/99 (a78225f8), que ya deriva el subtipo de modificacion de un diff de columnas explicitas. DOS TRAMPAS que no son repuntes directos: - v_vehiculos_export lee SOLO vehiculo_id y creado_en, asi que lo que derive de creado_en es una columna de AUDITORIA haciendo de fecha de negocio. Se re-deriva de fecha_alta en el repunte, no se arrastra. Su salida actual NO es objetivo de compatibilidad: si los numeros se mueven, los viejos estaban mal, y el diff es el HALLAZGO. - v_db_users_footprint_detalle lee SOLO creado_por y borrado_por: es superficie de seguridad y su denominador se mueve con la poblacion de filas. Se enuncia el denominador nuevo, no se lo deja derivar en silencio. CORRECCION de mi propio conteo: los sitios de escritura en dev@9aa33f3e son SEIS mas un UPDATE, no cinco. Falta applyColectivoEditWithHistory (src/repositories/vehiculos.ts:810), que hace UPDATE de fecha_baja en 948-949 para CERRAR un periodo e inserta el sucesor en 958 - la forma 'una modificacion cierra un periodo y no es una baja', la que costo 169 fichas al leerse como baja. Yo lo medi en el checkout compartido, que esta en una rama vieja donde esa funcion no existe: un grep sobre un checkout atrasado es una afirmacion sobre la RAMA, no sobre el codigo. normalizado_por de ese sitio = app-editar-colectivo (sexto valor). El cierre es un UPDATE por IDENTIDAD de fila, jamas por un predicado que pueda pegarle a un segundo periodo abierto. En la tabla ancha fecha_baja cierra el periodo y borrado_en es soft-delete: la tabla legacy confundia las dos y esa confusion NO viaja.
• wi-cli-venus note · 5w ago
  PASO 2 CERRADO del lado de la BASE (db03 aplica, db02 verifica). Estado: DDL aplicada en DEV (origen NOT NULL DEFAULT 'import' CHECK import|app, provenance de import nullable, motivo_id, las cuatro de auditoria, indice), trigger BEFORE DELETE vh_norm_reject_app_delete que rechaza borrar origen='app' y DEJA PASAR origen='import' (probado en los DOS sentidos: un guard que bloquea el rebuild seria peor que no tenerlo), CHECK vh_norm_app_snapshot_ck (origen='import' OR rutap_snapshot_id IS NULL) para que 'las filas de app son inalcanzables por el cascade' sea una invariante declarada y no una propiedad de los datos, y el archivo docs/migrations/2026-09-06-movilba-299-historia-ancha-app-writes-DEV.sql con el cuerpo LITERAL de la vista en vez del regexp sobre pg_get_viewdef. Equivalencia archivo-contra-vivo MEDIDA, no argumentada: en una transaccion con rollback se materializa la vista viva en una temp, se hace CREATE OR REPLACE desde el cuerpo del archivo y se corre EXCEPT en los dos sentidos. viva 2407, archivo 2407, viva EXCEPT archivo = 0, archivo EXCEPT viva = 0, denominador 2407. Mas firma de salida identica (62 columnas, mismo attnum/nombre/tipo) y predicado reimpreso identico. Script en /data-lezama/movilba/2026-09-06-vista-299-file-vs-live/except.sql. LIMITE: prueba que las dos definiciones coinciden sobre la poblacion de HOY (16126 filas, 3 snapshots), no sobre cualquier poblacion. Hallazgo estructural que vale mas alla de 299: la vista viva se habia creado con h.* ANTES de que 299 agregara seis columnas, y una vista CONGELA la expansion de la estrella al crearse. Por eso el archivo y el objeto vivo pueden divergir sin que nadie edite ninguno de los dos - lo que cambio fue la TABLA - y re-aplicar una migracion 'que no cambia nada' RE-expande. Inerte aca porque el SELECT exterior enumera y el WHERE apunta a h directo. Una vista se compara con su archivo por REIMPRESOS + pg_attribute + EXCEPT en los dos sentidos, jamas por diff de texto. Falta en 299: los seis writers de app mas el cierre por identidad de fila (coder-mba-l-ca), rutap.v_export_estado_actual con el vocabulario del LIBRO y etiquetas resueltas (coder03), y la re-derivacion de v_vehiculos_export.ultima_modificacion a GREATEST(fecha_alta, fecha_baja). El gate de periodo abierto queda ARMADO PERO NO PROBADO en su bloque E2 hasta que existan filas de app: lo re-corre quien shipee los writers.
• wi-cli-venus note · 5w ago
  CERRADO el hilo del orden de rutap.v_vehiculo_historial_actual: NO se cambia nada, ni el ORDER BY ni el CASE de estado_derivado. PPF407 y AC098EJ son una CONTRADICCION DEL LIBRO, no un defecto de la vista. Medido sobre las filas crudas de rutap.rutap_rows: PPF407 tiene un 'Modif' que abre el 2025-07-17 sin Fecha Baja, y ademas periodos 'Alta' que abrieron Y cerraron despues (2026-04-01 -> 2026-07-17). Identico en el libro y en la tabla ancha: el transform no invento nada. Ajustar nuestra semantica para que esas dos den una respuesta prolija seria REPARAR EL LIBRO DE NUESTRO LADO. Va a Eugenia por el tracker, verbatim, con la pregunta y sin respuesta propuesta. Es un estado ESTABLE de la fuente, no algo que trajo la bajada del 09-05: las mismas fechas exactas en los libros 9, 10 y 11, y 2 placas con periodo abierto solapado en cada uno de los tres. LIMITE HONESTO: solo se escanearon los tres libros que estan en la base; los otros seis del share no, asi que 'de larga data' esta probado del 09-03 al 09-05 y no mas atras. TRAMPA para el payload: fila_excel SE MUEVE entre libros (AC098EJ 3422 -> 3454), asi que la posicion de fila NO es identificador. Se cita la placa y las fechas; la fila solo como 'en el libro del 2026-09-05, fila N'. Fechas como TEXTO dd/mm/aaaa: 07/08 y 04/01 son dia <= 12 y la vuelta por Excel Online las da vuelta. HALLAZGO que sobrevive a estas dos placas: estado_derivado NO lee la fila que la vista selecciona. Es count(*) FILTER (WHERE fecha_baja IS NULL) OVER (PARTITION BY vehiculo_id, dominio), o sea contesta 'este vehiculo tiene ALGUN periodo sin cerrar', mientras el ORDER BY decide 'que fila representa al vehiculo'. Son DOS preguntas cableadas como una sola. Por eso reordenar la vista NO habria cambiado estado_derivado - un gate que yo mismo especifique habria reportado FALLA sobre un cambio correcto. Poblacion de la opcion 2 (cambiar el CASE), medida INDEPENDIENTEMENTE por db02 y db03: 2 vehiculos, los mismos dos. Bajo la clave ACTUAL la pregunta da 0 y tiene que dar 0 por construccion - con open-first, si existe una fila abierta ESA es la fila corriente, asi que la vista viva nunca puede exhibir el caso: **un gate preguntado sobre la clave actual contesta una pregunta que esa clave vuelve imposible de formular.** Denominador 2407: 1602 con fila corriente abierta, 805 cerrada, las 805 con eventos_abiertos = 0. No hay poblacion escondida y no hay decision de modelado que llevarle a Elazar: muere con la respuesta de Eugenia.
• wi-cli-venus assigned · 4w ago
  coder03-mba-l-cc / coder
• wi-cli-venus assigned · 4w ago
  coder02-mba-l-cc
• wi-cli-venus note · 4w ago
  Re-medido 2026-09-18 junto con el cierre de MOVILBA-305 (ver esa nota, misma medicion). Pasos 1, 2 y 5 de este ticket estan CUMPLIDOS - los ejecuto MOVILBA-441, un ticket distinto, mientras este seguia en backlog: snapshot desanclado y proyectado, las vistas repuntadas (10 dependientes reales hoy, medido por pg_depend/pg_rewrite contra rutap.vehiculo_historial_normalizado), DROP de public.vehiculo_historial sin CASCADE ya aplicado en DEV y PROD, cambios ya no se escribe desde ningun writer de app. Lo UNICO que sigue abierto de este ticket es el paso 3b: rutap.v_export_estado_actual (export de ESTADO ACTUAL con vocabulario del libro y etiquetas resueltas, sobre v_vehiculo_historial_actual, TODOS los origenes, sin literal de snapshot - distinto de rutap.v_export_libro que ya existe y hace round-trip del libro tal cual vino). Verificado que to_regclass('rutap.v_export_estado_actual') da NULL en DEV: no existe todavia. Es independiente y no bloquea nada mas del plan original (asi lo dice la nota de diseno del 09-06: 'no es trabajo de esta noche y no bloquea el paso 5'). Manteniendo este ticket en backlog, acotado a ese unico item.
• wi-cli-venus assigned · 4w ago
  db02-mba-l-cc / db
• wi-cli-venus note · 4w ago
  Delegado a db02-mba-l-cc: unico item restante es DDL (crear rutap.v_export_estado_actual), no codigo de app - va al carril db, no a coder02. Spec segun la nota de diseno original del 09-06 (MOVILBA-299): vista sobre rutap.v_vehiculo_historial_actual, TODOS los origenes (app + import), SIN literal de snapshot (auto-detecta el mas nuevo), con vocabulario/etiquetas del LIBRO resueltas (no raw_*) - es el export de "estado actual" para reemplazar el Excel de Eugenia, distinto de rutap.v_export_libro (que ya existe y hace round-trip literal del libro tal cual vino, con filtro de snapshot). No bloquea nada mas del plan de 299.
• wi-cli-venus progress · 3w ago
  Read-only DEV mapping 2026-09-19: rutap.v_vehiculo_historial_actual currently exposes 62 columns and selects one current row per vehicle/domain across app events plus the latest import internally; rutap.v_export_libro exposes 41 columns = rutap_snapshot_id + rutap_fila + the 39 RUTAP business columns. Contract for the remaining view: rutap.v_export_estado_actual should expose those same 39 business column names/order, omit snapshot/fila and every raw_* field, select from v_vehiculo_historial_actual without any snapshot literal/filter, and resolve catalog IDs with active business/catalog views to nombre_mostrable (plus canonical entity/line/service/subtype names). Trámite must come from tramite_id (sample import rows have blank normalized tramite text but resolved ALTA/MODIF labels exist). No database write performed; DEV DDL needs its fresh write GO.
• wi-cli-venus assigned · 3w ago
  coder03-mba-l-ca / coder
• wi-cli-venus progress · 3w ago
  Clarified exact DEV relations for migration: entity via active-only public.v_entidades(id,cuit,nombre), with COALESCE to typed h.cuit/h.identificador_empresa; line must NOT use v_lineas because its active assignment join can duplicate a line, so use public.lineas(id,numero_linea) with borrado_en IS NULL and fallback h.linea_numero; service public.regimen_servicio_modalidad(id,descripcion) active and fallback h.tipo_servicio; subtype public.vehiculos_subtipos_transporte(id,descripcion) active; catalog values via public.v_opciones(id,nombre_mostrable). Tramite uses COALESCE(option label,NULLIF(btrim(h.tramite),'')); fallbacks preserve normalized legacy values, never raw_*.
• wi-cli-venus progress · 3w ago
  Frozen migration artifact: commit 18e618e22ea62eef1394874f340fb0486f4c642d, path docs/migrations/2026-09-19-movilba-299-v-export-estado-actual-DEV-Y-PROD.sql, SHA256 9b28a1e404d7d807e52308bc5dbb987cd83ef4d752a1c653e11ce17b65a34730. Exact DDL: CREATE VIEW rutap.v_export_estado_actual, COMMENT, derived ALTER OWNER, conditional SELECT grants. Default ROLLBACK; apply only with -v apply=true. PRE requires the MOVILBA-514 dedicated AC catalog and zero stale AC refs. POST asserts exact 39-column/order parity with v_export_libro after its two provenance columns, 1:1 current-row cardinality, active resolver completeness, no raw/snapshot dependency, tramite_id resolution with normalized fallback, and owner parity. Static diff check passed; DEV/PROD untouched. Sent to audit-mba-l-cc and db02-mba-l-ca for review/preflight before one precise DEV GO question.
• wi-cli-venus verified · 3w ago
  Independent static audit PASS for frozen current-state export migration commit 18e618e22ea62eef1394874f340fb0486f4c642d, blob df1028cb55d68a044d740415cf11465c124d9270, SHA256 9b28a1e404d7d807e52308bc5dbb987cd83ef4d752a1c653e11ce17b65a34730. Exact 39 business-column order from v_export_libro; no provenance/raw/snapshot fields; option-backed fields resolve through scoped v_opciones catalogs/nombre_mostrable; tramite_id canonical with normalized fallback. PRE/POST gate dependencies, MOVILBA-514 air catalog, column identity, cardinality, unresolved IDs, definition safety and owner. Default is transactional rollback; exact artifact may proceed to precise DEV GO request.
• wi-cli-venus blocked · 3w ago
  Independent read-only review of commit 18e618e2 / SHA256 9b28a1e4: syntax parses; DEV source/join/distinct=2431/2431/2431, populated unresolved IDs=0; PROD is correctly sequenced after MOVILBA-514 because its 2413 current air references still fail dedicated-catalog resolution. Required artifact correction before DEV GO: motor currently projects only v_ui_fabricantes.label; add COALESCE(motor.label,h.motor_fabricante) and a preservation gate so a future unresolved/deactivated manufacturer cannot erase typed normalized/app data. Current population masks the defect (0 motor text without ID). Both audit lanes and coder03 told to hold old commit and re-audit revised bytes. No DB write performed.
• wi-cli-venus audit-finding · 3w ago
  RETRACTION/HARD HOLD: prior static PASS for commit 18e618e2 SHA 9b28a1e4 is withdrawn after db02 data-contract review identified a preservation defect. Projection lacks fallback to normalized ; unresolved or later-deactivated manufacturer can silently erase stored normalized/app data, while current population masks it. Require COALESCE(motor.label,h.motor_fabricante), explicit preservation gate, refrozen commit/blob/SHA, and complete re-audit before any DEV GO. No DB write authorized.
• wi-cli-venus audit-finding · 3w ago
  CORRECTION to immediately preceding retraction event (shell removed two identifiers): prior static PASS for commit 18e618e2 SHA 9b28a1e4 is withdrawn. Projection motor.label AS motor lacks fallback to normalized h.motor_fabricante; unresolved or later-deactivated manufacturer can silently erase stored normalized/app data, while current population masks it. Require COALESCE(motor.label, h.motor_fabricante), explicit preservation gate, refrozen commit/blob/SHA, and complete re-audit before any DEV GO. No DB write authorized.
• wi-cli-venus verified · 3w ago
  Fresh independent review PASS for corrected immutable artifact: commit 5ed48eeb091b934e133749812ba0328e703711a1, blob e0f8e3cea2df8d6d22c5fdaf961250c1d5f778f7, SHA256 51e6a79ae8a0e2554ea6ec757f2158db0d517fdc3de0a4cd9b83ab88ac017fec. Hashes/worktree/diff-check match; exact SELECT parses by read-only EXPLAIN. Delta from blocked artifact is only COALESCE(motor.label,h.motor_fabricante), a data-preservation POST check, and a pg_get_viewdef expression check. DEV: 2431 source rows, 0 duplicate domains, 0 duplicate vehicle IDs, 2430 nonblank normalized motor values and 2430 preserved outputs. Earlier full join preflight remains source/join/distinct=2431/2431/2431 and unresolved populated IDs=0. PROD sequence remains MOVILBA-514 first, because its 2413 current air references fail the dedicated-catalog gate until remapped. No DB write performed; fresh independent audit and explicit DEV GO still required.
• wi-cli-venus verified · 3w ago
  Corrected artifact static re-audit PASS for rollback-only DEV preflight only. Exact commit 5ed48eeb091b934e133749812ba0328e703711a1, blob e0f8e3cea2df8d6d22c5fdaf961250c1d5f778f7, SHA256 51e6a79ae8a0e2554ea6ec757f2158db0d517fdc3de0a4cd9b83ab88ac017fec; clean worktree. Corrected projection preserves normalized motor_fabricante via COALESCE and adds preservation plus installed-definition gates. apply=true remains blocked pending audited rollback preflight and explicit user GO.
• wi-cli-venus note · 3w ago
  AUDIT TRIAGE - DB batch #1. Complete PROD prerequisite plus original view migration. Current HOLD is narrow: prerequisite must fail closed by mapping movilba_dev->movilba_user and movilba->movilba_owner and asserting the derived owner before granting SELECT on public.v_ui_fabricantes. Then rerun rollback rehearsal and apply exact reviewed bytes only. Estimate: 0.5-1.5h.
• wi-cli-venus verified · 3w ago
  AUDIT 2026-09-20: corrected prerequisite exact identity 8b3f01cbeee994456eb307ec130f788bb5163d20 / blob 11b65d76a889b1bf30e523a734bdcddbd58455d4 / SHA256 0c6412d84ca4005f3c50a96e6ce0bf2525c29987b5725809d7006dfc3371847d passed independent static review and DEV apply=false rehearsal evidence review. Evidence SHA256 576a721cb1e54170857c5bf94df4e4745ac79ac91c721eec708a308a72581e96: PRE/POST pass, explicit ROLLBACK, fresh ownership/effective privilege/ACL unchanged. Prior owner-pin HOLD is resolved. No apply=true performed; PROD sequence remains subject to its own exact-artifact rehearsal and fresh evidence.
• wi-cli-venus verified · 3w ago
  AUDIT 2026-09-20: DEV prerequisite apply evidence SHA256 ac8426511fbb684d1e44a6b777cf9a82bd565ec9245456bbedb502698d3398de PASS at exact 8b3f01cb/11b65d76/0c6412d8; COMMIT and fresh explicit ACL confirmed. PROD prerequisite rollback evidence SHA256 971bc79906e3dc0b7e3cd292cf458489357812fe8e16e81b7cf1659d884a1020 PASS: owner movilba_owner, PRE SELECT=false, in-tx POST=true, explicit ROLLBACK, fresh SELECT=false and ACL byte-identical. Exact PROD prerequisite apply quality-released; original view migration still requires its own post-grant rehearsal/evidence.
• wi-cli-venus progress · 3w ago
  DB execution status 2026-09-20: DEV prerequisite grant applied and view applied; PROD original view rehearsal safe-failed on missing owner SELECT and left target absent. Corrected prerequisite artifact 8b3f01cb/0c6412d8 passed DEV rollback+apply and PROD rollback rehearsal. PROD prerequisite apply is held only for independent evidence review/release; review requested from coder03/audit. Evidence SHA 971bc79906e3dc0b7e3cd292cf458489357812fe8e16e81b7cf1659d884a1020. Once released: exact-byte prerequisite apply, then original 5ed48eeb/51e6a79a PROD rehearsal/apply with PROD-local denominators.
• wi-cli-venus verified · 3w ago
  Independent audit PASS for PROD prerequisite rollback rehearsal. Exact artifact 8b3f01cbeee994456eb307ec130f788bb5163d20 / blob 11b65d76a889b1bf30e523a734bdcddbd58455d4 / SHA256 0c6412d84ca4005f3c50a96e6ce0bf2525c29987b5725809d7006dfc3371847d; evidence SHA256 971bc79906e3dc0b7e3cd292cf458489357812fe8e16e81b7cf1659d884a1020. Released prerequisite PROD apply=true only. Original view still requires a fresh PROD apply=false rehearsal after grant commit.
• wi-cli-venus verified · 3w ago
  PROD view apply complete. Exact 5ed48eeb/e0f8e3c/51e6a79a committed after prerequisite and rollback rehearsal. Fresh target owner movilba_owner, 39 columns, 2413 rows/domains, runtime svc_nextjs reads 2413, dependency privilege retained. Evidence: /data-lezama/movilba-web/evidence/2026-09-20-movilba-299-view-prod-apply-db02-mba-l-ca.md
• wi-cli-venus verified · 3w ago
  Independent final audit PASS for PROD rutap.v_export_estado_actual apply. Exact commit 5ed48eeb091b934e133749812ba0328e703711a1 / blob e0f8e3cea2df8d6d22c5fdaf961250c1d5f778f7 / artifact SHA256 51e6a79ae8a0e2554ea6ec757f2158db0d517fdc3de0a4cd9b83ab88ac017fec. Apply evidence /data-lezama/movilba-web/evidence/2026-09-20-movilba-299-view-prod-apply-db02-mba-l-ca.md SHA256 b122bb1668363f02544b81cd36e0f79f80a72baa8708a319fdbcbc9eee680cfe. COMMIT; fresh owner movilba_owner, 39 columns, 2413 rows/domains, runtime svc_nextjs reads 2413, dependency privilege retained.
• coder04-mba-l-ca progress · 3w ago
  coder04-mba-l-ca | 2026-09-24 04:01 ART. Measured dev source only: rutap v_export_estado_actual work is recorded as applied on PROD, but the broader typed-history JSONB retirement is not established by that view. Leaving backlog on parked coder03-mba-l-ca; requires DB-owned contract census before closure.
• coder03-mba-l-cc assigned · 2w ago
  coder04-mba-l-ca
• coder04-mba-l-ca progress · 2w ago
  coder04-mba-l-ca | 2026-09-28 12:56 ART — Read current source at HEAD 6fc0e2c9: git grep for executable src readers of vehiculo_historial.cambios / vh.cambios returned no hits; app source is not currently consuming the legacy JSONB diff. This does not verify installed DB view dependencies or the remaining export/rebuild/drop sequence. Left backlog: DB-owned dependency census, round-trip gate on a different snapshot, rebuild, and final DROP remain unexercised; no DB work performed.
• coder04-mba-l-ca progress · 1w ago
  2026-10-06 source-reader census: rg across executable src found zero direct readers of public.vehiculo_historial, vehiculoHistorial ORM symbol, or its cambios JSONB. Current app history consumers use rutap.vehiculo_historial_normalizado / its views. Step 1 MOVILBA-269 is done; remaining ticket gates are DB-owned dependency/view rebuild + non-tip snapshot round-trip/rebuild/drop. No source change or DB access performed. Next: db lane completes step 2 dependency census/repoint; coder03 owns step 3 round-trip gate.
• db03-mba-l-cc progress · 1w ago
  db03-mba-l-cc 2026-10-06 - step 2 census, SELECT only, PROD then DEV: public.vehiculo_historial does NOT exist in either base (to_regclass null). pg_depend confirms zero dependents on a table by that name. public.v_vehiculo_historial (the compat view carrying the name) is itself ALREADY repointed: its own viewdef FROMs rutap.v_vehiculo_historial_normalizado_fuente_actual, not the old table - identical in PROD and DEV. Every one of the 11 ticket-named views that currently exists (v_vehiculo_cadena, v_vehiculos_detalle, v_vehiculos_export, v_monitor_historial_anomalias, plus audit views) reads vehiculo_historial transitively THROUGH that already-repointed v_vehiculo_historial, never the dropped table directly. Step 2 is DONE, no DDL needed, no view body changes. Caveat: 4 of the ticket's named v_audit_* views do not exist under those exact names - live audit views are v_audit_entidades_sin_vinculo, v_audit_integridad, v_audit_lineas_sin_vinculo, v_audit_vehiculo_vs_linea_entidad, v_audit_vehiculos_sin_vinculo, v_audit_vinculos_a_padre_borrado; v_vehiculos_hist_ultimo, v_audit_integridad, v_audit_vehiculo_vs_linea_entidad and v_db_users_footprint_detalle reference nothing historial-related at all - ticket's name list predates current naming, not independently verified further.
• coder03-mba-l-cc note · 1w ago
  2026-10-06 16:xx coder03: db03 confirms step 2 done - public.vehiculo_historial doesn't exist in PROD or DEV (to_regclass null, 0 pg_depend), so steps 4 (rebuild) and 5 (DROP) already happened upstream of this ticket; nothing irreversible left to gate against. Re-scoping: step 3's rutap.v_export_libro already exists (migrations 498/574/574b/574c/600), no new view needed. Remaining work is the round-trip gate itself (export via v_export_libro raw_*, re-import, row-diff empty, run against a non-origin snapshot, fail on zero denominator) as a standing export-fidelity check, not a pre-drop guard. Reassigning actual build to coder04 (ticket's 'coder03' step-owner is stale per live-roster convention); coder04's own MOVILBA-704 read-only scripts (db04) already cover most of the comparator.
• coder04-mba-l-ca statusChanged · 1w ago
  2026-10-06: Step 3 implementation added as tools/rutap-export-roundtrip.py. It exports v_export_libro through the actual non-tip snapshot, writes an ephemeral RUTAP-layout XLSX, reparses it with rutap-snapshot-import.py::read_sheet, and compares all 39 cells by fila_excel against rutap_rows; explicit nonzero denominator and one-cell negative control. No gate run locally; sending exact file to audit.
• audit-mba-l-cc audited · 1w ago
  audit fail: Ran tools/rutap-export-roundtrip.py against DEV read-only (snapshot 20); reviewed script in full
  payload

  {"scope":"Ran tools/rutap-export-roundtrip.py against DEV read-only (snapshot 20); reviewed script in full","outcome":"fail","evidence":"51157 cell diffs, all casing (SI/NO/BAJO catalog canon vs Si/No/Bajo raw book text) - piso/aire_acondicionado/cabina_antivandalica/adas/mdvr/pantallas/wifi/conexionesusb/identidad. Confirmed via psql: opciones.valor_opcion is uppercase canonical (24 SI/25 NO). Comparator wrongly byte-matches view-reimport against raw rutap_rows; catalog label != raw text by design (MOVILBA-574). Negative control also failed as a symptom (witness row already had 9 real diffs pre-mutation).","reportRef":null}

• coder04-mba-l-ca statusChanged · 1w ago
  2026-10-06 audit correction: the first comparator incorrectly included catalog-resolved fields. Updated tools/rutap-export-roundtrip.py to restrict the XLSX/reimport row-diff to the 22 fields MOVILBA-574 explicitly leaves raw; catalog-resolved SI/NO/BAJO and other labels are excluded. No gate run locally; resubmitting for audit.
• audit-mba-l-cc audited · 1w ago
  audit pass: Reviewed revised tools/rutap-export-roundtrip.py (RAW_FIELDS now 22 cols, verified against MOVILBA-574's raw_carroceria_categoria list), ran it myself PROD+DEV read-only
  payload

  {"scope":"Reviewed revised tools/rutap-export-roundtrip.py (RAW_FIELDS now 22 cols, verified against MOVILBA-574's raw_carroceria_categoria list), ran it myself PROD+DEV read-only","outcome":"pass","evidence":"DEV snapshot 20: 5548/5548 rows, 0 cell diffs, negative control=1. PROD snapshot 8: same. carroceria_categoria confirmed n.raw_carroceria_categoria in 574's view def, not catalog-resolved. Prior FAIL (casing false positives) resolved by excluding catalog-backed fields from roundtrip domain.","reportRef":null}

• researcher-mba-l-cc note · 1w ago
  researcher 2026-10-08 13:17 ART: no open sub-question is actually pending for Elazar on this ticket right now. GO was already given 2026-09-06; steps 1/2/4/5 are done (coder04/db03 confirmed); step 3's round-trip gate is mid audit-fail/retry (audit failed 2026-10-06 19:29, coder04 fixed the comparator's field scope same day, resubmitted, audit passed 19:32). This is execution in progress, not a decision - nothing here needs escalation to Elazar.
• coder04-mba-l-ca completed · 1w ago
  Remaining step-3 standing round-trip gate is already committed as a92e42ef (v5.6.176) and audit PASS on 2026-10-06: PROD snapshot 8 and DEV snapshot 20, 5,548/5,548 rows, 22 raw columns, zero cell/row diffs, negative control=1, non-tip snapshot and zero-denominator fail gates. PROD/DEV/pod now serve later builds. DB census established typed history and view repointing already live, old public.vehiculo_historial absent in both; steps 4/5 already occurred upstream. No further code or DDL owed under this item.