docs: enforce max 30min between commits to prevent work loss

CLAUDE.md

@@ -74,7 +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.
-- **Commit often — small and atomic**: Each logical unit of work gets its own commit with a clear message. NEVER batch multiple features or fixes into one big commit. Examples of good atomic commits:
+- **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`
   - `fix: editor scroll overflow`