Contribution workflow

The full rules are in CONTRIBUTING.md. This page is the short version.

Fork firstCopy Anchor Link

Contributors work from their own fork of tobin-protocol/tobin:

gh repo fork tobin-protocol/tobin --clone        # or use the Fork button, then git clone your fork
cd tobin
git remote add upstream https://github.com/tobin-protocol/tobin.git    # skip if gh already added it

Before each new branch, bring your fork's main up to date with git switch main, git fetch upstream, git merge --ff-only upstream/main and git push origin main. Push your branch to your fork and open the pull request against tobin-protocol/tobin main. See the full steps.

BranchesCopy Anchor Link

Start from the latest main and work on a dedicated branch named <type>/<short-description>. Never push directly to main.

Keep a branch narrowly scoped. Do not rewrite, amend, reset or force-push accepted commits.

CommitsCopy Anchor Link

Use Conventional Commits: type(scope): imperative summary.

feat(clearing): add obligation validation
fix(auth): prevent wallet challenge replay
docs(architecture): clarify settlement lifecycle

A message must describe what the commit really does. Do not add AI attribution or co-author trailers.

Pull requestsCopy Anchor Link

Open a pull request against main. The template asks for the problem, the implementation, the affected components, linked issues, the exact validation results (counts of passed, failed and skipped), screenshots at 1200 px and 420 px for meaningful UI changes, migration notes, security implications, and the documentation updates required.

Disclose every skipped test, check or validation you did not run, and why.

ReviewCopy Anchor Link

• One approving review is required by the repository ruleset.
• Project policy requires the CI checks to pass before merging. GitHub does not enforce it (the ruleset lists no required status check), so reviewers must check.
• Security-sensitive changes should have a reviewer who is not the author.

Reporting vulnerabilitiesCopy Anchor Link

Never open a public issue for a vulnerability. See the security policy.