App vehicle creation writes lifecycle Alta without trámite
App-created vehicle lifecycle rows can be written to rutap.vehiculo_historial_normalizado with both tramite and tramite_id NULL. DEV read-only evidence 2026-09-15: PR149II (id 6745, normalized id 193892) and JM111NA (id 6747, normalized id 193897) are app-origin Alta records with fecha_alta and expediente but no tramite fields. The UI/PDF therefore truthfully render Trámite: Sin dato; this is not an opciones catalog-label mismatch. Legacy history repair for PR149II masks the original write defect and JM111NA has no legacy row. Fix the app creation/history writer to persist ALTA (canonical option 317) for an Alta event, and add a regression test that inspects the normalized record. Preserve intentionally blank source-book trámite behavior covered by MOVILBA-282; this is an app-write invariant, not an import rule.
Sub-tickets — 1/1 done
Activity
-
Implemented and DEV-deployed at commit dcd76300 (v5.5.163) after audit-mba-l-cc PASS. createColectivo resolves the unique active vehiculo_historial/tramite ALTA catalog option inside its transaction and writes it as tramiteId in the initial normalized row. Focused contract test passed; deploy lint/typecheck passed; dev remote ref and /api/health verified. No DB repair or test-record write performed.
-
Deployment metadata follow-up: aaebaa79 updated package metadata to v5.5.164 after the path-limited logic commit dcd76300. DEV remote refs/heads/dev is aaebaa79. The logic diff remains exactly dcd76300 and audit-mba-l-cc PASS applies to it; no application-logic change in aaebaa79.
-
Reconciled 2026-09-15: implemented in dcd76300 and DEV metadata finalized in aaebaa79 (v5.5.164). The writer resolves the unique canonical ALTA tramite option inside createColectivo and persists tramiteId; the focused regression contract passed and audit-mba-l-cc recorded PASS. No data repair was part of this item.
-
Cierre verificado con control positivo independiente, y residuo medido (DEV, 2026-09-17, SELECT only). FIJADO: el escritor de alta por app (src/repositories/vehiculos.ts:808-818,924) resuelve ALTA en la misma transaccion desde v5.5.163 (dcd76300, 2026-09-15 02:36). dcd76300 esta en main, asi que PROD lleva el mismo camino de escritura. CONTROL POSITIVO (no tocado a mano): AI563JM creado por la app 2026-09-15 16:25 y AI563JL creado 2026-09-17 10:39, ambos normalizado_por=app-create-colectivo, ambos tramite_id=317. La ficha y el PDF resuelven tramite_nombre por el JOIN calificado a v_opciones, o sea muestran 'Alta'. Esta es la unica evidencia del arreglo que NO depende de una fila reparada. RESIDUO 1 - la reparacion a mano alcanzo a las DOS filas que Eugenia nombro y a ninguna otra. El item ya decia que PR149II estaba reparada; JM111NA tambien lo esta (tramite_id=317 Y tramite='Alta' texto) pese a haber sido creada 2026-09-14 15:51, o sea ANTES del arreglo. No hay fila en audit_log, ni migracion en docs/migrations, ni trigger en rutap.vehiculo_historial_normalizado que lo explique: fue un UPDATE directo sin testigo. Quedan 22 filas app-create pre-arreglo con tramite_id NULL, todas dominios sinteticos de prueba de DEV. Consecuencia de metodo: un re-test sobre PR149II o JM111NA mide la edicion manual, no el codigo. RESIDUO 2 - el arreglo no alcanza al reporte historico descargable: src/app/api/reportes/vehiculos-historico/route.ts:57 lee coalesce(h.raw_tramite, h.tramite), dos columnas de texto guardado que la app nunca escribe. AI563JM y AI563JL salen con la columna Tramite VACIA. Abierto como MOVILBA-463. PENDIENTE DE DECISION (Elazar, no lo corro): backfill de las 22 filas de prueba de DEV o dejarlas. El trigger vh_norm_reject_book_column_update no frena porque rutap_snapshot_id es NULL en filas de app.