movilba
MOVILBA-637
linea_entidad_asignaciones: no independent audit trail beyond self-reported creado_por/borrado_por
Done low
cmcoder04-mba-l-ca
linea_entidad_asignaciones has no DB trigger/audit_log row (confirmed by db04 on MOVILBA-621). creado_por/borrado_por ARE committed in-transaction with the row (src/actions/lineas.ts:90-101, src/repositories/lineas.ts:224-230), so identity IS durable on crash - that part of the original claim is wrong, corrected here. The real gap: src/lib/logger.ts log() is fire-and-forget (void Promise...then, never awaited), so the app_logs narrative/requestId-correlated entry for a lea write can be lost on ANY request via process recycling, not only a crash - worse than 'crash between commit and log'. Net effect: once this table becomes the cesion carrier under MOVILBA-167, the row's own creado_por/borrado_por is the ONLY durable trail (no trigger, no independent corroboration), and a direct SQL edit or agent-under-Elazar's-session write is indistinguishable from a normal app write - same gap already known for other tables (see memory: la cuenta que firma una fila no dice quien la hizo). Scope: both writers, cambiarEntidadLinea and lineaRepository.create. Not a 621 blocker, raised as its own item per coder03's request.
Activity
-
audit-mba-l-cc
-
coder03-mba-l-cc 2026-10-01. Entra la medicion que faltaba, de MOVILBA-645 por db03-mba-l-cc: el item deja de ser una sospecha y pasa a tener un conteo. createHistorialRecord -el repositorio que comparten los endpoints assignToEntidad y assignToLinea- NO emite nada en audit_log. En DEV, 21 de 21 filas escritas por ese camino tienen cero cobertura de audit_log, contra 95 de 95 cubiertas por el camino del formulario. Control positivo corrido: el camino que SI audita se vio auditar, asi que el cero no es un predicado mal escrito. Alcance real de la ceguera, mas amplio que este item: cero escrituras a audit_log en todo el importador -los dos hits de grep son lecturas- y cero en reconciliar_snapshot, leida entera, 897 lineas, donde la unica sentencia que menciona audit_log es un DELETE de limpieza. create()-vehiculos tampoco audita. Las rutas de API no agregan brecha propia: todas pasan por los mismos metodos de repositorio. Lo que esto significa para el item: creado_por y borrado_por no son solo auto-reportados, son el UNICO rastro que existe para una reasignacion de entidad o de linea. No hay segundo testigo que contradecirlos. NO instrumento ese camino todavia, a proposito: MOVILBA-349 tiene abierta la decision de RETIRAR esos dos endpoints publicados, y agregar auditoria a un camino que Elazar puede borrar es trabajo que se tira. Si 349 se resuelve por retirar, esta brecha se cierra sola; si se resuelve por conservar, la instrumentacion es el arreglo y recien ahi vale escribirla. Queda encadenado a 349. SIN EJERCITAR: el re-chequeo fila por fila en PROD -el codigo es identico, asi que aplica por construccion y no por medicion-, entidades, personas, choferes y validadoras_historial.
-
db03-mba-l-cc
-
db03 2026-10-01: MOVILBA-637 - PROD re-check + entidades/personas/choferes/validadoras_historial, as assigned. SELECT-only, both bases. PROD RE-CHECK (the UNEXERCISED item from my own 645/637 note): rutap.vehiculo_historial_normalizado in PROD has ZERO origen='app' rows of any kind (both normalizado_por='app-historial-record' and the form path are 0/0). The createHistorialRecord audit_log gap is real by code (same repo, same deploy) but UNEXERCISED in PROD data - no app-origin historial row has ever been written there yet, so there is no PROD row today that demonstrates the gap, only DEV's 21. Stating this as measured absence, not inferred from DEV: ran the identical query against PROD_DATABASE_URL, current_database()='movilba'. ENTIDADES: entidadesRepository.create() is UNAUDITED (plain db.insert, repositories/entidades.ts:295) - same shape as vehiculoRepository.create(). update()/delete() (lines 356/406) ARE wrapped in auditedOperation. DB-confirmed DEV: 46 entidades total, 0 CREATE rows in audit_log, 1 UPDATE row (the audited path exercised once, matches code). PERSONAS: personasRepository fully routes writes through auditedOperation (repositories/personas.ts:690,794,835) - no unaudited db.insert/update found. 55 audit_log rows under table_name='personas' in DEV. CHOFERES: no repository file - writes live directly in src/actions/choferes.ts. Mixed coverage, same pattern as vehiculo/entidad: 4 auditedOperation calls (alta-adjacent steps) alongside 4 separate plain db.transaction blocks (lines 175, 646, 713, 790) that are NOT audited - chofer alta (personas_datos_chofer + licencias_choferes + chofer_historial insert), linea assignment, linea de-assignment, entity-change de-assignment. DB-confirmed DEV: chofer_historial has 4 rows (all 'alta', the unaudited path) and chofer_linea_asignaciones has 35 rows - audit_log has ZERO rows for any of chofer_historial/personas_datos_chofer/licencias_choferes/chofer_linea_asignaciones (the only chofer/persona-adjacent audit_log rows are table_name='personas', 55, none of the chofer subtables). Same blind spot as vehiculo reassignment: chofer-linea assignment/de-assignment has only chofer_historial's self-reported creado_por/borrado_por as a trail, no audit_log corroboration. VALIDADORAS_HISTORIAL: repositories/validadoras.ts never imports auditedOperation - both its write methods (lines 244, 291) are plain db.transaction. DB-confirmed DEV: 59 rows in validadoras_historial, 0 audit_log rows matching table_name ILIKE '%validadora%'. Fully unaudited, out of vehiculo/vdc scope per 645 but now measured for 637. NET: the createHistorialRecord gap is not a vehiculo-specific anomaly - it is the SAME shape (an unaudited create() alongside an audited update()/delete(), or a plain-transaction side-channel table with no audit_log reach) repeated in entidades, choferes and validadoras. Wherever a table has its own historial/trail table written by a plain transaction, that trail's creado_por/borrado_por is the only witness, exactly 637's original finding for linea_entidad_asignaciones, now shown to generalize. UNEXERCISED: PROD row-level check for entidades/personas/choferes/validadoras (ran PROD only for the vehiculo historial re-check above, not these four - code-identical argument applies but not independently measured); whether linea_entidad_asignaciones itself (637's original named table, distinct from chofer_linea_asignaciones) was re-verified - not re-checked this pass, relying on db04's MOVILBA-621 finding already cited in the ticket description.
-
audit pass: methodology review only, static code cross-check of the generalized gap claim. DB EXECUTION NOT PERFORMED BY AUDIT
payload
{"scope":"methodology review only, static code cross-check of the generalized gap claim. DB EXECUTION NOT PERFORMED BY AUDIT","outcome":"pass","evidence":"every cited file:line confirmed exactly: entidades.ts create() plain insert:295 vs update/delete auditedOperation:356,406; choferes.ts 4 auditedOperation calls (275,379,433,475) + 4 unaudited db.transaction blocks (175,646,713,790), both counts match exactly; validadoras.ts both writers (244,291) are plain db.transaction, no auditedOperation import anywhere in the file. Generalization claim holds","reportRef":null} -
audit PASS 12:08 (static code cross-check). Generalized gap confirmed (entidades/choferes/validadoras all unaudited same shape as original finding). No fix written on purpose - chained to MOVILBA-349's retire-vs-keep decision on assignToEntidad/assignToLinea; instrumenting now risks wasted work if 349 retires the path.
-
coder03-mba-l-cc 2026-10-05 14:58 ART, relayed by db03: unblocked - adding audit_log rows destroys nothing, no Elazar decision needed; MOVILBA-349 no longer its blocker. Work: coder04 writes an audit_log row in the same transaction at every linea_entidad_asignaciones writer (src/actions/lineas.ts:95-105, src/repositories/lineas.ts:224, /api/vehiculos/[id]/entidad and /linea), then audit, then SHIP.
-
coder04-mba-l-ca / coder
-
Combined implementation with MOVILBA-349: endpoint expediente/date gates and atomic audit_log coverage at the linea/entity assignment writers.
-
Audit FAIL corrections shared with MOVILBA-349: restored session.user! assertions and supplied required expediente/date/requestId in rehearsal/concurrency callers. Atomic audit_log writes remain in each assignment transaction. Sent combined 349/637 diff for re-review; no gates run by coder.
-
Follow-up to audit FAIL at 2026-10-05T19:02Z: same type corrections in shared diff—session.user!.id! and route-source assertion tuple . Resubmitted combined 349/637 diff; no gates run by coder.
-
Same type corrections as MOVILBA-349 after audit FAIL at 2026-10-05T19:02Z: session.user!.id! and a readonly route-source assertion tuple. Resubmitted combined 349/637 diff; no gates run by coder.
-
Audit FAIL follow-up: fixed the optional session.user.id accesses in src/actions/lineas.ts callbacks; caller payload and route-test typing corrections are also in current shared diff. Fresh review requested; no gates run by coder.
-
Audit FAIL follow-up: fixed optional session.user.id accesses in src/actions/lineas.ts callbacks; caller payload and route-test typing corrections are in current shared diff. Fresh review requested; no gates run by coder.
-
Correction to prior note: audit rechecked 2026-10-05 15:54 ART and still found the MOVILBA-349/637 typecheck errors; claimed caller/test fixes are absent from current checkout. Awaiting release of coder03's deploy lock before editing tracked paths, then will reapply and submit for audit.
-
Current diff re-applies the corrections after deploy park: session.user.id non-null in line assignment callbacks, route test tuple const-asserted, and 344/560 callers provide expediente/date/requestId. Fresh audit requested; no gates run by coder.
-
2026-10-05 ART: Fresh candidate now includes the alta form required carroceriaCategoriaId, service-side required-field/catalog resolution, repository pre-write guard, and initial historial INSERT carroceriaCategoria from the service resolved canonical value. The prior FAIL predates the current source state; coder did not run gates.
-
Closed on coder03 2026-10-05 16:52 ART: audited 349/637 scope shipped in v5.6.166 and live on PROD, DEV and pod; fleet now v5.6.167. Remaining category storage migration is tracked separately as MOVILBA-709.
bug
2w ago by audit-mba-l-cc
1w ago
2026-10-05 20:38