mobile evaluation checklist

Author: Jumongweb

CONTRIBUTING.md

@@ -213,7 +213,7 @@ We strive to build a wallet that is accessible to everyone. Before submitting a
    - Reference any related issues using `Closes #<issue-number>`.
    - Describe how you tested the change.
    - Note any accessibility or security considerations.
-   - For GrantFox contract issues, review the [Evaluation Readiness Checklist](docs/evaluation-readiness-checklist.md) before the payment evaluation period. A merged PR does not guarantee payment approval.
+   - For GrantFox mobile issues, review the [Evaluation Readiness Checklist](docs/evaluation-readiness-checklist.md) before the payment evaluation period. A merged PR does not guarantee payment approval.
 
 7. A maintainer will review your PR. Please respond to feedback and update your branch as needed.
 

README.md

@@ -12,7 +12,7 @@ React Native Expo wallet for Stellar Testnet. The app aims to feel polished and
 ## Documentation
 
 - [Architecture Readiness Review](./docs/architecture-readiness-review.md) - Feature boundaries, duplicated state, SDK integration blockers, security-sensitive areas, and test gaps
-- [Evaluation Readiness Checklist](./docs/evaluation-readiness-checklist.md) - GrantFox contributor checklist for contract issues, including tests, CI, issue requirements, edge cases, and the reminder that merge does not guarantee payment approval
+- [Evaluation Readiness Checklist](./docs/evaluation-readiness-checklist.md) - GrantFox contributor checklist for mobile issues, including tests, CI, screenshots, acceptance criteria, and the reminder that merge does not guarantee payment approval
 - [Storage Guide](./docs/storage.md) - SecureStore vs AsyncStorage
 - [Contacts Guide](./docs/contacts.md) - Contact storage, backup limitations, and future export/import ideas
 - [Polyfills Guide](./docs/polyfills.md) - React Native polyfills and import order for Stellar SDK
@@ -48,7 +48,7 @@ PocketPay Mobile is part of a broader PocketPay stack:
 
 - [Screen Inventory](docs/screen-inventory.md) - A map of the main screens and routes in the app.
 - [Mobile Onboarding Checklist](docs/mobile-onboarding-checklist.md) - Quick-reference setup checklist for new contributors
-- [Evaluation Readiness Checklist](docs/evaluation-readiness-checklist.md) - Contract-issue review checklist for GrantFox contributors before payment evaluation
+- [Evaluation Readiness Checklist](docs/evaluation-readiness-checklist.md) - Mobile-issue review checklist for GrantFox contributors before payment evaluation
 - [UI State Catalogue](docs/ui-states.md) and [Accessibility Checklist](docs/accessibility.md) - Governance for major-screen states, shared component contracts, and accessible review evidence
 - [QR Receive Payload Format](docs/qr-payment-requests.md) - The address-only and SEP-0007-based payment-request formats the Receive screen encodes into its QR code
 

docs/evaluation-readiness-checklist.md

@@ -2,13 +2,13 @@
 
 ## Purpose
 
-This checklist is for GrantFox contributors working on contract issues. Use it before the payment evaluation period begins.
+This checklist is for GrantFox contributors working on mobile issues. Use it before the payment evaluation period begins.
 
-> Merging a contract PR does **not** guarantee payment approval. Approval still depends on evaluator review, passing checks, adequate tests, issue compliance, and overall implementation quality.
+> Merging a mobile PR does **not** guarantee payment approval. Approval still depends on evaluator review, passing checks, adequate testing evidence, issue compliance, meaningful implementation, and overall quality.
 
 ## When To Use This Checklist
 
-- Before requesting final review on a contract issue PR
+- Before requesting final review on a mobile issue PR
 - Before the payment evaluation period starts
 - After every substantial code, test, or scope update
 
@@ -19,55 +19,56 @@ This checklist is for GrantFox contributors working on contract issues. Use it b
 - [ ] I re-read the linked issue and matched the requested scope exactly.
 - [ ] I confirmed the implementation satisfies the issue acceptance criteria.
 - [ ] I documented any intentional scope limits, assumptions, or follow-up work in the PR.
-- [ ] I verified the contract behavior matches the expected user or protocol outcome.
+- [ ] I verified the mobile behavior matches the expected user experience and issue outcome.
 - [ ] I removed unfinished work, placeholders, dead code, and misleading TODOs that could affect evaluation.
 
-### 2. Contract Correctness
+### 2. Meaningful Implementation
 
-- [ ] I reviewed all changed contract paths for happy-path correctness.
-- [ ] I reviewed failure paths and verified the contract rejects invalid inputs safely.
-- [ ] I checked authorization, signer, and caller assumptions.
-- [ ] I confirmed state transitions are valid before and after each write.
-- [ ] I verified arithmetic, rounding, overflow/underflow, and precision-sensitive logic.
+- [ ] I made a real implementation change that solves the issue instead of a superficial workaround.
+- [ ] I reviewed happy-path behavior across the affected screens, hooks, stores, or services.
+- [ ] I reviewed failure, loading, empty, and disabled states introduced or affected by the change.
+- [ ] I confirmed navigation, state updates, and user actions behave correctly before and after the change.
+- [ ] I checked that naming, copy, and code structure make the implementation easy for evaluators to follow.
 
-### 3. Tests
+### 3. Mobile Testing Evidence
 
 - [ ] I added or updated tests for the main behavior introduced by the issue.
 - [ ] I added regression coverage for the bug or edge case that motivated the change.
-- [ ] I covered both success and failure paths where the contract can branch.
-- [ ] I verified test fixtures and mocks still reflect real contract expectations.
-- [ ] I confirmed the tests would help an evaluator understand why the change is correct.
+- [ ] I covered both success and failure paths where the mobile flow can branch.
+- [ ] I verified test fixtures, mocks, and app state setup still reflect real usage expectations.
+- [ ] I manually tested the affected flow in the app and captured concise verification notes in the PR.
 
 ### 4. CI And Verification
 
 - [ ] All required CI checks pass on the PR.
-- [ ] Local test commands for the affected contract area pass before review.
+- [ ] Local test commands for the affected mobile area pass before review.
 - [ ] Any lint, formatting, type, or static-analysis checks required by the repo pass.
 - [ ] I did not ignore, mute, or bypass failing checks to get the PR merged.
 - [ ] I included clear verification notes in the PR description.
 
-### 5. Security Review
+### 5. Screenshots Or Recordings
 
-- [ ] I reviewed access control and confirmed only authorized actors can trigger privileged behavior.
-- [ ] I checked for unsafe assumptions around external inputs, contract calls, and user-provided values.
-- [ ] I reviewed replay, duplicate execution, and unexpected re-entry or repeated-call scenarios where relevant.
-- [ ] I confirmed sensitive operations fail safely and leave the contract in a valid state.
-- [ ] I verified there are no debug shortcuts, test-only bypasses, or insecure defaults left in the change.
+- [ ] I attached screenshots or a short screen recording when the issue changes visible UI or user flow.
+- [ ] The media clearly shows the final state that should be evaluated.
+- [ ] I avoided placeholder evidence that does not demonstrate the actual fix or feature.
+- [ ] I made sure screenshots or recordings do not expose secrets, personal data, or unsafe debug information.
+- [ ] If the change is non-visual, I explained why screenshots or recordings are not applicable.
 
-### 6. Edge Cases
+### 6. Acceptance Criteria And Edge Cases
 
 - [ ] I tested zero, minimum, maximum, empty, and invalid input cases where applicable.
-- [ ] I reviewed boundary conditions for timestamps, counters, balances, and collection sizes.
-- [ ] I checked behavior when preconditions are missing or previous state is inconsistent.
-- [ ] I verified error messages or failure reasons remain clear enough for maintainers to evaluate quickly.
-- [ ] I considered upgrade, migration, or compatibility risks if the issue touches persisted state or interfaces.
+- [ ] I reviewed boundary conditions for form inputs, network states, persisted state, and repeated user actions.
+- [ ] I checked behavior when preconditions are missing, stale, offline, or partially loaded.
+- [ ] I verified errors, validation, and recovery actions remain clear enough for evaluators to review quickly.
+- [ ] I checked each acceptance-criteria item one by one and confirmed it is satisfied in the implementation or evidence.
 
 ### 7. Self-Review
 
 - [ ] I reviewed the full diff as if I were the evaluator.
 - [ ] I removed unrelated changes that could make the issue harder to evaluate.
-- [ ] I made sure naming, comments, and documentation explain non-obvious contract behavior.
+- [ ] I made sure naming, comments, and documentation explain non-obvious mobile behavior.
 - [ ] I confirmed the PR description links the issue and explains what was tested.
+- [ ] I honestly checked that the implementation is substantial enough to justify payment evaluation.
 - [ ] I am confident the work is ready for evaluation even if I am not available to clarify it live.
 
 ## Final Reminder
@@ -76,8 +77,9 @@ Before the payment evaluation period starts, make sure the PR is fully reviewabl
 
 - [ ] The implementation matches the issue requirements.
 - [ ] Tests and CI are passing.
-- [ ] Security and edge cases were reviewed.
+- [ ] Screenshot or recording evidence is included when applicable.
 - [ ] Acceptance criteria were checked one by one.
+- [ ] The implementation is meaningful and evaluator-ready.
 - [ ] The PR is evaluator-ready.
 
-If any box is still unchecked, treat the work as not yet ready for payment evaluation.
+If any box is still unchecked, treat the work as not yet ready for payment evaluation.