Add InspectCode diagnostics baseline feature with init/sync commands

[kurnakovv]

Summary

Add support for an InspectCode diagnostics baseline feature so users can snapshot the current diagnostics state and keep it synchronized over time.

Problem

Projects often adopt stricter analysis incrementally. Without a baseline mechanism, existing diagnostics make it difficult to distinguish newly introduced issues from already-known ones. This creates noise in CI and slows down adoption of formatting and analyzer enforcement.

Proposed solution

Introduce a inspectcode-baseline feature for InspectCode integration with two primary commands:

• init - generate an initial baseline from the current InspectCode output
• sync - refresh the baseline to match the current accepted diagnostics set

This command family is conceptually similar to warnings-baseline, but with different focus:

• warnings-baseline is focused on .NET compiler/analyzer warnings
• inspectcode-baseline is focused on InspectCode rules and diagnostics

Baseline behavior must write existing rules into the baseline using a fixed severity level defined by user configuration (default: suggestion). This severity mapping should be configurable in biak config and applied consistently during init and sync.

Configuration

Add a dedicated inspectCodeBaseline section in biak config.

Example:

{
  "inspectCodeBaseline": {
    "path": ".biak/.editorconfig-InspectCodeBaseline",
    "snapshotSeverity": "suggestion",
    "ruleIdOverrides": {
      "CanReplaceCastWithLambdaReturnType": "resharper_can_replace_cast_with_lambda_return_type_highlighting"
    },
    "additionalArgs": [
      "--settings=./team.DotSettings",
      "--no-build"
    ]
  }
}

Fields:

• path - target baseline file path in config (used when CLI flag is not provided)
• snapshotSeverity - fixed severity applied to rules written during init/sync (default: suggestion)
• ruleIdOverrides - custom mapping dictionary (biakRuleName -> inspectcodeRuleId) to add missing rules or override existing mappings
• additionalArgs - raw arguments passed to jb inspectcode for advanced scenarios; this is the initial extensibility mechanism for inspectcode-baseline (typed config flags can be added later if needed)

The feature should integrate with biak's centralized configuration model and support practical workflows for teams gradually tightening rule enforcement.

Scope

• Define a baseline file format for storing accepted InspectCode diagnostics (with severity)
• Add command-line support for initializing a baseline
• Add command-line support for syncing/updating an existing baseline
• Compare current InspectCode results against the stored baseline
• Surface only new or unresolved diagnostics outside the accepted baseline where appropriate
• Apply a configurable fixed severity level when writing existing baseline rules (default: suggestion)
• Support baseline target path in both CLI and config with precedence: --path flag -> inspectCodeBaseline.path -> default discovery logic
• Pass user-defined inspectCodeBaseline.additionalArgs through to jb inspectcode during baseline operations
• Ensure behavior works with existing biak concepts such as modular configuration, imports, variables, and enable/disable modes

Proposed CLI

Examples of the desired command surface:

biak inspectcode-baseline init [--path <path>]
biak inspectcode-baseline sync [--path <path>]

Init/Sync behavior

init

• Resolve target baseline path using precedence: CLI --path flag -> inspectCodeBaseline.path from config -> default discovery logic
• Run jb inspectcode (with configured inspectCodeBaseline.additionalArgs)
• Produce baseline entries with fixed severities according to inspectCodeBaseline.snapshotSeverity
• Write/update baseline blocks in editorconfig-style format, marked with # ^biak^ baseline

Conceptual output shape:

[{FilePath1,FilePath2}]
ruleId = severity # ^biak^ baseline
...

sync

• Resolve target baseline path using precedence: CLI --path flag -> inspectCodeBaseline.path from config -> default discovery logic
• If path is explicitly resolved (flag/config), use that file as primary target for reading/updating baseline entries
• If path is not explicitly resolved, in the .biak directory scan files whose names start with .editorconfig
• In discovered files, locate baseline entries marked with # ^biak^ baseline
• If no such files/entries are found, fallback to .editorconfig and apply the same marker-based logic
• If # ^biak^ baseline is not found anywhere, return a user-facing message asking to run biak inspectcode-baseline init

Potential follow-up options to consider:

• baseline file path selection
• overwrite/confirm behavior
• deterministic output ordering
• dry-run mode for sync

Acceptance criteria

• A user can create a baseline from existing InspectCode diagnostics using an init command
• A user can update the baseline using a sync command after intentional diagnostics/rule changes
• Baseline matching is deterministic and stable across runs for the same input
• Newly introduced diagnostics can be distinguished from diagnostics already present in the baseline
• Existing rules are written to baseline with a fixed configured severity from inspectCodeBaseline.snapshotSeverity (default: suggestion)
• inspectCodeBaseline.ruleIdOverrides supports adding custom rule mappings and overriding built-in mappings
• If a rule mapping exists in both built-in mappings and ruleIdOverrides, the override from config is used
• Path resolution precedence is deterministic and enforced as: CLI --path flag -> inspectCodeBaseline.path -> default discovery logic
• inspectCodeBaseline.additionalArgs is forwarded to jb inspectcode unchanged and in the specified order
• init writes baseline entries in editorconfig-style format with marker # ^biak^ baseline
• sync scans .editorconfig* files in biak directory for # ^biak^ baseline entries and falls back to .editorconfig if needed
• If baseline marker # ^biak^ baseline is not found anywhere, sync asks user to run biak inspectcode-baseline init
• The baseline workflow is documented with examples, including config usage