From 6167e1bbf1f50e07fb7d348700f5ba792ea19e78 Mon Sep 17 00:00:00 2001 From: teihin Date: Wed, 29 Jul 2026 11:37:36 +0800 Subject: [PATCH] Add reviewer evidence checklist --- README.md | 1 + docs/reviewer-evidence-checklist.md | 91 +++++++++++++++++++++++++++++ 2 files changed, 92 insertions(+) create mode 100644 docs/reviewer-evidence-checklist.md diff --git a/README.md b/README.md index b6e7db7..7bf4593 100644 --- a/README.md +++ b/README.md @@ -86,6 +86,7 @@ value-encoding rules, and the no-real-user-data guarantee. - [Contributor Self-Review Form](docs/contributor-self-review-form.md) — **mandatory self-review** covering requirements, implementation, tests, CI, documentation, and known limitations - [Local Deployment Guide](docs/local-deployment.md) — deployment assumptions, environment variables, Makefile reference, Soroban CLI usage, and common errors - [Reviewer Checklist](docs/reviewer-checklist.md) — standardized quality and security checklist for PR reviewers +- [Reviewer Evidence Checklist](docs/reviewer-evidence-checklist.md) — maintainer-side evidence checklist for scope, implementation quality, tests, CI, docs, acceptance criteria, and evaluation risk - [Contributor Experience Review](docs/contributor-experience-review.md) — known onboarding friction and follow-up items ## CI & Contributing diff --git a/docs/reviewer-evidence-checklist.md b/docs/reviewer-evidence-checklist.md new file mode 100644 index 0000000..05f05bf --- /dev/null +++ b/docs/reviewer-evidence-checklist.md @@ -0,0 +1,91 @@ +# Reviewer Evidence Checklist + +This checklist helps Aegis Contracts maintainers decide whether a pull request +has enough evidence to be considered complete and evaluation-ready. It is a +review aid, not a replacement for the contributor-facing +[PR Evidence Checklist](./pr-evidence-checklist.md) or the broader +[Reviewer Checklist](./reviewer-checklist.md). + +Use it before approving, merging, or marking a contribution ready for campaign +evaluation. + +## 1. Scope Evidence + +- [ ] The PR links to the issue it claims to resolve. +- [ ] The diff is limited to the issue scope and does not include unrelated + refactors, generated files, dependency churn, or formatting-only changes. +- [ ] Any out-of-scope work is explicitly removed or tracked in a separate + follow-up issue. +- [ ] The PR description explains why each touched file is necessary. + +## 2. Implementation Evidence + +- [ ] The implementation satisfies the behavior described in the issue, not + only the title. +- [ ] Contract changes preserve existing authorization, pause, compliance, + supply-cap, and transfer-restriction invariants. +- [ ] New public functions, events, errors, storage keys, or role checks are + documented in the PR description and relevant docs. +- [ ] The change is readable, minimal, and does not hide warnings with + broad `#[allow]` attributes. + +## 3. Test Evidence + +- [ ] Happy-path behavior is covered by focused tests. +- [ ] Negative paths cover unauthorized callers, invalid state transitions, + boundary values, and expected contract errors where applicable. +- [ ] Existing tests still pass, and fixture-impacting changes either preserve + or intentionally update SDK fixture expectations. +- [ ] If tests were not added, the PR includes a clear no-test justification + that is acceptable under [Minimum Testing Standards](./testing-standards.md). + +## 4. CI and Local Verification Evidence + +- [ ] The contributor reports the exact commands run, including `make verify` + or the relevant subset such as `make fmt-check`, `make clippy`, + `make test`, and `make build`. +- [ ] GitHub Actions are green before approval, or any failing job has a + documented, issue-linked reason that is not caused by the PR. +- [ ] Local failures, if any, are reproduced and explained rather than ignored. +- [ ] The reviewer can reproduce the key verification commands when the change + touches contract behavior or fixtures. + +## 5. Documentation Evidence + +- [ ] README links, contributor docs, contract docs, and SDK/dashboard guidance + are updated when the behavior affects users or downstream consumers. +- [ ] Documentation avoids regulatory or legal promises beyond the contract's + on-chain enforcement model. +- [ ] New docs include enough context for a future maintainer to verify the + change without reading the full issue thread. +- [ ] Existing docs are not contradicted by the new change. + +## 6. Acceptance-Criteria Evidence + +- [ ] Every acceptance criterion from the issue is mapped to implementation + evidence, test evidence, and status. +- [ ] Partial or deferred criteria are explicitly marked and justified. +- [ ] The reviewer checks the diff against the acceptance criteria directly + rather than relying only on the contributor summary. +- [ ] A PR with missing criteria is returned for revision before evaluation. + +## 7. Risk and Evaluation Notes + +- [ ] Security-sensitive changes receive extra review for authorization, + storage, event, and invariant impact. +- [ ] The reviewer records any known limitations that remain after merge. +- [ ] Merge readiness and reward evaluation are treated as separate decisions. +- [ ] If the PR is part of a paid campaign, the reviewer confirms that the + evidence is sufficient for evaluation but does not imply payout approval. + +## Reviewer Sign-off + +Before approving, leave a short note covering: + +1. the issue and acceptance criteria reviewed; +2. the commands or CI results used as evidence; +3. any docs or fixture impact checked; +4. any limitations, waivers, or follow-up issues. + +If any section above is not satisfied, request changes instead of approving the +pull request for evaluation.