commit-ruleslisted

# Commit rules Follow these when creating any commit in this repo. ## When to commit - Commit only when the user asks. Don't auto-commit after making changes. - If the current branch is the default branch (`main`/`master`), create a topic branch first, then commit. - Commit only what the user asked to include. Review `git status` and `git diff --staged` before committing; don't sweep in unrelated changes, generated files, or another task's edits. ## Scope — keep commits atomic - One logical change per commit. If the diff does two unrelated things, split it into two commits. - Each commit should leave the repo in a working state (tests/build not broken by that commit alone). - Don't mix refactors with behavior changes in the same commit. ## Message format ``` <short imperative subject, ~50 chars, no trailing period> <body: wrap at ~72 chars. Explain WHY the change was made and any context a reviewer needs — not a restatement of the diff. Omit the body for trivial, self-evident changes.> ``` - **Subject:** imperative mood ("add", "fix", "remove" — not "added"/"fixes"), concise, lowercase start, no period. If the repo already uses a convention (e.g. Conventional Commits `type(scope): …`), match it — check recent `git log` first. - **Body:** focus on intent and rationale. Reference issues/PRs if relevant. - Match the style of recent commits in the repo over these defaults when they differ. ## What not to commit - Secrets, credentials, tokens, `.env` f