Thanks for contributing. These rules aren't strictly enforced — but following them makes every PR easier. If anything's unclear, ping a core maintainer or open the PR and ask.
New to the backend? Start with doc/architecture.md.
Run the affected code path end-to-end before opening a PR. "It builds" is not "it works."
Add tests for new behavior, endpoints, or bug fixes. If something's genuinely hard to test, say so in the PR.
Match the shape of similar code already in the repo. doc/architecture.md is the source of truth for layers, wiring, and naming. If you think a pattern is wrong, raise it — don't quietly diverge.
Scan your diff for stray logs, debug routes, internal paths, secrets, tokens, or user data in errors/responses. When in doubt, return less. Flag any auth, permission, or data-export changes in the PR description.
For private security reports, see SECURITY.md.
Don't commit code you couldn't have written, debugged, or defended yourself. Read the diff, run it, and be ready to explain it in review.
If you change puter-js APIs (drivers or endpoints used by puter-js), update developer docs. puter-js itself may also need updating.
Fix the typo, the dead import, the missing test, the bit you had to read twice. Keep cleanup proportional to the change — no refactors riding along on bug fixes.
- One thing per PR where possible.
- Describe what and why; the diff shows how.
- Mention how you tested user-visible changes.
- Drafts welcome.
Questions? Message a core maintainer. Welcome aboard.