Automatización UI para los sitios y aplicaciones que construyes tú mismo

Lo que el agente puede hacer por tus pruebas

• Archivosread_file, write_file, append_file, edit_file, delete_file, make_dir, move_file, copy_file, list_dir, grep y glob funcionan dentro de la carpeta de trabajo del chat, y un contador muestra archivos creados, editados y leídos.
• Shellejecuta tu comando de prueba, un linter o una compilación en Windows local, WSL o mediante SSH en un servidor que poseas, y juzga el éxito por el código de salida real. Los comandos peligrosos están bloqueados.
• Webweb_search encuentra páginas y http_get lee una página de documentación oficial, para que una pregunta sobre un selector o una espera pueda verificarse contra el manual propio del framework.
• Capturas de pantalla e imágenesocr lee el texto en una captura de pantalla guardada, por ejemplo el banner de error de una ejecución fallida, y gen_image guarda archivos de imagen reales cuando los necesitas.
• Orquestacióntask divide comprobaciones independientes entre sub-agentes en paralelo, run_on_model envía un paso difícil a un modelo más grande, y skill almacena un libro de jugadas reutilizable como tu rutina de reparación habitual.
• Modos de aprobaciónAuto-run actúa de inmediato, Ask first pausa antes de acciones que cambian algo y muestra el diff, y Plan only escribe un plan y no ejecuta nada. Los planes sobreviven a los reinicios.
• Cronejecuta un prompt en un horario, por ejemplo para ejecutar tu comando de prueba en los momentos que configures e informar el código de salida en el chat, para que un flujo que falló durante la noche sea lo primero que leas.
• Modelosconecta un proveedor de IA en la nube a través de un punto de conexión API estándar, un modelo que se ejecuta localmente en tu PC, o el modelo integrado que está listo para usar sin tu propio punto de conexión. El botón de prueba verifica un punto de conexión antes de comenzar.

Cuatro tareas que el agente realiza en un proyecto de pruebas

Escribir el primer flujo

Las mejores prácticas para pruebas e2e comienzan con una lista breve de flujos que nunca deben fallar, así que pide a FlowLatch que escriba solo esos. list_dir y glob muestran cómo están nombradas tus pruebas existentes, read_file abre una como patrón, y write_file crea el nuevo archivo para el flujo de inicio de sesión con una cuenta de prueba y datos falsos. Shell luego ejecuta tu comando de prueba, y la tarjeta muestra el código de salida real. Un primer borrador rara vez es el definitivo, así que pide un cambio a la vez, como un nombre más claro o una comprobación añadida en el texto de la página. Antes de aceptar, lee el nuevo archivo en el diff, ejecútalo tú mismo una vez y guárdalo solo si coincide con el flujo que tenías en mente.

Ejecutar la suite y leer la falla

Shell ejecuta tu comando de prueba y la tarjeta conserva la salida completa, para que un resultado rojo nunca sea una suposición. grep busca en esa salida el paso que falla, y si tu framework guardó una captura de pantalla, ocr lee el mensaje en ella. Para reducir la inestabilidad en pruebas end-to-end, pide a FlowLatch que ejecute la prueba fallida de nuevo con el mismo comando y compara los códigos de salida. Un pase seguido de un fallo apunta a una espera fija, datos de prueba compartidos o el orden de las pruebas. Pide una explicación breve en el chat, luego revísala contra la salida antes de cambiar cualquier archivo.

Reparar un selector después de un cambio de diseño

Si las pruebas e2e valen la pena para el trabajo de frontend depende del flujo, así que cubre primero el inicio de sesión y el checkout. Cuando el diseño de la página cambia, grep encuentra todos los selectores que estaban vinculados a él, read_file muestra los pasos circundantes y edit_file propone etiquetas estables o test ids en su lugar. En Ask first, FlowLatch pausa antes de cada edición y muestra un diff, un archivo a la vez. Acepta las líneas que parezcan correctas, rechaza el resto, luego deja que Shell ejecute la suite de nuevo para ver el nuevo código de salida. Mantén el diff pequeño para que un revisor pueda leerlo en un minuto.

Mover una suite a otro framework

Al migrar pruebas e2e entre frameworks, mantén ambas suites en el repositorio hasta que la nueva pase. FlowLatch lista las pruebas antiguas con glob, lee cada una con read_file y escribe el nuevo archivo coincidente con write_file, un flujo a la vez. web_search y http_get pueden leer la documentación propia del nuevo framework para la sintaxis que no recuerdas. Ejecuta ambas suites con Shell, compara los códigos de salida, y aprueba cada archivo en Ask first antes de que se elimine el antiguo. Los planes sobreviven a los reinicios, así que una migración larga puede continuar al día siguiente.