From 5b06391b0142d63650376ee26ffbfafb5b85ff3f Mon Sep 17 00:00:00 2001 From: lucaronin Date: Sun, 22 Feb 2026 10:19:33 +0100 Subject: [PATCH] docs: add never-develop-on-main rule + PR-based merge requirement --- CLAUDE.md | 1 + 1 file changed, 1 insertion(+) diff --git a/CLAUDE.md b/CLAUDE.md index 6dc41917..fcba9220 100644 --- a/CLAUDE.md +++ b/CLAUDE.md @@ -74,6 +74,7 @@ After every meaningful architectural decision or abstraction, update the relevan - **Small steps**: Build one thing at a time. Get it working, test it, commit it. Then move to the next. - **Test as you go**: Write tests alongside code, not after. If you build a frontmatter parser, test it immediately with real-world examples before moving on. - **Verify constantly**: After each meaningful change, run the relevant tests (`cargo test`, `pnpm test`). Don't stack up a bunch of code and hope it all works. +- **Never develop on `main`**: all work happens on a feature branch (`task/`). This repo has CI that runs on PRs — pushing directly to main skips the pre-merge checks. Brian merges via PR (`gh pr create` + `gh pr merge`) after Luca approves. If you somehow end up on main, stash your work and switch to the correct branch first. - **Commit often — small and atomic**: Each logical unit of work gets its own commit. **Never work for more than 20–30 minutes without committing something.** If you've been coding for 30 min and have no commit, stop and commit what you have — even if it's incomplete (use `wip:` prefix). This protects against session crashes and timeouts. NEVER batch multiple features or fixes into one big commit. Examples of good atomic commits: - `feat: update color palette and CSS variables` - `feat: restructure sidebar with collapsible sections`