# `mix phoenix_kit.status`
[🔗](https://github.com/BeamLabEU/phoenix_kit/blob/v2.14.2/lib/mix/tasks/phoenix_kit.status.ex#L1)

Shows comprehensive status of PhoenixKit installation.

This task provides a detailed overview of your PhoenixKit installation status,
including version information, database connectivity, assets status, and
suggested next actions.

## Usage

    $ mix phoenix_kit.status
    $ mix phoenix_kit.status --prefix=myapp

## Options

  * `--prefix` - Database schema prefix. When omitted, resolves from
    `config :phoenix_kit, :prefix`, then defaults to "public".
  * `--verbose` - Show detailed diagnostic information
  * `--exit-code` - Exit non-zero unless `Next` is `Ready`. For deploy scripts
    and CI, which otherwise cannot tell a clean install from a module sitting
    four versions behind — the report is identical on stdout either way.
    Off by default so existing deploys that run this for its log line keep
    passing.

## Examples

    # Show status for default installation
    mix phoenix_kit.status

    # Show status for custom schema prefix
    mix phoenix_kit.status --prefix=auth

    # Show detailed diagnostic information
    mix phoenix_kit.status --verbose

    # Fail a deploy when core or any module schema is behind
    mix phoenix_kit.status --exit-code

## Sample Output

    PhoenixKit v1.7.216
    ├── Installed: V159 ✅
    ├── Database: Connected ✅
    ├── Modules: 2 modules, all up to date ✅
    │   ├── Boards: V01 ✅
    │   └── Inbox: V01 ✅
    └── Next: Ready

The `Modules` row covers PhoenixKit modules that own their migrations
(`c:PhoenixKit.Module.migration_module/0`) — each reports the schema version
installed in *your* database against the version its code expects. When one
is behind, the report says so and `Next` points at the fix and the reason:

    PhoenixKit v1.7.230
    ├── Installed: V159 ✅
    ├── Database: Connected ✅
    ├── Modules: 2 modules, 1 behind ⚠
    │   ├── Boards: V01 ✅
    │   └── Inbox: V01 ⚠ (code expects V02)
    └── Next: mix phoenix_kit.update — module schema behind: Inbox

The row is omitted entirely when no installed module owns migrations, so a
core-only install keeps the compact tree.

## "code expects", not "update available"

Everything reported here is measured against the version compiled into the
**running release** — this task never asks Hex what exists, so it cannot and
does not tell you a newer PhoenixKit is out. A version gap is therefore not
an optional upgrade being offered; it means the schema disagrees with the
code already querying it, which surfaces as runtime errors on whatever the
newer version added. The wording is deliberate:

    ├── Installed: V159 ⚠ (code expects V160)
    └── Next: mix phoenix_kit.update — database is V159, code expects V160

When core and a module are both behind, one command fixes both and both
reasons are listed, so re-running does not turn up a second finding that was
already knowable:

    └── Next: mix phoenix_kit.update — database is V159, code expects V160; module schema behind: Inbox

# `exit_code`

```elixir
@spec exit_code(tuple(), [map()] | :not_queried) :: 0 | 1
```

The process exit status `--exit-code` should produce: `0` only when the
install is verifiably ready, `1` otherwise.

Public because `run/1` is not a unit-test seam (it starts the app and needs a
real database) — this is the pure decision behind the flag, in the same shape
as `Mix.Tasks.PhoenixKit.Repair.exit_code/1`.

`modules` is a `PhoenixKit.Migrations.Modules.list/1` result, or `:not_queried`
when the database never answered.

---

*Consult [api-reference.md](api-reference.md) for complete listing*