Los valor_opcion de motor no son los del libro: 157='GN' y 59/17='EURO5'/'EURO3' contradicen GNC/E5/E3, y hay dos GNC duplicados
Elazar, CLI 2026-09-22, literal: 'our app must have the same values as ssot, thus if ssot reads GNC our app must use GNC (...) i dont care what you do, same ID, GNC'. El libro (2026-09-22-1455-parque-rutap.xlsx) escribe Unidad_Propulsora en {GO, GNC, ELECTRICO-CABA, ELECTRICO} y Tipo_Motor en {E5, E3, GNC, Electrico}. El catalogo guarda otra cosa en los ids que la data USA: motor.unidad_propulsora 157='GN' (617 filas PROD en vhn, 355 en vehiculos) y motor.estandar_emisiones 59='EURO5' (3990), 17='EURO3' (870). nombre_mostrable ya dice E5/E3/GNC, o sea la convencion quedo dada vuelta y el reporte de exportacion compensa leyendo mostrable en vez de valor_opcion. Ademas hay duplicados no usados: 158='GNC' (0 refs) y 34='COMBUSTION_GNC' (0 refs, viva en PROD, borrada en DEV). Arreglo: renombrar valor_opcion en los ids EN USO (157->GNC, 59->E5, 17->E3), retirar 158 y 34 por soft-delete (el indice unico es parcial sobre borrado_en IS NULL, asi que no hace falta tocar ningun trigger), y reemplazar rutap.proyectar_snapshot, unico objeto instalado que hardcodea 'GN' (el CASE de resolucion y el gate W3 de MOVILBA-269, que RAISE si 'GN' no resuelve a exactamente uno).
Activity
-
Aplicado en DEV y PROD 2026-09-22 15:26 ART, un solo archivo docs/migrations/2026-09-22-movilba-535-valor-opcion-igual-al-libro-motor-DEV-Y-PROD.sql md5 335c7f37209b8fba13f503a579351ce5, mismos bytes en las dos bases, bajo lock de hub sobre public.opciones (tomado y liberado). PRE/POST: DEV vivas 164->163, PROD 165->163. 157 GN->GNC, 59 EURO5->E5, 17 EURO3->E3; 158 y 34 retiradas por soft-delete (indice unico PARCIAL sobre borrado_en IS NULL: no hizo falta tocar ningun trigger ni hacer borrado fisico); rutap.proyectar_snapshot reemplazada con firma identica (p_snapshot_id bigint, md5 previo ca89b7fe0e4ef16188f012b152708e5b verificado por gate antes de pisarla) cambiando los dos unicos literales 'GN' del esquema entero; evidencia del resolver reescrita, mapeo GNC->157 intacto. Los 9 gates POST verdes en las dos bases. Controles positivos corridos contra DEV con ROLLBACK: apply limpio PASA; una fila movida a proposito -> GATE 5 aborta; funcion sin reemplazar -> GATE 8 aborta; md5 de funcion distinto -> GATE 0.b aborta; 158 renombrada en vez de retirada -> la aborta el indice unico antes del GATE 4. tools/opciones-diff.sh despues: GATE OK, catalogo vivo 163=163 IDENTICO y las 26 vistas identicas, o sea que esto tambien cierra la divergencia que quedaba de MOVILBA-534. NO exercitado: no se corrio un import completo, solo el predicado del gate W3.
-
db03: funcion instalada md5 4c47a51f78e933991602d1bcee804868 IDENTICA en DEV y PROD, sin literal GN; 157=GNC 59=E5 17=E3 en las dos. Re-medido despues del commit cefaaddd/af6441b1, independiente de coder03.
-
Carril coder cerrado. cefaaddd (v5.6.14): migracion de db03 + opciones-resolver.js (GNC resuelve por clave 'GNC' a 157, E3/E5) + master-data-populator.js (se eliminan createMissingOpcionesEntries y populateOpciones, que fabricaban COMBUSTION_GN/ELECTRICO_VEHICULO/GNC_EMISIONES) + route.ts reportes/vehiculos-historico (op_tipo_motor.valor_opcion) + fixture del test post-535 + rutap-transform-rules.md, opciones-catalogo.md, .claude/rules/catalogos.md + drizzle/schema.ts. af6441b1 (v5.6.15): revierte el texto ejecutable del artefacto a lo aplicado - los guards regprocedure que pidio audit quedan como comentario para el proximo artefacto que toque proyectar_snapshot (decision db03). Header corregido: la hoja Base tiene 5528 filas de datos, no 6957 (eso era el indice maximo). audit-mba-l-ca PASS, sin hallazgos abiertos. Sin deploy a prod.