Skip to content

Contributing

Welcome — contributions are very welcome.

Document Purpose
Contributing Guide How to fork, branch, and open a PR
Code Guidelines Strict coding rules (max 10 lines/method, zero any, OCP maps over chains, etc.)
Code of Conduct Behavioral expectations for all contributors
Roadmap What's coming next
Security Policy How to report vulnerabilities responsibly

At a glance

  • Branch naming: feat/<short-desc>, fix/<short-desc>, docs/<short-desc>, chore/<short-desc>, refactor/<short-desc>.
  • Conventional commits: feat:, fix:, refactor:, docs:, chore:. The squash-merge title becomes the commit message — keep it conventional so release-please versions correctly.
  • Git hooks: verification is split across two stages. git commit runs 6 gates on what you are committing (incremental type-check on src/, ESLint and Biome on staged files, config-structure, allowScripts pins, PII scan, ~9s with warm caches). git push runs 7 whole-repo gates (type-check:test, type-check:e2e, TypeDoc validation, uncached ESLint, markdownlint, circular-dependency, coupling regression, ~45s). Neither hook needs Docker, so a stopped Docker Desktop cannot block you. The build, npm audit, unit-test, manifest, Semgrep, link-check, ESLint-canary, Docker image build, Trivy, mocked + Telegram E2E, and CodeQL gates run in CI, not the hooks. See CI pipeline.
  • PRs: open a draft PR early. CI runs pr.yml automatically. Squash-merge after the required checks are green.

First time?

  1. Read the Contributing Guide and Code Guidelines.
  2. Pick an issue tagged good first issue.
  3. Comment on the issue to claim it.
  4. Run npm ci && npm run validate locally to confirm everything works.
  5. Open a draft PR — early feedback is faster than late rewrites.

Thank you for contributing! 🎉