> For the complete documentation index, see [llms.txt](https://docs.darcyiq.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.darcyiq.com/build/testdrive/results-and-evidence.md).

# Results & Evidence

Read a run's verdict, the report behind it, and the screenshots, video, and traces that prove it

Every run ends with a verdict and the evidence for it. The point is that you shouldn't have to reproduce a failure to believe it.

## The Run Detail Page

| Tab                 | What's there                                                                               |
| ------------------- | ------------------------------------------------------------------------------------------ |
| **Report**          | The verdict, each test's result, the failures in detail, and the evidence attached to them |
| **Agent activity**  | What the agent did, stage by stage, including the transcript of its reasoning              |
| **Knowledge graph** | What this run used and what it learned about your application                              |

The Report tab is available once the run completes. Agent activity is watchable while it's still going.

Run metadata sits above the tabs: what triggered it, when it started, how long it took, how many tests it covered, and how many artifacts it produced.

## Reading the Verdict

| Outcome            | What it means                                                                                 |
| ------------------ | --------------------------------------------------------------------------------------------- |
| **Passed**         | Every test in the run met its expected outcome                                                |
| **Failed**         | At least one test did not                                                                     |
| **App regression** | A test failed in a way that points at the application, while the script itself is still valid |
| **Error**          | The run couldn't complete — the environment, not the assertion                                |
| **Canceled**       | Someone stopped it                                                                            |

The distinction between a failed test and an **app regression** is the useful one: the first may mean your script drifted out of date with the interface, the second says the script did exactly what it always does and the application answered differently. One is maintenance; the other is a bug.

## Evidence

Failures carry their evidence inline, and you can open any of it full-screen and page through it.

| Kind                   | What it's good for                                                           |
| ---------------------- | ---------------------------------------------------------------------------- |
| **Screenshot**         | The state of the page at the moment it went wrong                            |
| **Video**              | The whole approach, when the failure is about how you got there              |
| **Playwright trace**   | Step-by-step replay with DOM snapshots, for when the screenshot isn't enough |
| **Request / response** | What the app actually sent and received                                      |
| **Console log**        | The errors the browser saw                                                   |

To open a trace, download the ZIP and run it locally:

```bash
npx playwright show-trace trace.zip
```

## Taking the Report Elsewhere

| Action              | Result                                                              |
| ------------------- | ------------------------------------------------------------------- |
| **Copy report**     | The report as text, for a ticket or a chat message                  |
| **Export PDF**      | The full report as a file, for people who don't have TestDrive open |
| **Fix with Cursor** | Hands the failure to your editor with the context already assembled |

## Next Steps

| Goal                             | Documentation                                              |
| -------------------------------- | ---------------------------------------------------------- |
| Understand what the run learned  | [Application Knowledge](/build/testdrive/app-knowledge.md) |
| Repair or rebuild a script       | [Tests & Scripts](/build/testdrive/tests-and-scripts.md)   |
| Run this automatically next time | [Running Tests](/build/testdrive/running-tests.md)         |


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.darcyiq.com/build/testdrive/results-and-evidence.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.