Run your first mobile project scan

Four commands from an unscanned project to a release decision you can hand to someone else. Every command here comes from the bundled CLI’s own help output, and every path is an example — substitute your own.

Before you start

A Flutter, native iOS or native Android project on this machine.
The Guardian CLI already installed and on your PATH.
No network connection is required for a local scan.

The walkthrough

1. Confirm Guardian responds

If this prints a version, the CLI is installed and reachable from this shell. If it does not, that is a PATH problem rather than a Guardian problem — see troubleshooting.

Terminal

guardian version

2. Check the local environment

This inspects the environment Guardian will run in. Missing platform tooling here becomes incomplete coverage later, so it is worth knowing first rather than being surprised by the report.

Terminal

guardian doctor

3. Move to the project

Point Guardian at one application, not at a repository root that contains several. In a monorepo, that distinction is usually the difference between a fast scan and a confusing one.

Terminal

cd /path/to/mobile-project

4. Detect the project

Detection tells you what Guardian thinks it is looking at, before any analysis runs. Read it. If the platform is wrong, everything after this is answering the wrong question.

Terminal

guardian detect .

Expected: the detected platform or platforms, and the analysis paths that apply. A Flutter project with both native targets reports all three.

5. Initialize configuration

Optional for a first look, and useful once you want the same settings on every machine and in CI. It writes configuration into the project.

Terminal

guardian init

6. Run the release check

This is the command that produces a decision rather than a list. It runs the release workflow and exits according to the configured policy, which is what makes it usable in a pipeline.

Terminal

guardian release check

7. Generate a report you can share

The HTML report is the one to send to a QA lead or a release manager. It opens in a browser with no tooling and no account.

Terminal

guardian scan . --format html --output guardian-report.html

Reading the result

A report has two halves, and reading only the first is the most common mistake.

Findings

What was found, with a severity, a location and a remediation step. Severity describes the finding itself.

Coverage

What ran, what was incomplete, and what did not run at all. A check that could not run is never counted as a pass.

The decision

Findings plus coverage plus your configured policy. A passing gate is not a statement that the release is safe.

The example report shows the same structure filled with sample data, and the checks catalogue explains each finding type in detail.

Fix, re-run, and compare

Fix what blocks.
Start with anything the policy treats as release-blocking.
Re-run the check.
Terminal
```
guardian release check
```
Record what you accept.
On an established codebase you will not fix everything on day one. A baseline records what you have already reviewed so that future runs can block only on what is new.
Terminal
```
guardian scan . --baseline guardian-baseline.json --fail-on-new
```

How baselines and release gates work