76 paso 3 en PROD: renombrar expediente/expediente_baja/fecha_expediente a expte_alta/expte_baja/fecha_alta en vehiculo_historial
Renombra 3 columnas en public.vehiculo_historial en PROD: expediente->expte_alta, expediente_baja->expte_baja, fecha_expediente->fecha_alta. Solo metadata, no mueve datos. Ya aplicado en DEV con su codigo (v5.3.230). SCRIPT: docs/migrations/2026-08-20-movilba-76-paso3-rename-simetria-alta-baja-PROD.sql md5 **a09af22b24d57723d8f9ade935bd13d1** - el UNICO que se aplica. Las versiones 419a2344 y 5ce5cad4 son previas al fix de audit y NO se aplican. ENSAYO VERDE CONTRA PROD (apply=false, ROLLBACK, prod intacto): GATE 0 base movilba, pasos 1+2 presentes, 3 columnas viejas, **0 funciones plpgsql nombran las columnas**, 4045 filas GATE 1 expte_alta / expte_baja / fecha_alta, tipos intactos, 4045 filas GATE 2 **101 relaciones (vistas + MATVISTAS), 883 columnas de salida, 0 cambios de nombre** GATE 3 las 101 relaciones siguen consultables - ejecutadas, no inspeccionadas Las cifras 88 vistas / 849 columnas que figuraban antes aca son las PREVIAS al fix de audit: los gates leian information_schema.views, que no ve matvistas, y el primer intento de arreglo tampoco (information_schema.columns tambien las omite). Ahora sale de pg_attribute + pg_class con relkind IN ('v','m'). Las 34 columnas de matvista que eran invisibles ahora se miden. POR QUE ES SEGURO EN PROD: las vistas religan por NUMERO DE ATRIBUTO y sobreviven un rename; una funcion plpgsql lleva el nombre de la columna como TEXTO y falla en el momento de la LLAMADA, no del rename - pasaria todos los gates y rompe al primer usuario que la dispare. Prod tiene 0 funciones asi, y GATE 0 lo re-verifica al aplicar en vez de confiar en esta medicion. VENTANA: AccessExclusiveLock, 0.314 s de reloj medidos, con los gates ADENTRO de la transaccion (GATE 3 ejecuta las 101 relaciones con el lock tomado). Los 3 ALTER son ~1 ms cada uno; la ventana real es 0.3 s, no 3 ms. lock_timeout=2s: si no toma el lock en 2 s ABORTA en vez de encolar - no aplica nada y es re-ejecutable literal. El riesgo real es la COLA, no la duracion. SECUENCIA (no se altera): 1. coder deja el codigo staged 2. db02 aplica y avisa inmediatamente 3. coder corre introspect.sh, commitea schema + codigo JUNTOS, despliega 4. ejercitar LISTA DE EJERCICIO - CINCO checks. **Corregida: la version anterior decia "sin filtro no dispara el join" y ESO ES FALSO.** Medido en src/repositories/parque-movil.ts: linea 117 needsVh = needsEntidad || needsLinea; linea 148 countFromWhere usa needsVh ? vhJoin : empty (GATEADO); linea 158 fromWhere usa vhJoin SIN CONDICION; el SELECT proyecta la columna renombrada en TODA llamada. El que esta gateado por el filtro es el COUNT, no el SELECT. 1. registrarExpediente 2. alta de vehiculo 3. la ficha de vehiculo 4. GET /api/v1/parque/vehiculos SIN filtro -> ejercita fromWhere + la proyeccion (el camino que pega todo consumidor) 5. GET /api/v1/parque/vehiculos CON filtro de entidad o linea -> ademas countFromWhere, unico lugar donde se lee needsVh Ninguno es redundante: el camino del count solo es alcanzable con filtro, y una pasada sin filtro no dice nada sobre el. ROLLBACK: primero se revierte el commit de CODIGO, DESPUES los 3 renames inversos (BEGIN; SET LOCAL lock_timeout='2s'; los 3 ALTER ... RENAME COLUMN inversos; COMMIT;). El orden inverso deja la app hablando con columnas que ya no existen - es la caida de las 06:05 con los pasos cambiados. LA API v1 CONSERVA 'expediente' POR ALIAS (SELECT h.expte_alta AS expediente) para no romper a SOTAMIT: es un campo publicado del OpenAPI y esta en required. EL PASO 4 NO VA EN ESTA VENTANA y no tiene GO. GATE ABIERTO, no es de la base: main esta 47 commits detras de dev, asi que desplegar el codigo del paso 3 arrastra MOVILBA-46 regla B (todo cambio a un vehiculo pasa a exigir expediente o motivo), 80, la etiqueta de 88 y los fixes de consumo. Un GO para el paso 3 no es un GO para eso. coder pregunto el alcance a Elazar y sostiene hasta que responda.
Activity
-
parent=#2783
-
CORRECCION a la lista de ejercicio (coder02, 11:02, leyendo src/repositories/parque-movil.ts). El item 4 decia 'con filtro de entidad o linea, sin filtro no dispara el join'. ESO ES FALSO y era mio. Medido: linea 117 needsVh = needsEntidad || needsLinea; linea 148 countFromWhere usa ${needsVh ? vhJoin : empty} (GATEADO); linea 158 fromWhere usa ${vhJoin} SIN CONDICION; linea 189 el SELECT proyecta vh.expediente en TODA llamada. O sea: el SELECT principal joinea siempre, el que esta gateado por el filtro es el COUNT. Item 4 correcto: GET /api/v1/parque/vehiculos SIN filtro Y CON filtro de entidad o linea - los dos, porque cubren queries distintas (sin filtro = fromWhere + proyeccion; con filtro = ademas countFromWhere, unico lugar donde se lee needsVh). Detectado por audit-mba-l-ca en pre-read, antes de que la lista se usara.
-
was: Renombra 3 columnas en public.vehiculo_historial en PROD: expediente->expte_alta, expediente_baja->expte_baja, fecha_expediente->fecha_alta. Solo metadata, no mueve datos. Ya aplicado en DEV con su codigo (v5.3.230). Script: docs/migrations/2026-08-20-movilba-76-paso3-rename-simetria-alta-baja-PROD.sql md5 a09af22b24d57723d8f9ade935bd13d1 (unico a aplicar; 419a2344 es la version previa al fix de audit). Ensayo verde contra prod: GATE 0 pasos 1+2 presentes / 0 funciones plpgsql nombran las columnas / 4045 filas; GATE 1 tipos intactos; GATE 2 88 vistas 849 columnas 0 cambios de nombre; GATE 3 las 88 vistas ejecutadas. Ventana de AccessExclusiveLock medida: 0.314 s con los gates dentro de la transaccion. lock_timeout=2s: aborta en vez de encolar, no aplica nada, re-ejecutable literal. SECUENCIA: coder deja el codigo staged -> db02 aplica y avisa -> coder corre introspect.sh, commitea schema+codigo juntos y despliega -> ejercitar registrarExpediente, alta de vehiculo, y GET /api/v1/parque/vehiculos CON filtro de entidad o linea (sin filtro no dispara el join). ROLLBACK: primero se revierte el commit de codigo, DESPUES los 3 renames inversos; el orden inverso es la caida de las 06:05 con los pasos cambiados. El paso 4 NO va en esta ventana.
-
DOS PRECISIONES SOBRE EL ALCANCE DEL DEPLOY, antes de que se abra la ventana (db02 + audit, 11:13). 1. El paquete de 47 commits SI tiene un cambio visible para el usuario, y es uno solo: **se levanta la regla B de MOVILBA-46** (v5.3.239). Antes, editar un vehiculo sin expediente ni motivo se RECHAZABA; ahora se ACEPTA. Es el cambio que Elazar ordeno, en direccion permisiva, pero es visible: quien aprendio que el campo era obligatorio lo ve dejar de serlo, y cualquier procedimiento apoyado en "la app no te deja guardar sin esto" deja de estar enforzado. Yo dije antes "el paquete ya no tiene cambios visibles" y ESO ES FALSO - lo corrijo aca porque la pregunta de alcance que tiene Elazar adelante se contesta sobre este paquete. El resto de los 47 son docs, tooling y arreglos: MOVILBA-80, la etiqueta de 88, los fixes de consumo 0, el indice de docs/migrations, el split de memoria y memory-orphan-sweep.sh. 2. El check 1 de la lista de ejercicio (`registrarExpediente`) CAMBIA DE SIGNIFICADO. Estaba en la lista en parte porque era el camino de escritura que la regla B custodiaba. Sin la regla, un verde ahi prueba que el rename no rompio la escritura - NO prueba que la regla del expediente funcione, porque ya no hay regla que funcione. El check se mantiene (el rename es de lo que se trata el paso 3), pero nadie lo lea como mas que eso. Los otros cuatro no cambian.
-
APLICADO Y VERIFICADO EN PROD. Rename commit 11:30:07 ART (db02, md5 a09af22b24d57723d8f9ade935bd13d1, SUPERUSER_ELAZAR_URL, -v ON_ERROR_STOP=1 -v apply=true). Deploy de codigo 11:31:03 (coder). Ventana de codigo-viejo-contra-columnas-nuevas: 56 segundos. Gates en el apply: GATE 0 pasos 1+2 presentes / 0 funciones plpgsql nombran las columnas / 4045 filas; GATE 1 tipos intactos; GATE 2 101 relaciones 883 columnas 0 cambios de nombre de salida; GATE 3 las 101 ejecutadas. Verificado DESPUES por las dos lineas, y por db02 como svc_nextjs (no con el superuser que aplico, que es donde aparece el bug de GRANT): 4045 filas, expte_alta 3598, expte_baja 2299, fecha_alta 4045, predicado 42 = 1599 identico al previo => el rename no movio datos. Bug de GRANT ausente. COBERTURA HONESTA, no cinco checks verdes: 3 sobre HTTP en prod (API v1 search sin filtro y con filtro -total baja 1736->57-, alias expediente intacto) + 2 por SQL. registrarExpediente, alta de vehiculo y la ficha NO se probaron en prod: estan detras de sesion y NO EXISTE login de app en prod (coder busco en los tres ltm). Se ejercitaron en dev. Esa es una laguna de cobertura permanente, no de este deploy. Paso 4 NO entro en esta ventana y sigue sin GO, sin preparar y sin ensayar.