Architektur-Überblick

CodeGuard besteht aus vier Schichten die getrennt entwickelt und getestet werden. Diese Trennung ist auch der Grund warum die Analyse deterministisch ist, jede Schicht hat klare Eingaben und klare Ausgaben.

Schichten von unten nach oben

1. Analysis (CodeGuard.Analysis)

Liest eine .NET-Solution mit MSBuild ein und baut ein abstraktes Code-Modell mit Typen, Methoden, Properties, Feldern und ihren Beziehungen (Coupling, Vererbung, Methodenaufrufe).

Außerdem läuft hier eine syntaktische Vor-Analyse die spezifische Pattern-Detection macht, z.B. "DateTime.Now wurde direkt aufgerufen" oder "Async-Methode hat keinen CancellationToken-Parameter". Diese Befunde landen als SyntaxIssue-Objekte im Modell.

Output: ein AnalysisModel mit den Collections Types, Methods, Properties, Fields, Events, Namespaces, Assemblies, TypeDependencies und SyntaxIssues.

2. DSL (CodeGuard.Dsl)

Liest .cgr-Dateien ein, parsed sie zu einem AST und kompiliert die LINQ-Queries zu ausführbaren Lambdas. Die DSL ist eine echte Untermenge von LINQ, die Queries werden zu kompilierten Lambdas übersetzt und gegen das Analysis-Modell ausgeführt.

Output: eine Menge ausführbarer Regeln, die gegen das Analysis-Modell laufen können.

Daneben liegt CodeGuard.Dsl.LanguageServer, ein LSP-Server für die VS-Code-Extension. Er gibt IntelliSense für DSL-Property-Namen, prüft Syntax-Fehler live und schlägt Schema-Pfade vor.

3. Output (CodeGuard.Output)

Konvertiert Findings in das angeforderte Format. Text, JSON, SARIF oder GitHub-Annotations. Jeder Output-Formatter ist eine eigene Klasse, neue Formate sind isolierbar.

4. Core (CodeGuard.Core)

Orchestriert die anderen drei Schichten. Cache-Verwaltung, Threading, CLI-Parameter-Parsing, Konfigurations-Loading. Hier wird auch entschieden ob etwas inkrementell oder voll-frisch analysiert wird.

Distributionen

Daten- und Kontrollfluss

codeguard analyze .
    │
    ▼
 Core.Loader               (liest Solution + .codeguard config)
    │
    ▼
 Analysis.Loader           (parsed Solution mit MSBuild)
    │
    ▼
 Analysis.SyntaxScanner    (erkennt DateTime.Now, leere Catch-Blocks, ...)
    │
    ▼
 Analysis.Model            (Collections aufbauen)
    │
    ▼
 Dsl.RuleLoader            (liest alle .cgr Files)
    │
    ▼
 Dsl.Compiler              (LINQ-Queries -> Lambdas)
    │
    ▼
 Dsl.RuleEngine            (führt Regeln gegen Modell aus)
    │
    ▼
 Core.FindingsCollector
    │
    ▼
 Output.Formatter          (--output console|json|sarif|github)
    │
    ▼
 Stdout / Datei

Was diese Architektur ermöglicht

• Determinismus weil die Analyse zustandslos ist. Selber Input, selber Output.
• Mehrere Output-Formate ohne dass die Analyse-Schicht etwas davon weiß.
• Eigene Regelpakete weil die DSL die Schema-Stabilität als Vertrag hat. Wir brechen das Modell nicht zwischen Patches.