chore: adopt linear git model without release-to-main branch (#34)

.ai/conventions/engineering-workflow.md

@@ -42,8 +42,15 @@ Issue и PR выбирай `hermes-agent`; незанятую задачу не
 `refactor`, docs → `docs`, test → `test`, ci → `ci`, chore → `chore`,
 performance → `perf`. Номер обязателен для новых рабочих веток; короткий
 английский slug в kebab-case. Ветки `main`/`develop` не место для прямой
-разработки. Release/hotfix, обратная синхронизация, Renovate и исторические
-ветки подчиняются существующему release/automation процессу, а не переименовываются.
+разработки. Release, Renovate и исторические ветки подчиняются существующему
+release/automation процессу, а не переименовываются.
+
+Рабочий PR сливается squash или rebase-merge; merge-коммит не используется.
+`main` обновляется только fast-forward из `develop`, поэтому `origin/main`
+всегда предок `origin/develop`. Срочный fix — обычная ветка `fix/*` от
+`develop`; отдельного hotfix-пути от `main` в обычном процессе нет.
+Merge policy, версии, теги и исключения принадлежат
+[процессу релиза](../../README.md#релизы-и-ветки).
 
 ## Commit Conventions
 
@@ -140,17 +147,19 @@ Frontend/backend запускают их как jobs в едином `verify.yml
 ## Exceptions and Recovery
 
 Срочный hotfix: немедленно завести/найти Issue, затем исправление в
-`release/hotfix-<name>` от актуального `main` по существующему release process;
-проверки и PR в `main`, затем вернуть результат в `develop`. Связать Issue
-в PR и сопровождающем коммите; специальная release-ветка исключена из обычного
-шаблона имён. Не отменять Issue или проверки из-за срочности.
+обычной ветке `fix/<issue>-<slug>` от актуального `develop`, PR в `develop`
+и релиз по существующему процессу. Отдельного пути от `main` нет: он сделал бы
+`main` не-предком `develop`. Если `develop` содержит незаконченную работу,
+быстрого фикса нет; обход требует явного решения и описан в
+[процессе релиза](../../README.md#ограничения-модели). Связать Issue
+в PR и сопровождающем коммите. Не отменять Issue или проверки из-за срочности.
 Если CI красный или PR устарел — исправить в той же ветке и перепроверить
 актуальный HEAD; если AC изменились — обновить Issue и при SDD вернуть change
 к затронутому approval gate. При недоступной Gitea продолжать только анализ.
 Изменение PR title после зелёного CI: проверить, что check пересчитан;
 если `edited` trigger у существующих checks отсутствует, reviewer проверяет
 текущий title вручную. Новые правила не применяются к историческим коммитам
-и автоматической обратной синхронизации релиза.
+и merge-коммитам, уже находящимся в истории.
 
 Примеры: фича с новым поведением — Issue → согласованный OpenSpec change →
 ветки Apply → PR каждого affected repo → archive → закрытие Issue. Локальный
@@ -158,5 +167,5 @@ bugfix — Issue → `fix/124-invalid-balance` → регрессия → PR →
 Cross-repo контракт — одна Issue с общими AC, `backend` и `frontend` PR с
 `WealthLedger/main#27` и взаимными ссылками; если независимые acceptance/owners,
 отдельные связанные Issues. Рефакторинг без изменения поведения — lightweight
-`refactor/125-simplify-api-client`. Hotfix — Issue → `release/hotfix-*` от
-`main` → PR/release → back-merge в `develop` → закрытие.
+`refactor/125-simplify-api-client`. Hotfix — Issue → `fix/*` от `develop` →
+PR в `develop` → релиз → закрытие.