Qodana baseline suppression gaps when inspection profiles gain new checks

Baseline behavior under profile evolution

Qodana baselines store suppressed issue fingerprints keyed to specific inspection IDs. When a team updates qodana.yaml to enable additional inspections — or syncs a revised IDE profile — the existing baseline file contains no entries for the newly activated inspection IDs. Consequently, code patterns that were previously suppressed for older inspections now surface as fresh violations, causing quality gates to fail unexpectedly.

Current constraints

• Baseline entries are bound to inspection IDs present at creation time; no automatic mapping occurs for new IDs.
• Documentation confirms baselines are profile-specific but does not prescribe a migration strategy when profiles change.
• No qodana baseline migrate or equivalent command exists to propagate suppressions across inspection versions.

Open questions

1. Is the intended workflow to regenerate the baseline entirely after each profile change, accepting all current issues as the new baseline?
2. Can baseline files be safely merged or extended manually by copying suppression entries and updating inspection IDs, and what risks does that introduce?
3. Does Qodana Cloud apply any implicit baseline upgrade logic that differs from the CLI behavior documented for 2024.x releases?