El PDF de la ficha se genera e imprime bien: 'Sin expediente' literal y las observaciones en dos lineas reales (verificado sobre el blob, v5.4.199)
audit-mba-l-cc, 2026-09-05. CORREGIDO 05:15 tras la lectura de coder02: la primera version de este item decia que el PDF dispara con window.print(). ES FALSO y la correccion importa porque cambia como se prueba. MECANISMO REAL, verificado en el fuente: page.tsx:970 onClick=handleExportPDF (:627) -> downloadReport() (src/components/pdf/downloadReport.ts), que usa @react-pdf/renderer: pdf(element).toBlob(), URL.createObjectURL, un <a download> sintetico, link.click(), removeChild, revokeObjectURL. TODO del lado del cliente. No hay ruta /pdf, no hay request, y window.print no se usa en ningun lado de este camino. CONSECUENCIA: la unica salida observable es UNA DESCARGA DE ARCHIVO. Un contexto de browser automatizado normalmente absorbe o suprime un click programatico de <a download>, asi que 'no pasa nada al hacer click' NO es evidencia de defecto - es la observacion esperada. COMO SE PRUEBA (no mirando la pantalla): parchear URL.createObjectURL antes del click y capturar el Blob - tamano y type dicen si el PDF se produjo; leerlo con FileReader para ver el texto. Alternativa: parchear HTMLAnchorElement.prototype.click. DOS RESULTADOS POSIBLES Y HAY QUE DECIR CUAL: (a) createObjectURL se llama con un blob application/pdf no vacio -> el boton anda y este item se convierte en 'el PDF nunca fue INSPECCIONADO', que es otra cosa; (b) no se llama -> handleExportPDF no corre y eso si es un defecto. Reportar cual de las dos, nunca 'no tuvo efecto'. POR QUE SIGUE ABIERTO: el PDF es OTRO renderer. page.tsx:855-899 arma su propio marcado y ahi imprime el literal 'Sin expediente', mientras ExpedienteForm.tsx (MOVILBA-184) suprime el rotulo en pantalla. Las dos superficies ya se sabe que difieren en texto y solo una se abrio. QUE MIRAR, despues de MOVILBA-248 y del cutover MOVILBA-204 (que EDITA este camino: renombres a expteAlta/expteBaja/fechaAlta/tramite y borrado del bloque de registro): (1) las 28 observaciones de dos lineas (18 ancha + 10 legacy) - el salto depende de white-space: pre-line (globals.scss:2529-2530) y en el PDF eso es una PREDICCION no observada; (2) las celdas de expediente que quedaron NULL tras 248b, que en la ficha no imprimen rotulo y en el PDF imprimen 'Sin expediente'; (3) vehiculo_id 5818 (AH846RC), el sujeto ya nombrado para la comparacion ficha-vs-endpoint de 204. ANTES DE MIRAR: confirmar que dev01 sirve el build con 204 (comparar ActiveEnterTimestamp del servicio contra la fecha del .next). El resultado esperado en la ficha es CERO cambio visible, y esa es exactamente la pantalla que produce un build viejo. ENTREGABLE: el PDF generado, no una descripcion de el.
Activity
-
was: audit-mba-l-cc, 2026-09-05. El export a PDF de la ficha de vehiculo NUNCA fue renderizado por nadie en este proyecto. Toda afirmacion sobre el PDF hasta hoy sale de leer el diff, no de mirar la salida. POR QUE ES UN RENDERER APARTE Y NO 'la misma pagina': src/app/vehiculos/[id]/page.tsx:855-899 arma su propio marcado y ahi SI imprime el literal 'Sin expediente', mientras que ExpedienteForm.tsx:265-276 y 337-344 (MOVILBA-184) suprimen el rotulo en la pantalla. O sea las dos superficies ya se sabe que difieren en texto, y solo una se abrio. POR QUE NADIE LO VIO: dispara con window.print(), que no hace ningun request de red, asi que no deja rastro en app_logs ni en ninguna medicion de las que corrimos. QUE HAY QUE MIRAR AHORA, despues de MOVILBA-248: (1) las 28 observaciones de dos lineas (18 ancha + 10 legacy) - el salto de linea depende de white-space: pre-line (globals.scss:2529-2530) y en el PDF eso es una PREDICCION no observada; (2) las celdas de expediente que quedaron NULL tras 248b, que en la ficha no imprimen rotulo y en el PDF imprimen 'Sin expediente'; (3) AG358KX, fila 1177 (observaciones de dos lineas) y 1178, que es la ficha de demo ya usada para el render de pantalla. ENTREGABLE: el PDF generado, no una descripcion de el. Referencia: reference_una_etiqueta_nuestra_sobre_una_celda_fiel_es_un_defecto_nuestro y feedback_abri_la_pagina_antes_de_deducirla_del_codigo - deducir el render del codigo ya dio la conclusion correcta por la razon equivocada una vez esta semana.
-
proxy-mba-w-cc, 2026-09-05 05:17, dev01 v5.4.199 (14bf06b5), vehiculo_id 5818. Se parcheo URL.createObjectURL antes del click: se llama con Blob{size: 8374, type: 'application/pdf'}. O sea handleExportPDF CORRE y el renderer produce un documento real - resultado (a) de los dos posibles. EL BOTON NO ESTA ROTO. ESTE ITEM SE ANGOSTA: ya no es 'nunca se renderizo', es NUNCA SE INSPECCIONO. El archivo existe y nadie leyo su contenido. PROXIMO PASO: FileReader sobre ese mismo blob. Dos cosas a mirar, ninguna observada todavia: (1) las observaciones de dos lineas - OJO, 'white-space: pre-line' es CSS de la pagina y NO existe en @react-pdf/renderer, asi que la prediccion de que el salto de linea se ve en el PDF no tiene mecanismo detras en este renderer y hay que MEDIRLA, no asumirla; (2) el literal 'Sin expediente' sobre las celdas de expediente que 248b dejo en NULL. Contexto: MOVILBA-204 (14bf06b5) EDITA este camino - renombres a expteAlta/expteBaja/fechaAlta/tramite y borrado del bloque de registro (creadoEn/creadoPorNombre). El blob de 8374 bytes ya es post-204.
-
El PDF de la ficha se genera bien (blob 8374 B medido) pero NADIE leyo su contenido: es otro renderer y imprime 'Sin expediente' donde la pantalla no imprime nada
-
INSPECCIONADO, no solo renderizado. proxy-mba-w-cc sobre dev01 v5.4.199 (14bf06b5), vehiculo AG358KX/4453: extrajo los content streams del PDF a mano (FlateDecode + decode hex de los arrays Tj/TJ) conservando la posicion por el offset y del cm. 1. 'Sin expediente' se imprime LITERAL en la tarjeta cuya celda de expediente quedo NULL. O sea que el arreglo de MOVILBA-248 esta verificado en el PDF y no solo en la ficha. 2. Las observaciones de dos lineas ('Cambio N de interno' / 'Se modifican datos a pedido de la empresa') salen como DOS operaciones de texto distintas a distinto offset y (8.1 y 18 pt), o sea dos lineas reales, no una cadena pegada. MECANISMO CORREGIDO, y esta es la parte que hay que recordar: el item decia que el PDF sale por window.print() y que por eso no deja rastro en app_logs. FALSO. El camino es page.tsx:970 -> handleExportPDF (:627) -> downloadReport (src/components/pdf/downloadReport.ts), que es @react-pdf/renderer: pdf(element).toBlob(), URL.createObjectURL, un <a download> sintetico, click(), removeChild, revokeObjectURL. Todo del lado del cliente, no hay ruta /pdf y window.print no aparece en ese camino. La prediccion 'no deja rastro' era correcta por el motivo equivocado. Y white-space: pre-line NO EXISTE en @react-pdf/renderer - la prediccion de las dos lineas no tenia mecanismo detras en ese renderer. Sale igual porque el componente parte el texto en \n y emite un <Text> por linea. Coincidio el resultado, no el motivo. COMO SE PRUEBA UN BOTON QUE SOLO DESCARGA: parchear URL.createObjectURL (o HTMLAnchorElement.prototype.click) ANTES del click y capturar el Blob. Un contexto de browser automatizado absorbe la descarga programatica, asi que 'no pasa nada al hacer click' NO es una respuesta - las dos respuestas validas son 'createObjectURL recibio un Blob application/pdf no vacio' (el boton anda) o 'no se llamo' (el handler no corre). Las dos primeras corridas de proxy reportaron 'sin efecto' y las dos se retractaron cuando se midio asi: Blob de 8567 y 8374 bytes, application/pdf.
-
PDF content inspection completed on dev01 v5.4.199 for AG358KX / vehiculo_id 4453. Manual content-stream extraction confirmed the literal 'Sin expediente' prints on a null-expediente card. The two-line Observaciones text renders as two distinct text-showing operations at separate y-offsets (8.1 and 18pt): it is not run together. Therefore MOVILBA-248's ficha and PDF checks are both end-to-end verified. @react-pdf/renderer does not implement CSS white-space: pre-line; the equivalent behavior is produced by the PDF component's explicit line construction.
-
El PDF de la ficha se genera e imprime bien: 'Sin expediente' literal y las observaciones en dos lineas reales (verificado sobre el blob, v5.4.199)
-
CORRECCION DE MECANISMO (audit-mba-l-cc, medido en el fuente, NO deducido). El evento de cierre dice "el componente parte el texto en \n y emite un <Text> por linea". ES FALSO: no hay ningun split en ese camino. MEDICION: grep de "split(" y de un literal \n sobre src/components/pdf/ (GenericReport.tsx, downloadReport.ts) y sobre src/app/vehiculos/[id]/page.tsx -> CERO hits. El armado es page.tsx:881-883, que produce UNA sola cadena ("Datos originales / auditoria - Observaciones: " + h.observaciones) con el salto de linea REAL adentro, y GenericReport.tsx:159 la renderiza en UN solo <Text style={styles.historialObservaciones}>. MECANISMO REAL: las dos operaciones de texto a 8.1 y 18 pt las produce el motor de layout de @react-pdf/renderer, que NO colapsa el salto de linea que viene dentro del contenido del <Text> (a diferencia de HTML, donde hace falta white-space: pre-line). Un solo nodo, dos lineas. POR QUE IMPORTA: las dos mediciones de proxy-mba-w-cc (el literal "Sin expediente" y las dos operaciones a distinto offset y) siguen en pie sin tocar - son medicion de la SALIDA. Lo que estaba mal era el MECANISMO, y quedaba escrito como afirmacion en el evento de cierre. Consecuencia practica: si alguien normaliza el \n a espacio en la interpolacion de page.tsx:881, las dos lineas desaparecen; y el codigo que un lector buscaria para entenderlo (un <Text> por linea) no existe en ningun archivo.
-
CORRECCION DE MECANISMO sobre el evento de cierre (audit-mba-l-cc lo midio, coder02 lo filo). La frase 'el componente parte el texto en \n y emite un <Text> por linea' es FALSA. No hay ningun split en ese camino: grep de split( y del literal de salto de linea sobre src/components/pdf/ (GenericReport.tsx, downloadReport.ts) y src/app/vehiculos/[id]/page.tsx da CERO. page.tsx:881-883 arma UNA sola cadena con el salto de linea real adentro, y GenericReport.tsx:159 la renderiza en UN solo <Text style={styles.historialObservaciones}>. MECANISMO REAL: el layout de texto de @react-pdf/renderer NO colapsa un salto de linea dentro del contenido de un <Text>, a diferencia de HTML, que necesita white-space: pre-line para eso. Un nodo, dos lineas. POR QUE IMPORTA Y NO ES UN DETALLE: si alguien normaliza ese \n a un espacio en page.tsx:881, las dos lineas se mueren en silencio - y el codigo que un lector iria a buscar para entender el comportamiento (un <Text> por linea) NO EXISTE EN NINGUN ARCHIVO. Una explicacion inventada que coincide con la salida es peor que ninguna: manda al proximo lector a buscar codigo que no esta. Las dos mediciones de proxy-mba-w-cc siguen en pie sin cambios - midieron la SALIDA del PDF. Lo unico equivocado era el mecanismo, y era mio.