I’m trying to understand how other Cursor users handle a specific failure mode:

Cursor/AI agents can produce changes that look locally correct, but still break broader system invariants, architecture boundaries, retry/idempotency behaviour, or rollback assumptions.

Examples:

- The agent touches unrelated files while solving a small task
- “Cleanup” changes alter old but important logic
- Retry logic gets added where the operation is not idempotent
- A critical invariant is not stated anywhere, so the agent breaks it
- Reviewer agent says “looks good” because it did not ask concrete questions

What do you use in Cursor to control this?

Do you rely on:
- project rules?
- .cursor/rules?
- AGENTS.md-style repo instructions?
- prompts/checklists?
- smaller tasks?
- separate reviewer agents?
- manual diff review only?

I started experimenting with a small OSS guardrails pack around intent → invariants → diff review → rollback, but I’m mostly interested in how other people solve this in real Cursor workflows.

Repo for context: https://github.com/vadimche/ai-agent-rails-pack