Run the real flow. Keep the evidence.

Three modes

• Your existing tests — Android local unit tests, instrumentation and UI tests, Flutter unit, widget and integration tests, discovered and published in the editor’s native Testing UI, grouped module → class → method with output, durations and failure locations.
• Guided feature QA — pick a feature from the Brain or describe a flow ("test login with invalid credentials then a valid account"). Appvecta proposes a deterministic plan using selectors that actually exist in your source. You review, edit and approve it.
• Recorded flows — perform a flow once and Appvecta records it as a reusable, editable flow. Planned for release 0.2.

Free-form exploratory QA is deliberately not a first-release commitment. Deterministic execution has to be reliable first.

Selector strategy

Selectors are chosen in a fixed preference order, and anything fragile is flagged in the report.

1  explicit test ID / key / resource ID
2  accessibility identifier or content description
3  semantic role plus a stable label
4  visible text
5  relative hierarchy
6  coordinates                                  (last resort)

An opt-in testability contract

Documented, never required: stable resource IDs on Android Views; meaningful test tags and content descriptions in Compose; stable Keys and semantics labels in Flutter; predictable debug-only test data; a safe way to reset local state; and no production credentials in test plans.

What every step records

flow and step ID          human-readable intent
action performed          selector and fallback used
start and end time        pre/post screenshot
UI hierarchy excerpt      assertion and result
app and process state     the relevant log window
network state metadata    failure reason and confidence
retry count

Failure classification

Not every failure is an app bug, and the report says which kind it is.

• Assertion failure
• App crash or ANR
• Build, install or launch failure
• Missing element
• Timeout
• Permission or system dialog
• Environment or test-data problem
• Automation-driver problem
• Suspected visual issue
• Inconclusive

Reports

• Summary — project, commit, dirty-worktree status, framework, variant, application ID, device and Android version, start time, duration, and passed/failed/blocked/skipped counts.
• Timeline — every action and assertion in order.
• Failures — expected versus actual, screenshot and optional recording, relevant logs and stack trace, the source components the Brain suggests are involved, plus classification and confidence.
• Actions — Replay, Open related code, Ask the Agent to investigate, Export Markdown or JSON.

Reports are JSON at the source, rendered as Markdown and as a self-contained HTML file. A step that only passes on retry is marked flaky, not passed.