Definir que campos de fecha/tramite necesita vehiculo_historial: vigencia_desde/hasta NO alcanza porque hay tramites sin fechas (ej. cambio de asientos)

Sub-tickets — 1/1 done

Activity

• wi-cli-venus created · 2026-08-20
• wi-cli-venus commented · 2026-08-20
  VEREDICTO audit: de acuerdo con los campos con forma de Excel, pero NO aprueba 'fila vigente = mayor fecha_alta' como regla completa. Un Modif es evento puntual, sin intervalo de validez. Mayor fecha_alta identifica el ultimo evento SOLO si las fechas son unicas; pares alta/baja o Alta+Modif del mismo dia necesitan desempate por ORDEN DE ORIGEN. Propone snapshot_id + fila_excel (procedencia, NO fechas de validez de negocio); id/creado_en NO es contrato de orden de origen. CUATRO SEMANTICAS SEPARADAS: (1) tramite cerrado = fecha_baja presente, con gate de integridad para expte_baja presente y fecha_baja ausente; (2) estado de servicio actual del vehiculo = vdc.estado_id, NO una fila de historial; (3) ultimo evento = ORDER BY fecha_alta + secuencia de origen con regla de empate explicita; (4) borrado_en = retencion/soft-delete y nada mas. NO llamar 'vigente' a ninguna fila hasta que la proyeccion y la regla de empate esten definidas. Campos: tramite queda como texto de origen (o catalogo que PRESERVE el valor crudo); fecha_alta NOT NULL y significa FECHA DEL EVENTO, no inicio de validez; fecha_baja/expte_baja nullable; cambios es derivado sin origen Excel. Si un origen futuro no trae fecha de evento, CUARENTENA, no inventar. EL BLOQUEANTE QUE QUEDA es la proyeccion de orden-de-origen/evento-vigente, no los nombres de campos.
• wi-cli-venus commented · 2026-08-20
  fila_excel MEDIDO por db-mba-l-cc (que propuso el desempate y lo verifico contra su propia propuesta). Leyendo los xlsx con openpyxl, hoja Base, header fila 2, datos desde fila 3. 08-18 vs 08-20: 2388/2388 dominios en comun, TODAS las posiciones identicas, cero dominios nuevos, ambos max fila 5088 - sin crecimiento en esa ventana, asi que ese par no prueba nada. 08-13 (superseded) vs 08-20, una semana con ediciones reales: 2388/2388 en comun, 2387 posiciones identicas, UNA excepcion - PMH988 gano un tramite nuevo, que aterrizo en fila 5088 (el max del 08-13 era 5087). Las filas existentes NO se corrieron. CONCLUSION: el crecimiento es APPEND-ONLY, los tramites nuevos van al final y lo ya escrito no se mueve. CAVEAT del que midio: n=1 para el caso de crecimiento real, o sea CONSISTENTE CON estable, no PROBADO bajo volumen. Si el flujo de Eugenia alguna vez inserta o reordena filas a mano en Excel (y no solo agrega al final), esto se rompe EN SILENCIO. Va como nota permanente en el documento de disenio, no como asunto cerrado. Nota: el par snapshot_id + fila_excel que propuso audit cubre justamente el caso de reordenamiento entre libros, porque el snapshot ancla la posicion a un libro concreto.
• wi-cli-venus commented · 2026-08-20
  PROYECCION (db02, disenio solo). MEDICION QUE ACOTA fila_excel: append-only reconfirmado por segunda clave (5085 tramites en ambos libros 08-13/08-20, delta 0 en TODOS, max 5087->5088). PERO crecimiento append-only NO es orden cronologico dentro del vehiculo: sobre 4260 pares de filas del mismo dominio, 3589 con la posterior mas nueva, 651 (15%) con la posterior mas VIEJA, 20 empates. fila_excel NO es senial cronologica intra-vehiculo - usarlo como orden primario saca 651 pares al reves. Sobrevive porque los empates son raros: solo 20 dominios tienen dos tramites con la misma fecha_alta, y solo 14 la tienen en la fecha maxima del vehiculo, que es el unico lugar donde el desempate cambia cual es la vigente. ENUMERAR Y MIRAR esas 14 antes de shippear. LAS 4 PROYECCIONES: (1) ULTIMO EVENTO = DISTINCT ON (vehiculo_id) ORDER BY vehiculo_id, fecha_alta DESC, snapshot_id DESC, fila_excel DESC - fila_excel INALCANZABLE salvo empate de fecha_alta; participan todos los tipos, Modif incluido. (2) PERIODO VIGENTE = solo filas tramite='Alta', la de mayor fecha_alta con el mismo desempate; CERRADO sii fecha_baja NOT NULL; los Modif EXCLUIDOS por construccion, un evento puntual no puede hacer que un vehiculo parezca abierto ni cerrado. (3) ESTADO DE SERVICIO = vdc.estado_id, no se deriva ni se espeja en historial. (4) RETENCION = borrado_en, soft-delete y nada mas, NUNCA consultado por 1/2/3. TRAMITE NULLABLE: la fila sin Tramite es fila_excel 1558, AI278EY, interno 234, linea 44, Fecha Alta 2026-07-16, Expte Alta EX-2026-32555710. Entra NULL, el importador la marca, va a la hoja de Eugenia como PREGUNTA. NULL se EXCLUYE de la proyeccion 2 (no se puede asumir Alta) y se INCLUYE en la 1. GATE DE REORDEN en el importador: para cada tramite presente en el snapshot anterior y el actual, comparar fila_excel; cualquier delta distinto de cero se REPORTA, nunca se auto-acepta - convierte una suposicion no medida en una monitoreada.
• wi-cli-venus commented · 2026-08-20
  LAS 14 ENUMERADAS Y REVISADAS por db-mba-l-cc (SELECT-only, conteo identico al de db02, medido independientemente). 13 de 14 son pares de fila_excel adyacentes (delta 1-2), incluidos los 4 AF8xx/AF9xx que db02 ya habia retractado como falsos duplicados - el desempate los resuelve trivialmente. El unico outlier, mirado a ojo: OPB348, filas 2195 y 2227, delta 32 - NO es un empate simultaneo real. La fila 2195 abrio Y cerro el mismo dia (2025-07-08 -> 2025-07-08, 'Cambio N de interno'), artefacto auto-superseded del mismo dia; la 2227 lleva el MISMO expediente pero vivio hasta 2026-04-01 con el interno corregido. fila_excel DESC elige la 2227, que es CORRECTO - y lo es porque es la fila que efectivamente persistio, no por la posicion cruda. Las 14 dan la respuesta correcta. DECISION DE COORDINACION (coder-mba-l-cc): tramite = VARCHAR + vista de catalogo para el desplegable, NO FK a opciones - opciones tiene trampas conocidas de clave natural y re-alta, el libro va a crecer tipos de tramite nuevos sin avisarnos (un FK convierte eso en falla de ingesta en vez de fila nueva) y la regla vigente es que filtros y catalogos viven en vistas. El valor crudo de origen se preserva, que era la condicion de audit. db02 y db votaron varchar+vista.
• wi-cli-venus commented · 2026-08-20
  TABLA COMPLETA de las 14, mirada fila por fila (db-mba-l-cc). Las 14 defendibles: en todos los casos la fila elegida (fila_excel mayor) lleva un expediente DISTINTO de la no elegida, misma fecha_alta, con forma de cargas del mismo dia en orden de presentacion. AB259JY 4082 Alta -> 4084 Modif; AE352LD 4073 Alta -> 4074 Modif; AF821DV 2539->2540; AF875JB 2591->2592; AF875JQ 2480->2481; AF899TF 2601->2602 (los cuatro AF8xx/AF9xx eligen la fila con el MISMO expediente EX-2025-55184093, un expediente de lote cerrando 4 tramites previos el mismo dia - forma consistente, no bandera roja); AH850FS 4829->4830; AH850GK 4980->4981; AI023DC 4881->4882; AI024HE 4749->4750; AI058QM 4921->4922; AI105QP 3871 Modif -> 3872 Alta; AI357IV 3917 Modif -> 3918 Alta (en los dos el evento de registracion real le gana a una nota administrativa del mismo dia, que es lo correcto); OPB348 2195 -> 2227. SIGN-OFF de db: la proyeccion es solida como esta disenada. Falta solo el sign-off de audit.
• wi-cli-venus commented · 2026-08-20
  LAS 14 CON DATOS COMPLETOS (db02, 28 filas). VALIDACION FUERTE: las cinco filas de linea 151 son los mismos vehiculos del bug de cadena de anoche, y AH850GK, AI023DC y AI024HE son EXACTAMENTE los 3 de 131 que la regla vieja de DISTINCT ON erraba. En los tres la proyeccion elige la fila con la fecha_baja POSTERIOR, la terminal verdadera. La regla nueva acierta, con evidencia independiente, justo los casos que la vieja erraba. SEGURAS 12/14. Linea 68 (4 vehiculos): ambas filas con fecha_alta Y fecha_baja identicas, el desempate da lo mismo; lo unico que cambia es que expte_alta se muestra - EX-2025-55184093 es expediente de LOTE compartido por los 4, el otro es el per-vehiculo. Cosmetico, pero si la ficha deberia mostrar el per-vehiculo, esta regla muestra el de lote. Anotado, no bloquea.
• wi-cli-venus blocked · 2026-08-20
  SIGN-OFF 3/3 (db02 disenio, db revision independiente, audit). La proyeccion es solida en los 12 casos seguros y ARREGLA los 3 errores de linaje previos (AH850GK, AI023DC, AI024HE = exactamente los 3 de 131 que erraba la regla vieja). RESUELTO POR coder-mba-l-cc: AI105QP/AI357IV se aceptan como los leyeron db02 y db - 'abierto' no es un estado en el que un Modif pueda estar (evento puntual, nunca recibe fecha_baja por construccion), asi que la ausencia de fecha_baja no lleva informacion y no puede ganarle a un evento de registracion real; va al documento de disenio como regla escrita con su razon. UNICO BLOQUEANTE VIVO: OPB348 espera a Eugenia - mismo expte_alta, misma fecha_alta, interno distinto (24 vs 46), uno cierra el mismo dia y el otro vive hasta 2026-04-01; el desempate lo resuelve por posicion de archivo, que es una resolucion y no una razon. Sin DDL ni escrituras hasta que vuelva su respuesta. Falta ademas el GO de Elazar sobre la lista de campos.
• wi-cli-venus commented · 2026-08-20
  PRECISION SOBRE EL SIGN-OFF, pedida por db02 y correcta: en AI105QP/AI357IV NO fue 3-0. audit dijo 'defensible bajo semantica de periodos solo-Alta PERO necesita confirmacion humana'. Mi ruling lo cerro como lectura correcta del modelo de datos sin subirlo a Elazar; db02 y db coinciden con el ruling. Queda registrado como: CERRADO por lectura de db/db02/coder, audit concurrio en que es defendible y HABIA PEDIDO confirmacion humana que no se le dio. Si algun dia resulta equivocado, quien lo revise tiene que poder ver que un carril queria un humano ahi. Barato de anotar ahora, caro de reconstruir despues.
• wi-cli-venus commented · 2026-08-20
  LIMITE DEL RULING 1, encontrado por coder02 al construir el gate de reorden - EL RULING NO CUBRE ESTE CASO y hay que decirlo explicito o el proximo que lo lea va a creer que si. Los 4 dominios de linea 68 (AF821DV, AF875JB, AF875JQ, AF899TF) tienen sus DOS filas con tramite='Modif', misma fecha_alta 2025-12-26, misma fecha_baja 2026-01-07 y mismo expediente de baja. Difieren SOLO en el expediente de ALTA, y uno de los dos es EX-2025-55184093 en los cuatro, o sea un expediente de LOTE. El ruling 1 desempata 'Alta cerrada el mismo dia' contra 'Modif abierta'; aca no hay ninguna abierta y ninguna es Alta, las dos estan cerradas con las mismas fechas. Para ese par la posicion en el archivo NO es el ultimo recurso: es el UNICO discriminador. IMPACTO: solo de visualizacion - las dos filas son identicas en fecha_alta y fecha_baja, asi que la proyeccion da lo mismo; lo unico que cambia es que expte_alta se muestra, y la regla actual muestra el de LOTE en vez del per-vehiculo. AD919PL es otra forma y esa SI la resuelve el ruling 1 (un solo expediente de alta, mismo interno 4533, una Alta cerrada el mismo dia y una Modif que vive hasta 2025-10-31).
• wi-cli-venus unblocked · 2026-08-20
  GO de Elazar 2026-08-20 sobre la lista de campos. Alcance autorizado = el cambio de esquema y el codigo que lo lee. OPB348 sigue sin respuesta de Eugenia pero NO bloquea: es una pregunta de desempate/visualizacion, no de que campos existen.
• wi-cli-venus commented · 2026-08-20
  DATO QUE SIMPLIFICA EL PASO 3 (coder02, medido sobre el importador, no recordado): los nombres DESTINO ya existen verbatim en rutap_rows del snapshot. Columnas reales hoy: nro_dominio, linea, nro_interno, chasis_nro, motor_nro, fecha_alta, fecha_baja, expte_alta, expte_baja, tramite, observaciones. El rename expediente->expte_alta / expediente_baja->expte_baja / fecha_expediente->fecha_alta no acerca Postgres al Excel por primera vez: lo acerca a un nombre que el pipeline YA usa desde la ingesta. La restriccion de nombres de Elazar se cumple sola y la transformacion snapshot->Postgres pasa a ser IDENTIDAD para esos campos en vez de un mapeo. Idem paso 1: rutap_rows.tramite ya existe con los valores tal cual ('Alta','Modif') y fecha_baja tambien, asi que el backfill del paso 2 lee columnas YA cargadas, no derivadas. LAS 15 CLAVES AMBIGUAS que el paso 2 va a reportar, conocidas de antemano en vez de descubrirlas a mitad del ensayo: AB259JY, AD919PL, AE352LD, AF821DV, AF875JB, AF875JQ, AF899TF, AG358KX, AH850FS, AH850GK, AI023DC, AI024HE, AI058QM, AI105QP, AI357IV. Cinco son las de linea 151 (los 3 de 131 del bug de cadena entre ellas) y cuatro las de linea 68 que el ruling 1 NO cubre. No son un defecto del backfill: son el mismo caso del ruling y su enmienda. EXPORT AISLADO: src/lib/exports/vehiculos.ts mapea key->header explicitamente ('expedienteAlta' -> 'Expediente alta'), no deriva del nombre de columna, asi que el rename no toca los headers congelados SIEMPRE Y CUANDO las VISTAS sigan emitiendo los mismos nombres de salida. Esa es la condicion real a verificar en el paso 3, no el codigo.
• wi-cli-venus commented · 2026-08-20
  DEPENDENCIA DE VISTAS PRE-MEDIDA (db-mba-l-cc, antes del ensayo en vez de bloquearlo). El paso 3 NO es un RENAME COLUMN plano: 6 vistas se rompen - v_vehiculo_historial, v_vehiculo_cadena, v_vehiculos_detalle, v_vehiculos_lineas_entidades, v_vehiculos_hist_ultimo, mas v_vehiculos_api_public solo en el DROP de estado_id del paso 4. v_vehiculos_export esta LIMPIA: su expediente_baja/estado_id leen de vdc, no de vehiculo_historial - falso positivo de la primera pasada. Detalle a nivel columna enviado a db02. NOTA DE ALCANCE (coder-mba-l-cc): la verificacion correcta del paso 3 no es 'que vista referencia los nombres viejos' sino 'que vista CAMBIA SUS NOMBRES DE SALIDA' - el export lee una VISTA y las keys del codigo (src/lib/exports/vehiculos.ts, 'expedienteAlta' -> 'Expediente alta') se atan a los nombres de salida de la vista, no a los de la tabla. Si una vista se reescribe emitiendo expte_alta en vez de expedienteAlta, el export se rompe sin que cambie ningun header ni ninguna linea de codigo. Toda vista que alimente el export o la API debe seguir emitiendo EXACTAMENTE lo que emite hoy.
• wi-cli-venus commented · 2026-08-20
  CHEQUEO CORREGIDO DEL PASO 3 completado (db-mba-l-cc): 'que vista CAMBIA SU NOMBRE DE SALIDA', no 'cual referencia las columnas viejas'. Columnas de salida sacadas de information_schema para las 6 candidatas. EN RIESGO 2 de 6, necesitan re-alias explicito o hay que actualizar a todos sus consumidores: v_vehiculo_historial expone expediente, fecha_expediente y expediente_baja como pass-through CRUDO sin alias (es la vista que mas probablemente lee el codigo por nombre); v_vehiculos_lineas_entidades expone expediente, misma exposicion. SEGURAS 4 de 6, solo reescritura interna sin riesgo de nombre de salida: v_vehiculo_cadena (vh.estado_id ya aliaseado dentro de un LATERAL); v_vehiculos_detalle (expediente/estado_id/motivo_id son claves DENTRO del blob jsonb_agg 'historial', no columnas planas - information_schema confirma que no existe columna plana; el contrato JSON se preserva independiente del rename); v_vehiculos_hist_ultimo (fecha_expediente es SOLO ORDER BY, nunca en el SELECT); v_vehiculos_api_public (estado_id solo dentro del CTE latest_historial para calcular fecha_estado/ultima_modificacion - usar vh.creado_en al reescribir, porque estado_id se DROPEA, no se renombra). CONFIRMADO trazando que selecciona cada una: NINGUNA de las 2 en riesgo alimenta v_vehiculos_export ni v_vehiculos_api_public (el export lee vdc directo; api_public usa el estado_actual plano de v_vehiculos_detalle mas su propio CTE). La superficie de export/API esta limpia; la exposicion esta enteramente en el codigo de la app que lee esas 2 vistas por nombre de columna, que ya cae dentro de mis 24 referencias.
• wi-cli-venus commented · 2026-08-20
  HALLAZGO QUE CAMBIA QUE SON LOS CAMPOS DE EXPEDIENTE (db02, snapshot 4, prod, 05:24, denominador 5086). Valores que NO empiezan con EX: 515 en expte_alta, 487 en expte_baja. LA MAYORIA NO ES CONTAMINACION: son RESOLUCIONES, un segundo tipo legitimo de instrumento legal. Res. SECT 214/2025 (93), Res-SECT-2025-214 Cesion T.GUIDO/TARSA (93), Res. SECT 207/2025 (77/76), RESOL-2026-56-GCABA-SECT (39), Res. SECT 18/2026 Fusion lineas 99 y 106 (36/35), Baja por modelo Res. SECT 139/2025 (21), Baja de oficio Res. SECT 65/2026 (18). Una cesion entre empresas, una fusion de lineas o una baja de oficio NO las abre un expediente: Eugenia anota la resolucion. EL CAMPO NO ES 'el expediente', ES 'el instrumento que abrio o cerro este periodo', y ~1 de cada 10 es una resolucion. CONSECUENCIA DE DISENIO: expte_alta y expte_baja quedan varchar libre SIN validacion de formato, NUNCA. Conservar el nombre del Excel es correcto por la restriccion de Elazar, pero EL NOMBRE ES MAS ANGOSTO QUE EL CONTENIDO. Quien agregue despues un CHECK '^EX-' rechaza 515 filas legitimas en silencio. Va como COMENTARIO EN LA COLUMNA, no como folklore. EL DEFECTO REAL en ese conjunto es UN solo valor: 'Se modifican datos a pedido de la empresa', 474 veces, en expte_alta Y expte_baja - es el texto de observaciones metido en una columna de expediente, un corrimiento de columna en el libro. 474 filas no es un typo, es un relleno sistematico. El paso 2 NO debe escribir esos 474 como si fueran instrumentos. LA CLAVE (dominio, fecha_alta, interno) NO ES UNICA: 15 claves duplicadas, 30 filas - exactamente la lista de 15 de coder02, obtenida independientemente y desde el otro lado. Las 'claves ambiguas' del paso 2 NO son defectos de backfill: son los 15 lugares donde la clave no separa dos filas. Se reportan, no se resuelven, y el numero se sabe de antemano. AG358KX es FAMILIA NUEVA: 6 filas con TRES internos distintos en una misma patente (23, 61, 68), 'Cambio N de interno' dos veces - una patente que se movio entre numeros internos. Las filas 975 y 978 comparten fecha_alta Y interno 23, asi que es COLISION DE CLAVE, no falla de match. PRUEBA INCIDENTAL DE LA PROYECCION: la cadena de AD919PL corre 3443 -> 3444 -> 3442; la cola (3442) tiene fila_excel MENOR que las dos que la preceden cronologicamente. Una regla fila_excel-primero elige 3444 y se equivoca; fecha_alta-primero elige 3442 y acierta. Es la propiedad del 15%-al-reves apareciendo en un vehiculo real y no en un agregado - por eso fila_excel queda inalcanzable salvo empate exacto de fecha_alta.
• wi-cli-venus commented · 2026-08-20
  PASO 1 escrito y ensayado limpio en DEV (db02). Archivo docs/migrations/2026-08-20-movilba-76-paso1-add-tramite-fecha-baja-DEV.sql, apply=false, revertido, dev intacto. GATE 0 se niega a correr si current_database() no es movilba_dev y si las columnas ya existen; conteo inicial medido en el momento: 3951 filas en movilba_dev (prod tiene 4045 - ninguna de las dos cifras se lleva al gate del otro entorno). ALTER tramite varchar(20) NULL + fecha_baja date NULL, las dos con COMMENT ON COLUMN explicando por que tramite es nullable y que fecha_baja - NUNCA borrado_en - responde 'este tramite esta cerrado'. GATE 1 verifica tipo y nullabilidad leyendo information_schema en vez de creerle al DDL, y afirma 0 filas con valor (el paso 1 no escribe dato). GATE 2 recorre TODAS las vistas con SELECT 1 atrapando excepciones: 87 de 87 consultables. DELIBERADAMENTE FUERA del paso 1: cualquier CHECK sobre expte_alta/expte_baja - 515 y 487 de esos valores son resoluciones, no expedientes, y un '^EX-' rechazaria cientos de filas legitimas; la razon esta escrita en el header del archivo para que nadie lo agregue despues creyendo que fue un olvido. CORRECCION de db02 sobre si mismo: el paso 4 toca 5 vistas distintas, no 6 - habia sumado las 5 de estado_id y las 2 de motivo_id sin deduplicar, y las 2 de motivo_id ya estan dentro de las 5. Union verificada contra el catalogo: v_vehiculo_cadena, v_vehiculo_historial, v_vehiculos_api_public, v_vehiculos_detalle, v_vehiculos_lineas_entidades. Era un conteo de joins reportado como conteo de entidades - misma forma de defecto nombrada cinco veces esta noche, cuarta instancia suya.
• wi-cli-venus commented · 2026-08-20
  RULING 1 ANULADO Y RE-DECIDIDO. La premisa era FALSA y la aporte yo (coder-mba-l-cc). Dije: 'abierto no es un estado en el que un Modif pueda estar - un evento puntual nunca recibe fecha_baja POR CONSTRUCCION, asi que su ausencia no lleva informacion'. MEDIDO sobre snapshot 4: de 2612 filas Modif, 1342 NO tienen Fecha Baja y 1270 SI LA TIENEN. El ensayo del paso 2 en dev lo levanto independiente: 873 filas Modif backfilleadas con fecha_baja sacada del libro. Casi la mitad de los Modif llevan fecha de cierre. Un Modif con fecha_baja es ORDINARIO, no imposible - y por lo tanto un Modif SIN ella es un Modif genuinamente abierto, lo cual SI es informacion. RE-DECISION: la conclusion se mantiene, el razonamiento se reemplaza entero. La proyeccion 1 (ultimo evento) ordena por fecha_alta y despues por orden de origen (snapshot_id, fila_excel). La apertura o el cierre de una fila NO PARTICIPA de esa proyeccion en ningun momento. En AI105QP y AI357IV las dos filas comparten fecha_alta, asi que decide el orden de origen, y el Alta esta en la fila posterior: se elige el Alta. Eso es correcto POR ORDEN DE ORIGEN, no por nada relativo a que este cerrada. El ruling original invocaba una propiedad que la proyeccion no consulta - era un razonamiento sobre semantica de periodos aplicado a una consulta de ultimo-evento. NO CAMBIA: la proyeccion 2 excluye los Modif del periodo alta/baja por lo que un Modif ES (no es un evento de registracion), no por si lleva fecha - esa exclusion no dependia de la premisa rota. LECCION: audit habia firmado 'defendible PERO pide confirmacion humana' y esa confirmacion no se obtuvo; registrar el disenso verbatim, a pedido de db02, es la unica razon por la que esto se ve limpio ahora.
• wi-cli-venus commented · 2026-08-20
  CORRECCION A LA LISTA DE CAMPOS (coder02, midiendo el codigo antes de escribir 46): 'cambios' NO ES UN CAMPO NUEVO. Ya existe - drizzle/schema.ts:1266 lo tiene como cambios jsonb(), hay un indice GIN sobre el (idx_vehiculo_historial_cambios) y src/actions/vehiculos.ts:424 lo escribe HOY en cada registrarExpediente. La lista lo proponia como 'ADD ... explicitly derived'. Si la migracion lo trata como ADD, falla o pisa un indice existente. db02: sacarlo del ADD. audit: no cambia el disenio, el campo pasa de 'hay que crearlo' a 'ya esta, hay que usarlo mejor'.
• wi-cli-venus commented · 2026-08-20
  PROYECCION 2 ROTA - la reporta db02 contra su propio disenio, medido en movilba_dev 05:38 corriendo el backfill del paso 2 en una transaccion revertida. De 1603 filas vivas de historial: Modif 1347, Alta 250, NULL 6. Y 1351 de 1601 vehiculos vivos NO TIENEN NINGUNA fila viva con tramite='Alta'. El 84% de los vehiculos tiene un Modif como fila actual; sus Altas estan todas soft-deleted. CONSECUENCIA: la proyeccion 2 tal como la firmaron los tres carriles ('periodo vigente = la fila Alta de mayor fecha_alta, cerrado sii fecha_baja NOT NULL') NO DEVUELVE NADA para 1351 de 1601 vehiculos. Se disenio desde EL LIBRO, donde Alta y Modif conviven fila a fila, y nunca se contrasto contra lo que la TABLA tiene, que es UNA fila viva por vehiculo del tipo que sea con el resto borrado. La proyeccion 1 NO esta afectada (ordena por fecha_alta y despues orden de origen, participan todos los tipos, una fila por vehiculo) - es la que los datos efectivamente sostienen. db02 NO propone una proyeccion 2 reparada en el mismo mensaje en que la reporta rota, deliberadamente: es como entraron las ultimas tres premisas malas. Necesita re-medicion. TAMBIEN CAE MI PROPUESTA DE INDICE PARCIAL (coder-mba-l-cc): 'UNIQUE (vehiculo_id) WHERE borrado_en IS NULL AND tramite=Alta' vigilaria una fila que el 84% de los vehiculos NO TIENE, y dejaria sin restringir la fila que si tienen. Sale del disenio de 76 y suena bien; no sobrevive al contacto con los datos.
• wi-cli-venus commented · 2026-08-20
  EL HUECO DE INSTRUMENTO DE CIERRE ES 475, NO 272 (db02, prod snapshot 4, 05:52). De 3487 filas con Fecha Baja: 272 no tienen NINGUN instrumento - la cifra que veniamos citando - y 203 MAS tienen la frase de contaminacion 'Se modifican datos a pedido de la empresa' metida en Expte. Baja. Hueco real = 475 filas cerradas sin instrumento. La frase pasa cualquier chequeo de 'tiene valor' exactamente igual que un NBSP; el 272 lo produjo un chequeo que lee PRESENCIA, y la frase esta presente. Misma forma de defecto que hizo importante el hallazgo de NBSP, una capa mas alla. NBSP: las celdas solo-NBSP en Expte. Baja son 53, no 38, y reconcilian exacto en las dos direcciones - Excel 3268 celdas string + 1818 vacias = 5086; base 3215 no-nulas + 1871 NULL = 5086; 3268-53=3215 y 1818+53=1871, sin resto. Expte. Alta tiene CERO celdas solo-NBSP. EL IMPORTADOR YA LAS MATA: en rutap.rutap_rows snapshot 4 hay 0 cadenas vacias, 0 solo-espacios y 0 solo-NBSP en las dos columnas de expediente - las 53 llegaron como NULL. O sea el riesgo de poblacion fantasma es real EN EL ARCHIVO y ausente EN NUESTRA COPIA. (Aparte: 3128 expte_baja y 4205 expte_alta CONTIENEN un NBSP interior - conocido, otra cosa.) TERCERA LECTURA INDEPENDIENTE confirma las filas de salto de linea: 1353, 1374, 1406, 1440. Y NO es un offset en el informe de audit: sus OTRAS dos filas (2395 AH850GD, 2420 AH940VA) son exactas en la misma numeracion, con las fechas confirmadas - dos de sus cuatro numeros estaban simplemente mal, no corridos.
• wi-cli-venus commented · 2026-08-20
  SOLAPAMIENTO MEDIDO (db02, xlsx, 05:53): de 5086 filas, 3487 con Fecha Baja y 53 con Expte. Baja solo-NBSP, el SOLAPAMIENTO ES CERO - ninguna de las 53 esta en una fila que tenga Fecha Baja. O sea el 272 no estaba inflado en nada y sobrevive la verificacion en vez de arreglarse por aritmetica; ademas se reproduce desde el archivo por un camino independiente (leyendo el libro con NBSP contado como vacio da 272 y 203, los mismos dos numeros que da la base). Dos fuentes, dos caminos de codigo, mismas cifras. Las 53 son una POBLACION DISTINTA del hueco de cierre: son filas que nadie cerro nunca, con una marca invisible en la columna del instrumento. Van a Eugenia igual, pero no mueven el numero del hueco. El hueco real sigue siendo 475 = 272 sin instrumento + 203 con la frase de contaminacion como instrumento.
• wi-cli-venus commented · 2026-08-20
  PROYECCION 2 REPARADA (db02, medido contra el libro y reconciliado contra prod, 05:47) Y LA REPARACION MATA EL CAVEAT QUE FIRMAMOS LOS TRES. REGLA NUEVA, una sola oracion: PERIODO VIGENTE = LA FILA CON Fecha Baja IS NULL. Cualquier Tramite. Sin comparacion de fechas, sin ordenamiento, sin desempate. UNICA POR CONSTRUCCION: patentes con mas de una fila abierta = 0 de 2388. IDENTIDAD EXACTA CON LA FLOTA VIVA: 1599 patentes con fila abierta; prod tiene exactamente 1599 vehiculos en estado_id=116; interseccion 1599, cero de cada lado. Conjuntos identicos, no parecidos. Las 789 patentes sin fila abierta son las cerradas. LA REGLA VIEJA fallaba masivamente: solo 256 de 2388 patentes tienen una fila Alta sin Fecha Baja, o sea no devolvia NADA para 2132 de 2388. EL CAVEAT DE audit MUERE, y hay que matarlo explicito: 'la proyeccion 2 puede seguir excluyendo Modif porque Tramite define el tipo de evento' - de las 1599 filas abiertas, 1342 son Modif (84%). Excluir Modif borra el 84% de los periodos vigentes y deja 1342 vehiculos vivos sin periodo. Mismo defecto que la proyeccion 2 original una capa mas arriba: las dos razonaron desde lo que 'Modif' SIGNIFICA en vez de contar, y las dos fallan en los mismos vehiculos. QUE ES fecha_baja: no es la baja del vehiculo, es el CIERRE DE UN PERIODO, y encadena - de 2391 filas cerradas con sucesora, 1897 (79%) tienen fecha_baja igual a la fecha_alta de la siguiente. TRAMPA NUEVA: el orden del archivo NO es cronologico - 307 patentes tienen su fila abierta NO ultima por fila_excel, asi que 'tomar la ultima fila' elige mal en 307 de 1599. La derivacion se ancla en Fecha Baja IS NULL, nunca en posicion.
• wi-cli-venus commented · 2026-08-20
  PROYECCION 2 REPARADA - VERIFICADA POR LOS TRES CARRILES, DE FORMA INDEPENDIENTE. db02 la ataco el mismo en vez de solo entregarla: (1) la unicidad NO es un accidente del snapshot 4 - vale en los tres snapshots, 2388 patentes cada uno, con 1602/786, 1599/789 y 1599/789 y CERO patentes con mas de una fila abierta en los tres; su afirmacion original descansaba en un solo snapshot y un solo snapshot no distingue un invariante de una coincidencia. (2) ninguna fila parece abierta por fallo de parseo: de 3487 Fecha Baja, 3487 son ISO yyyy-mm-dd, 0 en dd/mm/yyyy, 0 no parseables. (3) su normalizacion de dominio no parte una patente en dos: da 2388 distintas, una normalizacion agresiva que borra todo caracter no alfanumerico da las mismas 2388, y bajo la agresiva las patentes con mas de una fila abierta siguen siendo 0. db-mba-l-cc verifico contra PROD REAL, dominio por dominio (excluyo dev a proposito: los datos de vehiculos en dev estan derivados del estado del libro y daban 6/7 falsos desajustes ajenos a la regla): open_not_live=0, live_not_open=0, 1599 contra 1599 - coincidencia EXACTA DE CONJUNTOS, no solo de cardinalidad. audit acepto y exigio que se haga cumplir por GATES. LO QUE NO ESTA PROBADO, y db02 se nego a dejarlo pasar como cubierto: todo esto dice que abierta-y-unica es una propiedad ESTABLE DE ESTE LIBRO en tres exportaciones. NO prueba que el libro no pueda emitir dos filas abiertas - nada en la fuente lo impide, es la practica de Eugenia, no una restriccion. Por lo tanto cualquier cosa aguas abajo que dependa de la unicidad tiene que VERIFICARLA EN LA INGESTA y reportar la violacion, nunca asumirla. Una regla que valio tres veces es un buen default y una mala garantia.
• wi-cli-venus commented · 2026-08-20
  PASO 4 FRENADO. LA CONCLUSION DEL RULING 1 ESTA MAL, no solo su razonamiento (coder02). Las proyecciones 1 y 2 discrepan en exactamente 2 patentes, y son AI105QP y AI357IV - las mismas dos sobre las que se escribio el ruling. Proyeccion 1 (fecha_alta + orden de archivo) elige filas 3872/3918, el Alta CERRADO. Proyeccion 2 (Fecha Baja IS NULL) elige 3871/3917, el Modif ABIERTO. LA CADENA DE EXPEDIENTES LO DECIDE sin apelar a fecha ni posicion: en AI105QP el Expte. BAJA de la 3872 es EX-2026-10225370 y el Expte. ALTA de la 3871 es EX-2026-10225370 - el instrumento que CIERRA una es el que ABRE la otra, o sea la 3871 es la SUCESORA. AI357IV identico con EX-2026-32773878. El orden del archivo esta INVERTIDO respecto del orden real del tramite en esas filas: la proyeccion 1 no desempata mal un par ambiguo, elige la fila que la cadena prueba ya cerrada. Prod coincide con la 2: esas dos estan dentro de la interseccion exacta 1599/1599. ERROR PROPIO (coder-mba-l-cc): anule la premisa del ruling y CONSERVE su conclusion diciendo que llegaba a la fila correcta por el motivo equivocado. No llegaba a la fila correcta. Conservar una conclusion despues de destruir el argumento que la produjo es exactamente el error que estuve senalando toda la noche. REPARACION (propuesta de coder02, adoptada): LAS DOS PROYECCIONES COLAPSAN EN UNA. Si vigente = 'Fecha Baja IS NULL' - unica por construccion en los tres snapshots, cero excepciones - no hay empate que romper y EL ORDEN DE ARCHIVO NO PARTICIPA DE NINGUNA PROYECCION. El desempate por posicion existia solo para empates de fecha_alta, y la unica evidencia de que servia eran estas dos patentes, donde elige mal. snapshot_id + fila_excel SALEN de la proyeccion. Consistente con el hallazgo de db02 de que 307 patentes tienen su fila abierta fuera del final del archivo: las 307 son el caso general, estas 2 el subconjunto que ademas empata en fecha. El gate de reordenamiento de coder02 NO esta afectado: usa fila_excel para detectar si una fila SE MOVIO entre snapshots, nunca para decidir cual es vigente.
• wi-cli-venus commented · 2026-08-20
  NO SON 2 CASOS, SON 211 (db02, prod snapshot 4, 05:52). De las 1599 filas abiertas, 1097 encadenan con una hermana cerrada de la misma patente via expte_baja -> expte_alta. En 211 de ellas la PREDECESORA esta DESPUES de la fila abierta en el orden del archivo. O sea el orden del archivo esta invertido contra el orden real del tramite en 211 patentes, y la cadena de expedientes lo prueba sin usar fecha ni posicion. Las 2 filas del ruling 1 son el subconjunto que ADEMAS empata en fecha_alta: el empate hizo visible la eleccion equivocada, las otras 209 se elegian mal EN SILENCIO. Misma forma que los 3-de-131 de MOVILBA-69: un defecto que solo se ve cuando se alcanza un desempate, mientras el mismo ordenamiento equivocado ya estaba operando en casos que nunca empataban. Las 307 (filas abiertas que no son la ultima del archivo) y estas 211 son MEDICIONES DISTINTAS, no la misma reformulada - se corroboran desde direcciones distintas y ninguna se deriva de la otra. REGLA HONESTA DE TRES CLAUSULAS (db02, adoptada - corrige mi 'el orden de archivo no participa nunca', que es mas prolijo y es FALSO para 4 patentes): (1) si existe fila abierta, esa es la vigente - unica en los tres snapshots, 0 excepciones, sin ordenamiento ni fechas; (2) si no hay fila abierta (789 patentes, 1223 filas), cola de la cadena de expedientes -> resuelve 602 de 789; despues mayor Fecha Baja -> resuelve 183 mas, total 785 de 789; (3) siguen empatadas 4: AF821DV, AF875JB, AF875JQ, AF899TF, todas linea 68, mismas fecha_alta, fecha_baja y expte_baja, difieren solo en expte_alta y una de las dos es el expediente de LOTE EX-2025-55184093. Ahi la posicion en el archivo no es un desempate, es el UNICO discriminador, y no es una razon de negocio - por eso es MOVILBA-78, pregunta para Eugenia, impacto SOLO de visualizacion. RAZON PARA NO SIMPLIFICARLO: decir 'el orden de archivo nunca participa' seria mas limpio y estaria mal para 4 patentes, y estaria mal EN SILENCIO - una vista sin desempate devuelve una fila arbitraria y nadie lo ve.
• wi-cli-venus verified · 2026-08-21
  CHANGED - el bloqueo ESTRUCTURAL ya no existe, queda el entregable. Medido en prod por db02-mba-l-cc 2026-08-21 08:12. Lo que este item denunciaba era que vigencia_desde/hasta no puede expresar un tramite sin fechas. Hoy en prod fecha_alta y fecha_baja son las dos NULLABLE, tramite_id tipa el tramite de forma nativa (lo trajo MOVILBA-94) y la columna cambios jsonb esta ahi para llevar que cambio: un tramite sin fechas como un cambio de asientos YA es representable. Cero filas lo ejercitan hoy (0 filas con las dos fechas en NULL). Lo que sigue realmente pendiente son dos cosas y ninguna es de esquema: (1) el entregable nombrado - la lista de campos con nombre, tipo, nullability y columna de origen en el Excel - no existe como artefacto en ningun lado de docs/; (2) el catalogo de tramites solo tiene ALTA y MODIF, asi que un tramite 'cambio de asientos' no tiene todavia ningun valor al que apuntar. Restriccion para el diseno: observaciones es NOT NULL. Esto importa para lo que esta apilado detras: MOVILBA-42, 82 y 106 esperan el paso 3 de este item.
• wi-cli-venus completed · 7w ago
  Entregable documentado en docs/design/rutap-full-history-refactor-plan.md (Baseline transaction/date contract): nombre, tipo, nullability y mapeo RUTAP. Audit-mba-l-cc revisó y firmó 2026-08-26; campos existentes verificados por MOVILBA-93.