Reject changes the codebase does not need, even when the code is good

Clean code can still be the wrong change. The guide notes that a reviewer can turn down a change that adds a feature the system does not want, even if the change is well designed.

Common examples:

• A new configuration option nobody asked for, which every future change must now support
• A general framework built for one use case
• A feature that belongs in another service or another team's library

Unneeded code is not free: it must be read, tested, secured and maintained. When you say no, say why, and suggest what the author could do instead. If this keeps happening, the team should agree on direction before people write code, for example in a short design note or issue discussion.