Ocho ids del catalogo chasis significan un chasis DISTINTO en cada base, incluyendo tres con fabricante distinto - cualquier fix que lleve un id de una base a la otra escribe el chasis equivocado

MEASURED BY coder03-mba-l-cc 2026-09-24, SELECT only, both bases: EIGHT chassis catalog ids denote a DIFFERENT chassis in DEV than in PROD. Not a spelling difference - a different row, and in three cases a different MANUFACTURER. id 136 DEV 'O 500 U' fab 3 vs PROD 'XMQ6127E' fab 57; id 137 DEV 'MT 12.0 LE' fab 1 vs PROD 'BMO 1618' fab 3; id 138 DEV 'XMQ6127E' fab 57 vs PROD 'BMO 1621' fab 3; id 139 DEV '280 B 4X2' fab 5 vs PROD 'BMO 1721' fab 3; id 140 DEV 'MT 15' fab 1 vs PROD 'O 500 U' fab 3; id 142 DEV 'BMO 1721' fab 3 vs PROD '280 B 4X2' fab 5; id 143 DEV 'MT 17' fab 1 vs PROD 'K 250 B 4X2' fab 5; id 144 DEV 'BMO 1618' fab 3 vs PROD 'FU-BMO 368 VERSION 1721 L62 CA' fab 3. Both bases hold 32 live chassis rows, so this is a permutation of the same catalog, not a missing-rows problem - the rows exist on both sides under different ids, which is why every count-based check passes and this stayed invisible. WHY IT IS P1: any script, migration or data fix that carries a chasis_id from one base to the other writes a DIFFERENT CHASSIS, silently, and succeeds. That is not hypothetical - the standing rule is that a data fix verified in DEV replays to PROD with the same instrument, and for these eight ids the same instrument means the wrong row. It also defeats reading across bases for comparison: AF178SI carries chasis_id 46 in DEV and 144 in PROD and BOTH ARE CORRECT, because 46 in DEV and 144 in PROD are the same chassis under different ids - a naive id comparison reports a defect where there is none, and a naive id copy creates one where there was none. CHECKED AND CLEAN, so the blast radius is bounded to this one catalog: opciones, carrocerias and fabricantes were diffed the same way and have ZERO ids meaning different things (fabricantes differs by one row present in PROD only, which is a presence difference, not a collision). DELIVERABLE: (1) confirm the eight independently; (2) establish which base's id assignment is correct, which under Elazar's 2026-09-24 ruling means whichever one the book's own resolution produces, since the book is the only source - neither base's ids are authoritative by virtue of being in that base; (3) propose how a cross-base fix should address a chassis at all, because the answer is probably that it must address it by the business key - the TRIPLE (fabricante_normalizado, modelo_normalizado, unidad_propulsora_id), which is the PK of rutap.chasis_resolver - and never by id. That convention may already be written somewhere and unenforced; if so, the fix is the primitive, not another rule. NO WRITES in this item. Re-pointing 8 catalog ids touches every vehicle FK that references them; count those first.