Pantalla y PDF contestan distinto el Tramite de un mismo evento sin tramite_id
Hallazgo colateral al item 20 de Eugenia, verificado con audit-mba-l-cc contra 0dc7e5b9. Las dos superficies renderizan Tramite y las dos lo resuelven desde tramite_id, pero por caminos distintos: - PDF: src/app/vehiculos/[dominio]/page.tsx:1017, dentro de handleExportPDF (arranca en :722). Usa h.tramiteNombre || h.tramite || (esAlta ? 'Alta' : 'Sin dato'), con esAlta = h.anteriorId === null (742df464, v5.5.156, MOVILBA-99). - Pantalla: src/components/HistoryPeriodContent.tsx via HISTORY_FIELDS. El campo 'procedure' esta en RUTAP_HISTORY_FIELDS (rutap-modification-subtype.ts:11), definido en rutap-history-fields.ts:78-84 como column tramite_id / catalog option / optionGroup vehiculo_historial / optionFields ['tramite'] / face body, con etiqueta 'Trámite' en rutap-history-diff.ts:123. Un grep de la literal no lo encuentra porque la etiqueta viene por dato. La diferencia: SOLO el PDF tiene el fallback por posicion en la cadena. En pantalla, display() devuelve 'Sin dato' cuando tramite_id es NULL. Entonces para un primer evento de cadena sin tramite_id el PDF dice 'Alta' y la pantalla dice 'Sin dato' - la misma fila, dos respuestas. Poblacion en DEV 2026-09-17, borrado_en IS NULL: 18 filas app y 5 filas import con tramite_id NULL. Las 18 de app son dominios sinteticos de prueba anteriores a v5.5.163; las 5 de import no lo son y hay que mirarlas aparte. El fallback del PDF es estructural, no esta acotado por origen pese a que el comentario lo enmarca como 'legacy import'. Hoy no se dispara para altas de app porque vehiculos.ts:815-817 tira si el catalogo no resuelve exactamente un ALTA, o sea tramite_id nunca es NULL al escribir. Es latente, no activo. Decision a tomar: una sola regla para las dos superficies. O las dos infieren por posicion de cadena, o ninguna y un tramite_id ausente se muestra ausente en ambas.
Activity
-
coder04-mba-l-ca
-
Read-only decision packet: PDF page.tsx:1019-1025 treats h.anteriorId===null as esAlta and renders Trámite: Alta when both tramiteNombre and tramite are absent; HistoryPeriodContent uses RUTAP_HISTORY_FIELDS.procedure -> tramite_id catalog and renders Sin dato for that same row. OpenAPI components.ts:182 calls orden1/anteriorId null the server-known alta, supporting positional inference; but Elazar's literal MOVILBA-99 ruling says workbook Alta/Baja labels are traceability interval endpoints, not necessarily true vehicle-service events, and says not to reinterpret the book labels. Both policies are defensible: infer Alta for first chain event on BOTH surfaces, or show absent trámite on BOTH when no source value exists. The PDF's comment silently chooses the first while the screen chooses the second. No code or data changed; decision needed before aligning one shared display rule. Historical DEV counts in the item (18 app + 5 import NULL IDs, 2026-09-17) are stale and were not remeasured here.
-
Elazar must choose one Trámite display rule for first history event when tramite_id/tramite text are absent: infer Alta from chain position on both screen and PDF, or show Sin dato on both. MOVILBA-99's interval ruling conflicts with the PDF's implied business-event claim; no code edit until decision.