# Capturing a failing request as a test

The quickest reliable fix starts by reproducing the bug.
`jadpo test new --from <request id>` writes a route test that replays a
request `jadpo dev` recorded, with the data the request read written as
fixtures, the test data a test starts from. The test asserts what was
observed. You change the assertion to what should happen, watch the test
fail, then fix the code. Your agent can do the whole loop.

```jadpo
// domains/planning/routes/todos.test.jadpo
/// Captured from req_0b1e by jadpo test new --from.
test "completing a todo twice answers a conflict" {
    clock: "2026-10-12T09:14:03Z"

    var alice: Principal.user = captured_user_1()
    var todo: Todo = captured_todo_1(alice)
    var response: Response = request {
        method: HttpMethod.post
        path: "/todos/{todo_id}/complete"
        params: {
            todo_id: todo.id
        }
        as: alice
    }
    // observed: 409 todo_mutation_conflict
    assert response.status == 409
    assert response.code == "todo_mutation_conflict"
}
```

## What the captured test holds

- **Fixtures** go in the domain's `fixtures/` folder and create records
  through the entity's generated operations
  ([Shared test data: fixtures](shared-test-data-fixtures.md)).
- **Personal data** is never copied. Fields marked `personal:` are replaced
  with generated values, so a captured test never commits real personal
  data ([Marking personal fields](marking-personal-fields.md)).
- **Calls to providers** become `fakes:` that give the answers the request
  received.

## From a production event

`--from-event <file>` does the same from a production event. It uses only
what the event recorded, so it can't write the fixtures; you fill those in
yourself.