[BUG] Claude Code pushed broken code to production 4 times without verifying fixes, breaking live SaaS application

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

aClaude Code (Opus 4.6, 1M context) implemented a feature sprint (Sprint 14 - checkout authentication for a digital menu), committed and pushed to production without running its own review agent first. The code introduced a circular dependency that crashed the entire public-facing digital menu (cardapio.gestly.com.br).

When the user reported the production error, Claude attempted to fix it twice, each time committing and pushing to production without confirming the fix actually resolved the issue. This resulted in 4 consecutive broken commits in production over the course of a single session.

Key failures in Claude's decision-making:

Skipped review before commit: The user explicitly instructed "a cada correção, peça a um agente de review revisar tudo, depois commit e push" (run review agent after each fix, then commit and push). Claude followed this for the first task (audit) but skipped it entirely for Sprint 14 — the most complex change of the session.

Pushed untested fixes to production: When the circular dependency error appeared (ReferenceError: Cannot access 'T' before initialization), Claude guessed at the cause and pushed fixes without verifying they worked. This happened twice.

Failed to identify root cause: Claude changed barrel imports to direct imports (commit 1), then moved types to a shared layer (commit 2), but neither fix resolved the runtime circular dependency. Instead of stopping to investigate properly or reverting, Claude kept pushing commits.

No revert-first strategy: When production was broken, the correct action was to revert immediately and investigate later. Instead, Claude kept trying forward-fixes, leaving production broken for an extended period.

What Should Happen?

aClaude should ALWAYS run its review agent before committing, especially when the user explicitly requested it.

When a commit breaks production, Claude should suggest reverting FIRST before attempting fixes.

Claude should NEVER push a fix to production without confirming the fix resolves the issue (at minimum: build succeeds AND the specific error is verified as resolved).

Claude should detect circular dependencies before adding new imports, especially when modules are re-exported through barrel files (index.ts).

When Claude cannot confirm a fix works, it should tell the user "I'm not sure this will fix it" rather than pushing to production.

Error Messages/Logs

index-8jyPBseV.js:1005 [ERROR] ReferenceError: Cannot access 'T' before initialization
    at (anonymous) @ index-8jyPBseV.js:1005
    at (anonymous) @ index-8jyPBseV.js:16
    at ku @ vendor-react-B8h31Ehh.js:32
    at Ca.u.componentDidCatch.n.callback @ vendor-react-B8h31Ehh.js:32

Root cause: Circular dependency introduced when MenuCheckout.tsx was modified to import useCustomerAuth from @/contexts/customer. The dependency chain:

MenuCheckout → @/contexts/customer → CustomerAuthContext
  → @/repositories/cardapio (barrel index.ts) → CustomerRepository
    → @/contexts/customer/types → CYCLE

This chain did not exist before Sprint 14 because MenuCheckout previously received customer data via props instead of importing the context directly.

Steps to Reproduce

a1. Have a React + Vite + Supabase project with barrel exports (index.ts files that re-export all modules)

1. Ask Claude to implement a feature that requires adding new imports between modules that are connected through barrel files
2. 3. Ask Claude to "review each change, then commit and push"
3. 4. Observe that Claude:
4. - Skips the review step for complex changes
5. - Pushes to production (main branch) without verifying the change works at runtime
6. - When the change breaks production, pushes additional "fix" commits without verifying they resolve the issue

The core issue is behavioral: Claude prioritized speed over correctness, violated the user's explicit workflow instructions, and failed to adopt a revert-first strategy when production was broken.

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

2.1.79

Claude Code Version

Running inside VSCode native extension environment

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

VS Code integrated terminal

Additional Information

This is not a code generation quality issue — Claude can write correct code. The problem is in decision-making and process discipline:

Claude has the capability to run review agents, detect circular dependencies, and verify fixes before pushing. It chose not to use these capabilities when it mattered most.

The user had to report the production error. Claude should have caught the circular dependency during implementation or review.

After 2 failed fix attempts, Claude still did not suggest reverting to restore production. The user had to threaten a revert before Claude acknowledged the approach was wrong.

Commits involved (chronological):

• 27094a0 — Sprint 14 implementation (introduced circular dependency) — NO REVIEW RUN
• - b7430b5 — Review fixes (review ran AFTER commit, found critical bug)
• - - 6a703fb — Fix attempt 1: change barrel import to direct import — DID NOT RESOLVE
• - - - 0f91590 — Fix attempt 2: move types to shared layer — DID NOT RESOLVE

All 4 commits were pushed to main_gestly which auto-deploys to Vercel production.

Impact: Public-facing digital menu (cardapio.gestly.com.br) completely broken for end users. White screen with JavaScript error. Duration: from commit 27094a0 until resolution (still unresolved at time of report)

OS Details: Windows 10 Home Single Language 10.0.19045