Документация: вынести правила коммитов и версий

AGENTS.md

@@ -79,12 +79,8 @@
 - Для экранов регистрации, входа и других чувствительных UI-flow по умолчанию переносить экраны в Figma по одному, а не пачкой, если пользователь отдельно не подтвердил иной способ.
 
 ## Версионирование
-- Единый файл версий проекта: `VERSION.properties` (в корне репозитория).
+- Все правила по коммитам, merge в `main`, `git push` и обновлению `VERSION.properties` находятся в `COMMIT_AND_VERSION_RULES.md`.
-- Перед каждым новым коммитом обязательно увеличивать версии в `VERSION.properties`:
+- Этот файл считать единым источником истины по правилам версионирования и коммитов для данного репозитория.
-- `client.version` — версия клиентского UI.
-- `server.version` — версия серверной части.
-- Базовое правило инкремента: `+1` по последнему числовому сегменту (patch), если не оговорено иное.
-- Обычные коммиты делать стандартным `git commit`; переменная `$GITEA_TOKEN` для коммитов не нужна и не используется.
 
 ## Deploy
 - Все документы, инструкции, backup-правила и скрипты деплоя хранить в папке `deploy/`.
@@ -93,7 +89,6 @@
 - Тестовые/devnet серверы SHiNE: `t1.shineup.me`, `t2.shineup.me`, `t3.shineup.me`, `t4.shineup.me`.
 - В deploy-документах и скриптах использовать домены, а не IP.
 - По возможности все справки, комментарии и примечания в конфигах/документах писать на русском языке.
-- Для операций `git push` при необходимости использовать токен из переменной окружения `$GITEA_TOKEN`.
 - Любые изменения и любой деплой на production (`shineup.me` и `server2.shineup.me`) выполнять только после отдельного явного подтверждения пользователя.
 - Перед production deploy обязательно проверить/обновить бэкап в `deploy/backup/archive/`.
 - Если пользователь пишет просто `задеплой` без уточнения production/test, уточнить целевой контур; не выбирать production автоматически.

COMMIT_AND_VERSION_RULES.md

@@ -0,0 +1,47 @@
+# Правила коммитов, merge и версионирования
+
+Этот файл является единым источником правил для:
+- коммитов;
+- merge в `main`;
+- изменения версий в `VERSION.properties`;
+- `git push` из этого репозитория.
+
+## Язык
+
+- Пояснения к коммитам, PR и merge-запросам писать на русском языке.
+
+## Где хранится версия
+
+- Единый файл версий проекта: `VERSION.properties` в корне репозитория.
+- Основные поля:
+- `client.version` — версия клиентского UI.
+- `server.version` — версия серверной части.
+
+## Базовое правило для обычных коммитов
+
+- Перед каждым новым коммитом обязательно обновлять версии в `VERSION.properties`.
+- Если менялся только UI, увеличивать только `client.version`.
+- Если менялся только сервер, увеличивать только `server.version`.
+- Если менялись и UI, и сервер, увеличивать обе версии.
+- Для обычных коммитов вне `main` использовать стандартный patch-инкремент: `+1` к последнему числовому сегменту.
+- Пример: `1.2.346` → `1.2.347`.
+
+## Правило для `main`
+
+- Ветка `main` предназначена только для стабильных версий.
+- По умолчанию в `main` нужно не коммитить напрямую, а мержить готовые изменения из рабочей ветки.
+- Если пользователь просит сделать прямой коммит в `main`, нужно отдельно и явно предупредить, что это обход обычного стабильного процесса, и обязательно переспросить подтверждение.
+
+## Версионирование при merge или прямом коммите в `main`
+
+- Для попадания изменений в `main` действует отдельная схема инкремента.
+- Нужно увеличивать вторую цифру версии и обнулять третью.
+- Пример: `1.2.346` → `1.3.0`.
+- Если в наборе изменений менялся только UI, обновлять только `client.version`.
+- Если в наборе изменений менялся только сервер, обновлять только `server.version`.
+- Если соответствующая часть не менялась, её версию не трогать.
+
+## Правила для git commit и git push
+
+- Обычные коммиты делать стандартным `git commit`; токен для локального коммита не нужен и не используется.
+- Для операций `git push` при необходимости использовать токен из переменной окружения `$GITEA_TOKEN`.