Walker autónomo de app

El walker autónomo explora una porción acotada de la UI de una aplicación web en una VM tester gestionada. Registra estados, transiciones, capturas, diagnósticos de consola y red, y hallazgos deduplicados. Es útil para descubrimiento; no prueba que toda ruta o comportamiento se probó.

Disponibilidad: el plano de datos del walker, informes, perfiles autenticados, modos mechanical/AI/hybrid/task acotados, controles de seguridad y minería de escenarios están implementados. Un walk aún puede perder comportamiento por sus límites, UI dinámica, etiquetas inaccesibles, credenciales no disponibles o error de modelo/parser. Revisa su cobertura antes de confiar en el resultado.

Arrancar con seguridad

Usa un entorno no productivo y una cuenta de prueba dedicada. Obtén una VM tester, luego empieza con la política mechanical por defecto:


ensure_tester_vm(app="my-app", app_url="https://staging.example.com")

walk_app(
  app_name="my-app",
  app_url="https://staging.example.com",
  vm_name="<tester-vm>",
  max_states=40,
  max_depth=5,
  max_wall_seconds=600,
  destructive_allowed=false
)

walk_app devuelve de inmediato. Conserva su walk_id, luego haz polling con get_app_walk(walk_id=...); llama stop_app_walk si la ejecución debe terminar antes.

Modos de exploración

Mode	Behavior
`mechanical`	Bounded DOM-order traversal; no model ranking
`ai`	A model ranks candidate actions, then falls back when its call cap is reached
`hybrid`	Model ranking for the first configured states, then mechanical traversal
`cot`	Task-directed search with a decision cap and optional output schema

Los modos AI e hybrid recurren a mechanical cuando no hay backend de modelo admitido. El modo dirigido por tarea falla en su lugar. Las acciones rankeadas por modelo siguen sujetas a la misma política de origen y acciones destructivas.

Controles de seguridad

Las acciones destructivas se omiten por defecto.
destructive_allowed=true permite solo la clase protegida; las etiquetas de alto riesgo siguen bloqueadas salvo allowlist explícita.
El modo dirigido por tarea nunca acepta destructive_allowed=true.
El relleno de formularios evita campos sensibles y bloquea submits transaccionales.
La navegación está limitada por origen; el modo tarea puede añadir un allowlist de origen acotado explícito.
La configuración de autenticación contiene nombres de variables secretas, no credenciales literales. El runner de escenarios resuelve valores desde el keystore del propietario.

Un allowlist es una decisión de autorización del operador. Usa etiquetas literales estrechas, revisa el entorno objetivo y prefiere datos de prueba desechables.

Leer el resultado

Un walk completado reporta lo que realmente observó:

estados UI visitados y transiciones;
capturas e huellas de elementos interactivos;
errores de consola y red significativos;
hallazgos con severidad, categoría, evidencia y clave de deduplicación; y
los límites configurados de estado, profundidad, acción, tiempo, modelo y seguridad.

completed significa que la frontera terminó o se alcanzó un límite configurado sin error interno. No significa que la aplicación pasó. Revisa hallazgos blocker y major, acciones omitidas, estado de autenticación y totales de cobertura.

Walks autenticados

Prefiere un perfil de navegador cifrado cuando esté disponible. El flujo legacy usuario/contraseña acepta solo nombres de variables del keystore. Si el inicio de sesión falla o falta el contenido post-login esperado, la ejecución registra fallo de autenticación; no interpretes un walk de la página de login como cobertura del producto.

Convertir descubrimiento en pruebas de regresión

Tras revisar un hallazgo, guarda un escenario de app determinista para el flujo afectado. Un escenario minado puede ser de baja confianza salvo que pasara el checkpoint de verificación; inspecciona sus pasos antes de adoptarlo como puerta de release.