This skill builds on patrol-write-test: follow it for the order of actions, Patrol MCP usage, Patrol test rules and test keys, and apply the changes below on top. Where the two differ, this skill wins.

Changes to the order of actions

• Start by reading the key files directly (modules aggregator, test wrapper, main keys.dart, and the specific app feature files for the scenario). These are known paths — don't search for them, open them directly
• Look for functions to reuse or adjust in the existing modules
• While writing the test, still write patrol actions directly in the test file — do not create new methods in modules yet
• After full test passes, reorganize new code into existing/new modules instead of plain reusable functions. This is mandatory — the test file must only call module methods, not use Patrol APIs directly

Patrol Test Architecture

Structure

• Use custom testApp wrapper for all tests
• Each test file should contain only ONE test
• Organize tests using Modules, System, and ApiClients pattern
• Each module represents a feature from user perspective (eg. Auth, Home screen, Downloads, Player)
• System is a class for native interactions, specifically for actions that we need to perform by using $.platform that are not part of our app, eg. enabling airplane mode to test offline mode. Do not put methods here unless they don't fit any module of the app
• ApiClients - a class aggregating api clients for api communication. There will be separate clients for different apis we need to communicate with - eg. email server for testing, our test backend, or some third-party services