ESLint warn severities and the CI --max-warnings gate: advisory alerts or errors-only policy?

ESLint documents three per-rule severities — off, warn, and error — set in eslint.config.js (flat config, the default in ESLint v9+) or a legacy .eslintrc file. The intent is that error fails the run while warn surfaces advisory findings, letting teams introduce new or stylistic rules without breaking existing code.

The friction sits between the two integrations consuming these severities. Editor extensions such as the VS Code ESLint extension render warn inline in the same squiggle channel as error, so a large warning backlog can become visual noise that developers learn to dismiss. In CI, the documented --max-warnings flag makes the process exit non-zero once total warnings exceed a threshold, but the count spans all linted files, so one noisy generated or vendored file can trip the gate unless excluded through ignores.

That leaves a policy decision ESLint itself does not prescribe: some teams adopt an errors-only setup where every rule is either enforced or off, arguing that ungated warnings inevitably decay into ignored noise.

• When does a warn severity paired with a --max-warnings ratchet produce better long-term signal than an errors-only policy?
• Should the CI warning budget be zero, or a tracked decreasing count during a rule rollout?
• What criteria should trigger promoting a rule from warn to error?