Cadena entidad-linea-vehiculo: portador de estado actual para linea_id/entidad_id fuera de vehiculo_historial
Cadena entidad->linea->vehiculo: mover linea_id/entidad_id fuera de vehiculo_historial a un portador de estado actual. Decision de Elazar 2026-08-31 (registrada en MOVILBA-155): no hay FK directa vehiculo->entidad; la propiedad deriva por linea. Prerequisito de 'historial de usuario vacio al handoff'. Fusiona MOVILBA-165 (duplicado que file yo en paralelo, cancelado y apuntando aca). NOTA DE PROCEDENCIA: la decision me llego por dos relays (db03-mba-l-ca y pm-mba-l-cc), nunca de Elazar directo. Filar y diseñar es reversible y sigue; NINGUN DDL hasta confirmacion directa. == POR QUE EL ORDEN ES CORRECCION Y NO PREFERENCIA (medido por coder02 contra PROD, SELECT) == - La UNICA relacion vehiculo<->entidad que existe es la FK vehiculo_historial.entidad_id -> entidades. No hay columna de entidad ni de linea en vehiculos ni en vehiculos_datos_colectivos (identidad_id es otra cosa). - vehiculo_historial porta hoy linea_id, entidad_id, estado_id, motivo_id, tramite_id. - v_vehiculos_hist_ultimo lee FROM vehiculo_historial; v_vehiculos_lineas_entidades junta vehiculos+entidades+lineas A TRAVES de esa vista. => Vaciar el historial antes de que la cadena nueva exista Y ESTE POBLADA destruye la unica asociacion vehiculo-entidad y vehiculo-linea del sistema. SECUENCIA: (1) crear el portador, (2) poblarlo desde el LIBRO, (3) reapuntar vistas y codigo, (4) recien ahi tocar el historial. == IMPACTO (PROD) == vehiculo_historial: 4225 filas (DEV 4338). Dependen 11 vistas - v_vehiculo_historial, v_vehiculo_cadena, v_vehiculos_hist_ultimo, v_vehiculos_detalle, v_vehiculos_export, v_monitor_historial_anomalias, v_db_users_footprint_detalle y 4 v_audit_* - mas 1 trigger. FKs entrantes: 0. En codigo: 11 archivos (src/actions/vehiculos.ts, src/lib/historial-vehiculo.ts, src/repositories/{vehiculos,parque-movil}.ts, src/services/vehiculos.ts, src/types/vehiculos.ts, src/components/ExpedienteForm.tsx, src/app/vehiculos/[id]/page.tsx, /api/vehiculos/[id]/{entidad,linea}/history, src/lib/openapi/components.ts). CONSUMIDOR EXTERNO: la API de Rendiciones (MOVILBA-144, shipeada 08-31, key minteada) lee v_vehiculos_lineas_entidades. Si se vacia el historial antes de poblar la cadena, responde 200 con entidad y linea VACIAS: no falla, MIENTE. == LOS 818 SIN LINEA: VERIFICADO, Y LA CONCLUSION CAMBIA == 2388 vivos. 1570 con linea en la ultima fila viva. Los 818 restantes se parten en dos, y NINGUNO se arregla reproyectando: (a) 648 sin NINGUNA fila viva de historial. VERIFICADO contra el libro del 08-31 (hoja 'Base', 2394 dominios, 5260 filas): los 648 estan TODOS en el libro. La duda que dejo db02 ('verificar que sean los mismos 648 del Tipo-A antes de asumir que el import los cubre') queda cerrada: el import baseline los cubre. Ademas 0 vehiculos vivos de PROD faltan del libro, y 6 dominios del libro no estan entre los vivos. (b) 170 con filas vivas pero sin linea_id en ninguna. CORRIGE el diagnostico de db02: db02 los describio como 'ultima fila NULL pero una anterior con linea', y de ahi dedujo que el baseline debe tomar el ultimo linea_id NO NULO. Medido con borrado_en IS NULL da CERO casos de ese patron. La fila anterior que si tiene linea esta SOFT-DELETED en los 170 casos. O sea que 'ultimo linea_id no nulo' no es un arreglo gratis de proyeccion: RESUCITA filas borradas. Y no hace falta: los 170 estan en el libro con la columna 'Linea' poblada, asi que el baseline los saca del libro. => REGLA DE DISEÑO: el baseline sale del LIBRO, no de proyectar el historial existente. v_vehiculos_hist_ultimo no sirve como fuente, pero no por su ordering: sirve mal porque la fuente correcta es otra. Metodo: excluir siempre las filas borradas antes de comparar - es la misma trampa que db02 levanto el 08-31 en AD956UK. == LO QUE SIGUE EN PIE DE LA MEDICION DE db02 == 28 lineas activas, 0 sin entidad activa; uq_linea_entidad_activa (unique sobre linea_id WHERE borrado_en IS NULL) hace que linea->entidad resuelva unica. La direccion de la cadena es sana y vehiculo-data-model.md seccion 4 no la contradice: descarta entidad->linea (1:N), la direccion opuesta. == A DISEÑAR (owner coder02-mba-l-cc) == 1. Portador de linea_id/entidad_id como estado actual. 2. Venta individual mueve vehiculo<->linea con expediente y fechas: definir si expte_alta/expte_baja/fecha_vigencia_desde/_hasta de vdc son ese portador o si el vinculo necesita fila propia. Un traspaso de linea (todos los coches) y una venta individual tienen que quedar distinguibles despues. 3. Reconstruir las 11 vistas dependientes y las 4 superficies de campo. 4. De paso: linea_entidad_asignaciones tiene uq_linea_entidad_activa Y uq_linea_entidad_asig_activa, dos indices unicos sobre la misma columna con el mismo predicado. Redundante, unificar. == SIGUE VIGENTE == Baja es un ESTADO, no un borrado: DELETE / DISABLE TRIGGER sobre vehiculo_historial esta prohibido aun con GO. 'Historial en cero' se logra no proyectando el libro adentro, no borrando lo que hay, salvo orden explicita de Elazar. MOVILBA-42/76 (append-only vs una-fila-viva) y MOVILBA-99 (derivar historial del diff de columnas) asumen que el historial es el portador: hay que re-leerlos contra esta decision. MOVILBA-157 depende de que quede historial que verificar.
Sub-tickets — 1/1 done
Activity
-
coder02-mba-l-cc
-
parent=MOVILBA-155
-
was: Cadena entidad->linea->vehiculo: mover linea_id/entidad_id fuera de vehiculo_historial a un portador de estado actual. Decision de Elazar 2026-08-31 (registrada en MOVILBA-155): no hay FK directa vehiculo->entidad; la propiedad deriva por linea. Prerequisito de 'historial de usuario vacio al handoff'. MEDIDO EN PROD 2026-08-31 (db02-mba-l-cc, SELECT, 10.78.42.168 PG17.6), 2388 vehiculos vivos: - 648 sin NINGUNA fila de vehiculo_historial -> sin linea en ningun lado -> sin entidad bajo la cadena nueva. Coincide con el conteo Tipo-A de coder02 (dominios cuyo libro tiene filas que nosotros no); VERIFICAR que sean los mismos 648 antes de asumir que el import los cubre. - 170 con ultima fila de historial con linea_id NULL pero una fila anterior con linea. Defecto de PROYECCION, no de datos: el baseline debe tomar el ultimo linea_id NO NULO, no la ultima fila. v_vehiculos_hist_ultimo toma la ultima fila, asi que NO sirve como fuente del baseline tal cual. - 28 lineas activas, 0 sin entidad activa. uq_linea_entidad_activa (unique sobre linea_id WHERE borrado_en IS NULL) hace que linea->entidad resuelva unica: la direccion de la cadena es sana. vehiculo-data-model.md seccion 4 NO la contradice: descarta entidad->linea (1:N), que es la direccion opuesta. A DISENAR (owner coder02-mba-l-cc, dueno del DDL de esquema de app): 1. Portador de linea_id/entidad_id como estado actual (vehiculos_datos_colectivos no tiene ninguna de las dos hoy). 2. Venta individual mueve vehiculo<->linea con expediente y fechas: definir si expte_alta/expte_baja/fecha_vigencia_desde/_hasta de vdc son ese portador o si el vinculo necesita fila propia. Un traspaso de linea (todos los coches) y una venta individual tienen que quedar distinguibles despues. 3. Reconstruir las vistas dependientes (v_vehiculos_hist_ultimo, v_vehiculos_linea_actual, v_vehiculos_entidad_actual, v_vehiculos_list/detalle/export) y las 4 superficies de campo. 4. De paso: linea_entidad_asignaciones tiene uq_linea_entidad_activa Y uq_linea_entidad_asig_activa, dos indices unicos sobre la misma columna con el mismo predicado. Redundante, unificar. Sin DDL hasta que el diseno este aprobado; escritura en PROD requiere GO por item.
-
PRECISION (db02-mba-l-cc, 2026-08-31): los 648 y los 170 se cierran por MECANISMOS DISTINTOS y no hay que colapsarlos. - Los 648 son filas AUSENTES: el import las INSERTA. Se arreglan solas con cualquier import del libro. - Los 170 YA tienen vehiculo vivo y lo unico que les falta es la linea actual. No los cierra el insert: los cierra que la PROYECCION BASELINE tome el valor 'Linea' del libro. Eso es la regla de diseño de este item, no un efecto del import. CONSECUENCIA: si algun dia el baseline se construye desde algo que no sea el libro - por ejemplo proyectando el historial existente - los 170 se REABREN EN SILENCIO mientras los 648 siguen arreglados. Un chequeo post-import que solo cuente vehiculos sin linea vera bajar el numero por los 648 y no notara que los 170 volvieron. Por eso el gate post-import tiene que contar las DOS poblaciones por separado, no el total de vehiculos sin linea.
-
parent=MOVILBA-167
-
Reparentado de MOVILBA-155 a MOVILBA-167 (db02-mba-l-cc, 2026-08-31). 155 es el GO de import; 166 es trabajo de esquema y cae dentro del epic 167 como sus fases 1-2 para el portador de linea_id/entidad_id. Las mediciones de PROD de 166 (648 sin historial, 170 con linea solo en filas borradas, 28 lineas / 0 sin entidad activa) siguen siendo la linea base cuantitativa del epic.
-
Reparentado de MOVILBA-155 a MOVILBA-167 (db02-mba-l-cc, 2026-08-31). 155 es el GO de import; 166 es trabajo de esquema y cae dentro del epic 167 como sus fases 1-2 para el portador de linea_id/entidad_id. Las mediciones de PROD de 166 (648 sin historial, 170 con linea solo en filas borradas, 28 lineas / 0 sin entidad activa) siguen siendo la linea base cuantitativa del epic.
-
parent=MOVILBA-167
-
coder03-mba-l-cc / coder
-
db03-mba-l-cc
-
db04-mba-l-ca
-
db04 takes the highest-priority actionable child (rather than the parent epics 52/167/125). First step is a current-schema, SELECT-only census: whether line/entity current-state carrier already exists after 125/155, and whether the Aug-31 missing-history counts remain true. No DDL without the direct authorization required by this item.
-
db04 current installed-schema SELECT-only census, PROD then DEV (2026-10-08): public.vehiculo_historial retired; no vehiculos/VDC linea_id or entidad_id; selected rutap.vehiculo_historial_normalizado remains the sole physical vehicle-line/entity carrier, and v_vehiculos_hist_ultimo plus v_vehiculos_linea_actual/v_vehiculos_entidad_actual/v_vehiculos_lineas_entidades still read it. PROD 2424 not-soft-deleted vehicles, 0 missing selected history/line/entity; 1602 selected-state-nonnull all have a current line entity and 0 mismatch to history entity. DEV 2469, 7 no selected line (all origen_ingreso=app_dev), 1637 selected-state-nonnull with 0 mismatch. State-NULL group in each base has 11 lines without current entity and 32 history-entity vs line-current-entity differences; do not overwrite historical ownership by current line join. Old Aug31 648/170 gaps are obsolete for imported PROD rows. Evidence /data-lezama/movilba/evidencia/MOVILBA-166/2026-10-08-current-carrier-census.md. No DDL; item requires direct Elazar confirmation before schema write.
-
Current read-only PROD/DEV carrier census and reversible design recorded in /data-lezama/movilba/evidencia/MOVILBA-166/2026-10-08-current-carrier-census.md. Current line/entity values still live only in rutap normalized history; 1602 PROD state-nonnull rows resolve consistently through line, but historic state-NULL rows show why current-line entity cannot overwrite history. The item's own provenance note forbids DDL until Elazar directly confirms the independent current-state-carrier schema decision. Asked coder03 for that direct record in DM; no DB/code write authorized meanwhile.
-
MIGRATION GUARD (not merely census): never backfill historical entidad_id from a line's present entity. In BOTH bases, selected-history state-NULL rows include 32 history-entity/current-line-entity mismatches and 11 lines with no current entity. A blind join would alter history or invent ownership. Current-state carrier may derive present entity through current line assignment only; old normalized history must stay byte-exact. Reversible additive rollout, unique-current gate, book-sourced baseline, dual-read parity and rollback path documented at /data-lezama/movilba/evidencia/MOVILBA-166/2026-10-08-reversible-carrier-migration-intent.md. No DDL/data write until Elazar directly confirms schema decision.
-
HELD pending Elazar's direct confirmation of an independent current vehicle-line carrier (coder03 confirms none recorded; he will ask). Migration guard: the 32 historical-vs-current entity mismatches and 11 lines with no current entity occur in state-NULL rows in each base. Never backfill historical entidad_id from present line ownership; preserve history byte-exact. Reversible design and current census in /data-lezama/movilba/evidencia/MOVILBA-166/. No DDL/data write.