> For the complete documentation index, see [llms.txt](https://docs.xygeni.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.xygeni.io/xygeni-products/code-quality.md).

# Code Quality

Xygeni **Code Quality** analyses your source code for **maintainability and reliability defects** — code smells, complexity violations, dead code, duplication, and patterns that cause runtime failures — and surfaces them in a dedicated **Quality** section in the web platform, separate from security findings.

Quality is delivered as its own scanner (`xygeni quality`) that shares the static-analysis engine with [SAST](/xygeni-products/code-security-cs.md) (parsers, AST, file discovery) but maintains its own rule catalog focused on quality, not security.

## Quality scanner

Run a quality scan with the dedicated command:

```bash
xygeni quality -d <directory> [options]
```

The alias `xygeni code-quality` is also accepted.

The scanner shares its option model with `xygeni sast`. The most common options are:

| Option                       | Description                                                                                                                                                                      |
| ---------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `-d`, `--dir <directory>`    | Directory to analyse. Defaults to the current working directory.                                                                                                                 |
| `-n`, `--name <name>`        | Project name to report under.                                                                                                                                                    |
| `--upload`                   | Upload results to the Xygeni platform. By default, results are not uploaded.                                                                                                     |
| `--detectors <list>`         | Comma-separated list of detector IDs to run, a severity (`critical`, `high`, `low`, `info`), or `all`. When a severity is given, that severity and any higher ones are included. |
| `--skip-detectors <list>`    | Inverse of `--detectors`.                                                                                                                                                        |
| `-i`, `--include <patterns>` | Glob patterns of files to include.                                                                                                                                               |
| `-e`, `--exclude <patterns>` | Glob patterns of files to exclude.                                                                                                                                               |
| `-o`, `--output <file>`      | Output file path. Defaults to stdout.                                                                                                                                            |
| `-f`, `--format <format>`    | Output format.                                                                                                                                                                   |
| `--fail-on <severity>`       | Exit non-zero if findings of the given severity (or higher) are produced. Useful as a CI/CD gate.                                                                                |
| `--baseline <file>`          | Compare against a baseline report and only return new findings.                                                                                                                  |

For the full option list run:

```bash
xygeni quality --help
```

### Examples

Run a quality scan on the current directory and upload the results:

```bash
xygeni quality -n MyProject --upload
```

Export critical findings to JSON:

```bash
xygeni quality -d <dir> --detectors critical --format json --output quality.json
```

### Run quality alongside a SAST scan

The SAST scanner accepts an `--include-quality` flag that runs the quality rules in the same pass. The SAST and quality rules share the parser stage, so this is more efficient than running `xygeni sast` and `xygeni quality` back to back when you want both.

```bash
xygeni sast -d <dir> --include-quality
```

The scan produces both a SAST report and a separate quality report. SAST and quality findings remain on their own report files and on their own dashboard sections — `--include-quality` only changes how the scan is executed, not how the results are surfaced.

### Upload a previously generated quality report

Quality results are normally sent to the platform during the scan with `--upload`. When the scan runs where there is no connectivity to Xygeni (an air-gapped enclave, or a CI runner without network egress), save the report and upload it later with [`report-upload`](/xygeni-products/application-security-posture-management-aspm/importing-reports-from-3rd-party-tools.md):

```bash
# 1. Scan, keep the report locally (no --upload)
xygeni quality -d <dir> -n MyProject

# 2. Later, from a host with platform connectivity, upload it
xygeni report-upload -n MyProject -r depsdoctor-quality.json
```

The findings land in the **Quality** section exactly like a native quality scan — same triage, policy, baseline, and remediation behaviour — and never in the SAST / All Risks views.

`report-upload` recognises the report from its standard file name `depsdoctor-quality.json`. If the file was renamed (for example via `--output`), pass the format explicitly so it is not mistaken for a SAST report (both share the same report shape):

```bash
xygeni report-upload -n MyProject -r my-quality-report.json --format quality-xygeni
```

Uploading a quality report requires the **Code Quality** entitlement, the same as running the scan.

## Quality findings in the web platform

Quality findings are uploaded to the Xygeni platform alongside any other scan output and are displayed in a **dedicated Quality section** of the dashboard, separate from SAST and the rest of the security risks. Filtering, slide-out detail, baselines, and reports work the same way as for the other risk tables.

## Related

* [SAST Scanner](/xygeni-products/code-security-cs/ci-cd-scanner.md) — security-focused static analysis. Quality and SAST share the engine but ship as independent scan commands and rule catalogs.
* [Xygeni CLI Configuration options](https://github.com/xygeni/UserDoc/tree/main/xygeni-products/xygeni-scanner-cli/xygeni-cli-overview/xygeni-cli-configuration-options.md) — configuration files (`xygeni.yml`, `xygeni.<command>.yml`) and `--conf-option` overrides.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.xygeni.io/xygeni-products/code-quality.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
