> VAR watches what you changed, figures out what needs checking, and tells you what to fix next.

**Audience: Vary developers.** VAR validates your project code. If you are looking for the internal compiler verification tool, see [VAST](/vast/) instead.

## What VAR does

`vary var` answers one question: is my working tree ready?

It looks at which files changed since the last run, decides what validation is needed, and runs it. If checks fail, it lists the blockers. If tests fail, it points you at the failures. If everything passes, it says so.

You run it repeatedly as you work. Each invocation picks up where the last one left off. Fix a blocker, re-run, and it skips the stages that already passed.

If there are no uncommitted changes and no existing session, `vary var` exits early with a short message instead of creating an empty session. There is nothing to review yet. The early exit respects all output modes (human, compact, JSON). Re-running on a project with a prior session always continues that session, so an in-progress review is never skipped.

## Why it exists

Without VAR, the workflow is: run checks manually, run tests manually, maybe run mutation testing if you remember. Each step requires knowing the right command and the right scope. Easy to skip a step or run it on the wrong files.

One command does the right thing:

| Situation | What VAR does |
|-----------|--------------|
| Changed only docs? | Skip deeper stages |
| Changed core source? | Run checks, tests, and mutation |
| Already ran checks and they passed? | Skip them next time |
| Same blockers as last run? | Flag that you are stuck |

## How to use it

```bash
vary var              # What needs doing?
vary var --dry-run    # What would run, without running it?
vary var --json       # Machine-readable output for CI
vary var --reset      # Start fresh
```

See the [CLI reference](/docs/var/cli-reference/) for all flags and options.

## The six stages

VAR runs up to six stages, always in this order:

| Stage | What it does |
|-------|-------------|
| **Discovery** | Detect changed files via git diff (or filesystem scan if no git) |
| **Check** | Run static analysis on changed source and test files |
| **Test** | Run tests that cover changed modules |
| **Mutation** | Run mutation testing on changed source files (if enabled) |
| **Review** | Generate a review closeout packet (if enabled) |
| **Classification** | Determine terminal state: complete, blocked, partial, or advisory |

Not every stage runs every time. The [decision policy](/docs/var/decision-policy/) determines which stages to run, skip, or block based on the significance of your changes and a cost budget you control.

## Terminal states

After running, VAR classifies the outcome:

| State | Meaning |
|-------|---------|
| **Complete** | All stages passed. No further action needed. |
| **Blocked** | A stage failed. Blockers are listed with what to fix. |
| **Partial** | Some stages ran, others were skipped (budget or scope). |
| **Advisory** | Informational run with no blocking findings. |

## Session persistence

VAR saves its state to `.vary-var-session.json` in the project root so it can resume across invocations. If your working tree changes between runs (new edits, new commits), VAR detects the drift and resets to rediscovery. See [session state](/docs/var/session-state/) for details.