Automated formatting and linting as a team contract

Goal

Spend review attention on design and correctness by making layout and mechanical style a solved, automated problem.

Prerequisites

A formatter and a linter for each language in the repository, runnable from the command line with the configuration stored in the repository.

Steps

1. Add an .editorconfig for indentation, line endings and trailing whitespace so that editors agree before any tool runs.
2. Choose one formatter per language and run it on the whole codebase in a single commit that contains nothing else.
3. Enable linter rules in stages: start with correctness rules (unused imports, undefined names, unreachable code), then add style rules the team accepts. PEP 8 itself says its guidance yields to consistency within a project.
4. Run both tools in the pipeline as a required check and, optionally, in a pre-commit hook.
5. Treat rule changes like code changes: propose, review, apply to the whole tree in one commit.

Expected result

No review comments about spacing or import order; formatting diffs disappear from feature changes; new contributors get immediate, impersonal feedback from the tools.

Limits and test basis

Formatters decide layout, not naming or structure; those remain review topics. A linter with hundreds of enabled rules produces noise that people learn to ignore. The cited tools are examples; the contract matters more than the tool.