​

Contribution Workflow

​

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

pnpm lint
pnpm docs:lint
pnpm typecheck
pnpm test
pnpm build

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

​

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
• Issue & PR Etiquette
• Release Process
• CI/CD