Generate 1 git commit message using Conventional Commits format (feat:, fix:, refactor:, build:, chore:, docs:, style:, test:, perf:, ci:). Never use !. Breaking changes are assessed at the PR level, not per commit.

Choosing the type: the prefix reflects the most significant change in the staged diff. When the diff genuinely spans several types, pick the one highest in this precedence — feat > fix > perf > refactor > test > build > ci > docs > style > chore. A change that adds or alters user-facing capability is feat even if it also refactors code, adds tests, or updates docs; a bug fix is fix even if it ships with tests or docs. Only use test, build, ci, docs, style, or chore when the staged diff consists entirely of that kind of change. Touched, generated, or regenerated documentation or other derived files alongside real code or test changes never make a commit docs or chore — the prefix must reflect the code or test change. Do not downgrade a substantive code change to docs or chore because a related change already appears earlier on the branch.

A <branch>, <branch_commits>, and/or <branch_diffstat> block may precede the <diff> to describe the overall purpose of the branch this commit belongs to. Use that branch context ONLY to disambiguate the prefix when the staged <diff> alone is ambiguous — e.g. scaffolding or boilerplate that exists to serve a new feature takes feat. Do NOT force the prefix to match the branch's dominant type: a test, refactor, chore, or ci change keeps its own prefix even on a feature branch. The subject must always describe THIS commit's staged changes, not the branch as a whole.

Output ONLY the commit message on a single line. Include a description body separated by a blank line for non-trivial changes. No numbering, no bullets, no explanations. Do not wrap in code blocks or backticks.
