Walker app autonomo

Il walker autonomo esplora una porzione delimitata dell’UI di un’applicazione web in una tester VM gestita. Registra stati, transizioni, screenshot, diagnostica console e rete e finding deduplicati. È utile per discovery; non prova che ogni route o comportamento sia stato testato.

Disponibilità: data plane walker, report, profili autenticati, modalità mechanical/AI/hybrid/task delimitate, controlli sicurezza e scenario mining sono implementati. Una walk può comunque perdere comportamento per limiti, UI dinamica, etichette inaccessibili, credenziali non disponibili o errore modello/parser. Rivedi copertura prima di affidarti al risultato.

Avvia in sicurezza

Usa ambiente non produzione e account test dedicato. Ottieni tester VM, poi inizia con policy mechanical default:


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 ritorna subito. Conserva il suo walk_id, poi fai polling get_app_walk(walk_id=...); chiama stop_app_walk se la run deve finire prima.

Modalità esplorazione

Modalità	Comportamento
`mechanical`	Traversal ordine DOM delimitato; nessun ranking modello
`ai`	Un modello classifica azioni candidate, poi fallback quando cap chiamate raggiunto
`hybrid`	Ranking modello per primi stati configurati, poi traversal mechanical
`cot`	Ricerca task-directed con cap decisione e schema output opzionale

Modalità AI e hybrid fallback su mechanical quando nessun backend modello supportato è disponibile. Modalità task-directed fallisce invece. Azioni classificate modello restano soggette alla stessa policy origin e azioni distruttive.

Controlli sicurezza

Azioni distruttive sono saltate di default.
destructive_allowed=true permette solo classe guarded; etichette high-stakes restano bloccate salvo allowlist esplicita.
Modalità task-directed non accetta mai destructive_allowed=true.
Compilazione form evita campi sensibili e blocca submit transazionali.
Navigazione è limitata all’origin; modalità task può aggiungere allowlist origin delimitata esplicita.
Configurazione autenticazione contiene nomi variabile secret, non credenziali letterali. Runner scenario risolve valori dal keystore owner.

Un allowlist è decisione autorizzazione operatore. Usa etichette letterali strette, rivedi ambiente target e preferisci dati test scartabili.

Leggere il risultato

Una walk completata riporta ciò che ha osservato davvero:

stati UI visitati e transizioni;
screenshot e fingerprint elementi interattivi;
errori console e rete significativi;
finding con severità, categoria, evidenza e chiave deduplicazione; e
limiti configurati stato, profondità, azione, tempo, modello e sicurezza.

completed significa che la frontiera è finita o un limite configurato è stato raggiunto senza errore interno. Non significa che l’applicazione sia passata. Rivedi finding blocker e major, azioni saltate, stato autenticazione e totali copertura.

Walk autenticate

Preferisci profilo browser cifrato quando disponibile. Flusso username/password legacy accetta solo nomi variabile keystore. Se sign-in fallisce o contenuto post-login atteso è assente, la run registra fallimento autenticazione; non interpretare walk della pagina login come copertura prodotto.

Trasforma discovery in test regressione

Dopo revisione finding, salva scenario app deterministico per flusso interessato. Scenario mined può essere low-confidence salvo checkpoint verifica superato, quindi ispeziona passi prima di adottarlo come gate release.