Skip to content

Pull Requests

!!! info "TL;DR" Use branch naming conventions (feat/, fix/, refactor/). All PRs must pass CI (tsc, eslint, vitest, build). Include a clear description, test plan, and any operational considerations. Green CI is required before merging.

Branch Naming

Use conventional branch prefixes:

  • feat/ — New features (e.g., feat/survey-builder)
  • fix/ — Bug fixes (e.g., fix/vote-count-race-condition)
  • refactor/ — Code refactoring (e.g., refactor/consolidate-types)
  • docs/ — Documentation only (e.g., docs/adr-github-integration)
  • test/ — Test improvements (e.g., test/rls-policy-coverage)

Create a branch from main:

git checkout main
git pull origin main
git checkout -b feat/your-feature-name

Commit Messages

Follow conventional commit format:

<type>: <short description>

<optional body>

Types: feat, fix, refactor, test, docs, chore

Examples:

feat: add survey builder with question types

fix: resolve vote count race condition in triggers

refactor: consolidate duplicate type definitions

PR Description Template

Every PR must include:

  1. What changed: Brief summary of the change
  2. Why: Motivation or context (link to issue if applicable)
  3. How tested: Steps to verify locally
  4. Operational considerations: Migrations, environment variables, breaking changes

Example:

## What changed

Added survey builder UI with support for 5 question types.

## Why

Closes #123. Users need to create surveys programmatically.

## How tested

- Manual testing in local dev
- Added Vitest unit tests for question validation
- Playwright e2e test for survey creation flow

## Operational considerations

- Requires `ANTHROPIC_API_KEY` for sentiment analysis
- Migration `20260210_survey_schema.sql` must run before deploy

CI Gates

All PRs must pass these CI checks:

  1. TypeScript type checking: npx tsc --noEmit
  2. ESLint: npm run lint
  3. Vitest unit tests: npm run test
  4. Production build: npm run build
  5. Playwright e2e tests: npm run test:e2e (on Vercel preview)

If CI fails, fix the failures locally and push again. Do not merge with failing CI.

Review Process

  1. Self-review: Check the diff for unintended changes, commented code, or debugging statements
  2. Request review: Tag relevant reviewers (e.g., @reviewers or specific team members)
  3. Address feedback: Respond to comments, make requested changes, and re-request review
  4. Green CI: Ensure all checks pass before merging
  5. Merge: Use "Squash and merge" to keep a clean commit history

Testing Expectations

Every non-trivial change must include tests:

  • Unit tests: For Server Actions, utilities, hooks
  • E2e tests: For new user-facing features
  • RLS tests: For database policy changes
  • Failure paths: Test error handling, not just happy paths

See Testing for patterns and examples.

Pre-commit Hooks

Canviq uses lint-staged to auto-fix code on commit:

  • eslint --fix --max-warnings 0
  • prettier --write

If pre-commit hooks fail, fix the issues and commit again.

Breaking Changes

If your PR introduces breaking changes:

  • Mark the PR title with BREAKING:
  • Document the migration path in the PR description
  • Update relevant documentation (CLAUDE.md, design briefs, ADRs)

What's next