ESLint: test rules against real code and team habits

Run ESLint on a representative repository, including JavaScript or TypeScript patterns the team writes often. Start with a small ruleset that catches actual defects, then inspect every new warning and false positive. Make one intentional violation and confirm local editor and CI results agree.

A linter should make review more focused, not create a backlog of cosmetic noise. Version the configuration, document exceptions, and separate formatting from correctness rules where possible. The adoption test is whether developers fix the findings with confidence.