git:20261007.798a26d to git:20261016.9c6355c

9 added, 13 removed. Audit A to A.

---

name: unica-release

description: Выпуск самого Unica в публичный маркетплейс, проверка состояния версии и продолжение незавершённого выпуска. Используй по запросу выпустить, продвинуть или завершить релиз либо выяснить, почему потребители видят старую версию.

---

# Выпуск Unica

Прочитай [docs/release-runbook.md](../../../docs/release-runbook.md).

Он задаёт порядок подготовки версии, публикации, проверки и восстановления.

Команды и условия этапов бери из runbook; при расхождении с workflow выясни

причину до зависимого действия.

## Определить следующий шаг

Сначала установи цель запроса: узнать состояние, подготовить новый выпуск

или продолжить конкретный незавершённый. Если пользователь назвал версию,

работай с ней. Без названной версии для диагностики проверь последний

стабильный выпуск; для нового выпуска сначала определи целевую версию,

ветку и коммит по runbook.

Сверь исходный тег и GitHub release, связанную сборку и публикацию,

тег маркетплейса и ссылки каталогов обоих хостов — Codex и Claude — на ветках

- `main` и `next` маркетплейса. Тег `vX` маркетплейса появляется только при

- продвижении, вместе с каталогом, который его называет; до этого проверки

- установки идут по якорю `candidate-vX`. Якорь без `vX` значит, что продвижение

- не дошло; теги с `v0.9.1` по `v0.13.0-rc.5` стоят на коммите stage и называют

- каталог предыдущего выпуска. Выбирай прогоны по версии и исходному коммиту:

- последний запуск workflow может относиться к другому выпуску. Найди первый

- незавершённый этап и его причину.

+ `main` и `next` маркетплейса. Состояние тега нужной версии, якоря `candidate-vX`

+ и исключения старых тегов сверяй с

+ [правилом тега маркетплейса](../../../arch/rules/distribution/marketplace-release-tag.md).

+ Выбирай прогоны по версии и исходному коммиту: последний запуск workflow

+ может относиться к другому выпуску. Найди первый незавершённый этап и его причину.

- Кандидат `-rc.N` раздаёт только канал `next` (маркетплейс `unica-next`),

- другие предвыпуски не публикуются вовсе. Проверь суффикс версии и

- `isPrerelease`: для кандидата каталоги `main` не двигаются, а каталоги `next`

- после зелёных проверок установки называют его тег; для прочих предвыпусков

- отсутствие публикации ожидаемо. Не принимай это за зависшую публикацию и не

- обходи повторным запуском или ручным продвижением.

+ Для предвыпуска сверь суффикс версии, `isPrerelease` и ожидаемую публикацию

+ в маркетплейс с [таблицей каналов runbook](../../../docs/release-runbook.md#a-release-candidate-served-on-next-only).

+ Предусмотренное таблицей отсутствие публикации в маркетплейс не обходи

+ повторным запуском или ручным продвижением.

## Границы действий

- Запрос состояния не разрешает выпуск или его возобновление. Создание и push

исходного тега, ручной dispatch, повторный запуск публикующего workflow

и откат требуют явного поручения пользователя на соответствующее действие.

Уже данное поручение в этой задаче повторно не согласовывай.

- Подпись исходного тега остаётся за пользователем. Не получай и не вводи

пароль ключа. Если GPG заблокирован, сообщи причину и подготовь точную

команду для пользователя. Pipeline проверяет происхождение успешной сборки,

но не доказывает криптографическую проверку подписи тега.

- Опубликованные теги и байты Unica, маркетплейса и `unica-toolchain`

неизменны. Не двигай и не удаляй теги, не заменяй assets и не используй

номер заново для других байтов. Ошибочный выпуск исправляется новой версией.

- Каталоги продвигает только `promote` после успешных проверок установки

и обновления. Не редактируй их вручную и не делай force-push маркетплейса.

Согласованный откат выполняется по runbook возвратом коммитов продвижения

на каждой ветке, которую выпуск сдвинул.

## Подтвердить результат

При изменении упаковки или релизного конвейера запускай проверки на байтах,

извлечённых из собранного архива, на каждой поддерживаемой платформе.

Плагин и каталог проверь клиентом нижней поддерживаемой версии, закреплённой

для этого хоста в workflow. Для кандидата выпуска нужен отчёт оценки

на закреплённой конфигурации 1С: отказ блокирующего сценария запрещает

продвижение. Попадание в кеш не заменяет сборку и эти проверки.

Отчёт `release-proof` подтверждает только фактически исполненный режим:

dry P0 не доказывает установку, обновление, автономный запуск, перезапуск

или откат на опубликованных байтах; `deferred` не означает успех.

Для выпуска эти сценарии проверяются отдельным контуром.

При проверке установки на Codex и Claude открой свежую сессию каждого хоста:

в ней должны обнаруживаться навыки Unica и только публичный MCP-сервер

плагина. Старые закешированные регистрации не подтверждают новую установку.

После разрешённого действия проверь его фактический результат. Зелёная сборка

сама по себе не означает, что версия доступна потребителям: нужны результаты

проверок поставки и установки для выбранного выпуска, а оба каталога должны

указывать на его существующий тег. Сообщи версию, проверенный этап и следующий

шаг со ссылками на прогоны; не выдавай запущенную работу за завершённую.