Refactor: move GetEffectiveSeverity and IsFailingError from SeverityOverrides to RuleProvider

[Copilot]

SeverityOverrides was a bidirectionally coupled value object: it held domain logic (GetEffectiveSeverity, IsFailingError) that called back into the static service RuleProvider, while RuleProvider.Resolve simultaneously accepted SeverityOverrides as a parameter.

Changes

• SeverityOverrides: Removed GetEffectiveSeverity and IsFailingError. Added internal TryGetOverride helper. Now a pure data container with no dependency on RuleProvider.
• RuleProvider: Added GetEffectiveSeverity(code, overrides) and IsFailingError(code, overrides) as static methods. Updated Resolve to use GetEffectiveSeverity internally instead of delegating to the overrides object.
• Call sites (ValidatorRunner, ValidationReporter, SarifReporter): Updated to call RuleProvider.IsFailingError / RuleProvider.GetEffectiveSeverity directly.
• SeverityOverridesTests: Tests for the moved methods updated to call through RuleProvider.

// Before — SeverityOverrides called into RuleProvider:
overrides.IsFailingError(e.Code)
overrides.GetEffectiveSeverity(error.Code)

// After — unidirectional: RuleProvider owns the logic:
RuleProvider.IsFailingError(e.Code, overrides)
RuleProvider.GetEffectiveSeverity(error.Code, overrides)

Original prompt

Probleem

SeverityOverrides en RuleProvider zijn bidirectioneel aan elkaar gekoppeld:

• SeverityOverrides.GetEffectiveSeverity roept RuleProvider.Get(code) aan om de default severity op te halen.
• RuleProvider.Resolve(code, overrides) accepteert een SeverityOverrides als parameter.

Dit is een violation of the Dependency Inversion Principle: SeverityOverrides is eigenlijk een Value Object (een wrapper om een dictionary), maar bevat domeinlogica die afhankelijk is van de statische service RuleProvider.

Oplossing (Optie 2)

Verplaats GetEffectiveSeverity en IsFailingError uit SeverityOverrides en zet ze volledig in RuleProvider. SeverityOverrides wordt een pure data-container zonder verwijzing naar RuleProvider.

Concrete wijzigingen

SeverityOverrides.cs:

• Verwijder GetEffectiveSeverity(ValidationErrorCode code) — de logica verhuist naar RuleProvider
• Verwijder IsFailingError(ValidationErrorCode code) — de logica verhuist naar RuleProvider
• Verwijder de (nu onnodige) impliciete afhankelijkheid op RuleProvider
• Behoud IsIgnored, IsVisible, GetUsedCodes, de constructor, Count, indexer en IEnumerable-implementatie

RuleProvider.cs:

• De bestaande Resolve(ValidationErrorCode code, SeverityOverrides overrides) berekent al overrides.GetEffectiveSeverity(code) — vervang dat door de logica inline: pak DefaultSeverity als er geen override is, of de override-waarde anders.
• Voeg toe: public static RuleSeverity GetEffectiveSeverity(ValidationErrorCode code, SeverityOverrides overrides) — bevat de logica die eerder in SeverityOverrides zat
• Voeg toe: public static bool IsFailingError(ValidationErrorCode code, SeverityOverrides overrides) — bevat de logica die eerder in SeverityOverrides zat

Aanroepplaatsen aanpassen

De volgende aanroepplaatsen gebruiken overrides.IsFailingError(...) of overrides.GetEffectiveSeverity(...) en moeten worden omgezet naar RuleProvider.IsFailingError(...) / RuleProvider.GetEffectiveSeverity(...):

1. src/SLNX-validator/ValidatorRunner.cs (regel ~48):

   // Oud:
   var hasErrors = results.Any(r => r.Errors.Any(e => options.SeverityOverrides.IsFailingError(e.Code)));
   // Nieuw:
   var hasErrors = results.Any(r => r.Errors.Any(e => RuleProvider.IsFailingError(e.Code, options.SeverityOverrides)));

2. src/SLNX-validator/ValidationReporter.cs (regel ~15):

   // Oud:
   var isFailingResult = result.Errors.Any(e => overrides.IsFailingError(e.Code));
   // Nieuw:
   var isFailingResult = result.Errors.Any(e => RuleProvider.IsFailingError(e.Code, overrides));

3. src/SLNX-validator.Core/SarifReporting/SarifReporter.cs (regel ~76):

   // Oud:
   var effectiveSeverity = overrides.GetEffectiveSeverity(error.Code);
   // Nieuw:
   var effectiveSeverity = RuleProvider.GetEffectiveSeverity(error.Code, overrides);

   En RuleProvider.Resolve(code, overrides) intern ook aanpassen zodat het niet meer overrides.GetEffectiveSeverity aanroept maar de nieuwe RuleProvider.GetEffectiveSeverity.

Tests aanpassen

tests/SLNX-validator.Core.Tests/SeverityOverridesTests.cs:

• De tests voor IsFailingError en GetEffectiveSeverity testen nu methoden die niet meer op SeverityOverrides staan.
• Verplaats/herschrijf deze tests naar een nieuw testbestand (bijv. RuleProviderTests.cs) of pas de aanroepen aan naar RuleProvider.IsFailingError(code, overrides) / RuleProvider.GetEffectiveSeverity(code, overrides).

Eindresultaat

• SeverityOverrides heeft geen verwijzing meer naar RuleProvider — het is een pure data-wrapper.
• RuleProvider is de enige eigenaar van de logica rondom effectieve severity en failing-error-bepaling.
• De koppeling is eenrichtingsverkeer: RuleProvider kent SeverityOverrides, maar niet andersom.

The following is the prior conversation context from the user's chat exploration (may be truncated):

User: Ruleprovider en severityOverrides zijn aan elkaar gekoppeld? Hoe erg is het? Is dit door ddd? Mogelijke oplossingen?

Assistant: Hier is de analyse:

---

De koppeling tussen RuleProvider en SeverityOverrides

Wat is het probleem?

Er is een circulaire/bidirectionele afhankelijkheid tussen de twee klassen:

• SeverityOverrides roept RuleProvider.Get(code) aan om de default severity op te halen als er geen override is:

  public RuleSeverity GetEffectiveSeverity(ValidationErrorCode code)
  {
      if (_overrides.TryGetValue(code, out var severity) && severity.HasValue)
          return severity.Value;
      return RuleProvider.Get(code).DefaultSeverity; // ← afhankelijkheid van RuleProvider
  }

• RuleProvider accepteert `SeverityOverrid...

This pull request was created from Copilot chat.