Git and releases

BranchesCopy Anchor Link

Commit and push to develop. Never commit to main; it only moves through the develop to main pull request.

Commit messagesCopy Anchor Link

Commits follow Conventional Commits and commitlint checks them. The header is at most 72 characters and body lines are at most 100. Mark breaking changes with ! and a BREAKING CHANGE: footer.

Hooks stay onCopy Anchor Link

Lefthook formats and lints the staged files before a commit. Both the commit and the push then run pnpm verify:affected: lint, typecheck and test:unit for the workspaces affected since origin/develop. Because the gates match, a commit that lands can also be pushed, and Turbo's cache makes the push re-run fast. In tests/integration, test:unit runs only the static cross-package-node guards; the integration, DOM, workflow, Supabase and e2e suites run in CI. Do not pass --no-verify. When a hook fails, fix the cause and commit again.

ChangesetsCopy Anchor Link

Every user-visible change adds a changeset with pnpm changeset. The apps share one version through a fixed group, so pick any app and describe the change for users. Releases do not use release-please.

Uncommitted work belongs to the userCopy Anchor Link

Do not run git checkout, git restore, git reset or git stash on files you did not change in this task. The one routine exception is restoring the .po catalogs described in Translations.

Plans and long workCopy Anchor Link

• When implementing an attached plan, do not edit the plan body, do not recreate existing todos, keep the plan's todo statuses current (in progress, completed) as work proceeds, refreshing them every few minutes and after each subagent finishes during long runs, and continue through all todos unless blocked. Apply the work on the current working tree so the user can commit; do not create a side branch unless asked. Keep drafted plans as normal Cursor plans (under ~/.cursor/plans); do not save them as repo plans/*.md files.
• For long or broad work (migrations, lint or type cleanups), pull the latest develop first, then commit and push to develop in small, scoped batches as each slice passes the hooks, instead of holding a large uncommitted tree until everything is finished; land remaining gaps as follow-up commits. After the last push of a batch (not after every commit), confirm the develop Vercel deployment builds and fix it when it breaks. Subagents still do not commit unless the parent says so.