# `mix castle.appup`
[🔗](https://github.com/ausimian/forecastle/blob/1.0.0/lib/mix/tasks/castle.appup.ex#L1)

Checks appup coverage against the modules that changed between two builds.

    mix castle.appup --from <spec> [--to <spec>] [--app <app>]...

The task is read-only and exits non-zero when it finds a coverage error. Use it
as a release-pipeline check. `mix castle.appup.gen` accepts the same build and
application options and drafts missing entries.

## Builds

`--from` is required. `--to` defaults to the current compiled build. Both
switches accept a baseline spec:

    mix castle.appup --from rel:_build/prod/rel/my_app/releases/1.0.0/my_app
    mix castle.appup --from tar:artifacts/my_app-1.0.0.tar.gz
    mix castle.appup --from ref:1.0.0

A path without a prefix means `rel:`. Prefer `tar:` when the shipped artifact
is available. A rebuilt baseline may differ from the deployed release.

Repeat `--app` to select applications. The default is the current project and
its umbrella children. Name a dependency explicitly to check its appup.

## Results

Upgrade and downgrade directions are checked separately. The task reports:

- a changed or added module that no instruction loads;
- a removed module that no instruction deletes;
- a module that an edge both loads and removes;
- duplicate instructions for one module;
- a module deleted while still present in the target;
- a changed module absent from the application's `.app` inventory;
- invalid instructions or a missing entry for the from-version;
- code changes without an application version change.

An instruction for an unchanged module is reported but does not fail the run.
An edge that restarts the emulator needs no module-level coverage.

This task checks coverage. Relup generation determines whether `:systools`
accepts the complete script. An invalid instruction is credited with no
coverage, but a successful check does not guarantee that a relup will build.

Module fingerprints combine the BEAM md5 with persisted attributes. This
ignores stripping and documentation changes while retaining explicit `@vsn`
changes.

The task requires a baseline, so it belongs in the release pipeline rather
than `mix precommit`.

---

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