/argent-qa-flows

name: argent-qa-flows
description: Create repeatable QA regression E2E tests as Argent flows from test cases, tickets, or acceptance criteria. Use when the user asks to generate or preserve an automated regression scenario, with deterministic setup, stable targets, executable structural or visual evidence, and two consecutive full passes. For one-off UI checks or replayable paths without acceptance criteria, use argent-test-ui-flow or argent-create-flow. Supports iOS, Android, Chromium, and Vega (Fire TV), where recorded tv-remote steps replace touch directives. Apple TV and Android TV are unsupported; use argent-tv-interact there and report the limitation.

Create a QA regression flow

Load `argent-create-flow` as the authoring engine. Follow its required references for recorder syntax, selectors, polish, platform exceptions, and repair. This skill adds the QA contract and completion gate.

**Vega** supports every item below: `launch: { vega: ... }`, `await:`/`assert:` selectors, `snapshot:`, and `idle` all run there. Only the touch directives are missing, because Vega is remote-driven. Navigate with recorded `tool: tv-remote` steps and type with `tool: keyboard`, which leaves item 5 with nothing to govern. A D-pad path is relative to where focus already is, so gate every move with item 4's identity check rather than assuming the cursor landed. Read `argent-tv-interact` for focus reading and remote navigation.

**Apple TV and Android TV are out of scope.** The runner does not reject touch directives there, so they fail at the gesture layer instead of with authoring guidance. Use `argent-tv-interact` and report the limitation.

**Physical iPhones** run QA flows, with three hardware limits: replay never auto-binds a phone, so pass its udid as `device` (CLI `--device`) and keep it `connected`; `pinch`/`rotate` steps fail there like the live tools, so drive the app's own zoom UI instead; the flow tree is the `describe` tree (same ids and roles), so a selector authored on a simulator can miss there. Read `argent-ios-device-interact` for the app-scoped contract before recording.

Definition of done

A QA flow is complete only when:

1. The first step that is not `echo:` or `script:` is `launch:`. In-flow setup proves a deterministic data baseline. Repeated runs do not accumulate artifacts or require manual cleanup. 2. The first walkthrough recorded every action and live structural check. Only the three documented polish insertions are unrecorded. 3. Every requirement maps to a hard `await:`, `assert:`, or reviewed `snapshot:`. Echoes and screenshots are not verdicts. A negative check needs the same stable selector established as visible earlier. 4. Every screen change has destination identity followed by `idle` readiness. 5. Targets satisfy the stable-selector and coordinate-fallback rules. QA keeps coordinates only for genuinely unlabeled targets. Vacuous on Vega, which has no coordinate targets. 6. The unchanged YAML passes twice with the same runner. Pass 1 starts with fresh mobile Argent services, and pass 2 follows immediately.

1. Define the test contract

Before touching the app, write a compact table. Restate it in the final report. Include:

• App, platform, and named start state.
• Ordered user actions.
• One row for each expected outcome, persistence rule, or absence claim.
• Stable executable evidence for each row.
• Required data and side effects.

Use structural checks for semantic state, snapshots for pixels, and both for mixed requirements. One behavioral scenario becomes one `qa-<area>-<behavior>` flow.

Do not invent a material value or weaken ambiguity. Choose the strongest UI-verifiable reading and report it. Ask when the choice changes test meaning.

Make repeated runs deterministic:

1. Inspect the required baseline without mutation. 2. If the account is dirty, record a safe reset or seed flow. Alternatively, include safe normalization in setup. 3. After setup navigation, echo the named baseline and hard-check it before the first scenario mutation. Use `assert:` or a destination `await:` that fully proves the baseline. 4. Prefer to restore the baseline at the end.

A flow has two fixture mechanisms:

• `run:` replays a separately recorded reset or seed flow.
• `script:` runs requested local setup or cleanup. Record it with `flow-add-script` where it belongs in the walkthrough.

Ask before cleanup that creates or deletes meaningful user data outside the request.

Compact example

Ticket: select Dark in Settings. Verify Dark is selected, Light is absent, and the screen renders in dark mode.

| Contract row | Action | Evidence | State effect | | --------------------- | ------------------------ | --------------------------------------------------------------------------- | --------------------- | | Signed-in Home | Launch | `await: { visible: { id: home-screen } }`, then `await: { idle: true }` | Existing account | | Open Settings | Tap `settings-tab` | `await: { visible: { id: settings-screen } }`, then `await: { idle: true }` | None | | Prove Light selected | Inspect Settings | `assert: { visible: { id: theme-light-selected } }` | Fails if already Dark | | Prove Dark selected | Tap `theme-dark-option` | `await: { visible: { id: theme-dark-selected } }` | Theme becomes Dark | | Prove Light absent | Inspect settled screen | `assert: { hidden: { id: theme-light-selected } }` | None | | Verify dark rendering | Inspect settled screen | `snapshot: settings-dark` | None | | Restore baseline | Tap `theme-light-option` | `await: { visible: { id: theme-light-selected } }` | Next run starts c