COMPLETO: public.carrocerias queda en 17 filas TODAS VIVAS (era 74 con 56 borradas) y las 16 grafias del libro resuelven contra una fila viva sin re-crear ninguna

Sub-tickets

Activity

• wi-cli-venus created · 5w ago
• wi-cli-venus note · 5w ago
  RESPUESTA A LA PREGUNTA ABIERTA, y ademas este item pasa a ser la PRIMERA EJECUCION de la politica MOVILBA-378, no un caso suelto. Le pregunte a Elazar si editar el texto de la fila viva mal escrita entraba en alcance. Queda contestado por la politica que eligio: GANA LA GRAFIA DEL LIBRO. Donde la fila viva es la mal escrita y la fiel esta borrada - el caso 'YUTONG ' con espacio contra la id 70 borrada - el sobreviviente es el que el libro nombra, y todo lo demas se fusiona adentro reapuntando referencias. El criterio de supervivencia es el LIBRO, nunca el flag borrado_en. Y el borrado deja de ser "sacar basura": es FUSIONAR y despues borrar fisico. Las referencias se reapuntan primero. Eso resuelve tambien el peligro 1 de este item, los tres vehiculos soft-deleted sobre las ids 13 y 33: se reapuntan al sobreviviente vivo, no se conserva la fila por ellos y no se usa CASCADE. 377 no arranca hasta que 378 devuelva el censo y el limite opciones/tabla-propia.
• wi-cli-venus verified · 5w ago
  MEDICION PREVIA COMPLETA. 2026-09-08 db02-mba-l-cc, DEV, SELECT only, CERO escrituras a la base. Dump de pre-estado en /data-lezama/import-reports/2026-09-08-movilba-377-carrocerias-pre-estado-DEV.tsv, 75 filas de datos, modo 600, md5 692e22ef36103e7c78ff56cd93783f4a, con borrado_por enmascarado donde tenia forma de CUIT. EL BLOQUEANTE, y no lo tenia ninguno de los tres peligros listados: public.carrocerias TIENE UN TRIGGER BEFORE DELETE. CREATE TRIGGER trg_soft_delete_carrocerias BEFORE DELETE ON public.carrocerias FOR EACH ROW EXECUTE FUNCTION fn_soft_delete() y fn_soft_delete hace UPDATE ... SET borrado_en=NOW(), borrado_por=... WHERE id=$1 AND borrado_en IS NULL, y despues RETURN NULL. Un RETURN NULL en un BEFORE DELETE FOR EACH ROW CANCELA EL DELETE. O sea que un DELETE FROM public.carrocerias no borra fisicamente NADA: se convierte en soft-delete. Y como las 56 filas objetivo YA tienen borrado_en, el UPDATE interno matchea cero filas: el statement reporta DELETE 0 y no pasa absolutamente nada. Una migracion escrita sin saber esto corre limpia, informa exito y no borra una sola fila. El mismo trigger esta en 25 tablas, asi que esto no es una particularidad de carrocerias. CONSECUENCIA PARA EL ARTEFACTO: hay que ALTER TABLE public.carrocerias DISABLE TRIGGER trg_soft_delete_carrocerias dentro de la transaccion y re-habilitarlo, con un control final que afirme tgenabled='O' de nuevo. Requiere ser owner de la tabla. Y el control de exito NO puede ser el ROW_COUNT del DELETE: tiene que ser un count(*) posterior sobre los ids objetivo. 1. LAS 74 FILAS: en el TSV. Resumen: 18 vivas, 56 borradas. De las borradas, 54 llevan borrado_por 'system:carroceria-debundle-661' con borrado_en 2026-06-30 06:59:21 (el de-bundling de MOBAAPI-661), 1 lleva 'delete-test-data' del 2025-12-08 (id 15, UGARTE/'Bedazzle'), y 2 llevan una cuenta de usuario (ids 57 y 70). NINGUNA es del dedup del 2026-06-24. 2. REFERENCIAS SEPARADAS vivas/borradas: ninguna fila borrada tiene vehiculos VIVOS. Tres filas borradas tienen vehiculos SOFT-DELETEADOS: id 33 ITALBUS con 2, id 13 TODO BUS/'TODOBUS' con 1. Del lado historia: 12 filas de rutap.vehiculo_historial_normalizado tienen carroceria_id, TODAS origen='app', repartidas en ids 1 (2), 2 (1), 9 (4), 12 (4), 14 (1) - todas filas VIVAS del catalogo, ninguna apunta a una borrada. 3. TODA FK, desde pg_constraint y no de memoria: son DOS, las dos NO ACTION. public.vehiculos.carroceria_id -> vehiculos_carroceria_id_fkey rutap.vehiculo_historial_normalizado.carroceria_id -> vehiculo_historial_normalizado_carroceria_id_fkey Por pg_depend ademas: 4 indices, la secuencia, un default, entradas de pg_rewrite (vistas) y el trigger. Ninguna otra tabla. 4. QUE FILAS NOMBRA EL LIBRO: 16 grafias. 66 de las 74 filas llevan un carroceria_modelo que el libro nombra. Las 8 que NO: id 72 IGUAZU (viva, 0 refs), id 18 YUCHAI (viva, 1 vehiculo borrado), id 14 UGARTE (viva, 2 vehiculos borrados y 1 fila de historia), ids 15/65/66/67 UGARTE (borradas, 0 refs) e id 11 SALDIVIA A 325 U (borrada, 0 refs). 5. LISTA PROPUESTA. La regla mecanica -borrada, cero referencias de cualquier tipo, y su fabricante conserva una fila viva con la grafia del libro- da 49 ids. HAY QUE SACARLE UNO: el 70. EL PELIGRO 2 SE CUMPLE Y LA REGLA MECANICA CAE EN EL. YUTONG: la fila VIVA es la id 71 con carroceria_modelo 'YUTONG ' CON ESPACIO AL FINAL y 4 vehiculos; la fila que lleva la grafia exacta del libro, 'YUTONG', es la id 70 y esta BORRADA con 0 referencias. Borrar por la marca conserva la grafia mala y destruye la fiel, permanentemente. El 70 NO se borra: primero se decide si se corrige el 71 (un UPDATE, con su propio GO) o si se revive el 70 y se repuntan 4 vehiculos. BORRABLES SIN CONDICION, 48 ids: 19,20,21,22,23,24,25,26,27,28,29,30,31,32,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59,60,61,62,63,64,69,73,74. CINCO MAS, con una decision de una linea: 11 (SALDIVIA A 325 U), 15 (UGARTE/'Bedazzle', borrada por 'delete-test-data'), 65, 66, 67 (UGARTE). Las cinco tienen cero referencias; quedaron afuera de la regla solo porque su fabricante no tiene una fila viva con grafia del libro. Son basura por cualquier criterio, pero es una decision, no una derivacion. TRES RETENIDAS: 13 y 33, que tienen vehiculos soft-deleteados apuntando (por fila: repuntar el vehiculo borrado a la equivalente viva -id 12 y id 5 respectivamente- o conservar la carroceria); y 70, por la grafia. DOS VIVAS QUE NADIE USA, y son decision de Elazar, no borrado tecnico: id 72 IGUAZU con 0 vehiculos y 0 historia, e id 18 YUCHAI con 0 vivos y 1 borrado. El libro no nombra a ninguna de las dos. TOTAL A LLEVARLE A ELAZAR: 48 sin condicion, 53 si aprueba las cinco de UGARTE/SALDIVIA A 325 U, mas tres decisiones sueltas (13, 33, 70) y dos vivas (72, 18). NO EJERCITADO: PROD; si el rol que va a aplicar es owner de public.carrocerias, que es lo que habilita el DISABLE TRIGGER; y el efecto del mismo trigger en las otras 24 tablas.
• wi-cli-venus note · 5w ago
  GO DE ELAZAR, CLI, 2026-09-08. Textual: "go 53". Es sobre el par de numeros que le presente (48 incondicionales, 53 si aprobaba las cinco por decision). Aprobo 53. EL OBJETIVO LITERAL, 53 ids de public.carrocerias, DEV: 19,20,21,22,23,24,25,26,27,28,29,30,31,32,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59,60,61,62,63,64,69,73,74 (las 48 incondicionales) + 11,15,65,66,67 (las cinco por decision: cero referencias, excluidas solo porque su fabricante no tiene fila viva con la grafia del libro) LO QUE ESTE GO NO CUBRE, y no se toca en esta migracion: - id 70 y la correccion de 'YUTONG ' en la id 71. Es un UPDATE al texto de un catalogo y no fue aprobado. - ids 13 y 33, y el reapuntado de los 3 vehiculos soft-deleted a las ids 12 y 5. - ids 72 (IGUAZU) y 18 (YUCHAI), vivas y sin uso. - subtipos y tipos: es el paso 1 de MOVILBA-378, sin GO todavia. - chasis: bloqueado por MOVILBA-200 rama A. - PROD, en cualquier tabla. FORMA OBLIGATORIA DEL ARTEFACTO, por MOVILBA-379: 1. DISABLE TRIGGER trg_soft_delete_carrocerias DENTRO de la transaccion, y volver a habilitarlo en la misma transaccion. 2. Afirmar tgenabled='O' AL FINAL. La tabla no puede quedar sin su soft-delete. 3. CONTROL NEGATIVO QUE MUERDE, antes de deshabilitar: correr el DELETE con el trigger habilitado sobre un id objetivo y demostrar que borra CERO. Eso prueba que la guarda del artefacto es la que hace el trabajo y no un accidente. 4. El exito se prueba con count(*) POSTERIOR sobre los 53 ids, que tiene que dar 0. JAMAS con el ROW_COUNT del DELETE, que es exactamente el numero que miente. 5. Conteo de referencias CERO dentro de la transaccion, separando origen vivo de origen borrado, sobre los 53. 6. Guarda por current_database() = 'movilba_dev'. 7. Afirmar ANTES de borrar que los 53 tienen borrado_en NOT NULL y que ninguno esta en la lista en espera (13, 33, 70). 8. Cabecera con server_version (DEV es PG 15.17). 9. JAMAS CASCADE. PRE-ESTADO: ya existe, /data-lezama/import-reports/2026-09-08-movilba-377-carrocerias-pre-estado-DEV.tsv, 75 filas, md5 692e22ef36103e7c78ff56cd93783f4a, modo 600, borrado_por enmascarado donde tenia forma de CUIT. SECUENCIA: db02 escribe el .sql -> audit-mba-l-ca lo revisa ANTES de aplicar (SQL destructivo va a audit antes, no despues) -> se aplica en DEV -> el artefacto lo commitea un carril de codigo, no db02. Quedan 74 - 53 = 21 filas, de las cuales 18 vivas + 13, 33, 70 en espera.
• wi-cli-venus note · 5w ago
  SEGUNDO GO DE ELAZAR, CLI, 2026-09-08. Textual: "go on the 3 carrocerias". Son las TRES filas que estaban en espera: ids 13, 33 y 70, con las recomendaciones que le presente en el mismo mensaje. NO incluye las dos vivas sin uso (72 IGUAZU, 18 YUCHAI), que siguen sin decision. VA EN UN ARTEFACTO SEPARADO, aplicado DESPUES del de las 53. Motivo: el de las 53 es un DELETE puro y se audita como tal; esto suma dos clases de escritura que aquel no tiene - un reapuntado de filas de vehiculos y una correccion de texto de catalogo. Mezclarlas hace que un solo artefacto tenga tres invariantes distintas y que el control negativo de una tape a las otras. CASO A - ids 13 y 33, FUSION CON REAPUNTADO (la politica de MOVILBA-378: retirar es fusionar, no marcar): - 3 vehiculos SOFT-DELETED apuntan: 3801 (AE100DB) y 3805 (AE100DF) a la id 33 ITALBUS, y 5263 (AZE323) a la id 13. - Se reapuntan al sobreviviente VIVO: la id 33 va a la id 5 (ITALBUS viva), la id 13 va a la id 12 (TODO BUS viva). Ese destino lo midio db02 y hay que re-afirmarlo DENTRO de la transaccion, no confiar en el numero de este texto. - Recien despues se borran fisicamente 13 y 33. - CERO vehiculos VIVOS estan involucrados. Los tres son filas soft-deleted, y eso se afirma en la transaccion antes de tocarlas. - JAMAS CASCADE. El reapuntado es explicito y por id. CASO B - id 70, LA GRAFIA (regla de sobreviviente de 378: gana la grafia DEL LIBRO, jamas el flag borrado_en): - La fila viva id 71 lleva 'YUTONG ' CON ESPACIO AL FINAL y sostiene 4 vehiculos. La grafia fiel al libro, 'YUTONG' exacta, es la id 70, que esta borrada y sin referencias. - Se corrige el TEXTO de la id 71 a la grafia del libro y se borra la id 70. Sobrevive la fila que ya tiene los 4 vehiculos, con el nombre correcto: cero reapuntados. - La alternativa era revivir la 70 y mover 4 vehiculos. Mismo estado final, mas escritura y mas riesgo. ORDEN OBLIGATORIO DENTRO DE LA TRANSACCION, y es una trampa real: el catalogo esta keyeado por (fabricante_id, carroceria_modelo). Si se corrige la 71 a 'YUTONG' mientras la 70 todavia existe con esa misma grafia, se viola el unico. PRIMERO SE BORRA LA 70, DESPUES SE CORRIGE LA 71. Y hay que NOMBRAR LA COLUMNA, no asumirla: db02 tiene que decir en que columna exacta esta el espacio final - carroceria_modelo, el nombre de fabricante, o las dos - y corregir TODAS las que lo lleven en la id 71. Un trim aplicado a una sola columna deja la basura en la otra y parece arreglado. REQUISITOS DE FORMA, los mismos de MOVILBA-379 mas los de estos casos: 1. DISABLE TRIGGER trg_soft_delete_carrocerias dentro de la transaccion, re-habilitar en la misma, afirmar tgenabled='O' al final. 2. Control negativo que MUERDA sobre el DELETE (con trigger vivo borra CERO). 3. Exito por count(*) posterior sobre 13, 33, 70 = 0. Nunca el ROW_COUNT. 4. Afirmar ANTES: que los 3 vehiculos a reapuntar estan soft-deleted; que las ids 5 y 12 estan VIVAS; que la 70 no tiene ninguna referencia; que la 71 sostiene exactamente 4 vehiculos. 5. Afirmar DESPUES: que la 71 sigue sosteniendo esos mismos 4 vehiculos y que su texto ya no tiene espacio final; que 13, 33 y 70 no existen; que ningun vehiculo quedo apuntando a un id inexistente. 6. Guarda current_database() = 'movilba_dev'. Cabecera con server_version (PG 15.17). 7. Dump previo de las filas de vehiculos afectadas a /data-lezama antes del reapuntado - el pre-estado del catalogo ya existe, el de los vehiculos no. SIGUE SIN GO: 72 IGUAZU y 18 YUCHAI (vivas, sin uso, no nombradas por el libro), subtipos/tipos, chasis (bloqueado por MOVILBA-200), y PROD. Despues de los dos artefactos: 74 - 53 - 3 = 18 filas, todas vivas.
• wi-cli-venus spec · 5w ago
  ARTEFACTO ESCRITO Y ENSAYADO, NO APLICADO. 2026-09-08 db02-mba-l-cc. Archivo: docs/migrations/2026-09-08-movilba-377-borrar-fisico-53-carrocerias-DEV.sql md5 76c1421c3fc5a49cc9968974be9030ef, 251 lineas. NO SE EDITA MAS: cualquier cambio invalida esta firma y hay que re-ensayar. Precondiciones verificadas ANTES de escribir: current_user=movilba_user es OWNER de public.carrocerias (pg_has_role USAGE), que es lo que habilita el DISABLE TRIGGER; server_version 15.17; server_addr 10.9.10.54; db movilba_dev. Los 53 ids del GO existen los 53, los 53 tienen borrado_en NOT NULL, y ninguno de 13/33/70 esta en la lista. ENSAYO CON ROLLBACK, corrido sobre una copia en scratchpad con COMMIT cambiado por ROLLBACK -el artefacto NO se toco-. PASS, con los numeros reales: ANTES: 74 filas, 18 vivas, 53 en el objetivo; referencias del objetivo 0 vehiculos vivos, 0 borrados, 0 filas de historia. CONTROL NEGATIVO: con el trigger VIVO, DELETE sobre id 11 informa 0 filas borradas y la fila sigue con su borrado_en intacto. Es el control que MUERDE: si hubiera borrado, la premisa del archivo seria falsa y aborta. Con el trigger deshabilitado: DELETE 53. DESPUES: 21 filas (18 vivas + 13, 33, 70 retenidas), trg_soft_delete_carrocerias de vuelta en estado O, 0 referencias huerfanas. ROLLBACK. Verificado despues contra la base: 74 filas, 18 vivas, trigger en O. La base quedo intacta. CONTROLES QUE LLEVA, contra los 9 requisitos: 1/2. DISABLE y ENABLE del trigger dentro de la misma transaccion, y afirmacion final de tgenabled='O' leida de pg_trigger. Si algo falla despues del DISABLE, el ROLLBACK revierte tambien el estado del trigger: el DDL es transaccional. 3. Control negativo con el trigger vivo, descrito arriba, que ademas afirma que el trigger no re-estampo borrado_en. 4. Exito probado por count(*) posterior sobre los 53 ids = 0. El ROW_COUNT del DELETE no se usa como evidencia en ningun lado. 5. Conteo de referencias DENTRO de la transaccion y ANTES del cambio, separando vehiculos vivos, vehiculos borrados e historia en tres cifras distintas. 6. Guard current_database()='movilba_dev'. 7. Afirma que los 53 tienen borrado_en NOT NULL y que 13/33/70 no estan en el objetivo -y lo afirma sobre la tabla temp del objetivo, no sobre el texto del archivo, para que una edicion del INSERT no lo esquive. 8. Cabecera con server_version, server_addr, db y current_user por RAISE NOTICE. 9. Sin CASCADE en ningun lado. Extra no pedidos: las 18 vivas siguen siendo 18, el total queda en 21, las 3 retenidas siguen existiendo, y cero referencias huerfanas desde las dos FK entrantes. SIGUIENTE PASO: audit-mba-l-ca revisa ANTES de aplicar. No aplicado. PROD sin tocar.
• wi-cli-venus spec · 5w ago
  SEGUNDO ARTEFACTO, ESCRITO Y ENSAYADO, NO APLICADO. 2026-09-08 db02-mba-l-cc. Cubre las tres retenidas bajo el GO 'go on the 3 carrocerias'. Archivo: docs/migrations/2026-09-08-movilba-377b-merge-13-33-y-grafia-yutong-DEV.sql md5 e98f21791b0c17869edc32bf353eaf4d, 278 lineas. NO SE EDITA MAS. SE APLICA DESPUES del archivo de las 53. No depende de el -toca ids disjuntos- pero el orden es el del GO. RESPUESTA A 'NOMBRA LA COLUMNA', medida y no asumida: el espacio sobrante esta SOLO en public.carrocerias.carroceria_modelo de la fila 71, que vale 'YUTONG ' con 7 caracteres. public.fabricantes.fabricante de la id 61 vale 'YUTONG' con 6 y esta LIMPIA: no se toca. La 71 es ademas la UNICA de las 74 filas del catalogo con espacio sobrante en el modelo. El archivo corrige esa columna y afirma en el preflight que la del fabricante esta limpia, asi que si algun dia no lo estuviera, aborta en vez de arreglar la mitad. CORRIGE UNA PREMISA DEL PEDIDO: se dijo que el catalogo esta clavado por (fabricante_id, carroceria_modelo) y que corregir la 71 antes de borrar la 70 violaria ese unique. ESE UNIQUE NO EXISTE. public.carrocerias tiene exactamente dos constraints -PRIMARY KEY (id) y la FK a fabricantes- y sus otros cuatro indices no son unicos. La base no habria frenado nada, que es precisamente por que este catalogo llego a 74 filas con nueve AUTOBUS identicas. El orden (borrar 70, despues corregir 71) se respeta igual, y ademas el control POST afirma A MANO que no quedan dos filas vivas con el mismo fabricante y la misma grafia, justo porque no hay constraint que lo sostenga. HALLAZGO FUERA DE ALCANCE, reportado y no tocado: public.fabricantes tiene DIEZ filas con espacio sobrante en fabricante. Necesita su propio item y su propio GO. ENSAYO CON ROLLBACK sobre copia en scratchpad, el artefacto sin tocar. PASS con numeros reales: ANTES: repunte derivado DENTRO de la transaccion 13 -> 12 y 33 -> 5 (no constantes del comentario); 3 vehiculos borrados a repuntar; 0 vehiculos VIVOS involucrados; la 70 con 0 referencias; la 71 con 4 vehiculos y modelo [YUTONG ]. CONTROL NEGATIVO: con el trigger vivo, DELETE sobre id 70 informa 0 filas y la fila sigue ahi. UPDATE 3 (repunte) -> DELETE 3 (13, 33, 70) -> UPDATE 1 (btrim de la 71). DESPUES: 13, 33 y 70 no existen; la 71 se llama [YUTONG] y conserva sus 4 vehiculos; 0 referencias huerfanas; trigger en O. ROLLBACK. Re-leido despues: 74 filas, 18 vivas, modelo de la 71 [YUTONG ], las 3 retenidas presentes. Base intacta. PRE-ESTADO DE VEHICULOS, que no existia: /data-lezama/import-reports/2026-09-08-movilba-377b-vehiculos-afectados-pre-estado-DEV.tsv, 8 filas de datos, modo 600, md5 a1e9256fdb89bdf03408190155474840, borrado_por enmascarado donde tenia forma de CUIT. CONTROLES: guard current_database(); cabecera con server_version/addr/user; destinos del repunte RE-DERIVADOS exigiendo exactamente una fila viva del mismo fabricante por origen -si hubiera cero o dos aborta, porque entonces el destino seria una eleccion y no una derivacion-; afirma 0 vehiculos vivos sobre 13/33/70 y exactamente 3 borrados; afirma que la 70 tiene 0 referencias; DISABLE/ENABLE del trigger con afirmacion final tgenabled='O'; control negativo que muerde; exito por count(*) posterior y jamas por ROW_COUNT; verificacion de que 5263 llego a 12 y 3801/3805 a 5; cero referencias huerfanas desde las dos FK entrantes; y la invariante de unicidad afirmada a mano. Sin CASCADE. SIGUIENTE: audit-mba-l-cc revisa ANTES de aplicar (audit-mba-l-ca esta en el ARO pero NO registrada: el pedido a esa direccion no se entrega).
• wi-cli-venus verified · 5w ago
  APLICADO EN DEV. 2026-09-08 07:47 ART, db02-mba-l-cc, tras el PASS de audit-mba-l-cc. Archivo: docs/migrations/2026-09-08-movilba-377-borrar-fisico-53-carrocerias-DEV.sql, md5 76c1421c3fc5a49cc9968974be9030ef, sin editar desde la firma. Conexion por $DEV_DATABASE_URL. server_version 15.17, server_addr 10.9.10.54, db movilba_dev, current_user movilba_user. PROD sin tocar. Pre-estado leido inmediatamente antes: 74 filas, 18 vivas, trigger en O. SALIDA DEL APPLY, los mismos gates del ensayo, todos disparados: ANTES: 74 filas, 18 vivas, 53 en el objetivo; referencias del objetivo 0 vehiculos vivos, 0 borrados, 0 filas de historia. CONTROL NEGATIVO: con trg_soft_delete_carrocerias VIVO, DELETE sobre id 11 informa 0 filas borradas y la fila sigue con su borrado_en intacto. Es la prueba en la corrida real de que el trigger es lo que frena el borrado fisico. DELETE 53 con el trigger deshabilitado. DESPUES: 21 filas (18 vivas + 13, 33, 70), trigger en O, 0 referencias huerfanas. COMMIT. VERIFICADO DESPUES LEYENDO LA BASE, no por la salida del script: 21 filas, 18 vivas, 3 borradas, y las tres borradas son exactamente 13 [TODOBUS], 33 [ITALBUS] y 70 [YUTONG]. tgenabled='O'. Cero vehiculos apuntando a un id inexistente. CIERRA EL PUNTO 4 QUE AUDIT MARCO COMO SUPUESTO: audit no pudo re-consultar tgenabled en vivo por no tener credencial de DEV en ese carril. Medido aca antes de aplicar, el trigger estaba en 'O', y despues del apply sigue en 'O'. Deja de ser un supuesto. PENDIENTE: el artefacto lo commitea un carril de codigo, no yo. Y falta aplicar 377b (13, 33, 70), que espera revision de audit.
• wi-cli-venus verified · 5w ago
  377b Y 377c APLICADOS EN DEV. 2026-09-08 07:57-07:58 ART, db02-mba-l-cc, con PASS de audit-mba-l-cc sobre los dos md5. $DEV_DATABASE_URL, PG 15.17, 10.9.10.54, movilba_dev. PROD sin tocar. 377b md5 d325e375884293a4bdacec64821b6e2e: UPDATE 3 (repunte) -> DELETE 3 (13, 33, 70) -> UPDATE 1 (btrim de la 71). DESPUES: 18 filas, 0 soft-deleteadas, la 71 se llama [YUTONG] y conserva sus 4 vehiculos, 0 huerfanas por FK, trigger en O. 377c md5 b177ecb387b9fdbf3b4056460e65a4a7: control negativo mostro que con el trigger vivo el DELETE sobre una fila VIVA no borra pero SI estampa borrado_en, y la subtransaccion lo revirtio. DELETE 1. DESPUES: 17 filas, 17 vivas, la 18 YUCHAI intacta, trigger en O. ESTADO FINAL DEL CATALOGO: public.carrocerias tiene 17 filas y las 17 estan VIVAS. Cero filas soft-deleteadas. Era 74 con 56 borradas. EL ENTREGABLE — las 16 grafias del libro resueltas contra el catalogo vivo, sobre 21514 filas de import. NINGUNA quedo sin destino, asi que NO hubo que re-crear ninguna fila: id 12 TODO BUS [TODO BUS] — 7946 filas id 9 METALPAR [METALPAR] — 2973 id 6 LA FAVORITA [LA FAVORITA] — 2162 id 68 KING LONG [KING LONG] — 1970 id 1 AUTOBUS [AUTOBUS] — 1942 id 5 ITALBUS [ITALBUS] — 1408 id 7 MARCOPOLO [MARCOPOLO] — 1024 id 2 BAM BAM [BAM BAM] — 880 id 4 HEPRICAR [HEPRICAR] — 796 id 8 METALBUS [METALBUS] — 188 id 17 YAXING [YAXING] — 100 id 16 SALDIVIA [SALDIVIA] — 44 id 3 CORWIN [CORWIN] — 44 id 71 YUTONG [YUTONG] — 30 id 10 NUOVOBUS [NUOVOBUS] — 4 id 12 TODO BUS [TODO BUS] — 3, que son la grafia 'TODOBUS' resuelta como TYPO Suma 21514. REGLAS APLICADAS, las ya decididas: gana la grafia del libro; TODOBUS resuelve a TODO BUS por typo; NUOVOBUS y HEPRICAR quedan SEPARADAS porque las dos se presentaron asi, pendiente de Eugenia. DOS FILAS VIVAS QUE EL LIBRO NO NOMBRA, y se quedan porque algo las referencia: id 14 UGARTE (0 vehiculos vivos, 2 borrados, 1 fila de historia) e id 18 YUCHAI (0 vivos, 1 borrado: el vehiculo 6623 AA111EE). Borrarlas dejaria filas colgadas. PENDIENTE, una linea: el vinculo del import sigue sin escribirse. rutap.vehiculo_historial_normalizado.carroceria_id sigue en 0 de 21514 filas de import. El catalogo ya esta listo para resolverlas; falta que el camino de import lo consulte, que es MOVILBA-366.
• wi-cli-venus note · 5w ago
  COMPLETO. Los tres artefactos aplicados en DEV el 2026-09-08 entre 07:47 y 07:58, cada uno con GO de Elazar y PASS de audit-mba-l-cc. PROD sin tocar. - 377 (md5 76c1421c3fc5a49cc9968974be9030ef): borrado fisico de 53 filas sin referencias. - 377b (md5 d325e375884293a4bdacec64821b6e2e): reapunte de 3 vehiculos soft-deleted, borrado de 13/33/70, y correccion de la grafia de la 71. - 377c (md5 b177ecb387b9fdbf3b4056460e65a4a7): borrado de la id 72 IGUAZU, viva y sin referencias. RESULTADO: public.carrocerias pasa de 74 filas con 56 borradas a 17 FILAS, TODAS VIVAS. Cero soft-deleted. Es el estado que pedia la politica de MOVILBA-378: en un catalogo una fila esta viva o no esta. EL ENTREGABLE, que es lo que Elazar pidio de verdad - el catalogo es el SSOT normalizado. Las 16 grafias del libro sobre 21514 filas de import, todas resueltas contra una fila VIVA. NO HUBO QUE RE-CREAR NINGUNA: id 12 TODO BUS 7946 · id 9 METALPAR 2973 · id 6 LA FAVORITA 2162 · id 68 KING LONG 1970 · id 1 AUTOBUS 1942 · id 5 ITALBUS 1408 · id 7 MARCOPOLO 1024 · id 2 BAM BAM 880 · id 4 HEPRICAR 796 · id 8 METALBUS 188 · id 17 YAXING 100 · id 16 SALDIVIA 44 · id 3 CORWIN 44 · id 71 YUTONG 30 · id 10 NUOVOBUS 4 · id 12 TODO BUS 3 (la grafia 'TODOBUS', resuelta como typo). Suma 21514. Reglas aplicadas, ya decididas antes: gana la grafia del libro; TODOBUS resuelve a TODO BUS por ser typo; NUOVOBUS y HEPRICAR quedan SEPARADAS porque las dos se presentaron asi, a la espera de Eugenia (pregunta 11 del tracker). DOS FILAS VIVAS QUE EL LIBRO NO NOMBRA y que se conservan porque algo las referencia: id 14 UGARTE (0 vehiculos vivos, 2 borrados, 1 fila de historia) e id 18 YUCHAI (0 vivos, 1 borrado - el vehiculo 6623 AA111EE). Borrar cualquiera de las dos dejaria filas colgando y no hay id al que reapuntarlas. ARTEFACTOS COMMITEADOS en dev: ba1b6ff2 (377) y af1b6f38 (377b en su version aplicada d325, que reemplaza la e98f superseded, mas 377c). QUEDA ABIERTO, en su propio item y no aca: MOVILBA-366 - el import todavia no escribe el vinculo, rutap.vehiculo_historial_normalizado.carroceria_id sigue en 0 de 21514. El catalogo ya esta listo para resolverlos; falta que el camino de import lo consulte. MOVILBA-383 quedo cerrado sin defecto por instruccion de Elazar: no hay historia que preservar antes del go-live.
• wi-cli-venus titleChanged · 5w ago
  COMPLETO: public.carrocerias queda en 17 filas TODAS VIVAS (era 74 con 56 borradas) y las 16 grafias del libro resuelven contra una fila viva sin re-crear ninguna
• wi-cli-venus completed · 5w ago
  completed