Commit Granularity

Required Gate

Before staging or committing, analyze the full diff and decide how many logical commits are required.

Mandatory rules:

One commit must represent one clear business intent or technical purpose.
Split commits when the diff contains independent purposes, such as feature work, bug fixes, style-only cleanup, compatibility changes, generated files, dependency/build changes, tests, or docs.
Do not mix broad style normalization or mechanical refactors with business behavior changes.
Do not mix unrelated UI components, pages, services, or domains unless they are required by the same user-visible change.
Keep generated files with the source change that produced them when they are inseparable; otherwise isolate generated or build artifacts.
If the split boundary is unclear, stop and ask the user before committing.