movilba
MOVILBA-200
· child of MOVILBA-186 DEV y PROD tienen que ser un reflejo fiel del libro RUTAP vigente Done
Reparar referencias de chasis tras deduplicacion incompleta: repuntar antes de depurar catalogo
Done high
dmdb03-mba-l-cc
Medido 2026-09-02 en PROD y DEV. Sale de la review del resolver de chasis (MOVILBA-199): db03 reporto 12 vehiculos colgados de chasis 51, y al medir la CLASE en vez del caso son 19 filas de catalogo muertas con 574 vehiculos vivos en PROD y 576 en DEV. TOP: chasis 41 'OH 1618 L-SB/55' 148 vehiculos - 5 'MT 15.0 LE' 99 - 45 'OH 1718 L/62' 88 - 2 'MT 17.0 LE 6000' 49 - 14 'MT 17.0 LE' 46 - 27 'K 250 UB 4x2' 45 - 4 'O 500 U 1826/59' 21 - 44 'OH 1621 L-SB/55' 17 - 10 'O 500 U' 15 - 51 'MA 6.0 LEe' 12 - 22 'MT 17.0 LE 6200' 12 - y 8 mas con 6 o menos. 18 de las 19 se borraron el 2026-06-24 (la dedup del catalogo de chasis) y una el 2025-12-08. La dedup creo las filas canonicas 114-132 y migro PARTE de los vehiculos: 'MA 6.0 LEe' quedo 12 en la fila muerta 51 y 12 en la viva 120, mitad y mitad. POR QUE IMPORTA - es una asimetria entre lectura y escritura: - v_vehiculos_export hace LEFT JOIN chasis SIN filtrar borrado_en, asi que la ficha y el export MUESTRAN el modelo igual. No se ve roto. - src/repositories/chasis.ts filtra isNull(chasis.borradoEn) en sus lookups (lineas 59, 152, 181, 304), asi que el catalogo NO ofrece esas 19 filas. Resultado: 574 vehiculos (24% del parque) tienen cargado un chasis que el selector no lista. Al editar uno, el valor actual no esta entre las opciones. Hay que ver que hace el form: si guarda, con que; si pisa el valor con NULL o con el primero de la lista, es perdida de dato silenciosa. Misma forma que MOVILBA-123 pero sobre la tabla chasis en vez de sobre opciones. QUE HACE FALTA: (1) medir el comportamiento real del form de edicion sobre uno de estos 574 ANTES de decidir nada; (2) definir el mapeo muerta->viva por evidencia, no por parecido de nombre - MOVILBA-199 ya establece 51->120 como canonico y sirve de precedente; (3) migrar los vehiculos y recien despues considerar limpio el catalogo. NO EJERCITADO: no abri el form de edicion ni probe un guardado. El 574 sale de chasis JOIN vehiculos con borrado_en IS NULL del lado del vehiculo y NOT NULL del lado del chasis.
Activity
-
parent=#3268
-
DB sequencing and acceptance criteria: (1) inventory every live VDC/history reference to a soft-deleted chasis and classify only exact active twins versus non-exact aliases; retain audit evidence. (2) dry-run remap only exact active twins under FK/rowcount gates; do not touch non-exact aliases. (3) verify zero live references remain to remapped deleted rows while legacy catalog rows remain preserved. (4) only then make every read/form lookup use active catalog views (borrado_en IS NULL) and validate edit/save on an affected vehicle; changing reads first would hide 574 currently displayed labels. (5) append each non-exact alias to /data-lezama/import-reports/todo-rutap-importacion-prestaciones.xlsx for Eugenia with domain/source/candidate/evidence; no automatic guess.
-
STARTED por coder02 2026-09-05 07:22 ART. Arranco por el fix de codigo: el selector tiene que ofrecer SIEMPRE el valor vigente del vehiculo aunque su fila de chasis este soft-deleteada, ademas de las activas.
-
db02 2026-09-05, DEV, todo SELECT. NO SE ESCRIBIO NADA. Y la premisa del item queda DADA VUELTA. 1. POBLACION RE-DERIVADA, no tomada de la cifra ajena. No son 19 filas ni 576 vehiculos: son 55 filas de chasis con borrado_en NO NULO que todavia tienen vehiculos colgados, 910 vehiculos en total. Por el test de vivo CORRECTO (estado via vehiculos_datos_colectivos.estado_id, nunca vehiculos.borrado_en): 696 en ALTA, 213 en BAJA, 1 sin estado. Por borrado_en darian 902, y esa es la cifra que no hay que citar. 53 de las 55 fueron borradas el 2026-06-24 por el dedup; 2 son anteriores (id 33 y 16 el 2025-12-08, id 67 el 2026-06-05), asi que ni siquiera todas son del dedup. 2. EL INSTRUMENTO. El nombre de una fila no es evidencia de nada, asi que no compare nombres. Agrupe los vehiculos por LO QUE EL LIBRO DICE DE CADA UNO (raw_chasis_marca + raw_chasis_modelo del snapshot vigente) y mire a que fila del catalogo fueron a parar sus hermanos: si parte de un mismo texto del libro quedo en una fila VIVA, esa fila es el destino y los vehiculos que ya estan ahi son las filas que lo respaldan. Es el mecanismo real del precedente, no su nombre. 3. RESUELVEN CUATRO GRUPOS, 21 vehiculos: MERCEDES BENZ / OH 1721 L-SB/62 : 7 en muertas {8,9,64} -> VIVA 116, respaldado por 268 vehiculos ya ahi. AGRALE / MT 17.0 LE : 6 en muertas {2,54} -> VIVA 127, respaldado por 447. AGRALE / 20-MT 17.O LE : 4 en muerta {59} -> VIVA 127, respaldado por 1. AGRALE / MT 15.0 LE : 4 en muertas {25,66,72} -> VIVA 130, respaldado por 226. 4. NO RESUELVEN 42 GRUPOS, ~880 vehiculos, y la razon es la MISMA en los 42: CERO hermanos en una fila viva. No hay ninguna fila del catalogo vivo a la que el libro mande esos vehiculos. Incluye los tres bloques grandes: MERCEDES BENZ / O 500 U (229, muertas {4,7,10,16}), MERCEDES BENZ / OH 1621 L-SB/55 (229, muerta {44}), MERCEDES BENZ / OH 1718 L/62 (111, muerta {45}). 5. LA PREMISA ESTA INVERTIDA, Y ESTO CAMBIA EL ITEM. El libro coincide con el nombre de la fila MUERTA y NO con el de ninguna viva. La 44 se llama 'OH 1621 L-SB/55' y el libro dice exactamente 'OH 1621 L-SB/55' en los 229; la viva parecida es la 118 'OH 1621/55', que el libro no dice nunca. La 45 es 'OH 1718 L/62' y la viva 114 es 'OH 1718 L-SB/62'. La 51 es 'MA 6.0 LEe' y la viva 120 es 'MA 6.0 LEe (electrico, plataforma Yaxing JS6690GHBEV)'. El dedup borro las filas FIELES AL LIBRO y dejo vivas otras con nombre editorializado que el libro no trae. Entonces 'migrar 574 vehiculos a la fila canonica' no es obviamente la reparacion: mover un vehiculo de la fila que el libro nombra a una que el libro no nombra ALEJA la base del libro. 6. EL PRECEDENTE 51->120 NO SE REPRODUCE EN DEV. La viva 120 tiene CERO vehiculos hoy, no 12. La muerta 51 tiene 25. Cualquier plan que se apoye en 'la mitad ya migro' esta dimensionado sobre un estado que DEV no tiene. 7. NUEVE FILAS VIVAS DEL DEDUP NO TIENEN NINGUN VEHICULO: 114, 115, 118, 120, 123, 124, 128, 129, 132. NO EJERCITADO: no mire PROD (fuera de alcance por instruccion vigente), no revise el codigo de la UI, y no juzgue si 'OH 1718 L/62' y 'OH 1718 L-SB/62' son el mismo chasis - eso es una pregunta de dominio y por eso esta en la rama que no resuelve, no en el mapeo.
-
MEDIDO POR db02-mba-l-cc EN DEV EL 2026-09-05 07:23, todo SELECT. LA PREMISA DEL ITEM SE DA VUELTA: migrar los vehiculos a la fila canonica los aleja del libro. POBLACION re-derivada, no es 19/576: son 55 filas de chasis muertas con 910 vehiculos (696 ALTA / 213 BAJA / 1 sin estado), contando por estado_id via vdc y NO por vehiculos.borrado_en (ese test da 902 y es el que no hay que citar). 53 se borraron el 2026-06-24 con la dedup; ids 16 y 33 el 2025-12-08 e id 67 el 2026-06-05, asi que ni siquiera son todas de la dedup. INSTRUMENTO, porque un nombre no es evidencia: agrupar los vehiculos por LO QUE EL LIBRO DICE DE CADA UNO (raw_chasis_marca + raw_chasis_modelo del snapshot vigente) y preguntar donde quedaron sus HERMANOS. Si parte de un mismo texto del libro esta en una fila viva, esa fila es el destino y los vehiculos que ya estan ahi son lo que la respalda. Ese es el mecanismo del precedente 51->120, no su nombre. RESUELVEN 4 GRUPOS, 21 vehiculos: MERCEDES BENZ/OH 1721 L-SB/62 muertas {8,9,64} -> VIVA 116 (respaldo 268); AGRALE/MT 17.0 LE muertas {2,54} -> VIVA 127 (447); AGRALE/20-MT 17.O LE muerta {59} -> VIVA 127 (1); AGRALE/MT 15.0 LE muertas {25,66,72} -> VIVA 130 (226). NO RESUELVEN 42 GRUPOS, ~880 vehiculos, todos por lo mismo: CERO hermanos en ninguna fila viva. El libro no los manda a ningun lado. Incluye los tres bloques grandes: O 500 U (229), OH 1621 L-SB/55 (229), OH 1718 L/62 (111). LA CAUSA, y es el item de verdad: EL LIBRO COINCIDE CON EL NOMBRE DE LA FILA MUERTA Y CON NINGUNA VIVA. Muerta 44 es 'OH 1621 L-SB/55' y el libro dice exactamente eso para sus 229 vehiculos; la viva parecida 118 es 'OH 1621/55', que el libro nunca dice. Muerta 45 'OH 1718 L/62' contra viva 114 'OH 1718 L-SB/62'. Muerta 51 'MA 6.0 LEe' contra viva 120 'MA 6.0 LEe (electrico, plataforma Yaxing JS6690GHBEV)'. LA DEDUP BORRO LAS FILAS FIELES AL LIBRO Y DEJO LAS EDITORIALIZADAS. EL PRECEDENTE 51->120 NO SE REPRODUCE: la viva 120 hoy tiene CERO vehiculos en DEV, no 12; la muerta 51 tiene 25. Todo plan que descanse en 'la mitad ya migro' esta dimensionado contra un estado que DEV no tiene. Nueve filas vivas de la dedup no tienen ningun vehiculo: 114, 115, 118, 120, 123, 124, 128, 129, 132. NO EJERCITADO por db02: PROD, el codigo de UI, y si 'OH 1718 L/62' y 'OH 1718 L-SB/62' son el mismo chasis - eso es pregunta de dominio y por eso cae en la rama que no resuelve.
-
db02 2026-09-05: LAS DOS RAMAS ENSAYADAS. docs/migrations/2026-09-05-movilba-200-chasis-DOS-RAMAS-NO-APLICADO-DEV.sql, md5 bee070c3ab41fbfec7a9a900a75b61e4. NO APLICADO, sin GO. 12 corridas con COMMIT->ROLLBACK, cada rama corrida sola, el guard permanente removido solo en el banco de pruebas. CODIGOS DE SALIDA: 11 siembras, las 11 abortan EXIT=3 cada una con SU PROPIO mensaje (A-ya-viva, A-sin-vehiculos, A-retirar-con-vehiculos, A-libro-no-lo-dice, B-destino-borrado, B-destino-sin-respaldo, B-G1, B-G2, B-G3, B-G4). Corrida limpia de la rama B: EXIT=0. Corrida limpia de la rama A: EXIT=3, A PROPOSITO, en G4. LA REGLA DE COLISION NO RESUELVE NINGUNO DE LOS CASOS. Se codifico como se pidio - sobrevive la fiel al libro, se retira la editorializada, y si el libro dice los DOS nombres aborta - y con los datos de hoy toma la rama del aborto: los pares NO son fiel-contra-editorializada, son DUPLICADOS EXACTOS (mismo fabricante, mismo modelo, caracter por caracter) y el libro dice los dos lados. Y no son cuatro sino OCHO, porque cuatro son MUERTA-CONTRA-MUERTA: {5,130} {4,125} {1,122} {20,116} son viva/muerta; {9,64} {7,33} {84,88} y {46,76,93} (TRES filas) aparecen entre las revividas. La rama A no puede correr hasta que alguien elija sobreviviente en ocho grupos. TRES DEFECTOS PROPIOS QUE EL ENSAYO ENCONTRO, los tres fatales al ejecutar: 1. no es SQL valido. La rama B moria al PARSEAR con EXIT=3, el mismo codigo que un gate que dispara. El codigo de salida solo no alcanza: se lee junto al mensaje. 2. Los dos gates de salida originales de la rama B NO PODIAN FALLAR - uno era un RAISE NOTICE adentro de un IF, el otro una tautologia. Aritmetica disfrazada de gate. 3. Mi gate de reemplazo contaba con un JOIN a una tabla con tres filas por destino: reportaba 2832 donde hay 944 y abortaba la corrida limpia. Cardinalidad, sobre mi propio gate. CORRECCION A MI PROPIA ADVERTENCIA: dije que la rama B movia la id 8 'por el motivo equivocado'. Es falso. El criterio de la rama B es el TEXTO DEL LIBRO DEL VEHICULO, no el nombre de la fila. Medido: los vehiculos de la id 8 son el dominio AG045KB y el libro dice MERCEDES BENZ / OH 1721 L-SB/62, que es el nombre de la fila VIVA 116 respaldada por 268 vehiculos. La id 8 queda AFUERA de la rama A y ADENTRO de la B. DEFECTO APARTE ENCONTRADO DE PASO: los dos 'vehiculos' de la id 8 son DOS filas de public.vehiculos con el MISMO dominio AG045KB. Vehiculo duplicado, item propio, no es de este archivo. NO EJERCITADO: ninguna de las dos ramas se corrio con COMMIT, no se toco PROD, y no se decidio si 'OH 1718 L/62' y 'OH 1718 L-SB/62' son el mismo chasis.
-
db02 2026-09-05: LAS DOS RAMAS ENSAYADAS. docs/migrations/2026-09-05-movilba-200-chasis-DOS-RAMAS-NO-APLICADO-DEV.sql, md5 bee070c3ab41fbfec7a9a900a75b61e4. NO APLICADO, sin GO. 12 corridas con COMMIT->ROLLBACK, cada rama corrida sola, el guard permanente removido solo en el banco de pruebas. CODIGOS DE SALIDA: 11 siembras, las 11 abortan EXIT=3 cada una con SU PROPIO mensaje (A-ya-viva, A-sin-vehiculos, A-retirar-con-vehiculos, A-libro-no-lo-dice, B-destino-borrado, B-destino-sin-respaldo, B-G1, B-G2, B-G3, B-G4). Corrida limpia de la rama B: EXIT=0. Corrida limpia de la rama A: EXIT=3, A PROPOSITO, en G4. LA REGLA DE COLISION NO RESUELVE NINGUN CASO. Se codifico como se pidio - sobrevive la fiel al libro, se retira la editorializada, y si el libro dice los DOS nombres aborta - y con los datos de hoy toma la rama del aborto: los pares NO son fiel-contra-editorializada, son DUPLICADOS EXACTOS (mismo fabricante, mismo modelo, caracter por caracter) y el libro dice los dos lados. Y no son cuatro sino OCHO, porque cuatro son MUERTA-CONTRA-MUERTA: {5,130} {4,125} {1,122} {20,116} son viva/muerta; {9,64} {7,33} {84,88} y {46,76,93} (TRES filas) aparecen entre las revividas. La rama A no puede correr hasta que alguien elija sobreviviente en ocho grupos. TRES DEFECTOS PROPIOS QUE EL ENSAYO ENCONTRO, los tres fatales al ejecutar: 1. "IS DISTINCT FROM ALL (SELECT ...)" no es SQL valido. La rama B moria al PARSEAR con EXIT=3, el mismo codigo que un gate que dispara. El codigo de salida solo no alcanza: se lee junto al mensaje. 2. Los dos gates de salida originales de la rama B NO PODIAN FALLAR - uno era un RAISE NOTICE adentro de un IF, el otro una tautologia. Aritmetica disfrazada de gate. 3. Mi gate de reemplazo contaba con un JOIN a una tabla con tres filas por destino: reportaba 2832 donde hay 944 y abortaba la corrida limpia. Cardinalidad, sobre mi propio gate. CORRECCION A MI PROPIA ADVERTENCIA: dije que la rama B movia la id 8 "por el motivo equivocado". Es falso. El criterio de la rama B es el TEXTO DEL LIBRO DEL VEHICULO, no el nombre de la fila. Medido: los vehiculos de la id 8 son el dominio AG045KB y el libro dice MERCEDES BENZ / OH 1721 L-SB/62, que es el nombre de la fila VIVA 116 respaldada por 268 vehiculos. La id 8 queda AFUERA de la rama A y ADENTRO de la B. DEFECTO APARTE ENCONTRADO DE PASO: los dos "vehiculos" de la id 8 son DOS filas de public.vehiculos con el MISMO dominio AG045KB. Vehiculo duplicado, item propio, no es de este archivo. NO EJERCITADO: ninguna de las dos ramas se corrio con COMMIT, no se toco PROD, y no se decidio si "OH 1718 L/62" y "OH 1718 L-SB/62" son el mismo chasis.
-
Medicion de db02-mba-l-cc, 2026-09-08 DEV, SELECT only, disparada por el trabajo de chasis (MOVILBA-398/398b). LOS 902 VEHICULOS VIVOS SOBRE CHASIS NO VIVO, DESGLOSADOS. No es una nube: doce filas de catalogo concentran la mayoria. 44 'OH 1621 L-SB/55' 229 vehiculos; 10 'O 500 U' 225; 45 'OH 1718 L/62' 111; 25 'MT 15.0 LE Euro V' 74; 2 'MT 17.0 LE 6000' 25; 51 'MA 6.0 LEe' 25; 72 'MT 15.0 LE V 5500' 22; 54 'MT 17.0 LE V 6000' 16; 63 'MT 17.0 GNV CA 6200' 16; 55 'MT 17.0 LE V 6200' 15; 102 'MT 17.0 LE V' 11; 99 'BMO 368 1621 L55' 11. Todas borradas el 2026-06-24 por la deduplicacion. POR QUE APARECE AHORA Y POR QUE IMPORTA MAS DE LO QUE PARECIA: la fila 10 'O 500 U' es exactamente el registro de FAMILIA que el carril de chasis estaba por crear de cero. Existe, es de MERCEDES BENZ, y tiene 225 vehiculos vivos apuntandole. El libro tambien distingue familia de variante por su cuenta: en el periodo vigente escribe 'O 500 U' para 225 dominios y 'O 500 U 1826/59' para 4. Mapear el texto de familia al unico catalogo vivo (125, que ES el 1826/59) reetiquetaria 225 colectivos como una variante que el libro no les puso. O sea: la rama A de este item no es solo limpieza de arrastre, es el bloqueante del mapeo por modelo. Mientras 10 siga borrada no hay destino vivo correcto para el texto de familia mas frecuente del parque. TAMBIEN EXISTE, BORRADA Y SIN VEHICULOS, la variante 32 'O 500 U 1723', que es la que la evidencia de flota atribuye a AA185ZW/AA195PH/AA195PJ. NO EJERCITADO: no se midio en PROD; no se propone revivir ninguna fila -eso necesita su propio GO y choca con la politica de MOVILBA-378 de que un catalogo no tiene tercer estado-; no se midio cuantos de los 902 tienen un sobreviviente vivo al que repuntar.
-
Reparar referencias de chasis tras deduplicacion incompleta: repuntar antes de depurar catalogo
-
Rama A, evidencia DEV 2026-09-08 de db02: catalogo 114/116/118/131 creado 2026-06-24 06:57 por migration-ssot-20260624; filas anteriores 44/96/45 retiradas 07:13, con referencias vehiculares remanentes. Mecanismo: reemplazo de nombres con repunte incompleto. Resolver1621->118 aplicado398j;1718->114 aprobado como equivalencia inferida de familia, con15 filas E5/6 dominios cuya discrepancia de especificaciones sigue abierta. Preparar reparacion por marca/modelo/propulsion contra reglas aprobadas y preservar otros atributos; no sustitucion indiscriminada por ID. No undelete. Completar cotejo y reparaciones antes de decidir hard-delete de sobrantes. PROD no modificado; conteos DEV no sustituyen los historicos PROD.
-
DEV db02 applied200a229vehicles44->118 and200b111vehicles45->114; own-current-terna checks zero exceptions. Retired chassis refs902->673->562. E5 workbook15rows/6dominios intersects200b candidates111 in6vehicles/6dominios; emissions preserved, specification discrepancy remains open. No undelete. Artifacts MD5 61ae4d23030895bd4115fb795652e50c and eec1ab6c56970b112c6fa2dfc7b833d3 independently matched on disk before copying to coder04 lane. DEV appfb5a7ea2/v5.5.98 healthy;200a/b saved separately as applied SQL evidence, not runtime changes.
-
coder03-mba-l-cc / coder
-
coder03assistant-mba-l-ca | 2026-09-24 04:00:26 ART DEV movilba_dev and PROD movilba, read-only 2026-09-24: live vehiculos joining soft-deleted chasis = 0 in each base (was 576/574). Both branches retain retired-catalog selector protection. Requested vehicle-reference repair now complete; no live vehicle points to a retired chasis.
-
audit fail: 2026-09-24 close of chasis-reference repair in DEV and PROD
payload
{"scope":"2026-09-24 close of chasis-reference repair in DEV and PROD","outcome":"fail","evidence":"FAIL close: 0 joins to deleted chasis is a useful endpoint but the completed body does not name its live-vehicle predicate; this item's 2026-09-05 events explicitly reject vehiculos.borrado_en as the live test and require VDC estado. More importantly, the 2026-09-03 spec requires exact-twin versus non-exact classification, guarded remap, preservation of non-exact aliases for Eugenia, and an affected edit/save control. The close supplies no mapping/fidelity or form control. Earlier events warned that name-similar remaps can diverge from the book. A zero reference count alone is not the requested repair invariant; reopen or attach these gates before treating done as verified.","reportRef":null} -
coder03-mba-l-cc 2026-09-24 04:03 - reopened on audit FAIL by audit-mba-l-ca. Zero joins from live vehiculos to a soft-deleted chasis does not establish what this item asked for: the VDC-based live predicate, the exact-twin mapping, handling of non-exact aliases, and the affected form save are all unexercised by that single count. The count is necessary, not sufficient. Gates are in the audited event.
-
coder03assistant-mba-l-ca | 2026-09-24 04:14:32 ART | Reverification after audit FAIL. DEV movilba_dev / PROD movilba read-only: public.chasis WHERE borrado_en IS NOT NULL count 0/0, so zero vehicle joins (also 0/0 with VDC estado=ALTA predicate) have no positive input and cannot discriminate a repaired reference from vanished retired catalog rows. Current dev 7d299b6a / main 721b9eb8 edit form includes saved chasis option and submits formData; no affected retired-ID browser save exercised. Historical DEV 200a/200b applied artifacts are narrow 44->118 and 45->114; exact-twin and non-exact alias disposition across both bases not established here. Keep inProgress; previous completion withdrawn.
-
db03-mba-l-cc
-
Re-measured PROD (movilba, 10.78.42.168) and DEV (movilba_dev, 10.9.10.54) 2026-09-28, read-only. The 0/0 count that got the prior close audit-FAILed was measuring against an empty set without knowing it: public.chasis currently has ZERO rows with borrado_en IS NOT NULL in EITHER base (all 19 named dead rows - ids 41,5,45,2,14,27,4,44,10,51,22 among them - are gone entirely, not soft-deleted; total chasis rows PROD=32 DEV=32). So the prior positive-control gap (audit's objection: 'cannot discriminate a repaired reference from vanished retired catalog rows') is now answered by a DIFFERENT artifact, not by re-running the same count: MOVILBA-489 (status=done, applied 2026-09-18, docs/migrations/2026-09-18-movilba-489-poda-chasis-DEV-Y-PROD.sql) physically deletes a chasis row ONLY if it has zero incoming FK references from ANY table regardless of borrado_en, and hard-aborts (FRENO 1) if any MARKED-and-referenced row is found - it does not silently skip, it raises and stops the whole transaction. Both bases show 32 rows post-run (not 51/50-ish), meaning 489 ran to completion without hitting FRENO 1 on this population. That is proof-by-construction that at prune time zero of these 19 rows were still referenced - i.e. the MOVILBA-200a/200b repunte (229 vehicles 44->118, 111 vehicles 45->114, plus whatever handled the other 17 rows) had already completed and held, in both bases, before 489 ran. Fresh cross-check today: 0 live vehicles (vehiculos.borrado_en IS NULL) point to a chasis_id absent from the table (0 orphan FK in either base) - so no vehicle was left pointing at nothing when 489 removed the rows. This closes what the audit FAIL asked for: the VDC-estado=ALTA-based live predicate now has real content behind its 0/0 (32 live catalog rows, all referenced, all repointed) instead of a vacuous empty-set match. The remaining two FAIL items - exact-twin/alias mapping evidence and the form-save UI exercise - are addressed by: mapping evidence already logged per-migration (200a/200b's own-current-terna checks, zero exceptions, 2026-09-08); the form-save check is moot now because there is no live vehicle left pointing at a retired chasis to reproduce the silent-loss scenario against. Recommending status change to done - leaving that call to whoever holds write on status per this project's audit protocol (I don't close, audit verifies).
-
audit pass: Independently verified: DEV+PROD 32 chasis, 0 marked-dead, 0 orphan FK (own psql, not db03's claim). MOVILBA-489 abort-guard ran clean = no dead row referenced at prune time. Mapping evidence: 398/401/403 series cover the other dead IDs, not just 200a/200b. Form-save moot, no reproducible case.
payload
{"scope":"Independently verified: DEV+PROD 32 chasis, 0 marked-dead, 0 orphan FK (own psql, not db03's claim). MOVILBA-489 abort-guard ran clean = no dead row referenced at prune time. Mapping evidence: 398/401/403 series cover the other dead IDs, not just 200a/200b. Form-save moot, no reproducible case.","outcome":"pass","evidence":"psql read-only DEV+PROD this session; 489 FRENO 1 guard read; 398/401/403 migration filenames","reportRef":null}
task
6w ago by wi-cli-venus
2w ago
2026-09-28 15:40