# Debugging and review

Jadpo code is written mainly by coding agents and read by people, so two
jobs matter most. When something goes wrong, you or your agent need to get
from the symptom to the `.jadpo` line and the reason, without reading the
code Jadpo generates. And when an agent hands over a large change, you need
to see what it does to your app, such as who can now read which data,
before you read it line by line. This page covers both: where errors
point, how to see what a request did and why, and how to review a change.

The command line, the developer console and the agent tools (MCP) all show
the same evidence. The compiler and the runtime record that evidence, and
each view only displays it. If the console shows why a caller was refused,
that's because the compiler and the runtime recorded the reason, not
because the console worked it out.

| Tool | What it does |
|---|---|
| Errors point at `.jadpo` | Always a `.jadpo` file and line, in development and production |
| Production incidents | `jadpo incident` names the line in the build that failed, then where that code is now |
| Breakpoints | Not offered |
| Why the language decided something | `jadpo why` |
| What a request did | The request timeline in `jadpo dev`; `jadpo trace <request id>` |
| Watching code run | `jadpo watch` waits for a named part of the code to run and prints it |
| Provider calls in development | `jadpo calls`: every call logged with full values, in development only |
| Traces, metrics and logs in development | `jadpo traces`, `jadpo metrics`, `jadpo logs`, with filters, `--follow` and `--json` |
| Failing request to test | `jadpo test new --from <request id>` |
| Run a query or action | `jadpo call <name> --as <user>` |
| Developer console and MCP | A local web page and read-only agent tools over the same evidence |
| Reviewing a change | A report with behaviour first, and a static web view of it |
| JSON for agents | Every command and view ([Tools for agents](tools-for-agents.md)) |
| Coverage by path | Tests and production compared path by path |
| Production in review | The approval report shows traffic and failures on the paths a change touches |
| Replaying a production request | Opt-in recording of what each effect returned, replayed locally |
| Query cost of a change | Queries added or removed per path, in the approval report |

Most of this isn't built yet; [What is built](debugging-and-review-built.md) says which
parts are.