ca-marketplace-scraper/.ruler/00-LINT-RULES.md

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.