scout_criterion
Record whether each acceptance criterion passed, failed, or was not tested, with confidence and linked findings, to track coverage during exploratory UI testing.
Instructions
Record whether one acceptance criterion of a ticket read with scout_tickets passed, failed or was not tested, with how sure you are. The link from a criterion to the findings that show it is YOUR judgement, stated with a confidence — never matched on words. A "fail" names the findings that show it (file them with scout_finding first); "not-tested" says why in untestedBecause. Recording the same criterion again from the same session replaces your earlier verdict. Touches no browser.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| reason | Yes | What you saw, or why it could not be tried, in a sentence | |
| ticket | Yes | The ticket's id as scout_tickets gave it, e.g. "PROJ-12" or "T1" | |
| session | No | Target this session directly instead of the active one — pass it explicitly when dispatching to MULTIPLE sessions in one turn (e.g. two scout_click calls with different `session`), which then run CONCURRENTLY rather than queueing. Omit for single-session sequential use. | |
| verdict | Yes | "pass", "fail" or "not-tested" | |
| findings | No | Ids of the findings that show this criterion failing (required for a fail; may be given for a pass, none for not-tested) | |
| criterion | Yes | The criterion's id, e.g. "AC2" (or just "2") | |
| confidence | Yes | How sure you are of this verdict and of the findings linked to it, from 0 to 1. State it honestly | |
| untestedBecause | No | Only with verdict "not-tested": "no-access" (the role this run used could not reach it), "observe-blocked" (it needs a change sent and this session is in observe mode), "out-of-scope" (it is outside what this run could check, such as an email or another system) |