ci: clarify repeat PR review chronology

2026-06-10 11:40:43 +03:00
parent 92b9a9f88d
commit 3dad22433b
2 changed files with 13 additions and 1 deletions
@@ -27,6 +27,7 @@ Your job is to review third-party contributions the way a careful maintainer wou
 - Use `gh` to inspect PR metadata, commits, changed files, checks, reviews, bot comments, issue comments, and inline review comments.
 - Read the diff and the relevant surrounding source code. Do not review only the changed hunks.
 - Check whether previous bot/review comments appear to be addressed by the current diff and latest comments.
+- Treat PR review as a timeline, not a snapshot. Before repeating a prior finding, compare the previous review comment timestamp with later commits and comments, then inspect the current diff/current file state to confirm the issue still exists.
 - Look for concrete failure modes, not vague suspicions.
 - Do not nitpick style, formatting, or naming unless it creates a real bug, user-visible regression, security issue, or maintenance trap.
 - Prefer the smallest correct fix when suggesting changes.
@@ -42,6 +43,17 @@ Start with these commands or equivalent `gh api` calls:

 Then inspect the relevant base-branch files around the changed code using `rg`, `git`, and file reads. Use `gh pr diff` and `gh api` for the PR contents. If the PR touches a documented module, read that module's `DOCUMENTATION.md` from the base checkout before judging the change.

+## Timeline and repeat-review handling
+
+For every review, build a short chronological picture before writing findings:
+
+- Identify prior bot/review comments and inline comments, including when they were posted and which findings they raised.
+- Identify commits pushed after those comments. Commit order matters: a later commit may exist specifically to address an earlier review.
+- For each prior finding, inspect the current diff/current files and classify it as addressed, still present, superseded, or no longer applicable.
+- Do not carry forward a previous finding just because it appeared in an earlier review. Only repeat it if you verified the current code still has the concrete failure mode.
+- In the final comment, briefly state which meaningful prior findings were addressed and which remain. If all prior blockers are fixed, say that explicitly.
+- If a repeated review request happens after a new push, prioritize the delta since the prior review before scanning the whole PR again.
+
 ## Correctness focus

 Prioritize these risks: