El tag de procedencia existe en las dos bases pero en PROD es legacy_unknown en 2407 de 2414 filas, asi que ningun predicado de procedencia se puede evaluar en PROD
Elazar, CLI 2026-09-24: he was told once that the column marking whether a row was imported or created by the app is absent, then told it IS there. Both statements were sloppy and the second one hid the real problem. MEASURED TODAY, 2026-09-24, SELECT only, BEGIN READ ONLY, both bases: the column EXISTS in both, identical type, nullability and default on every shared table - public.{vehiculos, vehiculos_datos_colectivos, entidades, lineas, personas, validadoras}.origen_ingreso text nullable, and rutap.vehiculo_historial_normalizado.origen text NOT NULL DEFAULT 'import'. So 'the tag is missing' is false. But in PROD the tag carries NO INFORMATION: vehiculos 2407 legacy_unknown vs 7 ssot_import, vdc identical, and rutap.vehiculo_historial_normalizado has 5538 rows all origen='import' with ZERO app rows. DEV by contrast is populated and usable: vehiculos 2396 ssot_import + 35 app_dev, vdc 2396 + 28, history 5528 import + 54 app. 'legacy_unknown' on 99.7% of PROD is the MOVILBA-442 backfill never having been finalized. THAT is the defect: a provenance predicate written against PROD returns legacy_unknown for almost every row, so any rule of the form 'skip what a user created' or 'delete what the book omits unless the app made it' cannot be evaluated there at all - and it fails OPEN or CLOSED silently depending on how the predicate is written, which is how this becomes a deletion incident rather than a wrong number. Two more limits that must be stated in whatever gets written, because they are what makes a naive backfill wrong: (1) origen_ingreso is stamped only on INSERT - src/lib/origen-ingreso.ts, used only in the alta paths of src/repositories/vehiculos.ts, never re-stamped on update - so it is a birth certificate and cannot answer 'who edited this row'; the instruments for edits are public.audit_log (pruned by AUTHORSHIP, not by date, per MOVILBA-354, so it is a witness and not a census) and the vdc _archive table, which only covers the period since its trigger existed; (2) creado_por asserts 'system_import' in places where it does not know. DELIVERABLE, measurement first and no writes in this item: determine whether PROD's 2407 legacy_unknown rows can be resolved to a real origin from evidence that exists - the zero app rows in PROD history is suggestive but does not by itself prove no PROD vehicle was ever app-created, so check audit_log and the archive tables before concluding. Report how many resolve to import, how many to app, and how many CANNOT be resolved from any surviving evidence; that third number is the one that matters and it must not be rounded into the first. Propose the FINALIZE migration with its gates separately, for review - do not write to PROD under this item. Related: MOVILBA-442, MOVILBA-486.
Activity
-
RULING - Elazar, CLI 2026-09-24, literal: 'there is no legacy or unknown. three is one ssot, thruth comes from ssot thus if ssot has a value that is the value prod shall have and if prod has a record that is not in ssot it gets deleted from prod and if prod has a record with a value different from ssot then prod gets updated to ssot value because it is ssot.' and 'ssot is ssot, thus data in prod or dev is irrelevant, only data in ssot is ssot'. THIS DISSOLVES THE QUESTION THIS ITEM ASKED. I filed it to establish how many of PROD's 2407 legacy_unknown rows resolve to a real origin. Under this ruling that does not need answering for PROD: PROD is the book, so no PROD row needs a provenance defence and no provenance predicate gates a PROD write. A row absent from the book is deleted; a row whose value differs from the book is updated to the book. The origen_ingreso tag is therefore NOT a PROD instrument at all and the MOVILBA-442 backfill is not owed in PROD. WHERE IT STILL MATTERS, and this is the whole of its remaining scope: DEV, where the same CLI message says do not touch data created or edited by users. DEV's tag is populated and usable - 35 app_dev on vehiculos, 28 on vdc, 54 app rows on the wide history - so the predicate is evaluable exactly where it is now needed. NARROWED SCOPE for whoever picks this up: stop measuring PROD provenance. Establish only that DEV's tag is trustworthy enough to protect DEV rows with, which means the known limit still binds - origen_ingreso is stamped on INSERT and never re-stamped on update (src/lib/origen-ingreso.ts, alta paths only), so it identifies rows the app CREATED and cannot by itself identify imported rows a user later EDITED. That second class is the one Elazar's instruction also protects and the tag cannot see it; say so plainly rather than reporting the tag as sufficient.
-
db03-mba-l-cc
-
db03 2026-10-01: narrowed scope per coder03's 09-24 ruling - PROD provenance dropped, DEV only. SELECT-only. DELIVERABLE (is DEV's origen_ingreso trustworthy enough to protect DEV rows with): NO, not alone - measured, not assumed. What it DOES see reliably: 35 app_dev vehiculos, 28 app_dev vdc, 54 app-origin history rows - stamped on INSERT, never re-stamped, confirmed via src/lib/origen-ingreso.ts (alta paths only). This half is solid. What it CANNOT see (the "or edited" half Elazar's ruling also protects): checked public.audit_log as the only available witness. 243 of 2396 ssot_import vehicles (10.1%) carry at least one audit_log action of 'UPDATE'/'update' against table_name='vehiculos' - i.e. a real post-import edit that origen_ingreso cannot show, because origen_ingreso still reads 'ssot_import' on every one of those 243 rows. Same shape on vdc: 45 distinct ssot_import-backed vdc ids have a non-CREATE audit_log entry. A reconciler exclusion keyed only on origen_ingreso='app_dev' would blindly treat all 243+45 as safe-to-overwrite/delete, which is exactly the failure MOVILBA-592 must guard against. 243 is a FLOOR, not the true count: audit_log only has 1011 rows total (2025-10-06 to today), and nothing establishes what fraction of the app's write paths are actually instrumented into it - an edit outside an audited path leaves no trace at all and is invisible to both origen_ingreso and audit_log. vdc_archive CHECKED AND REJECTED as a second witness: archive_reason only has two values (UPDATE 36112 rows, DELETE 26) with no source tag, and it fires on ANY vdc UPDATE whose tuple changed - including the reconciler's own import-driven rewrites (MOVILBA-516's UPDATE runs IS DISTINCT FROM-guarded on every import). 36112 rows against 2396 ssot_import vehicles (~15/vehicle) is consistent with repeated reconcile runs, not with 15 user edits per vehicle. Using it as an edit-witness would massively overcount without being able to attribute a single row to a user versus an import. Not usable. CONCLUSION, stated plainly per the instruction not to round this into the first number: DEV's origen_ingreso protects the CREATED half completely, protects at least 243 vehiculos + 45 vdc of the EDITED half via audit_log (itself a partial witness, not a census), and leaves an unknown remainder of edited-but-invisible rows with zero surviving evidence of any kind. Any DEV-side reconciler fix (MOVILBA-592) built on origen_ingreso alone will under-protect; adding an audit_log cross-check narrows but does not close the gap, and that residual must be reported alongside any fix, not presented as solved.
-
audit pass: methodology review only, DEV-scope conclusion. DB EXECUTION NOT PERFORMED BY AUDIT
payload
{"scope":"methodology review only, DEV-scope conclusion. DB EXECUTION NOT PERFORMED BY AUDIT","outcome":"pass","evidence":"insert-only stamping claim confirmed statically: all 3 origenIngresoNuevaFilaApp call sites in vehiculos.ts (626,934,979) are .insert() blocks; the 4 .update() calls (758,831,1513,1520) never touch origenIngreso. vdc_archive rejection reasoning (36112 rows / 2396 vehicles ~15x, no source tag) is sound - matches MOVILBA-516's documented IS DISTINCT FROM reconciler-rewrite pattern. Conclusion matches the project's own ruling 1 wording ('or edited' is wider than origen_ingreso) verbatim","reportRef":null} -
audit PASS 12:03 (methodology review, DB exec not re-run). Insert-only origenIngreso stamping confirmed static; or-edited gap stands per 2026-09-24 ruling.