Deriva DEV/PROD en public: de los seis objetos del censo 09-22 sobreviven tres, y en dos de ellos la flecha apunta al reves de como se filo

Sub-tickets — 1/1 done

Activity

• wi-cli-venus created · 3w ago
• wi-cli-venus note · 3w ago
  STARTED MOVILBA-537 at 2026-09-22 16:27:29 -03 por db03-mba-l-cc. Primer paso: re-derivar los seis objetos contra las dos bases antes de citar el censo (el doc esta fechado 09-22 09:28 y la regla del propio ticket lo exige).
• wi-cli-venus verified · 3w ago
  Re-derivados los SEIS objetos contra DEV y PROD (SELECT only, misma consulta, keyeada por nombre). Correccion completa en docs/reference/movilba-479-dev-prod-schema-census.md, seccion nueva al pie; evidencia cruda en /data-lezama/movilba/evidencia/MOVILBA-537/. LAS LINEAS 102-107 QUE CITA ESTE TICKET ESTAN MAL EN DIRECCION Y EN CONTEO. Error de metodo, no de estos seis objetos: un diff de PRESENCIA entre dos bases no tiene direccion - un DROP deliberado de un lado y un hotfix del otro se imprimen identicos como 'solo en X'. La flecha sale del historial de migraciones y de drizzle/schema.ts, nunca de que lado tiene el objeto. El censo leyo 'solo en PROD' como 'PROD adelantado' en tres items y en los tres PROD esta ATRASADO. Clasificacion objeto por objeto: 1) vehiculos.fecha_ultima_actualizacion DEFAULT CURRENT_DATE = clase (a), PROD atrasado. Es la pata PROD de 2026-08-28-movilba-145-remove-batch-date-default-DEV-PROD.sql, aplicada en DEV y nunca en PROD. Vivo: materializar_snapshot_raices NO nombra la columna, asi que en PROD un alta nueva la estampa con la fecha del dia - el defecto que describe MOVILBA-145. reconciliar_snapshot si la nombra. DECISION DE ELAZAR (145 esta deferred P1 sin asignar). 2) vdc.observaciones = clase (a) INVERTIDA: DEV adelantado. Se borro a proposito en DEV por MOVILBA-472 (portar-y-borrar, sin contraparte en el libro). Falta la pata PROD, y NO es replay mecanico: PROD conserva dependientes vivos que DEV ya no tiene (fn_archive_vehiculos_datos_colectivos y v_vehiculos_export_vdc). CIFRA QUE ES LA DECISION: en PROD 595/2413 vehiculos difieren entre vdc.observaciones y el observaciones del periodo abierto, y 3 tienen texto SOLO en vdc. DECISION DE ELAZAR: es un DROP sobre datos poblados de PROD, explicitamente fuera del carve-out pre-live. 3) Los 6 CHECK: CINCO NO EXISTEN COMO HALLAZGO - estan en las dos bases con el mismo predicado, impresos distinto por la trampa PG15/PG17 de pg_get_constraintdef que este mismo doc declara en la linea 13 y que esa corrida no aplico a mano. 3b) El sexto se llama validadoras_historial_mounting_kit_check y tambien esta en las dos, con regex REALMENTE distinta: DEV ^[A-Za-z0-9-]{1,15}$ (acepta guion), PROD ^[A-Za-z0-9]{1,15}$. El MISMO delta esta en fn_validadoras_historial_validar, que difiere entre bases en esa unica linea (DEV md5 c3181fe5..., PROD bcd56f0b...). Un cambio coherente en DOS objetos, hecho en DEV y no portado. Clase (c), DEV mas ancho. PROD tiene 0 filas en validadoras_historial (DEV 58): nada ejercitado. 4) personas.uq_personas_cuit_cuil_activo = b2, portar a DEV. Sin rastro en migraciones ni en schema.ts: hotfix directo en PROD, pero es mejora real. NO se puede crear en DEV hoy: par violatorio personas id 91 y 177, cuit 20-42118402-0. PROD 0 violaciones. DECISION DE ELAZAR, chica: cual de las dos filas gana. 5) fn_validadoras_historial_tipo_check = b1, residuo, con explicacion completa: ningun trigger la ejecuta, ninguna funcion la referencia, fn_validadoras_historial_validar ya cubre su regla por modalidad_id, y ADEMAS esta rota - lee v.tipo_id (SUBE/OPENPASS) y lo compara contra EMBARCADA/PUESTO_A_TIERRA, que son valores de modalidad, asi que sus dos RAISE son inalcanzables. La creo movilba128-validadoras-tipo-check-PROD.sql y movilba128-validadoras-replacement-DEV.sql la dejo sin lugar en DEV. 6) Las 3 vistas anchas se DISUELVEN: v_vehiculos_export_vdc 32/31 es solo observaciones (item 2); detalle 60/55 y export 46/42 es observaciones + las 4 columnas openpass/sube. La linea 107 dice 'expedientes' y es falso: expte_alta/expte_baja estan en los dos lados. Las 4 columnas de validadora existen en la TABLA y en v_vehiculos_export_vdc de LAS DOS bases; solo difiere si detalle/export las levantan. NO SE TOCA bajo 537: el gate real de MOVILBA-72 vive en el codigo (isFaithfulHost), no en el ancho de la vista, y un CREATE OR REPLACE con el cuerpo de DEV angosta PROD. NO SE APLICO NINGUN DDL. 537 pide clasificacion. Cobertura: solo estos seis objetos; el resto del censo sigue fechado y no re-medido, y bajo la misma sospecha de direccion.
• wi-cli-venus descriptionChanged · 3w ago
  was: Censo completo en docs/reference/movilba-479-dev-prod-schema-census.md lineas 102-107. SEIS objetos de public existen o son mas anchos en PROD y no en DEV; ninguno lo produce el branch dev, son arreglos hechos directo en PROD que nunca se replicaron. Cero objetos DEV-only, cero drift en tablas, triggers, constraints restantes e indices restantes, keyeado por NOMBRE y en los dos sentidos. Los seis: (1) public.vehiculos.fecha_ultima_actualizacion con DEFAULT CURRENT_DATE en PROD y sin default en DEV - se cruza con MOVILBA-145, que pide que el importador NO estampe la fecha del lote; (2) public.vehiculos_datos_colectivos.observaciones (text) existe solo en PROD, 33 columnas contra 32; (3) 6 CHECK solo en PROD: los tres *_archive_reason_check de asociaciones_entidad_persona_archive/entidades_archive/personas_archive, instalacion_historial.chk_instalacion_evento_tipo, notas.notas_fuente_nombre_check, validadoras_historial.mounting_kit_check; (4) 1 indice unico solo en PROD, personas.uq_personas_cuit_cuil_activo, parcial sobre cuit_cuil donde borrado_en IS NULL AND cuit_cuil <> ''; (5) 1 funcion solo en PROD, public.fn_validadoras_historial_tipo_check; (6) 3 vistas mas ANCHAS en PROD: v_vehiculos_detalle 60/55, v_vehiculos_export 46/42, v_vehiculos_export_vdc 32/31. LO QUE SE PIDE: clasificar OBJETO POR OBJETO segun la regla de Elazar - b1 residuo que se borra, o b2 mejora real que se porta a DEV - y no presumir que todo se porta. DOS TRAMPAS: (i) las tres vistas anchas emiten justamente las columnas de validadora openpass/sube que MOVILBA-72 esta esperando exponer (bloqueado en GO de Elazar), asi que borrarlas como residuo mata el sustrato de 72; (ii) un CREATE OR REPLACE de esas tres vistas con el cuerpo de DEV ANGOSTA PROD y le saca columnas a quien las lea - se chequea el consumidor antes, no despues. Re-derivar el censo antes de citarlo: el metodo esta en la seccion 'Como re-derivar' del mismo doc.
• wi-cli-venus titleChanged · 3w ago
  Deriva DEV/PROD en public: de los seis objetos del censo 09-22 sobreviven tres, y en dos de ellos la flecha apunta al reves de como se filo
• wi-cli-venus decision · 3w ago
  Blackboard bb-coder03-mba-l-cc-mudr1myi-6ykdgl, 2026-09-23 03:57 ART, respondieron db03-mba-l-cc y audit-general-cc de forma independiente (no hay carril de audit de MovilBA registrado; el rol se resolvio al unico auditor vivo). RECOMENDACION AL HUMANO, orden (3) -> (1) -> (2). DOS DE LOS TRES NO SON DECISIONES SUYAS y los dos respondedores coinciden en eso por separado. (1) DROP DEFAULT de vehiculos.fecha_ultima_actualizacion en PROD: ACT NOW, ya contestado por el carve-out de DDL pre-go-live - no deshabilita proteccion, no borra, no dropea dato poblado, y es reversible en una sentencia. El estado 'deferred' de MOVILBA-145 no lo bloquea: lo diferido es la DERIVACION, que el propio header entrega a MOVILBA-146; la baja del default ya estaba decidida y probada en DEV. Medido: columna nullable en PROD, 0 nulls de 2413 hoy contra 9 de 2422 en DEV, asi que despues del drop un vehiculo nuevo nace NULL igual que en DEV. Hoy PROD fabrica dato equivocado en CADA import porque materializar_snapshot_raices no nombra la columna: cada dia de demora agrega filas estampadas con la fecha de la corrida. Salvedad de audit, contestada por db03: el drop convierte 'fecha equivocada' en 'fecha NULL', no en 'fecha correcta' - y eso ES el estado buscado, un NULL visible es la representacion correcta de 'el libro todavia no lo dijo'. (3) uq_personas_cuit_cuil_activo: ACT NOW, la premisa de que hay que elegir entre dos personas es FALSA. db03 leyo las dos filas: la 177 se apellida literalmente 'Galati Test', no tiene DNI, y su creado_por es el CUIT de la 91 sin puntuacion - es basura de QA creada por pantalla desde la sesion de la 91 en DEV, no una persona ni un duplicado de una. Rige la regla de que el dato de prueba de DEV es descartable: soft-delete de 177, que el indice parcial ya excluye, y se crea el indice; la 91 no se toca. UNICA precondicion, que db03 declara no haber medido: chequear si alguna FK de DEV referencia a la 177 antes del soft-delete. (2) DROP de vdc.observaciones en PROD: ES la unica decision real de Elazar, y llega mucho mas chica de lo que decia el ticket. El '595 de 2413 difieren' no es el riesgo: el libro es SSOT y su Observaciones ES la del periodo, o sea que 592 de esas diferencias son la copia de VDC siendo correctamente superada. Lo unico que el drop destruiria son las 3 filas con texto que no existe en otro lado, medidas enteras: AB674IP y AE631MI llevan el boilerplate 'Se modifican datos a pedido de la empresa', que ya aparece verbatim en filas de periodo; UNA SOLA oracion en toda la base es unica, la de AG202SZ - 'Se cedio la linea a la empresa NUDO S,A,' - y es justo la unica que lleva un HECHO. PRECONDICION: preservar esa oracion en la fila de periodo abierta de AG202SZ y verificar que se lee de vuelta (eso NO pide aprobacion, es un data fix del tipo que DEV ya probo), resolver pg_depend y NUNCA CASCADE porque PROD todavia tiene fn_archive_vehiculos_datos_colectivos y v_vehiculos_export_vdc nombrando la columna, y recien entonces preguntarle a Elazar un SI/NO angosto. Audit agrega, y vale: archivar la columna entera antes de cualquier drop. EVIDENCIA QUE NADIE TIENE Y NO SE RELLENO: (a) si alguna FK de DEV referencia a personas 177; (b) por que sobrevivio el default en PROD - ningun artefacto distingue 'se intento y fallo' de 'nunca se corrio'; (c) si algun consumidor EXTERNO lee v_vehiculos_export_vdc.observaciones - se chequeo la base y este repo, que no es lo mismo que chequear todos los llamadores de la API externa.
• wi-cli-venus audit-finding · 3w ago
  CORRECCION a la recomendacion del blackboard, item (1), 2026-09-23 03:58 ART. La pregunta de audit-general-cc - si DEV escribe la fecha del libro una vez sacado el estampado falso - la midio db03 y la respuesta es peor que lo que supusimos los dos. DEV NO la escribe, y el estampado de la fecha de corrida NO es el DEFAULT. Censo de escritores de public.vehiculos.fecha_ultima_actualizacion en las dos bases: dos funciones la nombran, fn_archive_vehiculos() (copia al archive, no decide valor) y rutap.reconciliar_snapshot(integer,boolean), cuyo cuerpo instalado lleva en la linea 484 'fecha_ultima_actualizacion = current_date' IDENTICO en DEV y en PROD. O sea que el camino de UPDATE estampa la fecha de la corrida en DEV igual que en PROD; lo que MOVILBA-145 bajo en DEV fue el DEFAULT, que solo dispara en el INSERT de un vehiculo nuevo, y el escritor DOMINANTE quedo intacto de los dos lados. Verificado por coder03 del lado del codigo, que es su carril: la app NUNCA escribe la columna - src/repositories/parque-movil.ts:205 la expone en la descarga de Parque Movil, src/lib/openapi/components.ts la declara en el contrato de la API externa, y no hay ningun otro camino de escritura en src/. QUE CAMBIA: (a) DEV NO es el estado bueno al que PROD converge en este campo - las dos estan mal, de la misma forma, en el camino que toca a TODO vehiculo existente en cada import; la frase 'PROD fabrica dato equivocado en cada import' era cierta e incompleta, DEV tambien lo fabrica, por el reconciliador. (b) Bajar el default de PROD NO cierra 145: cierra el camino de alta y deja el de update, asi que el reporte despues de aplicarlo es '145 sigue abierto', no '145 hecho'. El ACT NOW sigue en pie igual - es DDL pre-go-live, reversible en una sentencia, y saca uno de los dos estampadores. (c) La mitad que escribe la fecha CORRECTA del libro no existe en NINGUNA de las dos bases: eso es lo que MOVILBA-146 tiene que definir, y es por eso que el header de la migracion dice a proposito que no backfillea. NO CAMBIA: item (3), persona 177 es 'Galati Test' sin DNI con creado_por = CUIT de la 91 sin puntuacion, basura de QA; item (2), la perdida unica es una sola oracion, la de AG202SZ.
• wi-cli-venus note · 3w ago
  Item (1) del ticket CORREGIDO por medicion posterior: el DEFAULT de PROD es el MENOR de dos estampadores. rutap.reconciliar_snapshot escribe fecha_ultima_actualizacion = current_date sobre todos los vehiculos existentes en cada import, identico en DEV y PROD, asi que DEV no es el estado bueno al que PROD converge en ese campo. Sacar el default en PROD sigue siendo correcto (DDL pre-live, reversible en una sentencia) pero NO cierra 145 y no debe reportarse como que lo cierra. Detalle completo y evidencia: MOVILBA-540.
• wi-cli-venus decision · 3w ago
  SEGUNDO blackboard, bb-coder03-mba-l-cc-mudr9zet-ptxzrx, 2026-09-23 04:03 ART, db03-mba-l-cc y audit-general-cc independientes. No hay carril de audit de MovilBA registrado - ni -cc ni -ca - asi que el rol se resolvio al unico auditor vivo. ORDEN RECOMENDADO, CAMBIADO: (3) -> (2) -> (1). Los dos coinciden en (a) y (b); difieren en el orden, y se toma el de db03 porque su argumento es sobre el TAMANO de cada item y no sobre su dificultad. (a) Bajar el DEFAULT de PROD sigue siendo ACT NOW pero YA NO ES UN ARREGLO, es una limpieza: saca un escritor que esta mal en todos los casos en que dispara y elimina una divergencia DEV/PROD, sin mejorar el dato de ningun vehiculo. El riesgo principal pasa a ser el REPORTE. Texto exigido, en este orden: MOVILBA-145 sigue ABIERTO; se bajo el DEFAULT de PROD, que cierra SOLO el camino de INSERT; el escritor dominante, reconciliar_snapshot linea 484, queda INTACTO e identico en DEV y PROD y dispara sobre todo vehiculo existente en cada import; la fecha de ningun vehiculo es mas correcta despues del cambio, solo dejan de adquirir una equivocada los vehiculos nuevos; la mitad del valor correcto no existe en ninguna de las dos bases y es MOVILBA-146. El ticket NO se cierra, NO sale de deferred y NO se marca parcialmente hecho. db03 agrega una salvaguarda del artefacto: aplicar el drop con un gate que afirme que el cuerpo de reconciliar_snapshot TODAVIA contiene la linea current_date al momento del apply, para que el propio artefacto registre que el estampador grande seguia en pie cuando se saco el chico. audit agrega que eso va en el TICKET, no solo en el mensaje de commit. (b) Frenar el estampado de reconciliar_snapshot es DECISION DE ELAZAR, no carve-out - pero NO por el motivo que puso la pregunta, que db03 retiro midiendo: la columna no quedaria en NULL, max(fecha_alta) sobre los periodos cubre los 2413 vivos de PROD con CERO NULLs. Es decision porque max(fecha_alta) es UNA derivacion defendible y no LA derivacion, y elegir entre defendibles es la definicion de decision. Detalle completo y el paso de solo lectura que sigue: MOVILBA-539. (c) (2) y (3) no cambian en sustancia. (1) baja a ultimo para que no se lea como avance sobre 145; (2) sube porque es el unico de los tres que hace a PROD mas fiel al libro y el unico que realmente espera a Elazar, y ponerlo detras de dos tareas de limpieza es lo que lo hizo esperar. audit prefiere dejar el orden y correr 539 en paralelo; no hay conflicto practico, 539 no bloquea a los otros tres ni al reves. (d) Lo que NINGUNO recomienda sin evidencia que no tiene: db03 no propone max(fecha_alta) como el valor que 146 debe escribir, aunque cubra los 2413 - cobertura total prueba que la columna PUEDE poblarse del libro, no que esa fecha sea lo que 'ultima actualizacion' significa para quien la lee; falta una DEFINICION de Elazar o de Eugenia, y ninguna consulta la produce. audit no recomienda tocar el estampado sin saber que hacen con el campo la descarga de Parque Movil y el contrato de la API externa - si lo leen como dato, como senal de frescura, o como nada. GAPS QUE QUEDAN NOMBRADOS Y SIN RELLENAR: por que nunca corrio la pata PROD de la migracion de 145 - ningun artefacto distingue 'se intento y fallo' de 'nunca se intento'; y quienes son los consumidores de la API externa, que no se pueden enumerar desde aca.
• wi-cli-venus audit-finding · 3w ago
  CORRECCION al evento decision del segundo blackboard, 2026-09-23 04:14 ART, la hace db03 sobre su propia medicion. reconciliar_snapshot NO estampa a todo vehiculo en cada import. El UPDATE de las lineas 473-493 del cuerpo instalado lleva WHERE v.id = s.vehiculo_id AND (dominio, subtipo_id, chasis_id, numero_serie_chasis, numero_serie_motor, anio_modelo, chasis_modelo, asientos, motor_fabricante_id, motor_unidad_propulsora_id) IS DISTINCT FROM la tupla del libro: es change-detected y solo alcanza a los vehiculos cuya fila proyectada CAMBIO. El comentario 469-472 del propio cuerpo explica el motivo - sin ese predicado el trigger de archive escribiria una fila por vehiculo por corrida y el archive mediria corridas de import en vez de reescrituras reales. Se cito el SET y no se leyo el WHERE. CONSECUENCIA QUE INVIERTE UNA AFIRMACION MIA ANTERIOR: la columna NO es residuo de lote. Significa 'fecha del ultimo import que cambio la fila proyectada de este vehiculo', que es un significado coherente. Las cifras ya lo falsificaban antes de leer el cuerpo: un estampado masivo dejaria UNA fecha y no ocho, y haria imposible que 1049 vehiculos llevaran un tramite del libro posterior al sello. EL DEFECTO QUE SOBREVIVE ES MAS ANGOSTO Y SIGUE SIENDO REAL: la columna no ve las ediciones de la app. Medido en PROD: 166 vehiculos vivos tienen una edicion en audit_log y en 99 de ellos la ultima edicion es POSTERIOR a la columna; mas 1049 de 2413 con un tramite del libro posterior al sello. Sub-declara por DOS caminos independientes. LO QUE CAMBIA PARA ELAZAR: aparece una TERCERA opcion y ninguno de los dos carriles la rankea - (A) escribir la fecha del tramite, (B) sacarle el camino de escritura y dejar el historial como unica fuente, que es lo que MOVILBA-98 eligio para la UI, (C) dejarla como esta y DOCUMENTAR que mide. La comparacion de solo lectura ya corrio y esta en MOVILBA-540 con artefacto en /data-lezama/movilba/evidencia/MOVILBA-540/ (md5 39a6d8e55b4bb3d1502a5bed4f75fc10): 2407 de 2413 cambiarian, delta mediano -34 dias, max(fecha_alta) y max(greatest(alta,baja)) divergen en 807 vehiculos, 'ultimo MODIF' queda DESCARTADO como candidato unico porque deja 672 en NULL, y los 9 NULLs de DEV son la unica huella del DEFAULT que 145 bajo. NO CAMBIA: el orden (3)->(2)->(1), ni el item (2) - AG202SZ - ni el (3) - persona 177.
• wi-cli-venus note · 3w ago
  G7 NO es 537 y la distincion queda escrita aca porque es donde se confunden: G7 es un cambio de PROYECCION (dejar de EMITIR la columna en la descarga y en la API); 537 es el DROP fisico sobre 1545 filas pobladas de PROD. Distinto acto, distinto radio. Superficies de G7 medidas por db04-mba-l-ca en el checkout actual 2026-09-23 12:16 ART: (1) /vehiculos ExportButton src/app/vehiculos/page.tsx:295 -> src/components/ExportButton.tsx:56 -> /api/export?entity=vehiculos&format=xlsx (src/app/api/export/route.ts); (2) externa /api/v1/exports/vehiculos -> src/lib/exports/vehiculos.ts:63, que TODAVIA lista Observaciones; (3) JSON /api/v1/parque/vehiculos/{id} y /search -> src/repositories/parque-movil.ts:155 current_h.observaciones; (4) aparte, reporte historico src/app/api/reportes/vehiculos-historico/route.ts:85, observaciones crudas/vigentes. Instruccion de db04 que se obedece: verificar VALOR EMITIDO y procedencia, no sola presencia, y NO borrar observaciones del libro apoyandose en la redaccion vencida de G7.
• wi-cli-venus note · 3w ago
  CORRECCION DEL CONTEO VIGENTE: la descripcion de este item todavia dice que solo 3 filas pobladas de observaciones son unicas de VDC. Ese numero sale de una comparacion por igualdad EXACTA y quedo vencido. Hallazgo de audit-mba-l-ca revisando si algun numero mio seguia apoyado en esa suposicion - si, este. Numero vigente, censo normalizado contra el archivo entero del libro (puntuacion, caso y acentos): de 1545 filas pobladas en PROD, 1233 se recuperan de la fila de import vigente, 261 de otra fila del mismo vehiculo, y 11 no se recuperan de ningun lado. Esas 11 son todas la formula generica 'Se modific(aron/an) datos/identidad ... a pedido/solicitud de la empresa'. DOS NUMEROS QUE NO SON EL MISMO Y SE VENIAN MEZCLANDO: 595 es la cantidad de vehiculos donde el texto del periodo vigente DIFIERE del texto legacy de vdc - sirve como fixture y es valido, se uso como gate de comportamiento del artefacto de 562 y fallo 595/595 contra el cuerpo viejo. 11 es la PERDIDA irrecuperable si se borra la columna. Una diferencia cruda no es una perdida: la mayor parte de esas 595 se recupera del libro o de otra fila. Citar 595 como perdida sobreestima por un factor de 54. Los eventos historicos de este item quedan como estan: su correccion posterior esta registrada y borrarlos escondería que el numero se movio. Lo que se corrige es la descripcion VIVA, que es lo que alguien lee para decidir. Es la tercera vez en esta saga que la igualdad exacta sobre la corrupcion coma-por-punto del libro infla un conteo, y las tres veces el numero inflado llego a Elazar antes de re-medirse.
• coder03-mba-l-cc assigned · 2w ago
  db04-mba-l-ca
• coder03assistant-mba-l-ca note · 1w ago
  MOVILBA-472 scope transferred here: VDC.observaciones versus period Observaciones discrepancy and its unresolved PROD schema/data remediation are part of this broader schema-census item. Track one decision/remediation path here to avoid parallel ownership.
• coder03-mba-l-cc assigned · 1w ago
  db03-mba-l-cc / db
• db03-mba-l-cc note · 1w ago
  db03 2026-10-08: re-measured fresh, all 3 named decisions, against current PROD/DEV. 1 of 3 is now fully moot, 1 has a cleared precondition but still needs a GO to execute, 1 is unchanged and still Elazar's alone. (1) vehiculos.fecha_ultima_actualizacion DEFAULT drop in PROD - MOOT, SUPERSEDED, NOT JUST DONE. information_schema.columns returns ZERO rows for this column in EITHER base today - the column itself was physically dropped (not just its DEFAULT), consistent with MOVILBA-146 (closed this session): "fecha_ultima_actualizacion RETIRADA de public.vehiculos el 2026-09-23 (MOVILBA-145)", docs/reference/vehiculo-data-model.md:119. rutap.reconciliar_snapshot(integer,boolean)'s installed body no longer references the column at all (grepped the full pg_get_functiondef output, zero hits) - the writer this item worried about surviving the default-drop was itself removed in the same pass. Nothing left to act on; MOVILBA-145/146 own whatever is still open about the field's replacement (the LEFT JOIN LATERAL derivation audited under MOVILBA-195, closed). (2) vdc.observaciones DROP in PROD - UNCHANGED, STILL ELAZAR'S CALL, NOT TOUCHED. Measured today: vehiculos_datos_colectivos.observaciones still exists in PROD (information_schema confirms the column). Not dropped, not archived, AG202SZ's unique sentence not independently re-verified preserved this pass. This remains the one item of the three that is a genuine Elazar SI/NO, per the 09-23 blackboard's own framing - no new information to report beyond what is already on the ticket. (3) personas 91/177 + uq_personas_cuit_cuil_activo in DEV - PRECONDITION NOW MEASURED, WAS THE ONE GAP LEFT OPEN ON 09-23 ("si alguna FK de DEV referencia a la 177 antes del soft-delete" - explicitly flagged as not measured then). Measured today: YES, 2 live FK references exist - chofer_historial.id=4 (observaciones literally "Persona creada para test", creado_por = CUIT 20421184020, the same QA-session artifact the ticket already identified for persona 91) and personas_datos_chofer.id=10 (empty chofer-data row, no fecha_inicio_actividad, no ambito). Both are themselves disposable fixtures of the SAME test session that created persona 177, not independent real data - they do not change the "persona 177 is QA garbage" verdict, and a soft-delete (UPDATE borrado_en, not a hard DELETE) never engages a FK constraint regardless. Precondition clears: nothing blocks the recommended soft-delete-177 + create-index path on referential-integrity grounds. STILL NOT EXECUTED THIS PASS - leaving the actual soft-delete + CREATE UNIQUE INDEX for an explicit go-ahead, since the ticket's own text lists this as one of the three items that "suben a Elazar" even though the 09-23 blackboard's technical conclusion was ACT NOW; not resolving that framing conflict unilaterally by writing DDL. Index still does not exist in DEV (uq_personas_cuit_cuil_activo: zero rows in pg_indexes), persona 177 still live (borrado_en NULL) - both exactly as left on 09-23, now with the one previously-missing precondition filled in.
• coder03-mba-l-cc blocked · 1w ago
  Espera la palabra explicita de Elazar: el DROP de vehiculos_datos_colectivos.observaciones en PROD destruye datos poblados, y eso nunca entra en la autorizacion de rutina pre-live. Hasta que el la de, 537 NO es trabajo tomable de la cola de db03, que es como estaba quedando - backlog, prioridad 2 y sin bloqueo escrito. Dos cosas cuelgan de esta decision, medidas el 2026-10-08: (1) el objetivo unificado del trigger de archive de VDC en MOVILBA-731 queda UNRESOLVED, porque el unico delta de cuerpo es OLD.observaciones y DEV ya no tiene la columna - ningun cuerpo se puede copiar a la otra base sin converger columna y funcion juntas; (2) la convergencia de ese objeto no se puede cerrar por el lado de DEV sin revertir una migracion ya aplicada. La autoridad del lado DEV es la MIGRACION 2026-09-18-movilba-472-drop-vdc-observaciones-DEV.sql, no el item MOVILBA-472, que esta CANCELED por haberse fusionado aca el 2026-10-05 sin descartar hallazgos. La excepcion a 'la estructura fluye PROD->DEV' se cita contra la migracion aplicada; un item cancelado no establece nada.