# Commands for services, calls, email and stored data

These commands change a feature flag while your app runs, show what your app
sent outside while you develop it, the provider calls and the email, and check a
deploy before it happens.

| Command | Does |
|---|---|
| `jadpo flags` | Lists feature flags; `set`, `reset`, `remove` |
| `jadpo calls` | The development call log |
| `jadpo email` | The dev inbox and the sending domain's records |
| `jadpo runs unfinished --build <build id>` | Lists the multi-step runs a deploy would stop |

| Command | What it does |
|---|---|
| [`jadpo flags`](/docs/jadpo-flags.md) | Change and remove flags. |
| [`jadpo calls`](/docs/jadpo-calls.md) | Show provider calls in dev. |
| [`jadpo email`](/docs/jadpo-email.md) | Read the dev inbox and check mail. |
| [`jadpo runs`](/docs/jadpo-runs.md) | Check runs before a deploy. |

## `jadpo flags`

Changes who gets which value of a feature flag while the app runs, and
removes a flag from the source
([Feature flags](/docs/feature-flags.md)). `flag` is a
synonym, and it takes `--json`.

- `jadpo flags`, or `list`, is a table of each flag: everyone's value,
  how many users are named, its shares, the day it last changed and its
  state: `○ default` for a flag never changed, `● rolling out` while
  callers get different values, `● true for everyone` once one value
  holds, and `✓ ready to remove` when it has held for seven days. A
  footer and, for the first flag ready to remove, its `remove` command
  follow. It succeeds whatever it lists.
- `set <flag> [<value>]` changes one part of the state and leaves the
  rest: with no option, everyone's value; `--users <id>,…` the named
  users'; `--percent <n>` one share, `0` removing the shares; `--split
  <value>=<n>,…` a share for each value. A `Bool` flag's value is
  `true` when an option is given without one. It shows what the flag
  gave before and gives now, who made the change and that every server
  has it within ten seconds.
- `reset <flag>` gives everyone the `default:` again; with `--users` it
  stops naming those users.
- `remove <flag> --keep <value>` rewrites the source as if the flag had
  always held that value, lists every change file by file, and checks
  the result, undoing it when it doesn't check
  ([Flag rules: changing, listing, removing](/docs/flags-changed-listed-and-removed.md)).

```text
$ jadpo flags set new_checkout --percent 10
✓ Set `new_checkout`
    was       false for everyone (the default)
    now       true for 10% of users; false (the default) for everyone else
    logged    sam · role app_owner
    applies   within 10 s, on every server
```

Each change writes a row of `jadpo_flag_changes` in the same statement,
with the operator's name and the database role, as `jadpo deliveries`
does. The database is `--url`'s, the connection's setting's, or a
running `jadpo dev`'s; there is no `--env` flag. An unknown action,
flag, value, user or share is `cli.flags_arguments`, with the nearest,
and a database it can't read or a flag that changed meanwhile is
`flags.unavailable`.

## `jadpo calls`

Shows the provider calls `jadpo dev` made, faked or real. It takes
`--json`. `--connection`, `--operation` and `--request` filter it.

- `jadpo calls` is a table of the last 500 calls, oldest first, each with
  its id, operation, source (`generated`, `scripted`, `sandbox`,
  `recording`), how it ended, its time and its request, then a footer and
  one hint.
- `calls show <id>` prints one call in full, laid out: what was sent,
  never its headers, and what came back.
- `calls script <operation> <answer>` sets the next answer for an
  operation: one of its failures' codes, or `unavailable`, `lost`,
  `in_use` or `misconfigured`. It checks the operation and the answer
  against the project first. `calls script ai.<prompt> <condition>` sets
  the next answer of a prompt asked through a package that fills `ai`, as
  one of `ai.generate`'s five conditions ([AI](/docs/ai.md)).

An unknown action, call, operation or answer is `cli.calls_arguments`,
with the nearest ([Debugging](/docs/debugging-and-review.md)).

## `jadpo email`

`jadpo dev` catches every email your app sends in a dev inbox, so nothing
reaches a real address ([Email](/docs/email.md)). It takes
`--json`.

- `jadpo email` is a table of the mail caught, oldest first, each with its
  id, email, address, subject and health. `--to` narrows it.
- `email show <id>` prints one with its text (`--html` for its HTML), its
  links numbered, its attachments, and each health problem with its fix.
- `email links <id>` numbers its links, and `email open <id> <link>` opens
  one in `$BROWSER` or the system's browser.
- `email clear` empties the inbox.
- `email check-domain [<domain>]` reads SPF, DKIM (`--selector`) and DMARC
  for the domain given, or for `email: { from: }`'s.

An unknown action, mail or link is `cli.email_arguments`, with the
nearest. A browser that can't be started is `email.browser_failed`, with
the link to open yourself.

## `jadpo runs unfinished`

Run it against production before a deploy. It lists the unfinished
multi-step runs and batches whose recorded path the new build changes, so
an operator knows what will stop as `diverged`
([Deploys](/docs/several-changing-calls-in-one-action.md#deploys)). It takes `--json`.

`--build` takes the new build's id, `b_` and twelve hex digits, as its
stamp carries it ([The build stamp](/docs/a-native-deployable.md#the-build-stamp)) and the manifest
lists it for each deployable. It must be the id of a build the checkout
makes; `cli.runs_arguments` names the ones it does otherwise. It shows a table of each record whose build differs and
whose action's step shape the build changes, so the record stops as
diverged, or no longer keeps, so its steps are sent again. It also lists
each running batch run whose call the build changes, which fails. A footer
and one hint follow. `--url` and `--store` work as for `jadpo deliveries`
(`runs.unavailable`).

Not built yet:

- `jadpo services`, with `start`, `stop`, `restart <name>`,
  `logs <name>` (`--follow`, `--since`) and `shell <name>`. It shows each
  container a package runs: its package, image, state, health, CPU and
  memory, restarts and uptime, and manages one. `shell`, a shell inside
  one, is for development only. In production they talk to the running
  app, never to the container engine ([External
  services](/docs/external-services.md)).
- `jadpo dev grants add <connection> --owner <id>`, which makes a fake
  OAuth grant for local development ([OAuth grants](/docs/oauth-grants.md)).
- `jadpo files ls`, `show`, `get`, `put` and `copy`, which work on any
  store, in development or production, `copy` copying files between two
  stores (S3, R2, disk) ([Files](/docs/files.md)).
- `jadpo batches list`, `show <id>` and `cancel <id>`, which list batch
  runs (file reads and writes, `batches.each`) with their state and
  progress, show one run's progress and problems, and stop one, as
  `batches.cancel` does ([Background work](/docs/jobs-and-events.md)).
- `jadpo search reindex`, which rebuilds a search index from the
  database ([Search](/docs/search.md)).