# Commands for debugging, editors and help

| Command | Does |
|---|---|
| `jadpo why <schedule>` | Says why a schedule didn't run, or how its last run went |
| `jadpo lsp` | Runs the language server for editors |
| `jadpo help [command]` | Help for one command; `--help` works everywhere |
| `jadpo completions <shell>` | Prints the Tab-completion script for zsh, bash or fish |
| `jadpo version` | Prints the version |
| `jadpo toolchain` | Lists, removes and pins the Jadpo releases kept for projects |

`jadpo why <schedule>` ends with the schedule's `.jadpo` place, and takes
`--json` ([Watching schedules](what-an-operator-sees.md#watching-schedules)).
Another name is `cli.why_arguments`.

`jadpo lsp` is what your editor runs ([Editor support](editor-support.md)).

`jadpo toolchain` lists the releases kept for projects, `remove
<version>` deletes one, and `pin` and `unpin` write the release a project
runs with into `jadpo.lock`. Each takes `--json`
([Which jadpo runs](which-jadpo-runs.md)).

`jadpo help [command]` explains one command, every command takes `--help`
with examples, and `jadpo help --json` gives the rule catalogue and the
schemas of the manifest and of `jadpo test --json`.

Not built yet: the debugging commands of [Debugging and
review](17-debugging-and-review.md), which are proposed there:
`jadpo trace <id>`, `jadpo why` for anything but a schedule,
`jadpo call` and `jadpo console`. Also `jadpo incident [file | -]`,
which explains a runtime event from a file, from standard input
(`pbpaste | jadpo incident -`, or a log stream piped in), or, with no
argument in a terminal, from text pasted at a prompt. It finds the Jadpo
events inside the surrounding log text and groups them by request.