## CRITICAL: Lint Rules Are Sacred and Immutable

**ABSOLUTE PROHIBITION**: You are **FORBIDDEN** from modifying, disabling, or bypassing any lint rules, ESLint configurations, TypeScript compiler settings, or any other code quality enforcement mechanisms in this repository.

## Non-Negotiable Principles

### 1. Rules Must NEVER Be Changed

- **NO** adding `// eslint-disable` comments
- **NO** adding `// @ts-ignore` or `// @ts-expect-error` comments
- **NO** modifying `.eslintrc`, `eslint.config.js`, or any ESLint configuration files
- **NO** modifying `tsconfig.json` compiler options to silence errors
- **NO** modifying `biome.json`, `prettier.config.js`, `.oxlintrc`, or any formatter settings
- **NO** adding files to `.eslintignore` or exclude patterns
- **NO** downgrading errors to warnings or warnings to off
- **NO** adjusting rule severity or options

### 2. Fix the Root Cause, Not the Symptom

When encountering a lint error or type error:

1. **Attempt 1-10**: Fix the underlying code issue that violates the rule
   - Refactor the code to comply with the rule
   - Restructure the logic to avoid the violation
   - Use proper types and patterns that satisfy the linter
   - Redesign the approach entirely if needed
   - Consider alternative implementations
   - Review similar patterns in the codebase for guidance
   - Consult documentation for the library/framework being used
   - Try multiple different architectural approaches
   - Explore edge cases and alternative solutions
   - Exhaust ALL possible code-level fixes

2. **After 10+ Genuine Attempts**: If you have exhausted ALL reasonable code fixes and the error persists:
   - **STOP** and **ASK THE USER** for guidance
   - Present the specific rule violation
   - Explain what you've tried (all 10+ attempts)
   - Ask if there's a pattern you're missing or if an exception is warranted
   - **NEVER** make the decision to disable or modify rules yourself

### 3. Why Rules Exist

- Lint rules enforce consistency across the codebase
- They prevent bugs and anti-patterns
- They represent team decisions and conventions
- They ensure code quality and maintainability
- They are project-specific and carefully chosen

### 4. Common Scenarios and Correct Responses

#### Scenario: "Unused variable" error
- ❌ WRONG: Add `// eslint-disable-next-line no-unused-vars`
- ✅ RIGHT: Remove the unused variable or use it properly

#### Scenario: "any type" error
- ❌ WRONG: Add `// @ts-ignore` or change to `unknown` just to silence
- ✅ RIGHT: Define proper types that accurately represent the data

#### Scenario: "Missing dependency in useEffect" warning
- ❌ WRONG: Add `// eslint-disable-next-line react-hooks/exhaustive-deps`
- ✅ RIGHT: Add the missing dependency or restructure to avoid the issue

#### Scenario: "Type errors in third-party library"
- ❌ WRONG: Use `@ts-expect-error` or cast to `any`
- ✅ RIGHT: Install proper type definitions, create a typed wrapper, or use proper type assertions

#### Scenario: "Complexity too high" error
- ❌ WRONG: Disable the complexity rule
- ✅ RIGHT: Refactor the function into smaller, simpler functions

### 5. Enforcement Priority

Lint rules have **MAXIMUM PRIORITY**. They outrank:
- Personal coding preferences
- Convenience
- Speed of implementation
- Desire to "just make it work"

### 6. Remember

**You are here to serve the repository's conventions, not to modify them.**

If you find yourself thinking "it would be easier to just disable this rule," that is **EXACTLY** when you must **NOT** do it.

## Summary

1. ❌ NEVER disable, ignore, or modify lint rules
2. ✅ ALWAYS fix the code to comply with rules
3. ✅ Try 10+ different approaches to fix the root issue
4. ✅ ASK THE USER if all code-level fixes fail
5. ❌ NEVER act autonomously on rule modifications

**These are not guidelines. These are absolute requirements.**
