AiNetLinter ist ein .NET 10 CLI-Tool, das C#-Code per Roslyn-Syntaxanalyse gegen konfigurierbare Qualitätsregeln prüft. Die Regeln sind auf den agentischen Entwicklungsworkflow mit AI-Tools wie Cursor, Claude Code oder GitHub Copilot ausgelegt — mit dem Ziel, die Fehlerrate autonomer Agenten beim Bearbeiten von C#-Code zu senken. Die wissenschaftlichen Grundlagen der Regelauswahl sind in der Design-Rationale dokumentiert.
Das Tool läuft in zwei unabhängigen Modi:
| Modus | Was es tut |
|---|---|
| CLI-Batch-Modus | Ein Lint-Lauf gegen eine Solution: Markdown-Report auf stdout, CI-tauglicher Exit-Code, optionaler Auto-Fixer für triviale Verstöße. |
MCP-Server-Modus (--mcp-server) |
Stdio-basierter MCP-Server, der dieselbe Roslyn-basierte Solution-Analyse als 14 einzeln abfragbare Tools (Symbolsuche, Referenzen, Impact-Analyse, Lint-Status u. a.) direkt in einen laufenden AI-Coding-Agenten einbindet, statt nur einen fertigen Report auszugeben. |
Beide Modi teilen sich dieselbe Analyse-Engine und dieselbe rules.json-Konfiguration.
AiNetLinter ist kein Ersatz für Compiler oder Tests — es setzt dort an, wo Build und Tests bereits grün sind:
dotnet build ✓
dotnet test ✓
ainetlinter ← hier
Der Linter prüft keine Syntaxfehler oder Laufzeitverhalten, sondern Designqualität: Komplexität, KI-taugliche Codestruktur, Architektur-Constraints.
ainetlinter --config rules.json --path ./src/MeinProjekt.slnxDer Linter gibt einen Markdown-Report auf stdout aus und beendet sich mit Exit-Code 0 (keine neuen Verstöße) oder 1 (Verstöße gefunden — CI-tauglich).
Die eingebauten Discovery-Commands ermöglichen einem KI-Agenten, das Tool explorativ zu verstehen und eigenständig in ein Projekt zu integrieren — ohne Vorab-Konfiguration durch den Entwickler.
# Tool erkunden (kein --path nötig):
ainetlinter --list-rules
ainetlinter --list-evals
ainetlinter --describe-rule EnforceSealedClasses
ainetlinter --docs configuration
# Eval-Audit-Prompts assemblieren (inkl. frischer Evidenz und Spezifikation):
ainetlinter --eval naming-drift --path ./src/ --spec README.md > prompt.md
# Lint-Lauf:
ainetlinter --config rules.json --path ./src/MeinProjekt.slnx
# Auto-Fix für triviale Verstöße (sealed, nullable, PascalCase):
ainetlinter --config rules.json --path ./src/ --fix --check # Dry-Run: zeigt Anzahl, schreibt nichts
ainetlinter --config rules.json --path ./src/ --fixTypischer Einstieg: AiNetLinter in ein eigenes Verzeichnis außerhalb des Projekts installieren (z. B. C:\Tools\AiNetLinter\). Das Tool bringt mehrere Dateien mit, lässt sich so von mehreren Projekten gleichzeitig nutzen, und Updates sind an einer einzigen Stelle erledigt. Den Pfad zur Exe einem Agenten im Projektkontext übergeben — dieser exploriert das Tool über die Discovery-Commands und integriert es eigenständig, z. B. als Schritt in einem Test- oder CI-Skript.
Vollständige Agent-API-Referenz (alle Flags, Workflows, Error-Format): Docs/agent-api.md. Schritt-für-Schritt-Integrationsanleitung (Verzeichnisstruktur, Baseline, Agent-Regeln-Sync): Docs/integration.md.
ainetlinter --mcp-server # sucht .sln/.slnx im aktuellen Verzeichnis
ainetlinter --mcp-server --path ./src/MeinProjekt.slnx # explizite Ziel-SolutionDer Server lädt die Solution einmal beim Start über MSBuildWorkspace und hält sie über die Prozesslaufzeit resident — Tool-Calls arbeiten gegen den geladenen Zustand statt gegen wiederholte Disk-Scans, und werden bei Dateiänderungen inkrementell aktualisiert (Datei-mtime + SHA-256-Hash-Vergleich, kein Komplett-Reload).
| Tool | Zweck |
|---|---|
find_symbol |
Klassen/Methoden/Properties/Interfaces per Namensmuster finden |
find_references |
Aufrufstellen eines Symbols (optional transitiv über depth) |
get_impact |
Betroffene Call-Sites für uncommittete Änderungen oder ein Symbol |
get_type_hierarchy |
Basisklassen, Interfaces, abgeleitete Typen, heuristische DI-Registrierungen |
get_file_skeleton |
Struktur-Skelett einer Datei (Signaturen ohne Bodies) |
get_symbol_body |
Source-Body eines einzelnen Symbols per stabiler ID |
get_index_scope |
Dateityp-Aufschlüsselung der geladenen Solution |
get_hotspots |
Dateien nahe oder über dem MaxLineCount-Limit |
metrics_tree |
ASCII-Baum mit aggregierten Werten pro Verzeichnisknoten (Code-Größe, Kommentaranteil, Lint-Verstöße, Komplexität), Ebene für Ebene explorierbar |
get_violations |
Aktuelle Lint-Verstöße für einen Scope |
safeguard |
Deterministischer 0–10-Qualitätsscore inkl. Pass/Fail gegen einen Schwellenwert |
search_pattern |
Text-/Regex-Suche über alle Dateitypen (Fallback für Nicht-C#-Treffer) |
reload_config |
rules.json zur Laufzeit neu einlesen, ohne Server-Neustart |
get_server_health |
LoadState, geladene Solution/Config, Uptime, Call-Statistik |
Registrierung im MCP-Host (Claude Code, Cursor, eigene Agent-Loops):
{
"mcpServers": {
"ainetlinter": {
"command": "ainetlinter",
"args": ["--mcp-server"]
}
}
}Vollständige Tool-Referenz (Parameter, Trunkierung, Error-Codes, Call-Log): Docs/agent-api.md#mcp-server-modus. Registrierungs-Anleitung inkl. Mehrdeutigkeits-Behandlung und Tool-vs-rg-Empfehlung: Docs/integration.md#mcp-server-registrieren.
| Regel/Feature | Zweck |
|---|---|
Codebase-Landkarten & Evals (--map, --eval) |
Generiert strukturierte Markdown-Übersichten (vocabulary, structure, hotspots, skeleton) oder vollständig assemblierte LLM-Audit-Prompts mit frischer Evidenz für Drift-Audits. |
Baseline / Ratchet (--baseline) |
Friert bestehende Verstöße per SHA-256 ein — nur geänderte Dateien werden geprüft. Ermöglicht den Einsatz in Legacy-Projekten mit bestehenden Verstößen, ohne diese vorher beheben zu müssen. |
AI-Context-Footprint (MaxAIContextFootprint) |
Misst die transitiven Codezeilen, die ein KI-Modell für eine Klasse laden müsste. Direkte Metrik für Kontextbudget-Verbrauch im agentischen Workflow. |
Phantom-Dependency-Ban (DetectAndBanPhantomDependencies) |
Verbietet nicht auflösbare Namespaces und Reflection-Lade-APIs. |
Komplexitätsgrenzen (MaxCyclomaticComplexity, MaxCognitiveComplexity) |
McCabe- und SonarSource-Kognitiv-Komplexitätsmetriken pro Methode. |
Project Overrides (ProjectOverrides) |
Projektscharfe Regelanpassungen (z. B. *.Tests mit anderen Limits) statt einer einzigen Konfiguration für alle Projekte. |
Compound-Suppressions (CompoundSuppressions) |
Kontextabhängige Regelunterdrückung inkl. SeverityOverride: "warning" — Verstöße in konfigurierten Szenarien können auf Warning herabgestuft werden, ohne den Build zu blockieren. |
LINQ-Kettenlänge (MaxLinqChainLength) |
Begrenzt die Anzahl verketteter LINQ-Methoden pro Ausdruckskette. Konfigurierbare Whitelist für Builder-Ketten. |
Globales Scope-Filtering (--project, --namespace) |
Eingrenzung der Analyse auf bestimmte Projekte oder C#-Namespaces (inkl. Wildcard-Unterstützung und Ausschluss-Shortcut für Test-Projekte). |
Suppression-Bypass (--ignore-suppressions) |
Umgeht Code-Unterdrückungen (disable all und inline disable [Rule]) dynamisch beim Linter-Lauf für konfigurierte Sprachklassen (all, cs/c#, razor, js, css). |
| Web-Asset-Linting (CSS, JS, Razor) | Analyse für CSS (ExCSS), JS (Esprima) und Razor: Dateigrößen-Limits, ES6-Modul-Pflicht, Verbot globaler window-Zuweisungen, HTML-Verschachtelungstiefe, Control-Flow-Blöcke, Komponenten-Parameter, Ternaries in HTML-Attributen. Opt-in über Web.IsEnabled = true. |
Vollständige, aktuelle Regel-Liste: ainetlinter --list-rules. Vollständige Konfigurationsreferenz: Docs/configuration.md.
Alle Dokumente sind in die Binary eingebettet und ohne Netzzugriff per ainetlinter --docs <name> abrufbar (z. B. ainetlinter --docs agent-api).
| Dokument | Inhalt |
|---|---|
| Docs/agent-api.md | Agent-API: alle CLI-Flags, Workflows, Error-Format, Discovery-Commands, MCP-Tool-Referenz |
| Docs/configuration.md | Vollständige Konfigurationsreferenz (rules.json-Schema, alle Regeln und Defaults) |
| Docs/integration.md | Schritt-für-Schritt-Integration in ein bestehendes Projekt, MCP-Server-Registrierung |
| Docs/rationale.md | Design-Entscheidungen & wissenschaftliche Grundlagen |
| Docs/ROADMAP.md | Entwicklungshistorie nach Epics |
AiNetLinter — Quellcode, Changelog und Issues auf GitHub.