movilba
MOVILBA-588
El import del libro 2026-09-24 corrio en PROD a las 06:30 sin dejar registro en bwi ni en docs/migrations - establecer autorizacion, gates y que borro el reconciliador
Done high
dmdb03-mba-l-cc
PROD imported the current book while the coder lane believed both bases were held. VERIFIED INDEPENDENTLY by coder03-mba-l-cc 2026-09-24, SELECT on rutap.snapshots in both bases, not taken on report: PROD snapshot id 6 = 2026-09-24-0434-parque-rutap.xlsx, md5 a7b14f7c2f6fa9bcb3383aaf2a7136cf, 5538 rows, importado_en 2026-09-24T06:30:00. DEV snapshot id 18 = 2026-09-19-0648-parque-rutap-corrected.xlsx, md5 2fc7ea9bd52c99a07defde06c0f830d4, 5528 rows, importado_en 2026-09-20T03:46. rutap.rutap_rows.digitos exists in BOTH bases, so the MOVILBA-373 DDL was applied to both. The problem is not that the import ran - PROD holding the current book is the goal. The problem is that commit 78ffc13e (05:34) states in its message that both bases remain on 2026-09-19-0648 and that the import is held pending Elazar's authorization, and nothing in bwi or docs/migrations records the PROD run that followed at 06:30. An import that leaves no record is indistinguishable from one that was never gated. ESTABLISH, read-only: (1) which lane ran it and under what authorization - look for the bwi item, the migration file or the note that should carry it, and if there is none, say so plainly rather than inferring an authorization from the fact that it succeeded; (2) whether the import's own gates ran and what they returned - the preflight and the reconciliation are the db lane's own gates and the measurement IS the gate, so a run without them is unmeasured, not merely undocumented; (3) what the reconciler DELETED in PROD, by count and by origin, since the installed body (516/517) deletes vehicles absent from the book without distinguishing provenance and PROD carries 2407 of 2414 rows tagged legacy_unknown (MOVILBA-587), which means a provenance-blind deletion there cannot be audited after the fact by that tag - use the archive tables and audit_log instead and state their coverage limits; (4) whether PROD's post-import state passes the fidelity checks against the pinned digest, i.e. the app export equalling the book is a start but it compares our output to our input and does not by itself establish that nothing was dropped. Report counts with denominators and name what was NOT exercised. No writes.
Activity
-
STARTED MOVILBA-588 at 2026-09-24 07:24:27 -03 (db03-mba-l-cc, read-only)
-
db03-mba-l-cc 2026-09-24 07:27 -03 - MOVILBA-588 report, read-only, PROD movilba (current_database checked, 10.78.42.168), no writes. Q1 who/authorization: the run is recorded in bwi. MOVILBA-155 (assignee db04-mba-l-ca) event 2026-09-24T09:42:44Z reports the PROD import from book SHA-256 94c3499d (matches file 2026-09-24-0434-parque-rutap.xlsx, re-hashed by me), snapshot id 6. Authorization: NO item, migration file or doc names who granted the GO or quotes it. The only wording is 'Authorized current-book import preflight, PROD first' (MOVILBA-155, 08:55Z) and MOVILBA-74 'import that value unchanged' (about value handling, not a PROD-write GO). Commit 78ffc13e (05:34) said the import was held pending Elazar's explicit authorization. I do not infer authorization from success. Open: whoever holds the GO must post it on MOVILBA-155, else the record says unauthorized-by-record. Timestamps disagree: rutap.snapshots.importado_en = 06:30:00 (round), vehiculos/VDC archive rows stamped 06:30:00.07, but the completion event is stamped 06:25 ART and was written 06:42 ART. Q2 gates: preflight first attempt exit 1 (header gate, col_39/col_52, digitos) at 05:55 with downstream gates NOT RUN; migration MOVILBA-373 then applied; after that the only evidence that preflight/reconciliation ran and passed is db04's own bwi text (reconciliation 0 deletes, parity, sync-checks). No run log or output file exists under /data-lezama/movilba*, /data-lezama/import-reports or the repo. I did NOT re-run preflight or the reconciler. Q3 deletes in PROD: no DELETE at 06:30. vehiculos_archive (1663 rows) has 10 DELETE, all 2026-09-18 (MOVILBA-486/489 era, users 20247094211 x2, 20341207038 x3, svc_nextjs x5); VDC archive 8 DELETE, same day. Rows archived in the import window: 1 vehiculos UPDATE (system_import) and 1597 VDC UPDATE, all at 06:30:00. 1 vehiculo created 06:30:00.07: AI563JO id 7026 (live 2414, was 2407 at MOVILBA-441; other rows created 09-07 x19, 09-17 x6). History: rutap.vehiculo_historial_normalizado now 5538 rows, all snapshot 6; snapshot 5 rows are gone (replaced), snapshot 5 row count before is not recoverable from any archive (no history archive table exists) - db04 reported 5388 at 441, unverified for 09-23. Coverage limits: archive triggers cover only vehiculos and VDC, not history; audit_log holds 573 rows, max 2026-06-17, so it has NOTHING for 09-24; origen_ingreso useless (2407/2414 legacy_unknown, MOVILBA-587). So: history deletion count/origin is NOT establishable; vehiculos/VDC deletion = 0 in window. Q4 fidelity vs pinned digest (DB tables vs book file, not the export): domains book 2414 = PROD 2414, book-only 0, PROD-only 0; history rows book 5538 = PROD 5538; per-domain row counts 0 mismatches over 2414. Checked ONLY set/count parity. NOT exercised by me: per-column value fidelity (dates, estado, catalog labels via v_opciones) in this pass; earlier 574c matched 44/44 up-dependent rows to the 09-24 book. The app export equalling the book (0 differences) is a round-trip check (our output vs our input), not a fidelity check. DEV not refreshed (17 app_dev vehicles + 54 app-origin history rows would be deleted).
-
coder03-mba-l-cc 2026-09-24 - CORRECTION to my own framing of this item, and it narrows the finding. I wrote the body around 'under what authorization', and db03's answer 'no GO on record' reads as a violation. It is not one. Elazar ruled on 2026-09-02, confirmed by him directly in CLI after a peer relayed it: 'I do not want you to ask for a GO to sync Prod to ssot, while analizeing Dev'. Syncing PROD to the current book is routine pre-authorized work until go-live; no GO was owed and none should have been sought. So the absence of a GO is CORRECT and is not part of this finding. WHAT SURVIVES as the finding, unchanged: the run left no record in bwi or docs/migrations, and commit 78ffc13e (05:34) asserts the opposite state of the world - both bases held on 2026-09-19-0648 - roughly an hour before the import landed at 06:30. Being pre-authorized is not being unrecorded: the next reader of that commit message is misinformed about which book PROD holds, which is how today's whole chassis measurement started from a false premise. VERIFIED BY ME against rutap.snapshots and rutap.vehiculo_historial_normalizado in both bases, not taken on report: PROD holds snapshot id 6 only, 5538 import rows, ZERO app rows; DEV holds snapshot id 18 only, 5528 import rows plus 54 app rows. One snapshot per base is the designed behaviour - the book is a snapshot and the import REPLACES, it is not a ledger - so prior-snapshot rows being gone is not evidence of a defect. db03's window measurement stands: no vehiculo or VDC deletions (archives show 1 vehiculo, 1 UPDATE, 1597 VDC updates), domain and row-count parity against the pinned book 2414 / 5538 with 0 mismatches, per-column fidelity NOT exercised, history deletions NOT establishable because there is no history archive and audit_log ends 2026-06-17. THE ONE THING THAT MATTERS FOR THE PENDING DECISION: PROD having zero app-origin history rows today cannot be distinguished from PROD having had some that this import removed, precisely because the instruments to tell those apart do not exist for history. That is not a reason to assume either. It IS a reason to settle the reconciler ruling before DEV imports, because DEV has 54 app rows right now and the installed 516/517 body deletes provenance-blind - the cost of getting that ruling wrong is 54 concrete rows, not a hypothetical. And Elazar's own 2026-09-02 instruction already says DEV test data must be identified and protected BEFORE reconciling, which the installed body does not do.
-
db03-mba-l-cc 2026-09-28 summary paragraph (all facts already measured 2026-09-24, this is the compressed answer): the 06:30 PROD import ran under Elazar's standing 2026-09-02 pre-authorization to sync PROD to SSOT (no GO was owed, none was missing) - the actual defect was that commit 78ffc13e (05:34) asserted both bases still held the 2026-09-19 book an hour before the run, and neither bwi nor docs/migrations recorded the run itself, so the next reader was misinformed. It deleted 0 vehiculos and 0 VDC rows in that window (1 vehiculo UPDATE, 1597 VDC UPDATE, 1 new vehiculo created); history-table deletion count is NOT establishable (no history archive, audit_log stops 2026-06-17). Post-import PROD matched the pinned book on set/count parity (2414 domains, 5538 rows, 0 mismatches) but per-column fidelity was not exercised and the export-equals-book check is a round-trip, not independent fidelity proof. Closing my reporting scope here.
-
audit pass: Verified against bwi record (2026-09-24 note + 2026-09-28 summary), not DM prose. All 4 deliverables present: auth (standing 2026-09-02, real defect is 78ffc13e's stale claim), preflight fix (MOVILBA-373 file confirmed on disk), zero vehiculo/VDC deletes (archives), set/count parity.
payload
{"scope":"Verified against bwi record (2026-09-24 note + 2026-09-28 summary), not DM prose. All 4 deliverables present: auth (standing 2026-09-02, real defect is 78ffc13e's stale claim), preflight fix (MOVILBA-373 file confirmed on disk), zero vehiculo/VDC deletes (archives), set/count parity.","outcome":"pass","evidence":"Caveats are honest, not overclaimed: downstream gate pass only in db04's own text, no run log; history-delete count NOT establishable (no archive, audit_log predates window); per-column fidelity NOT exercised, export=book is round-trip not proof. Today's re-verification not yet posted as bwi event.","reportRef":null} -
db03-mba-l-cc 2026-10-01 21:1x -03 - re-verification only, no new findings, confirms the 2026-09-24/09-28 record. rutap.snapshots is single-row (overwritten by design): PROD now shows only id=8 (2026-09-30-1305-parque-rutap.xlsx, 5548 rows), DEV only id=20 (same file, 5548 rows) - the id=6/2026-09-24-0434 row cited in the original report no longer exists in that table, confirming [[reference_rutap_snapshots_guarda_una_sola_fila]] and that the table cannot be used to re-derive this finding later; the archive tables (append-only) remain the correct instrument and still show 0 DELETE-reason rows in the 2026-09-24 05:00-08:00 window across vehiculos/VDC/entidades/personas/asociaciones archives, only 1 vehiculo UPDATE + 1597 VDC UPDATE at 06:30:00.07, archived_by='system_import' (self-attested literal, not an authenticated identity). journalctl -u postgresql@17-main covers the window (boot 0 since 2026-09-10, well before) and returns zero entries for 05:00-08:00 that day - confirms postgres does not log to journald on this host, not a retention gap. pg_stat_statements is loaded in shared_preload_libraries but the extension is NOT created in movilba (PROD) - no query-text history available regardless of retention. audit_log (app-level) has zero rows for creado_en between 2026-09-24 05:00 and 08:00 - confirms the import ran outside the app's audited code path. None of this changes Q1-Q4; it closes the instrument-availability question raised in the original report (journalctl coverage, pg_stat_statements presence) that was left open.
-
db03-mba-l-cc 2026-10-01 - audit PASS recorded (hub, 21:16 ART). Closing my reporting scope. Status change not mine - audit verdicts don't close (per protocol); coder03/PM to flip status.
-
coder03-mba-l-cc 2026-10-05: closed at db03's report; audit PASS already recorded in bwi (2026-10-02).
task
3w ago by coder03-mba-l-cc
1w ago
2026-10-05 15:01