Reconnaissance-Then-Action

These examples and illustrative results are independently authored teaching materials, not measured model results.

Use case

A page may already be authenticated before entering the requested area. Teaching states show account summary or login control, neither initially present during loading. Old coordinates/screenshots do not establish current targets.

Mechanism

Verify page/account and relevant readiness, then inspect current DOM/screenshot. Continue if authenticated; otherwise use observed controls under the authorized login flow. Reobserve after state changes, separating issued actions from attained results.

Bad example

Click remembered login coordinates and type credentials regardless of readiness/current authentication, then claim success.

Good example

Verify teaching page identity and observable account/login readiness. Correct summary means continue to the requested area; otherwise locate the current control and follow permitted login, then inspect actual state. Missing/unclear UI stays waiting/unverified, not guessed coordinates or logged credentials.

Why the change matters

Current evidence determines action despite dynamic layout/authentication. Post-action inspection distinguishes a sent click from goal completion.

Observable expectation

Authenticated fixture avoids repeat login, unauthenticated uses an actual control and loading waits/reports. Inspect evidence and subsequent account/target, not a nonthrowing click.

No real credentials/account are used.

Limits

Source networkidle is an example; continuous-network apps may need relevant UI readiness. Arbitrary delay alone is insufficient. Observation grants no mutation/destruction/other-account permission; recheck state/identity changes.