> ## Documentation Index
> Fetch the complete documentation index at: https://docs.switchbord.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Contribution Workflow

> Expected flow for proposing, implementing, validating, and documenting changes.

# Contribution Workflow

This repository favors narrow, reviewable pull requests over large platform rewrites.

## Default workflow

1. Open or confirm an issue first if the change affects behavior, architecture, or contributor policy.
2. Create a focused branch or worktree.
3. Implement the smallest complete slice that can be reviewed on its own.
4. Update docs in `apps/docs` for user-facing or contributor-facing behavior changes.
5. Update repo-level notes in `docs/*.md` when the change affects architecture, CI/CD, migration, or operational posture.
6. Run the local verification set before asking for review.

## Minimum local checks

```bash theme={null}
pnpm lint
pnpm docs:lint
pnpm typecheck
pnpm test
pnpm build
```

Use targeted runs when narrowing failures:

```bash theme={null}
pnpm --filter app test
pnpm --filter api test
pnpm --filter control-plane test
pnpm --filter worker test
```

## What a good PR includes

* one coherent change set
* typed code
* tests for the changed behavior
* doc updates
* a short note on rollout, replay, or operational impact if relevant

When a branch will live for more than a short fix, prefer a separate worktree. See [Worktrees](/contributing/worktrees).

## What to avoid

* mixing unrelated refactors into a feature PR
* changing route contracts without updating docs
* shipping architecture claims in docs that the code does not yet satisfy
* bundling broad dependency churn with product behavior changes

## Read next

* [Worktrees](/contributing/worktrees)
* [Issue & PR Etiquette](/contributing/issue-pr-etiquette)
* [Release Process](/contributing/release-process)
* [CI/CD](/operations/cicd)