94 lines
3.8 KiB
Markdown
94 lines
3.8 KiB
Markdown
## 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.**
|