chore: Conventional adjustments (#37677)

Add enhancement to possible tags

---------

Signed-off-by: Nicolas <bircni@icloud.com>

AGENTS.md

@@ -7,7 +7,7 @@
 - Run single playwright e2e test files with `GITEA_TEST_E2E_FLAGS='<filepath>' make test-e2e`
 - Add the current year into the copyright header of new `.go` files
 - Ensure no trailing whitespace in edited files
-- Use Conventional Commits format for commit messages and PR titles (e.g. `type(scope): subject`)
+- Use Conventional Commits format for commit messages and PR titles (for example `type(scope): subject`; place `!` immediately before the colon when the change is breaking)
 - Never force-push, amend, or squash unless asked. Use new commits and normal push for pull request updates
 - Preserve existing code comments, do not remove or rewrite comments that are still relevant
 - Keep comments short, prefer same-line, explain why, never narrate code

CONTRIBUTING.md

@@ -195,14 +195,30 @@ PR titles must follow the [Conventional Commits](https://www.conventionalcommits
 type(scope)!: subject
 ```
 
-The allowed types are `build`, `chore`, `ci`, `docs`, `feat`, `fix`, `perf`, `refactor`, `revert`, `style`, and `test`. The generic `chore` type is intentionally not accepted; pick a more descriptive type instead.
+The scope in parentheses is optional. A `!` immediately before the colon marks a [breaking change](https://www.conventionalcommits.org/en/v1.0.0/#summary): either `type!:` or `type(scope)!:` (not `type!(scope):`).
+
+Use one of these types:
+
+- `build`: Changes affecting the build system, packaging, or external dependencies
+- `ci`: Changes to CI/CD configuration files and scripts
+- `chore`: Maintenance changes that do not affect production code or should not appear in the changelog
+- `docs`: Documentation-only changes
+- `feat`: A larger user-facing feature, improvement, or new functionality
+- `enhance`: Small or trivial user-facing improvements or UX polish (for example wording changes, color adjustments, spacing or padding tweaks, placeholders, small UI behavior improvements)
+- `fix`: A bug fix, UX correction, or security-related dependency update
+- `perf`: Performance improvements (speed, memory, scalability)
+- `refactor`: A code change that neither fixes a bug nor adds a feature
+- `revert`: Reverts a previous change
+- `style`: Formatting or style-only changes that do not affect code behavior (for example lint-driven edits)
+- `test`: Adding or correcting tests
 
 Examples:
 
 ```text
 fix(web): prevent avatar upload crash on empty file
 feat(api): add pagination to repo hooks list
-ci(workflows): lint PR titles with commitlint
+enhance(repo): improve diff toolbar spacing
+ci(workflows): lint PR titles in CI
 ```
 
 Keep this summary up-to-date as the PR evolves. \
@@ -217,6 +233,10 @@ Another requirement for merging PRs is that the PR is labeled correctly.\
 However, this is not your job as a contributor, but the job of the person merging your PR.\
 If you think that your PR was labeled incorrectly, or notice that it was merged without labels, please let us know.
 
+For pull requests that use a valid Conventional Commits title, CI automatically applies a matching `type/…` label when the title prefix is `feat`, `enhance`, `fix`, `docs`, or `test` (for example `enhance(web): …` receives `type/enhancement`).\
+That label is kept in sync with the PR title when the title is edited.\
+Other title prefixes do not get an automatic `type/…` label; the merger still assigns the correct labels (including `type/…` when needed) for changelog and backport decisions.
+
 If your PR closes some issues, you must note that in a way that both GitHub and Gitea understand, i.e. by appending a paragraph like
 
 ```text

tools/lint-pr-title.js

@@ -1,7 +1,7 @@
 #!/usr/bin/env node
 import {env, exit} from 'node:process';
 
-const allowedTypes = 'build, chore, ci, docs, feat, fix, perf, refactor, revert, style, test';
+const allowedTypes = 'build, chore, ci, docs, enhance, feat, fix, perf, refactor, revert, style, test';
 const title = env.PR_TITLE;
 
 if (!title) {