No hay duplicado de chasis que convergir: los 32 nombres del catalogo son identicos en PROD y DEV y 8 difieren solo en el id surrogado, ya salvado con literales por base

Sub-tickets — 1/1 done

Activity

• coder03-mba-l-cc created · 1w ago
• researcher-mba-l-cc statusChanged · 1w ago
  researcher-mba-l-cc 21:16:58Z. Taking the identity half (which chasis_id is the real AGRALE MT 17 row, db03 owns the convergence/FK remap). No DB credential - requesting the actual public.chasis row content (fabricante, modelo, pbt/any other distinguishing column) for chasis_id 123, 135, 143 in both bases from db03, who already has the live measurement. Will research manufacturer identity once I have the row text.
• db03-mba-l-cc blocked · 1w ago
  Parked by db03: the convergence half cannot be decided before MOVILBA-755 says which chasis id describes the AGRALE MT 17 the book names. db03 is active on MOVILBA-731. Measurement handed to researcher for 755: in PROD id 123 = 'MT 17.0 LE GNV' fab 1 AGRALE, id 135 = 'MT 17' fab 1, id 143 = 'K 250 B 4X2' fab 5 SCANIA; in DEV id 123 = 'MT 17.0 LE GNV' fab 1, id 143 = 'MT 17' fab 1, and id 135 DOES NOT EXIST. So the same id means a different chassis in each base and 143 is not the same row across bases - which is the thing that makes 'which side converges to which' unanswerable until 755 lands.
• db03-mba-l-cc note · 1w ago
  db03 2026-10-08, unblocked by MOVILBA-755. SELECT only in both bases, nothing written. ANSWER TO THE LOOKUP coder03 asked for, with its premise corrected. There is no propulsion column on public.chasis - propulsion lives in rutap.chasis_resolver as the third member of its primary key (fabricante_normalizado, modelo_normalizado, unidad_propulsora_id). So the question is not which propulsion the chasis row carries, it is which resolver keys land on the bare row, and the resolver already answers it. Exactly two keys reach it, identical in both bases: 'MT 17' with unidad_propulsora_id 124 GO, and 'MT 17.0 V6200' with 124 GO. Of 123/127/129 only 127 ('MT 17.0 LE') is the GO member - 123 is GNC 157 and 129 is ELECTRICO 37 - so a propulsion-only lookup resolves both to 127. 728'S CONVERGENCE PREMISE IS VOID, and this is the measurement that kills it rather than an opinion. The two bases hold the SAME 32 chasis names, diffed in both directions: 0 only-PROD, 0 only-DEV, 0 duplicate names in either. The full resolver image for AGRALE is also identical - 38 rows each, same keys, same propulsion ids, same chasis_modelo text behind every one. The ONLY thing that differs is the surrogate integer, and it differs on 8 of the 32 rows, not on MT 17 alone: AGRALE MT 15 PROD 134 DEV 140 AGRALE MT 17 PROD 135 DEV 143 KING LONG XMQ6127E PROD 136 DEV 138 MERCEDES BENZ BMO 1621 PROD 138 DEV 145 MERCEDES BENZ BMO 1721 PROD 139 DEV 142 MERCEDES BENZ O 500 U PROD 140 DEV 136 SCANIA 280 B 4X2 PROD 142 DEV 139 SCANIA K 250 B 4X2 PROD 143 DEV 146 So there is nothing to merge and nothing to delete: neither base carries a duplicate of the other's row. The item's own instruction to count FK references before a DELETE is satisfied by there being no DELETE candidate, and the counts say a delete would be destructive anyway - bare MT 17 carries 9 vehiculos / 17 historial / 2 resolver in PROD and 9 / 20 / 2 in DEV, and PROD id 140 O 500 U carries 241 / 499 / 7. Also retired here: the id-reuse on 143 is NOT 'coincidence and irrelevant' as 755 relayed it. SCANIA K 250 B 4X2 exists in BOTH bases, PROD 143 and DEV 146, with live references on both sides. The reuse is one instance of the same 8-row offset, so the second row is as divergent as the first. THE DIVERGENCE IS ALREADY KNOWN AND ALREADY WORKED AROUND, which is why it is reported and not fixed. MOVILBA-710's applied migration carries per-base literals for exactly this reason - docs/migrations/2026-10-06-movilba597-mt15-v5500-backfill-PROD-Y-DEV.sql:2 reads 'chasis_id 134->130 PROD, 140->130 DEV'. Renumbering DEV to match PROD means UPDATEs on a primary key with FK remaps across public.vehiculos, rutap.vehiculo_historial_normalizado and rutap.chasis_resolver - 249 vehiculos on DEV's O 500 U alone - for no change to any label a user or a surface sees, against the standing ruling that DEV is updated cheaply. I am NOT proposing it. If Elazar wants id convergence it is its own item with its own GO. THE LIVE HAZARD worth naming, since it is the only cost the offset actually has: a bare chasis id quoted across bases resolves to a DIFFERENT chassis. PROD 140 is O 500 U and DEV 140 is MT 15. Any pin, migration, fixture or report that carries one of these 8 ids without naming its base is wrong in one of them. The single-literal ids in applied PROD-Y-DEV migrations were checked and are safe: 116, 130, 141 and 144 are identical in both bases. WHAT I DID NOT DO: no write, no DDL, and no resolver repoint - MOVILBA-367 is inProgress on how proyectar_snapshot resolves chasis, so a resolver UPDATE now would land under semantics that are being redesigned. The two keys above were not researched for model identity; that is the follow-up item, not this one. Columns other than id and chasis_modelo were not diffed, and the non-AGRALE resolver keys were not compared key by key.
• db03-mba-l-cc titleChanged · 1w ago
  No hay duplicado de chasis que convergir: los 32 nombres del catalogo son identicos en PROD y DEV y 8 difieren solo en el id surrogado, ya salvado con literales por base
• db03-mba-l-cc unblocked · 1w ago
  cleared: Parked by db03: the convergence half cannot be decided before MOVILBA-755 says which chasis id describes the AGRALE MT 17 the book names. db03 is active on MOVILBA-731. Measurement handed to researcher for 755: in PROD id 123 = 'MT 17.0 LE GNV' fab 1 AGRALE, id 135 = 'MT 17' fab 1, id 143 = 'K 250 B 4X2' fab 5 SCANIA; in DEV id 123 = 'MT 17.0 LE GNV' fab 1, id 143 = 'MT 17' fab 1, and id 135 DOES NOT EXIST. So the same id means a different chassis in each base and 143 is not the same row across bases - which is the thing that makes 'which side converges to which' unanswerable until 755 lands.
• db03-mba-l-cc completed · 1w ago
• coder03-mba-l-ca decision · 2d ago
  Elazar corrected the closure interpretation on 2026-10-14: catalog IDs are manual and must be the same across PROD and DEV. Matching labels with different IDs are not acceptable parity. The 2026-10-08 measurement remains useful, but the 'no convergence needed' conclusion is superseded. Follow-up MOVILBA-797 owns fresh census and safe ID convergence; do not change historical evidence in this completed item.