comments-about-code-not-changelisted

# Comments about the code, not the change ## Purpose A source comment is read by someone opening the file cold in a year — not by someone following your PR. So it must describe what the code *does and why*, in the present tense, as if it were always this way. The moment a comment references the change that produced it — an issue number, a PR number, a maintainer's @handle, "the previous code did X", "close-enough mistake", "aligned per #NNNN" — it stops being documentation and becomes change-narrative that belongs in the PR and commit, where it is contextual and doesn't rot. Maintainers across projects call this out as a top AI tell; it's a cheap, high-frequency source of "this reads like slop". Exception: a **test** that guards a specific regression MAY cite the issue number in a comment — that links the test to what it protects, and projects do this. Even there, keep it to the ticket ref, not a change-narrative or an @handle. ## When to use - Before committing any code change to a repo you don't own. - Any time you write a comment that only makes sense to someone reading the PR. ## When NOT to use Docstrings/comments that explain *behavior* — even long ones — are fine; this only bans change-narrative (issue#, @handle, "previously"), not thorough documentation. ## The practice (checklist) - [ ] Write comments in the **present tense**, describing behavior and the reason for it — as if the code were always this way. - [ ] Keep OUT of source: issue numbers, PR nu