Borrar public.parque_rutap_temp: staging del Excel de 2025-12 superseded por el libro vigente
Tabla de staging de ~2025-12 con las MISMAS columnas que el libro vigente trae hoy por tramite. Guardaba carroceria_id POR VALOR sin FK, por lo que pg_constraint no la veia: 1398 de sus 1601 filas apuntaban a carrocerias marcadas para borrado fisico. Aparecio desde el barrido por valor de MOVILBA-504 y se venia rastreando bajo ESE numero, que es INCORRECTO: 504 es el port de la limpieza de carrocerias (56 marcadas, YUTONG id 71, IGUAZU id 72) y sigue ABIERTO con sus tres patas sin correr. Este item existe para que cerrar el DROP no cierre la poda - lo levanto audit y lo confirme midiendo en PROD. DECISION: blackboard bb-db02-mba-l-cc-mu74c8os-extt6t, coder03 y audit los dos (A) DROP, independientes. Los dos corrigieron mi premisa: el importer VIVO no toca esta tabla (escribe rutap.snapshots); lo que la escribia era el camino de import viejo. Forma general: una tabla que un pipeline escribia no sigue siendo suya despues de que el pipeline se reemplazo. GO de PROD: Elazar, CLI 2026-09-18, literal '1a'. Sus palabras reemplazaron el parrafo pendiente del header ANTES de correr. APLICADO en DEV (10.9.10.54) y PROD (10.78.42.168), 1601 filas cada una, to_regclass = NO EXISTE en las dos. Archivo: docs/migrations/2026-09-18-movilba-504-drop-parque-rutap-temp-DEV-Y-PROD.sql - el nombre lleva 504 y hay que repuntarlo a ESTE ref en un commit nuevo. Commits: 21e1a91c (espejo drizzle, v5.5.245, tambien arrastra el port serial->identity de rutap.snapshots) + 79f92b93 (la migracion, 241 lineas, verificada byte a byte contra lo aplicado con git show). INSTRUMENTOS, cada cero con su nombre: pg_depend+pg_rewrite 0, pg_get_functiondef 0, pg_views.definition 0, pg_matviews.definition 0, pg_policies 0, pg_constraint contype=f 0, pg_trigger 0. Y el que faltaba, que lo pidio audit: pg_stat_user_tables - PROD marcaba seq_scan=1280 sobre una tabla que ningun codigo lee, pero el andamiaje hermano de la misma base marcaba 976/934/787 y en DEV toda la familia marcaba 10-11 uniforme: firma de barredor de esquema, no de lector. La comparacion es el instrumento; el absoluto solo no discrimina. Lo fuerte: 0 escrituras en 127 dias. pg_stat_statements NO esta instalado en PROD, asi que las lecturas no se pudieron atribuir a una consulta - declarado, no tapado. Costo pagado: MOBAAPI-649 nombraba esta tabla como fuente del backfill de motor_id; coder03 lo repunto al libro vigente por comentario de Jira antes del apply. PENDIENTE, no de este item: limpiar el texto 'RUTAP import staging (SSoT)' en tools/import/IMPORT_STATUS.md y tools/aiql-movilba/CLAUDE.md, y revisar el package-lock.json que cambio en 21e1a91c (proyecto pnpm).
Activity
-
parent=#3945
-
Aplicado y verificado en DEV y PROD, committeado en 21e1a91c + 79f92b93, archivo verificado byte a byte con git show contra lo aplicado. MOVILBA-504 queda ABIERTO: sus tres patas (56 marcadas, YUTONG id 71, IGUAZU id 72) siguen sin correr, medido en PROD despues del DROP.
-
DUPLICADO de MOVILBA-508. Los dos items son el mismo DROP de parque_rutap_temp y se crearon con un minuto de diferencia: audit nos mando a los dos, a coder03 y a mi, a 'filar un item separado y cerrarlo', y los dos lo hicimos sin chequear si el otro ya lo habia hecho. GANA MOVILBA-508, y no por ser anterior sino porque el commit d5495c65 ya renombro el archivo de migracion a 2026-09-18-movilba-508-drop-parque-rutap-temp-DEV-Y-PROD.sql y re-prefijo sus 16 excepciones/notices. El ref esta escrito en el artefacto; mover el artefacto a este numero seria un segundo rename por nada. 509 queda como duplicado cerrado. No leer nada de aca: el registro completo (GO literal, los siete instrumentos + pg_stat_user_tables, la ausencia de pg_stat_statements, las dos respuestas del blackboard) esta en 508. LA FORMA QUE VALE LA PENA, porque es la misma trampa que el propio ticket documenta a otra escala: una instruccion correcta mandada a DOS carriles a la vez produce trabajo duplicado, igual que un 'cerra 504' mandado sin mirar el titulo del item produce un cierre equivocado. El que recibe una orden de crear algo chequea primero si ya existe.
-
DUPLICADO de MOVILBA-508, que coder03-mba-l-cc creo y cerro pocos minutos antes por el MISMO hallazgo de audit y el MISMO trabajo (el DROP de parque_rutap_temp). Los dos carriles reaccionamos al mismo mensaje y ninguno vio el item del otro. Se CANCELA este y queda 508 como el registro, por dos razones concretas, no por antiguedad: el archivo de migracion ya se renombro a 2026-09-18-movilba-508-... y sus 16 excepciones/notices ya dicen MOVILBA-508 en commit d5495c65, y 508 lleva adentro el GO literal, los siete instrumentos, el hueco de pg_stat_statements y las dos respuestas del blackboard. Repuntar el archivo a 509 seria un tercer commit sobre lo mismo. Nada de este trabajo se pierde: esta todo en 508 (cerrado) y el padre real, MOVILBA-504, sigue abierto con la poda.
-
Duplicado de MOVILBA-508. Mismo DROP de parque_rutap_temp, creado con un minuto de diferencia porque audit nos mando a coder03 y a mi a filar el item separado y ninguno de los dos chequeo si el otro ya lo habia hecho. GANA 508 - no por anterior sino porque el commit d5495c65 ya renombro el archivo de migracion a su numero y re-prefijo sus 16 excepciones/notices: el ref esta escrito en el artefacto. El registro completo (GO literal '1a', los siete instrumentos de catalogo + pg_stat_user_tables, la ausencia de pg_stat_statements, las dos respuestas del blackboard) vive en 508; no leer nada de este item. La forma, y es la misma trampa que el ticket documenta a otra escala: una instruccion correcta mandada a DOS carriles a la vez produce trabajo duplicado, igual que un 'cerra 504' mandado sin mirar el titulo del item produce un cierre equivocado. El que recibe una orden de crear algo chequea primero si ya existe.