The higher-leverage version of your problem: a rule that a tool can enforce should be enforced by the tool, not written in a document.
Of your three complaints, two are almost certainly automatable:
The wrong logging library, a lint rule banning the import, with a message saying what to use instead. Then it is caught in seconds, by the same check that catches it for humans, and the correction arrives as an error rather than as a review comment.
Tests in the wrong directory, a structural check, or simply a test runner configuration that only looks in the right place, so misplaced tests visibly do not run.
Comment density is a taste thing and belongs in the document.
The reason this matters beyond convenience: prose instructions compete with everything else in the context, and a check does not. A failing command is unambiguous and self-correcting. A line in a document is one instruction among fifty.
It also fixes the problem for the humans on the team, and it keeps working when the model changes.
So the order I would go in: automate what is automatable, write down what is genuinely contextual, and keep the written part short enough that it is read rather than skimmed.