For the complete documentation index, see llms.txt. This page is also available as Markdown.
Developer

Checking your setup

How to check that Sonar Vortex is installed correctly and can reach SonarQube Cloud for your project.

After you install Vortex, confirm that your agent can reach it. Vortex gives your agent two capabilities, so run both checks: one for the context it receives before writing code, and one for the analysis of the code it produces.

Check the context: ask about the project's architecture

Ask your agent "What is the current architecture of the project? Limit the answer to the top-level blocks." The agent uses Vortex to retrieve the current architecture (it might ask for your confirmation), then presents a high-level overview of the current project.

Example response:

The architecture has 19 top-level modules with 35 dependencies between them:

  ---
  Foundation (no dependencies)

  ┌──────────────────┬──────────────────────┐
  │      Module      │      Depended on by    │
  ├──────────────────┼──────────────────────┤
  │ proj-api-base    │ All 18 other modules │
  └──────────────────┴──────────────────────┘

  ---
  Core layer (depend only on api-base)

  ┌────────────────────────────────────────────────┬────────────────────────────────────────┐
  │                     Module                     │                Purpose                 │
  ├────────────────────────────────────────────────┼────────────────────────────────────────┤
  │ proj-api-injection                             │ DI configuration interfaces            │
  │ proj-common                                    │ Shared utilities                       │
  │ proj-documentation                             │ Documentation                          │
  │ proj-impl-configuration-gestalt                │ Gestalt config implementation          │
  │ proj-peripheralcommadapter-loopback            │ Peripheral loopback driver             │
  │ proj-plantoverview-base                        │ Base UI components                     │
  │ proj-plantoverview-panel-loadgenerator         │ Load generator panel                   │
  │ proj-plantoverview-panel-resourceallocation    │ Resource allocation panel              │
  │ proj-plantoverview-themes-default              │ Default UI themes                      │
  │ proj-strategies-default                        │ Default routing/dispatching strategies │
  └────────────────────────────────────────────────┴────────────────────────────────────────┘

  ---
  Mid layer (depend on api-base + common)

  ┌────────────────────────────────────────┬────────────────────────────┐
  │                 Module                 │      Also depends on       │
  ├────────────────────────────────────────┼────────────────────────────┤
  │ proj-commadapter-loopback              │ common                     │
  │ proj-kernel-extension-http-services    │ common                     │
  │ proj-kernel-extension-rmi-services     │ common                     │
  │ proj-plantoverview-common              │ common, plantoverview-base │
  └────────────────────────────────────────┴────────────────────────────┘

  ---
  Application layer (leaf modules, nothing depends on them)

  ┌─────────────────────────────┬────────────────────────────────────────────────────────────┐
  │           Module            │                         Depends on                         │
  ├─────────────────────────────┼────────────────────────────────────────────────────────────┤
  │ proj-kernel                 │ api-base, common, commadapter-loopback                     │
  │ proj-kernelcontrolcenter    │ api-base, common, commadapter-loopback                     │
  │ proj-modeleditor            │ api-base, common, plantoverview-base, plantoverview-common │
  │ proj-operationsdesk         │ api-base, common, plantoverview-base, plantoverview-common │
  └─────────────────────────────┴────────────────────────────────────────────────────────────┘

  ---
  Dependency flow (simplified)

  proj-api-base
    └── proj-common
          └── proj-commadapter-loopback
          │     ├── proj-kernel
          │     └── proj-kernelcontrolcenter
          └── proj-plantoverview-base
                └── proj-plantoverview-common
                      ├── proj-modeleditor
                      └── proj-operationsdesk

  proj-api-base is the clear foundation — every module depends on it and nothing depends on the four application-layer modules (kernel, kernelcontrolcenter, modeleditor, operationsdesk).

Check the analysis: ask your agent to edit a file

Ask your agent to edit a file in your project. After it applies the change, Vortex analyzes the modified code and surfaces any new findings. How the findings reach you depends on your agent:

  • Claude Code and Codex run a hook after the edit and feed the findings back into the session, so the agent can fix new issues before ending its turn.

  • Cursor runs an always-applied rule after the edit.

  • Antigravity and GitHub Copilot CLI check the files they edit and return the findings in their response.

If you installed Vortex through the SonarQube MCP server, including for Kiro, your agent has no post-edit hook and runs the analysis on request instead. Ask it to analyze a file, for example "Verify the file path/to/file.java." Your agent invokes the analysis (it might ask for your confirmation) and reports the issues currently present in that file, grouped by severity.=

If a check fails

  1. Confirm your authentication with sonar auth status.

  2. Restart your agent so the integration is loaded for the current project.

If the checks still fail, re-run the installation for your agent. See How to install Vortex for your agent.

Last updated

Was this helpful?