Add PocketPay Mobile issue approval readiness checklist

[El-swaggerito]

Description

Difficulty: Expert

Type: Documentation

Summary

Create an issue approval readiness checklist for PocketPay Mobile contributors.

Current Behaviour

Contributors may assume their work is complete once a PR is merged, even when tests, CI, documentation, or acceptance criteria are incomplete.

Expected Behaviour

The repo should provide a clear checklist that contributors and reviewers can use before considering an issue ready for evaluation.

Suggested Implementation

Add checklist documentation covering implementation completeness, tests, CI status, acceptance criteria, documentation, and known limitations.

Files or Areas Likely Affected

• src/
• tests/
• docs/
• README.md
• .github/
• package.json

Acceptance Criteria

• Approval readiness checklist is added.
• Checklist states that merged PRs are still subject to evaluation.
• Testing expectations are included.
• CI status expectations are included.
• Acceptance criteria review is included.
• README links to the checklist.

Additional Notes

This helps contributors evaluate their work before payment periods.

[vickman787]

Hi, I'd like to take this on.

This checklist's core value is the first acceptance criterion — stating plainly that a merged PR is not automatically approved — everything else (tests, CI, acceptance criteria, docs, known limitations) is the support for that claim.

My plan:

Check for overlap with sibling repos first. If anchorkit or pocketpay-contracts already have an equivalent self-review/readiness doc from this same campaign, I'd adapt the structure for consistency across the org rather than invent a third, slightly different format — contributors working across multiple Axionvera repos shouldn't have to learn three different checklists that mean the same thing.
Ground it in this repo specifically, since it's listed as mobile (src/, package.json suggests a JS/RN or similar mobile stack) — checklist items should reference the actual test runner and CI setup here, not generic mobile-app boilerplate. I'd check .github/workflows/ and package.json scripts before writing the testing/CI sections.
Structure as a literal checklist, not prose: implementation completeness against the issue's stated acceptance criteria, tests added/justified, CI green, docs updated if user-facing behavior changed, known limitations explicitly stated (not omitted).
State plainly, near the top: "A merged PR starts the evaluation period; it does not conclude it." This is the one line the whole issue exists for — I'd make sure it isn't buried under six checklist items.
Land it under docs/, link from README, verify the six acceptance criteria literally.

Given the "Expert" label and the src/tests/package.json areas listed (unusual for a pure docs task), I'd take that as a signal the checklist needs to reference this repo's actual test/CI mechanics specifically, not just restate the same five generic categories as the other campaign docs — that's where I'd spend the real effort here.

[grantfox-oss]

🦊 GrantFox — @vickman787 has been assigned to this issue as part of the Official Campaign | FWC26 campaign!

Next steps:

1. Open a Pull Request referencing this issue (e.g., Closes #493)
2. Your PR will be reviewed by the Axionvera maintainers

Good luck! Track your progress on GrantFox.

[grantfox-oss]

🎉 This issue has been marked as completed on GrantFox as part of the Official Campaign | FWC26 campaign!

@vickman787's PR #517 was approved and merged by @El-swaggerito.

🏆 @vickman787: You earned 35 FoxPoints for this contribution! Your current tier: Explorer (428 total points). Track your full progress on GrantFox.

👏 Great work, @vickman787! Keep contributing to Axionvera.