GauntletCI Documentation
website·Indexed 30 days ago
https://gauntletci.comGauntletCI is a local-first change risk engine for C# and .NET that analyzes pull request diffs to detect behavioral risks. It provides a comprehensive set of rules (GCI series) covering security, data integrity, async and concurrency, architecture and design, and observability and error handling. The tool can be integrated into CI/CD pipelines, editors, and AI assistants.
What's inside GauntletCI
- GauntletCI is a local-first change risk engine for C# and .NET. It analyzes pull request diffs to identify breaking changes and regressions before they are merged. Unlike a general linter or static analysis tool, it specifically evaluates whether a diff introduces behavior that is no longer properly validated, using 37 deterministic rules to flag issues such as behavior changes without test updates, breaking public API changes, and removed null guards.
Understand the 'Implicit Contract' risk in code diffs
The 'Implicit Contract' occurs when a piece of code (like a guard clause) provides safety that is never explicitly verified by a test because the guard itself is the coverage. If the guard is removed, the test suite remains green because no test was ever written to fail without that guard, creating a silent behavioral regression.// Before diff: the implicit contract if (user == null) return; Process(user.Name); // After diff: guard removed, tests still pass. Process(user.Name);Choose between AI-assisted review and deterministic risk analysis for PRs
When selecting a pull request review tool, distinguish between an AI assistant and a deterministic merge gate. AI-first tools (e.g., CodeRabbit) provide narrative comments, summarization, and coaching, which are useful for reviewer productivity but can be inconsistent due to the probabilistic nature of LLMs. In contrast, GauntletCI provides rule-backed findings tied to changed code, ensuring that the same commit produces the same result regardless of model state. Use deterministic analysis when the goal is to block known risky change patterns before merge.Understand GauntletCI's Behavioral Change Risk detection
GauntletCI is designed to identify 'Behavioral Change Risk'—changes that are syntactically correct and compile cleanly but introduce runtime risks. Unlike AI review tools that focus on style and intent, GauntletCI analyzes the staged diff to find logic shifts that often bypass human and AI reviewers, such as:
- Deletion of null guards
- Silent changes to exception paths (e.g., swallowing an exception)
- Modified API contracts
- Concurrency hazards and data-loss paths
Prevent NullReferenceExceptions with Guard Deletion Remote Use (GCI0059)
The GCI0059 rule detects instances where null or validation guards are removed from a method, but the guarded symbol continues to be used later in the same method. This prevents the reintroduction ofNullReferenceExceptionor invalid-state paths that might be missed during testing.// Triggers GCI0059: Guard removed, but 'order' is still accessed - if (order is null) throw new ArgumentNullException(nameof(order)); return order.Total; // Passes GCI0059: Guard is replaced by a safe return - if (order is null) throw new ArgumentNullException(nameof(order)); + if (order is null) return 0; return order.Total;Use GauntletCI Default Mode for local deterministic analysis
Default Mode provides deterministic local analysis with no network requirements. It enables 37 active deterministic rules, diff-based change detection, local AST analysis (Roslyn syntax trees), pre-commit hook integration, and CLI/config file support. No code, diffs, or analysis results leave the local machine. This mode is active by default and requires no additional setup.Enforce architectural boundaries with Architecture Layer Guard (GCI0035)
The Architecture Layer Guard (GCI0035) prevents architectural erosion by checking added directives against a set of configured forbidden import pairs. It ensures that layer boundaries (e.g., preventing a Domain layer from importing infrastructure-specific libraries like Entity Framework Core) are enforced at commit time rather than relying on manual documentation.// This would trigger GCI0035 if Microsoft.EntityFrameworkCore // is forbidden in the Domain layer: // src/MyApp.Domain/Order.cs using Microsoft.EntityFrameworkCore;Implement a deterministic architecture for AI code review
To maintain trust and repeatability in a CI/CD pipeline, separate the discovery of a finding from its explanation. A reliable AI code review system should follow this architecture:
- Deterministic Core: Use a deterministic analysis engine (e.g., static analysis, diff parsing) to identify structural changes, behavioral risks, or validation gaps. This ensures that the same input and configuration always produce the same finding.
- AI-Assisted Interpretation: Use an LLM to narrate, summarize, or explain the deterministic finding to the developer. The AI acts as the 'narrator,' not the 'reviewer of record.'
- Human-Owned Intent: The final decision on whether a finding is a bug, intentional, or irrelevant remains with the human developer.
This approach prevents 'debugging the reviewer'—where developers encounter different results for the same code—and ensures auditability for compliance.
[Deterministic Engine] -> Identifies: "Condition changed from non-null to non-null active; no test updated" [AI Layer] -> Explains: "This change narrows the accepted input set. If inactive records should be excluded, add a test to prove this behavior."Use GauntletCI as a deterministic PR risk gate
GauntletCI serves as a deterministic risk gate within the GitHub review process. Unlike probabilistic AI tools or broad static analysis, GauntletCI is designed to block merges when it detects specific behavioral or contract risks, such as:
- Changes in production behavior
- Removal of a public contract
- Introduction of unsafe async patterns
- Validation gaps
Detect resource exhaustion patterns with GCI0020
The GCI0020 rule identifies patterns that may lead to resource exhaustion vulnerabilities and denial-of-service (DoS) attacks. It specifically flags the removal of safeguards that bound resource use, including: timeout removal, iteration limit removal, resource limit increases, cleanup removal, and unbounded async operations.// Triggers GCI0020 (Removal of timeout handling or resource cleanup) try { await ProcessAsync(order); } - catch (TimeoutException) { } // OR - using var conn = new SqlConnection(cs); // Passes GCI0020 (Proper timeout and error handling) try { await ProcessAsync(order, TimeSpan.FromSeconds(30)); } + catch (TimeoutException ex) { _logger.LogError(ex); throw; }Understand Behavioral Change Risk (BCR)
Behavioral Change Risk (BCR) is a software risk category where a code modification alters the observable behavior of a system, but that change is not detected or asserted by the existing test suite. This creates a validation gap where the system's actual behavior diverges from what the tests are capable of verifying.
BCR occurs when two conditions are met:
- The modification alters observable behavior:
B(C + ΔC) ≠ B(C). - The behavioral delta (
ΔB) is not exercised and asserted by the test suiteTagainst the modified codebase.
Crucially, BCR is not always a defect; it is a validation gap. The risk is that the behavioral change has not been explicitly validated, regardless of whether the change was intentional or accidental.
- The modification alters observable behavior:
Use GauntletCI for automated Behavioral Change Risk detection
GauntletCI is a reference implementation designed to automate the detection of Behavioral Change Risk (BCR). It analyzes code diffs to identify structural patterns associated with BCR categories (e.g., identifying when a guard clause was removed or an exception handler was narrowed).
Unlike general static analysis tools (like Semgrep, CodeQL, or SonarQube) that analyze the full codebase, GauntletCI scopes its analysis specifically to the diff at the pre-commit stage. This allows developers to address behavioral shifts at the moment of lowest remediation cost. The tool surfaces the 'what' (the pattern), while the developer provides the semantic judgment on the 'why' (whether the change is intentional or acceptable).