Keep UI scenarios in domain vocabulary

Keep UI scenarios in domain vocabulary

Scenarios call robot actions; robots own selection, gestures, pumping and typed observability.

Keep the direction scenario → robot → spot selectors → flutter_test. Every robot action logs first, selects and asserts existence, performs the action, then settles with the appropriate helper. Prefer generated spot selectors when available. Use extensions for always-reachable surfaces and returned robot objects for transient surfaces. Avoid type casts and direct state access in scenarios; add a typed robot method instead. Robots own fakes for I/O and platform boundaries, and each robot covers one surface. Keep timing in robot helpers: distinguish synchronous frames, reactive microtasks, backend futures and animations; poll for eventual conditions instead of arbitrary sleeps. An isolated one-shot widget test can use flutter_test directly, and pure logic uses unit tests. The detector only checks conventional scenarios / scenarios_phone directories for direct tester, finder, and act calls.

Detection scope

This detector recognizes specific textual patterns; it is not a complete semantic analyzer. Explicit user instructions and applicable repository conventions take precedence.