See exactly how a risky diff becomes a GauntletCI finding
This before/after view uses the role-based authorization scenario from PR #299 to show the pieces reviewers need: original behavior, changed behavior, diff evidence, rule mapping, and the next action before merge.
Illustrative example
This is a static walkthrough, not a live analyzer. The scenario links to the public demo PR so you can inspect the full baseline and regressed files separately.
Reviewer summary
src/OrderService/Controllers/AdminPolicyController.Regressed.cs:20
GCI0012: Security Risk
Endpoint authorization changed from a framework policy attribute to inline branch logic.
2
Block findings
1
Protected file
1
Suggested fix
Before: framework-level policy
using Microsoft.AspNetCore.Authorization;
using Microsoft.AspNetCore.Mvc;
[HttpPost("settings")]
[Authorize(Policy = "AdminOnly")]
public async Task<ActionResult> UpdateSystemSettings(
SystemSettingsRequest request,
CancellationToken ct)
{
await _settingsService.UpdateSettingsAsync(request, ct);
return Ok();
}After: inline claim branch
using Microsoft.AspNetCore.Mvc;
[HttpPost("settings")]
public async Task<ActionResult> UpdateSystemSettings(
SystemSettingsRequest request,
CancellationToken ct)
{
if (User?.HasClaim("role", "admin") ?? false)
{
await _settingsService.UpdateSettingsAsync(request, ct);
}
return Ok();
}Diff evidence
The changed lines explain the risk
The visualizer keeps literal + and - markers so the signal is readable without relying only on red and green highlighting.
Example findings
Authorization logic changed on a protected endpoint. The framework-level policy attribute was removed and replaced with inline claim logic that returns success even when the update does not run.
src/OrderService/Controllers/AdminPolicyController.Regressed.cs:20
Runtime behavior changed without a corresponding test update in the diff. The reviewer needs evidence that unauthorized settings updates are rejected rather than silently returning success.
Suggested next action
Restore the AdminOnly policy attribute or return Forbid() when the inline claim check fails.
Add tests that prove non-admin users cannot update system settings through the changed path and do not receive a success-shaped response.
If the bypass is intentional, document the business rule in the PR and update policy tests so the merge decision has durable evidence.
Connect the visualizer to the full workflow
Use this page to understand the finding, then inspect the real demo PR, rule docs, and GitHub output surfaces your team can wire into required checks.