Dos periodos invertidos vivos (AH850GD, AH940VA) y ningun CHECK de fecha_baja >= fecha_alta
Dos filas VIVAS de vehiculo_historial tienen el periodo invertido - la baja es anterior al alta: AH850GD (id 10212) fecha_alta 2026-02-24 / fecha_baja 2026-01-30, y AH940VA (id 10166) fecha_alta 2026-02-05 / fecha_baja 2026-01-30. Las dos las escribio import-rutap-faltantes-2026-08-21-dev y los dos dominios ESTAN en el libro. No existe CHECK de fecha_baja >= fecha_alta en DEV, asi que el import las escribio y ningun gate las miro nunca. Pedido: (1) agregar el CHECK - es el gate mas barato de todos, solo puede dispararse sobre filas que ya estan mal; (2) probarlo contra un estado donde DEBE fallar (estas dos filas) antes de darlo por bueno; (3) decidir el valor correcto contra el libro para las dos filas antes de que el constraint las bloquee. Nota: el asunto 3 del tracker de Eugenia sobre estos mismos dos dominios figura CERRADA con respuesta 'Corregido' - o sea el libro se corrigio y nuestras filas no. Relacionado: YAM567 tiene fecha_alta 2030-09-21 (cuatro anios en el futuro) y ABC1234 tiene fecha_alta NULL, ambos dominios de prueba (MOVILBA-239).
Activity
-
db03-mba-l-cc
-
db02-mba-l-cc
-
db02-mba-l-cc, 2026-09-12: agrupacion para la propuesta de escritura (detalle en MOVILBA-190). Este item va SOLO, no agrupado con 318 ni con las reparaciones de datos, porque tiene tres pasos con orden obligatorio y el orden es la mitad del item: (1) decidir contra el libro el valor correcto de las dos filas invertidas, (2) corregirlas, (3) recien entonces crear el CHECK de fecha_baja >= fecha_alta - si el constraint entra antes, bloquea la correccion que lo habilita. Y el punto que el propio item ya pide y que hay que respetar: el CHECK se prueba contra un estado donde DEBE fallar antes de darlo por bueno. Un constraint que nunca se vio fallar no esta verificado, esta puesto.
-
db04-mba-l-ca
-
db04-mba-l-ca 2026-09-24 04:07 ART — SELECT-only installed-history check: the retired public.vehiculo_historial is absent in DEV movilba_dev and PROD movilba. In its replacement rutap.vehiculo_historial_normalizado, zero nondeleted rows have fecha_baja < fecha_alta; AH850GD is 2026-02-24..2026-04-30 and AH940VA is 2026-02-05..2026-04-30 in both. No CHECK referencing fecha_baja is installed on the replacement table, so the protective part of the ticket remains open; no status change.
-
db04-mba-l-ca 2026-09-24 04:02 ART — Timestamp correction only: the immediately preceding sweep body on this item carried a future 04:04/04:07 time; the BWI event createdAt is authoritative. No change to its measured findings or status.
-
db03-mba-l-cc / db
-
db03-mba-l-cc 2026-10-05 15:26 ART - REMEASURED, SELECT only, PROD then DEV. public.vehiculo_historial is gone. fecha_baja < fecha_alta: rutap.vehiculo_historial_normalizado 0 PROD / 0 DEV; rutap.rutap_rows (current book) 0 in both. The only inversions left are 2 in the August DEV staging tables (parque_rutap_20260813_raw, parque_rutap_20260820_1601_raw), i.e. the pre-correction book Eugenia fixed (tracker issue 3, 'Corregido'); those are scratch, not data. Part (3) of the ask (fix the two rows) is resolved by re-import. PROD vdc_mdvr_import_baseline was not readable by svc_nextjs (permission denied), so it is unmeasured there; DEV has 0. OPEN = part (1), the CHECK. It conflicts with the standing fidelity rule (CLAUDE.md: a book value is imported as stated and only an absent or ambiguous mapping blocks a row): a CHECK on vh_norm aborts the WHOLE import the day the book carries one inverted period. Decision for Elazar: A) CHECK (fecha_baja IS NULL OR fecha_baja >= fecha_alta) on vehiculo_historial_normalizado, so an inverted book row stops the import loudly; B) no CHECK; the importer reports inverted periods as a finding for Eugenia and imports them as stated. Recommendation B, consistent with the fidelity rule; if A, it can also be scoped to origen='app' (app writes only), which leaves imports faithful.
-
db03-mba-l-cc 2026-10-08. CHECK designed and tested under ROLLBACK, DEV and PROD (PROD via SET LOCAL ROLE movilba_owner). DDL: ALTER TABLE rutap.vehiculo_historial_normalizado ADD CONSTRAINT vh_norm_check_periodo_app CHECK (origen <> 'app' OR fecha_baja IS NULL OR fecha_baja >= fecha_alta); Scope decision: option A from the prior progress note, scoped to origen='app' only (hybrid of my earlier A/B recommendation) - blocks NEW inverted periods written by the app, leaves book imports faithful per the standing fidelity rule even if the book itself carries an inverted period. Forced-failure test, both bases, under BEGIN/SAVEPOINT/ROLLBACK (no persisted change, verified after - 0 test rows, constraint absent): - positive control: origen='import' row with fecha_alta=2026-02-24/fecha_baja=2026-01-30 -> ACCEPTED (book fidelity preserved) - negative control: origen='app' row with the same inverted dates -> REJECTED with "violates check constraint vh_norm_check_periodo_app" (gate fires) Both controls passed in DEV and PROD. Design is ready to apply. Part (3) of the original ask (the two specific rows AH850GD/AH940VA) was already resolved by re-import, per my 2026-10-05 progress note - public.vehiculo_historial is retired, and rutap.vehiculo_historial_normalizado has 0 inverted rows in either base today. Not applying the DDL myself - this is a coder-lane/db-lane apply decision per standing PROD-DDL-no-GO rule (project CLAUDE.md commons §6), and whoever applies should decide whether to wrap it in a dated migration file under docs/migrations/ given it's a schema object, not a bare value fix.
-
coder03 11:15 ART: APPLY authorized (Elazar-assigned item, pre-live PROD DDL needs no separate GO, CHECK adds a protection, destroys nothing). PROD first, then DEV, migration doc under docs/migrations/, diff to audit.
-
db03-mba-l-cc 2026-10-08. APPLIED, PROD then DEV. docs/migrations/2026-10-08-movilba-240-vh-norm-check-periodo-app-PROD-Y-DEV.sql (SHA256 3159e537...). CHECK (origen <> 'app' OR fecha_baja IS NULL OR fecha_baja >= fecha_alta) on rutap.vehiculo_historial_normalizado. Rehearsed under ROLLBACK first in both bases (zero trace after), then applied for real: 0 pre-existing origen='app' violations in either base, forced-failure savepoint test fired correctly in both (app row w/ inverted dates rejected), verified installed via pg_get_constraintdef post-apply, 0 test rows left in either base. Part (1) of the original ask done. Part (3) (AH850GD/AH940VA) already resolved by re-import, 2026-10-05 progress note - public.vehiculo_historial retired, 0 inverted rows in rutap.vehiculo_historial_normalizado today in either base. Part (2) (forced-failure proof) is embedded in the migration file itself, runs every time it's executed. docs/migrations/README.md updated. Audit PASS pending.
-
audit pass: migration file + README entry, SHA + live PROD+DEV constraint verified by SELECT
payload
{"scope":"migration file + README entry, SHA + live PROD+DEV constraint verified by SELECT","outcome":"pass","evidence":"SHA256 3159e537...fca9 matches file; pg_get_constraintdef identical and present in both app.movilba.com:movilba and movilba_dev; DDL additive/app-scoped, self-rehearsing, forced-failure savepoint test in file is sound","reportRef":null} -
coder03 11:35 ART: fleet parity v5.6.185 on PROD, DEV and pod (pod /api/health patch 185 via proxy-mba-w-cc).