docs: make frontend instructions self-contained

README.md

@@ -55,7 +55,7 @@ document и затем выполните `npm run openapi:generate`.
 `npm run build:catalog`. Каталог использует общую тему приложения, вымышленные
 данные и локальные действия без application API. Примеры не доказывают
 восстановление реального запроса. Визуальные роли описаны в
-[дизайн-системе](../docs/design/overview.md).
+[UI convention](.ai/conventions/ui.md#визуальная-основа).
 
 ## Документация
 
@@ -65,16 +65,49 @@ document и затем выполните `npm run openapi:generate`.
 - [Data/API/cache](.ai/conventions/data.md)
 - [Testing](.ai/conventions/testing.md)
 - [UI-каталог Storybook](#ui-каталог-storybook)
-- [Обзор поставленной системы](../docs/overview.md)
-- [Карта проектных фактов](../docs/README.md)
 
-Runtime OpenAPI backend сверяется с frontend snapshot отдельной read-only
-backend командой `npm run test:openapi-contract`.
-Разработка идёт напрямую по задаче пользователя. Каждый affected repo проходит
-свой verify; при изменении wire contract дополнительно выполняется contract check.
-Обязательного OpenSpec/SDD lifecycle нет.
-
-Версии и ветки: [процесс релиза](../README.md#релизы-и-ветки).
+Checkout frontend содержит все входы сборки и проверок. Публичная схема API
+поступает как отдельный artifact; команды frontend используют только её
+локальную копию и не обращаются к исходникам или CI сервера. Доставка новой
+схемы — явное обновление snapshot с review и `npm run openapi:generate`.
+Runtime URL API задаётся окружением, а не расположением другого репозитория.
+Разработка идёт напрямую по задаче пользователя; OpenSpec/SDD — по явному запросу.
 
 Knip исключает `conventional-changelog-conventionalcommits`: release-it загружает
 preset по имени из `.release-it.json`. Версия preset закреплена напрямую.
+
+## Релизы
+
+Репозиторий выпускается независимо. `develop` — интеграция, `main` — принятые
+релизы. Работа: `codex/<task>` от актуального `develop`, PR в `develop`.
+Обычные PR допускают squash; release и обратная синхронизация сохраняют историю.
+Commits и PR titles — Conventional Commits, включая `spec:`. Версии вручную не повышай.
+
+1. Получи `main`, `develop` и теги: `git fetch origin --tags`. Убедись, что
+   `develop` содержит последний релиз. Создай `release/<name>` от проверенного
+   `develop`; `nvm use --silent`, `npm ci`. Hotfix начинается от `main` в
+   `release/hotfix-<name>` и проходит тот же процесс.
+2. На чистой ветке выполни `npm run release:preview`, просмотри версию/changelog,
+   затем `npm run release:prepare`. Команда создаёт `chore(release): X.Y.Z`,
+   обновляет manifest/lockfile/CHANGELOG; тег и push не выполняет. Не обходи
+   guards ветки, чистого дерева, отсутствующих тегов или уже подготовленной версии.
+3. Проверь diff и штатные gates этого репозитория. Отправь только release-ветку,
+   открой PR в `main` с заголовком `chore(release): X.Y.Z`. После зелёных
+   `verify`, `security`, `commits` выполни fast-forward-only merge. Если `main`
+   изменился, согласуй историю и повтори проверки кандидата.
+4. Получи удалённый `main`, сравни его HEAD с проверенным release SHA и версией
+   manifest/lockfile. Создай аннотированный `vX.Y.Z` именно на этом SHA:
+   `git tag -a vX.Y.Z <release-sha> -m "Release X.Y.Z"`, затем отправь только
+   `git push origin refs/tags/vX.Y.Z`. Не запускай release-it повторно на `main`.
+5. Верни release-коммит через PR `main → develop` без squash/rebase; проверь,
+   что `develop` содержит тег. Опубликованные теги не перемещай. При сбое после
+   merge создай отсутствующий тег без нового bump; до merge исправь и проверь
+   существующий кандидат без повторного повышения версии.
+
+`feat:` повышает minor, `fix:`/`perf:` и прочие разрешённые типы — patch;
+`!`/`BREAKING CHANGE:` — major, включая версии до 1.0. `chore(release):`
+исключён из рекомендации и changelog. Конфигурация — `.release-it.json`.
+В Gitea для `main`/`develop` должны быть запрещены прямой/force push и обход
+администратором, обязательны `verify`, `security`, `commits`; теги `v*` защищены.
+Workflow сам не включает эти настройки. Отдельное review approval для одного
+владельца не требуется. Npm publishing, deploy и Gitea Releases не включены.