Maestro

Migra los flujos de Maestro de este repositorio a Autonomy con las herramientas MCP de Autonomy.

Preparación
1. Llama a autonomy_project_list y pregúntame qué proyecto usar. Llama a autonomy_environment_list con su projectId y pregúntame en qué entorno ejecutar. Comprueba que tiene un objetivo android para el appId de los flujos; si no lo tiene, avísame antes de crear nada.
2. Llama a autonomy_test_case_list con el projectId. Omite los flujos que ya cubra un caso de prueba existente.

Para cada flujo
3. Crea UN caso de prueba con autonomy_test_case_create: projectId, name = el nombre del flujo o de su archivo, platforms = ["android"]. Las pruebas en iOS todavía no están disponibles: omite los flujos que solo son de iOS y enuméramelos. No migres por separado los subflujos que solo se ejecutan desde otros flujos.
4. Escribe cada paso como un resultado esperado: lo que es cierto cuando el paso termina, en palabras sencillas ("Existe una cuenta nueva para un correo nuevo"). Di lo que demuestra el flujo, no cómo: sin tapOn, inputText, scroll, selectores ni esperas. Un paso puede abarcar varios comandos que sirven a un mismo resultado esperado. Usa 12 pasos o menos; divide un flujo más largo en varios casos de prueba.
5. Cada paso es {id, text, attachments[]}. Cada adjunto tiene id, kind y exact. Tipos: account {role}, inbox (sin dirección = una bandeja de entrada nueva por ejecución), phone, file, screenshot, data {label, value} o {label, intent} para datos generados.
6. Nunca escribas una contraseña, un token o una clave en un paso. Por cada cuenta con la que los flujos inician sesión (a menudo un subflujo de login), pídeme que la guarde en el panel (Sign-ins del proyecto, New sign-in) y que te diga su nombre de cuenta; después empieza la prueba con un paso como "El propietario de la tienda ha iniciado sesión" con esa cuenta adjunta. Para otros secretos de env, propón nombres y referéncialos como {{env.NAME}}; añádelos como valores secretos con autonomy_environment_upsert solo después de que yo esté de acuerdo.
7. Los valores sobre los que trata el flujo (el texto que comprueba un assertVisible, un cupón que debe aplicarse, una entrada que debe rechazarse): un adjunto data con exact: true. Los demás valores de env: {{env.NAME}}.
8. Datos de registro (correos, nombres, contraseñas, números de teléfono, valores aleatorios de evalScript): una bandeja de entrada nueva, un adjunto phone y datos generados, nunca un valor fijo.
9. Integra los subflujos de runFlow en los resultados esperados de los flujos que los llaman. Descarta launchApp con clearState (cada ejecución empieza con una instalación limpia), extendedWaitUntil, waitForAnimationToEnd y los bloques retry y repeat que solo esperan.

Al terminar
10. Si los flujos están agrupados (etiquetas, carpetas, includes de la configuración), ofréceme crear un plan de pruebas por grupo con autonomy_test_plan_create.
11. Ejecuta un caso de prueba migrado con autonomy_run_trigger en el entorno que elegí. Síguelo con autonomy_run_get (pasa el último cursor y waitMs) hasta que termine. Para cada paso que no se haya superado, lee autonomy_run_step_actions y cuéntame qué pasó.
12. Termina con una tabla: flujo de origen, ID del caso de prueba, número de pasos y todo lo que no hayas podido trasladar.