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 instead.
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.
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 |
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 for all flags and options.
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 determines which stages to run, skip, or block based on the significance of your changes and a cost budget you control.
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. |
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 for details.