Contributing

We follow trunk-based development. main is the single source of truth and is always deployable; everything else is a short-lived branch with a PR back into main within 2–3 days.

Branch naming

<type>/<app>-<short-description>

Type	When
feat	New feature
fix	Bug fix
chore	Maintenance, config, tooling
docs	Documentation only
refactor	Code restructure without behavior change

<app> refers to the target app or package: web, server, android, ios, desktop, schema, docs, cli, mcp. For monorepo-wide changes use the closest applicable scope (e.g. chore/repo-...).

Examples:

feat/web-landing-page
feat/server-prediction
fix/desktop-recording-crash
chore/schema-update
docs/site-bootstrap

Commit messages

<type>: <short description>

Imperative mood. No trailing punctuation. Examples:

feat: add landing page
fix: resolve router redirect issue
chore: update event schema
docs: bootstrap Docusaurus site at /docs

Do not add Co-Authored-By: Claude or any other AI co-author trailer to commits in this repo.

Pull requests

• One logical change per PR. If a refactor and a feature ride together, split them.
• Fill in the PR template (.github/PULL_REQUEST_TEMPLATE.md) — Overview, Proposed Changes, Testing, Note to Reviewers.
• PR body is English only.
• Always assign cloneisme.
• One approval required to merge.

Releases

Surface	How
Web / Server / Docs	Auto-deploy on merge to main.
Desktop	Code-signed and notarized release; cadence varies.
Mobile (android, ios)	Cut a release/<platform> branch from main. SemVer tags (v1.0.0).

Reviewing

• Verify the PR's Testing section matches the diff. If a surface changed, the matching command should appear in the test plan.
• For schema changes, confirm packages/schema/events.ts and packages/schema/events.schema.json were both updated and that the relevant apps/server/recording/tests.py cases still pass.
• For UI changes, ask for a screenshot or short video — the PR template's Testing section is the place for it.