Argent QA Flows

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.

The initial Light check establishes the selector used by the later hidden check. The final restore makes pass 2 independent.

2. Record the scenario

Follow argent-create-flow's start order and live-authoring cycle. Record each structural contract check when its state appears.

A snapshot has no recorder form. Inspect its stable state during the walkthrough, then add the planned snapshot during polish. If direct recovery changes state, re-record the affected behavior. A recovered walkthrough is not proof.

3. Make evidence discriminating

• State change: prove the new state and the old state's absence when both can otherwise match.
• Cancel/persistence: cross the commit boundary. After cancel or save, leave, re-enter, then verify the stored state: unchanged after cancel or updated after save.
• Absence: prove the containing screen and record the same stable selector as visible, then the action, then hidden. Do not add an unestablished hidden check only to strengthen a positive baseline. In a collection, viewport absence is not global absence. Use fixed seeded position, count, empty state, or other collection-wide evidence.
• Overlays: use the create-flow obscured-target procedure.
• Repeated controls: prefer an id. Otherwise use flow-only within with a stable container. Use text.in to prove rendered membership inside that container.
• Dynamic content: assert controlled state or stable app chrome. Use anchored structure for unavoidable dynamic values and disclose the dependency.
• Visual state: snapshot only a correct, settled, deterministic screen. Use full screen for global changes and cropOn for one component.

Never put acceptance evidence inside when:. Use when: only for optional setup that reconverges to the required path.

4. Finish and audit

Complete the create-flow polish and blocking audit. Then:

1. Map every contract row to an executed action or hard check.
2. Build a navigation table with one row per screen change, naming both the identity gate and the readiness gate. A row missing either is a blocking defect.
3. Confirm setup and end state permit an immediate second run.