|
| 1 | +# Contributing to AgenticPay |
| 2 | + |
| 3 | +Thanks for your interest in contributing to AgenticPay. This guide covers the expectations for code style, commits, pull requests, and testing so contributions are easy to review and merge. |
| 4 | + |
| 5 | +## Project Structure |
| 6 | + |
| 7 | +- `frontend/`: Next.js web application |
| 8 | +- `backend/`: Express.js API server |
| 9 | +- `contracts/`: Soroban smart contracts written in Rust |
| 10 | + |
| 11 | +When possible, keep changes focused to a single area of the codebase. If a change spans multiple areas, call that out clearly in your pull request. |
| 12 | + |
| 13 | +## Getting Started |
| 14 | + |
| 15 | +1. Fork the repository and clone your fork. |
| 16 | +2. Create a branch from `main`. |
| 17 | +3. Install dependencies in the area you plan to change: |
| 18 | + |
| 19 | +```bash |
| 20 | +cd backend && npm install |
| 21 | +cd frontend && npm install |
| 22 | +cd contracts && cargo build |
| 23 | +``` |
| 24 | + |
| 25 | +4. Configure any required environment variables described in [README.md](./README.md). |
| 26 | + |
| 27 | +## Code Style Guidelines |
| 28 | + |
| 29 | +### General |
| 30 | + |
| 31 | +- Match the existing structure and naming patterns in the files you touch. |
| 32 | +- Prefer small, focused pull requests over large mixed changes. |
| 33 | +- Do not commit secrets, API keys, or `.env` files. |
| 34 | +- Add or update tests when behavior changes. |
| 35 | + |
| 36 | +### Frontend and Backend |
| 37 | + |
| 38 | +- Use TypeScript for application code and keep types accurate. |
| 39 | +- Run ESLint before opening a pull request. |
| 40 | +- Avoid introducing `any` unless there is a clear reason and it is documented in the code. |
| 41 | +- Remove unused imports, variables, and dead code before submitting. |
| 42 | +- Keep components, routes, and services narrowly scoped to one responsibility. |
| 43 | + |
| 44 | +Useful commands: |
| 45 | + |
| 46 | +```bash |
| 47 | +cd frontend && npm run lint |
| 48 | +cd frontend && npm test |
| 49 | + |
| 50 | +cd backend && npm run lint |
| 51 | +cd backend && npm test |
| 52 | +``` |
| 53 | + |
| 54 | +### Smart Contracts |
| 55 | + |
| 56 | +- Follow existing Rust and Soroban patterns in `contracts/src/lib.rs`. |
| 57 | +- Keep contract interfaces explicit and deterministic. |
| 58 | +- Build and test contract changes before submitting. |
| 59 | + |
| 60 | +Useful commands: |
| 61 | + |
| 62 | +```bash |
| 63 | +cd contracts && cargo test |
| 64 | +cd contracts && cargo build --target wasm32-unknown-unknown --release |
| 65 | +``` |
| 66 | + |
| 67 | +## Commit Message Format |
| 68 | + |
| 69 | +Use a short, imperative commit message in this format: |
| 70 | + |
| 71 | +```text |
| 72 | +type: brief summary |
| 73 | +``` |
| 74 | + |
| 75 | +Recommended commit types: |
| 76 | + |
| 77 | +- `feat`: new functionality |
| 78 | +- `fix`: bug fixes |
| 79 | +- `docs`: documentation updates |
| 80 | +- `refactor`: code changes that do not change behavior |
| 81 | +- `test`: adding or updating tests |
| 82 | +- `chore`: maintenance work |
| 83 | + |
| 84 | +Examples: |
| 85 | + |
| 86 | +```text |
| 87 | +docs: add contributing guide |
| 88 | +fix: handle missing invoice validation |
| 89 | +feat: add project payment status badge |
| 90 | +``` |
| 91 | + |
| 92 | +Try to keep the summary under 72 characters and make each commit represent one logical change. |
| 93 | + |
| 94 | +## Pull Request Process |
| 95 | + |
| 96 | +1. Create a descriptive branch name such as `feat/payment-status` or `docs/contributing-guide`. |
| 97 | +2. Make your changes in the smallest reasonable scope. |
| 98 | +3. Run the relevant lint, test, and build commands for the areas you changed. |
| 99 | +4. Push your branch and open a pull request against `main`. |
| 100 | +5. In the pull request description, include: |
| 101 | + - a short summary of the change |
| 102 | + - linked issue or task reference, if available |
| 103 | + - testing notes describing what you ran |
| 104 | + - screenshots or recordings for UI changes, if applicable |
| 105 | +6. Respond to review feedback with follow-up commits unless a maintainer asks for a squash or rebase. |
| 106 | + |
| 107 | +## Testing Requirements |
| 108 | + |
| 109 | +Every contribution should be verified before review. |
| 110 | + |
| 111 | +- Frontend changes: run `npm run lint` and `npm test` in `frontend/`. |
| 112 | +- Backend changes: run `npm run lint` and `npm test` in `backend/`. |
| 113 | +- Contract changes: run `cargo test` and `cargo build --target wasm32-unknown-unknown --release` in `contracts/`. |
| 114 | +- Cross-cutting changes: run checks for every affected area. |
| 115 | +- If automated coverage is not practical, include clear manual verification steps in the pull request. |
| 116 | + |
| 117 | +Pull requests may be sent back for updates if they do not include appropriate validation for the code they change. |
| 118 | + |
| 119 | +## Questions and Support |
| 120 | + |
| 121 | +If you are unsure about an implementation detail, open an issue or start a discussion before investing heavily in a large change. Early alignment helps us review and merge contributions faster. |
0 commit comments