Clarify validation evidence provenance

Author: mchwang

AGENTS.md

@@ -44,6 +44,7 @@ Every reproduced race requires a failing-before and passing-after regression. As
 - Run final validation against the exact pushed head after the last change.
 - Report current test counts separately from historical milestone counts.
 - Before requesting automated review, report the current head, CI state, mergeability, unresolved threads, and deferred follow-up issues.
+- In evidence records, label cited commits as baselines, intermediate checkpoints, or validated heads. Keep final exact-head results in a place that can name the resulting commit, such as the PR body or CI record.
 - Reproduce summary-only review concerns or turn them into a concrete follow-up issue. Do not repeatedly patch vague wording without a failure case.
 - A validation fixture for a summary-only concern must assert the disputed intermediate representation or state before using a downstream outcome as evidence that the concern was exercised.
 - For each review round, record what changed, what was declined and why, and the regression evidence. Re-request review until a round returns no new findings.

docs/experiments/review-summary-edge-cases.md

@@ -1,6 +1,6 @@
 # Review-summary edge-case validation (#10)
 
-Validated on 2026-09-23 from `5a2685c`, before selecting real issues for the plan-indexed review experiment. These were summary-only concerns from PR #9, not reproduced defects. No production behavior changed during this validation.
+Validated on 2026-09-23 before selecting real issues for the plan-indexed review experiment. The validation branch started from baseline `5a2685c`; final exact-head results are recorded in PR #17. These were summary-only concerns from PR #9, not reproduced defects. No production behavior changed during this validation.
 
 ## Renamed-file reassignment