ci: clarify repeat PR review chronology

.github/workflows/pr-review.yml

@@ -149,7 +149,7 @@ jobs:
         run: |
           opencode run --agent pr-review "A pull request in the OpenChamber repository needs code review.
 
-          This may be a repeated review request. Before writing a new review, inspect prior PR comments, bot comments, reviews, and inline comments via GitHub, then determine which previous findings are already addressed by the current diff.
+          This may be a repeated review request. Before writing a new review, inspect prior PR comments, bot comments, reviews, inline comments, and the commit timeline via GitHub. Compare prior findings against commits pushed after those comments, then only repeat findings that still exist in the current diff/current file state.
 
           PR: $PR_URL
           Number: $PR_NUMBER

.opencode/agent/pr-review.md

@@ -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: