demo(18-dependabot-api-drift): 18 — Dependabot PR slips a public API change in next to a package bump

[EricCogen]

18 — Dependabot PR slips a public API change in next to a package bump

Expected verdict: ❌ Fails — GauntletCI should fire GCI0052 (Dependency Bot API Drift).

What changed

This PR is shaped like a routine Dependabot update — bumps a
package version in OrderService.csproj — but quietly also changes
a public method in PricingService.cs:

• src/OrderService/OrderService.csproj — adds a new
  <PackageReference> for Polly (the "lockfile-equivalent" change a
  bot would author).
• src/OrderService/Pricing/PricingService.cs — adds a new public
  method ApplyShipping, expanding the public surface of the
  PricingService.

Why this is risky

• Dependency-bot PRs get rubber-stamped by reviewers far more often
  than human-authored PRs because they're expected to be mechanical
  package bumps.
• A bot account that has been compromised — or a misconfigured bot
  template — can use that low-scrutiny channel to slip in production
  code changes that would normally require deeper review.
• Even when benign, an API surface change wedged into a "chore: bump
  Foo to 1.2.3" PR is invisible to consumers downstream and ships in
  the next release without an API-change review.

How GauntletCI catches this

GCI0052 Dependency Bot API Drift fires only when all three
conditions hold inside one PR:

1. The PR's GITHUB_ACTOR matches a known dependency bot
   (dependabot[bot], renovate[bot], snyk-bot, snyk[bot]).
2. The diff touches a lockfile or *.csproj.
3. The diff also adds a public method signature in a *.cs file.

In real CI, condition (1) is set automatically by GitHub Actions when
Dependabot is the PR author. To simulate that here without
running an actual bot account, the base .github/workflows/gauntlet.yml
contains a single conditional that only fires for this scenario's
branch:

GITHUB_ACTOR: ${{ github.head_ref == 'demo/18-dependabot-api-drift'
  && 'dependabot[bot]' || github.actor }}

Every other PR in the repo is analyzed under its real actor — only this
one demo branch is treated as if Dependabot opened it.

How to fix it

• Split the PR — bots should only touch dependency manifests; code
  changes should come from a human-authored PR with a real review.
• Lock down the bot's permissions or branch-protect the public-API
  surface so bot identities can't push behavior changes.
• Add a CODEOWNERS rule routing public-surface files to a human
  reviewer regardless of who opens the PR.

[github-actions]

GauntletCI found issues in this PR. See inline comments for details.

[github-actions]

GCI0052 — Dependency Bot API Drift

Dependency bot PR introduces a public API change — verify backward compatibility

Evidence:

src/OrderService/Pricing/PricingService.cs line 28: public Money ApplyShipping(Money subtotal, Money shipping)

⚠️ Why it matters: Automated dependency bots (Dependabot, Renovate, Snyk) should not be changing public method signatures. This may indicate a transitive dependency pulled in an unexpected API change or a bot misconfiguration.

💡 Suggested action: Review the public API change carefully. If unintentional, revert the non-lockfile changes. If intentional, use a human-authored PR instead.

_{Confidence: Medium | Severity: Block}

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 3ab7160d67

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Keep dependency-bump commits free of public API drift

This commit adds a new public method (PricingService.ApplyShipping) alongside a package manifest change, which expands the service’s externally consumable API in what appears to be a mechanical dependency update. That coupling is risky because dependency-bot/style bump PRs typically get lighter review, so behavior/API changes can ship without the normal API-review path; this should be split into a separately reviewed feature change or kept non-public.

Useful? React with 👍 / 👎.