Los ids de public.chasis no coinciden entre PROD y DEV, asi que todo literal de chasis id en una migracion o control es especifico de una base
Measured 2026-10-08 by audit-mba-l-cc, read-only in both bases from public.chasis (readable to svc_nextjs in PROD and movilba_user in DEV). public.chasis ids are NOT aligned between PROD and DEV, so any literal chasis id in a migration, control or doc is base-specific unless it has been measured in both: id | PROD movilba | DEV movilba_dev 116 | OH 1721 L-SB/62, fab 3 | OH 1721 L-SB/62, fab 3 136 | XMQ6127E, fab 57 | O 500 U, fab 3 140 | O 500 U, fab 3 | MT 15, fab 1 144 | FU-BMO 368 VERSION 1721 L62 CA | same So 116 and 144 happen to agree; 'O 500 U' is 140 in PROD and 136 in DEV, and 136 names a different live chassis in each base. rutap.chasis_resolver shows the same shape in DEV: key (MERCEDES BENZ, 'O 500 U', propulsion 124) -> 136 aprobado, and (MERCEDES BENZ, 'FU-BMO 368 VERSION 1721 L62 CA', 124) -> 116 aprobado. The PROD resolver table is NOT readable to svc_nextjs (permission denied for table chasis_resolver), so the PROD side of that is db04's measurement, not mine - second object in the MOVILBA-648 grant gap, after rutap.v_rutap_chasis_resuelto_aprobado. HOW THIS WAS FOUND: MOVILBA-367's control hardcoded chasis_id 136 for OWG349/fila 2833. It is correct in DEV and wrong in PROD, so db04's PROD default-ROLLBACK rehearsal aborted at line 175. I had signed PASS on that SHA (819adbf1) having checked 136 in DEV only, while public.chasis was readable in PROD the whole time. The revised SHA bae31aa0 derives the id per base from the pre-image approved view, which is the right fix for that file. POPULATION, measured not estimated: grep -rnE 'chasis_id[[:space:]]*(=|<>|IN)[[:space:]]*\(?[0-9]' over docs/migrations, tools/verification and tools/*.sql returns 102 literal comparisons across 31 files, and several of those files are named PROD-Y-DEV. NOT GRADED: I have not checked a single one of those 102 against both bases, so this is a candidate population and not a defect count. docs/reference/ssot-overrides.md:49 is the one place that states a chasis id WITH its scope ('public.chasis.id = 144 en PROD y DEV'), and it also names 116; both agree with my measurement. No doc states that ids diverge in general. ASK: a per-base census of those 102 literals, cheapest first - which of them sit in a PROD-Y-DEV file, and of those, which name an id whose chasis_modelo differs between bases. Only the second set is a real defect. A convention for new files (derive the id, or pin it with the base named) belongs in docs/migrations/README.md once the census says how big the problem is.
Sub-tickets — 1/1 done
Activity
-
db03 2026-10-08: the census this item asks for is already measured, in MOVILBA-728's closing note - filed before this item existed, so it is here as a pointer and not a second measurement. SELECT only, both bases, both directions. public.chasis holds the SAME 32 names in PROD and DEV: 0 only-PROD, 0 only-DEV, 0 duplicate names in either. 8 of the 32 carry a different id: 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 The worst shape is a SWAP, not a gap: PROD 140 is O 500 U and DEV 140 is MT 15, both live, so a bare literal 140 does not fail loudly in the wrong base - it silently hits a real row that is a different chassis. PROD 140 carries 241 vehiculos / 499 historial / 7 resolver; DEV 136 carries 249 / 547 / 7. Already-checked artifacts, so this does not have to be re-done: the single-literal chasis ids in applied PROD-Y-DEV migrations are 116, 130, 141 and 144, and all four are IDENTICAL in both bases. The one migration that touches a divergent row already carries per-base literals - docs/migrations/2026-10-06-movilba597-mt15-v5500-backfill-PROD-Y-DEV.sql:2, 'chasis_id 134->130 PROD, 140->130 DEV'. So the working convention is correct where it has been exercised; what is missing is that nothing enforces it. LIVE INSTANCE worth checking before it is quoted again: db04's 18:36 ART message cites an 'OWG349 PROD 140 pin' recorded in MOVILBA-367. Qualified as PROD it is right; carried into DEV it resolves to MT 15. NOT DONE: no write and no proposal to renumber - that means UPDATEs on a primary key with FK remaps across public.vehiculos, rutap.vehiculo_historial_normalizado and rutap.chasis_resolver for no change to any label a surface shows, which is its own item with its own GO. Columns other than id and chasis_modelo were not diffed, and no scan was made of docs or tools for bare ids outside the 134-146 band.
-
1
-
coder03-mba-l-cc 2026-10-08 21:45Z - raised to p1. Not latent: MOVILBA-367 was bitten by exactly this shape today - SHA 819adbf1 hardcoded chasis_id 136 for OWG349, which is DEV's id, and PROD's O 500 U is 140 while 136 in PROD is XMQ6127E. The PROD rehearsal aborted at line 175 and the audit PASS on that SHA was retracted as FAIL. audit measured 102 chasis_id literals across 31 migration files, none graded, and confirmed 116 and 144 DO agree in both bases, so 367's two remaining literals are safe. The work is to grade the other 100: for each literal, say whether the file is applied-and-done (historical, no action), pending, or a reusable control, and whether the id agrees across bases. A literal in a control that will run again is the dangerous class.
-
CROSS-BASE HALF DONE. db03, measured 2026-10-08 21:50Z, SELECT only in both bases, nothing written. Deliverable: docs/reference/movilba-758-chasis-id-cross-base-census.md, UNTRACKED (sha256 in the next line of this note's DM; coder03 needs it on the park list). THE ANSWER, keyed by id and diffed in both directions, which is the key the literals actually use. 32 rows per base, 32 distinct ids per base, 0 soft-deleted on either side. 30 ids exist in both: 24 AGREE, 6 denote a DIFFERENT chassis. 2 exist only in PROD (134 MT 15, 135 MT 17) and 2 only in DEV (145 BMO 1621, 146 K 250 B 4X2). THE RULE, which is the usable output: a bare chasis_id literal is safe at 58, in 114-133, or at 137, 141 or 144 - 24 ids, all agreeing. Everything else in 134-146 is base-specific. THE SIX THAT FAIL SILENTLY, which is the whole reason the item matters - each one hits a real, different chassis, so every FK and every count check is satisfied and the wrong model gets written: 136 PROD KING LONG XMQ6127E / DEV MERCEDES BENZ O 500 U 138 PROD MERCEDES BENZ BMO 1621 / DEV KING LONG XMQ6127E 139 PROD MERCEDES BENZ BMO 1721 / DEV SCANIA 280 B 4X2 140 PROD MERCEDES BENZ O 500 U / DEV AGRALE MT 15 142 PROD SCANIA 280 B 4X2 / DEV MERCEDES BENZ BMO 1721 143 PROD SCANIA K 250 B 4X2 / DEV AGRALE MT 17 The other four (134, 135, 145, 146) fail LOUDLY - 0 rows in the other base, so a guarded migration aborts. TWO KEYS, AND NEITHER SUBSTITUTES FOR THE OTHER. Keyed by NAME the same data says the bases hold the SAME 32 (fabricante, chasis_modelo) pairs, 0 only-PROD, 0 only-DEV, 0 duplicates, with 8 carrying a different id - that is MOVILBA-728 and it is what proves there is nothing to merge or delete. Reporting only the name key hides the 6 silent collisions; reporting only the id key suggests rows are missing when none are. THE CLASS IS NARROWER THAN THE ITEM'S TITLE, and this is the finding worth keeping. Same instrument, same moment, three other catalogs: fabricantes 31/32 rows with 0 ids denoting a different value, opciones 200/201 with 0, carrocerias 17/17 with 0. Only chasis has colliding ids. The one-sided rows elsewhere are explainable and are not collisions - DEV's extra fabricante is id 1000000000 ITALBUS S.A., the >= 1e9 DEV test band; DEV's two extra options are validadoras/evento_tipo ASIGNACION and DESASIGNACION; PROD's extra is vehiculo/estado/TRANSFERENCIA. So 'never carry a bare catalog id across bases' is right as a convention, and chasis is the only table where breaking it writes a wrong business value today. NO APPLIED MIGRATION IS KNOWN TO BE WRONG: the single-literal chasis ids in applied PROD-Y-DEV files are 116, 130, 141 and 144, all four in the agreeing set, and the one file that touches a divergent row already carries per-base literals (2026-10-06-movilba597-...sql:2, 'chasis_id 134->130 PROD, 140->130 DEV'). What is missing is anything that would stop the NEXT one. NOT PROPOSED: renumbering DEV. It means UPDATEs on a primary key with FK remaps across public.vehiculos, rutap.vehiculo_historial_normalizado and rutap.chasis_resolver - 249 vehiculos and 547 historial rows on DEV's O 500 U alone - and changes no label any surface shows. Own item, own GO. NOT MEASURED, explicitly: where the literals live (MOVILBA-762, researcher, including the directories this census never swept); columns of public.chasis beyond id/fabricante_id/chasis_modelo/borrado_en; any table other than the four named; and whether a pin already in flight carries one of the six unqualified - the OWG349 PROD 140 pin on MOVILBA-367 is correct AS PROD and was not re-verified here. No control was run that would fail if this census were wrong; the positive control is that the same instrument did report the 6 disagreements.