docs: require regression provenance in PR reviews

.agents/skills/openclaw-pr-maintainer/SKILL.md

@@ -138,7 +138,9 @@ Output only qualifying candidates, with: ref, surface, proof, cause, fix sketch,
 
 - Start every PR review with 1-3 plain sentences explaining what the change does and why it matters. Put this before `Findings`.
 - Then list findings first. If none, say `No blocking findings` or `No findings`.
-- Always answer: bug/behavior being fixed, PR/issue URL and affected surface, and best-fix verdict.
+- Always answer: bug/behavior being fixed, PR/issue URL and affected surface, provenance for regressions when traceable, and best-fix verdict.
+- For bug/regression fixes, include a compact `Provenance:` line after cause/root-cause when a bounded history pass can identify it. Use `git log -S/-G`, `git blame`, linked PRs/issues, and tests; separate author, committer/merger, and current PR author when they differ.
+- Phrase provenance as `introduced by`, `made visible by`, or `carried forward by`, with confidence (`clear`, `likely`, `unknown`). If unclear, say what evidence is missing instead of guessing. For features, docs, and refactors, use `Provenance: N/A` or omit it when no broken behavior is being fixed.
 - Keep summaries compact, but include enough proof that the verdict is auditable without rereading the PR.
 
 ## Read beyond the diff
@@ -160,8 +162,9 @@ Output only qualifying candidates, with: ref, surface, proof, cause, fix sketch,
 - Before landing, require:
   1. symptom evidence such as a repro, logs, or a failing test
   2. a verified root cause in code with file/line
-  3. a fix that touches the implicated code path
-  4. a regression test when feasible, or explicit manual verification plus a reason no test was added
+  3. provenance for regressions when traceable by bounded git/PR history
+  4. a fix that touches the implicated code path
+  5. a regression test when feasible, or explicit manual verification plus a reason no test was added
 - If the claim is unsubstantiated or likely wrong, request evidence or changes instead of merging.
 - If the linked issue appears outdated or incorrect, correct triage first. Do not merge a speculative fix.
 - If Crabbox/E2E proof is blocked, say exactly why and use the closest available

AGENTS.md

@@ -81,7 +81,7 @@ Skills own workflows; root owns hard policy and routing.
 - No unsolicited PR comments/reviews/labels/retitles/rebases/fixups/landing. Exception: close/duplicate action that needs a reason comment after explicit close/sweep/landing request.
 - Maintainer decision closes the cluster: if deciding reported behavior/proposed fix is not planned, comment+close all directly associated open issues/PRs unless explicitly told to keep one open. Associated means linked PRs/issues, duplicates, companion workaround PRs, and the canonical issue for the rejected behavior.
 - Do not leave associated issues open for hypothetical future repros. Close with rationale; ask for a new issue or reopen only if concrete new evidence appears. Close comment states: decision, why, supported alternative, and what evidence would change the decision.
-- PR review answer: bug/behavior, URL(s), affected surface, best-fix judgment, evidence from code/tests/CI/current or shipped behavior.
+- PR review answer: bug/behavior, URL(s), affected surface, provenance for regressions when traceable, best-fix judgment, evidence from code/tests/CI/current or shipped behavior.
 - Issue/PR final answer: last line is the full GitHub URL.
 - Changelog: PR landings/fixes need one unless pure test/internal. Do not mention missing changelog as a review finding; Codex handles it during fix/landing.
 - PR verification: before merge, post exact local commands, CI/Testbox run IDs, before/after proof when used, and known proof gaps.