Unica Release

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

# Выпуск Unica

Прочитай [docs/release-runbook.md](../../../docs/release-runbook.md).
Он задаёт порядок подготовки версии, публикации, проверки и восстановления.
Команды и условия этапов бери из runbook; при расхождении с workflow выясни
причину до зависимого действия.

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

Сначала установи цель запроса: узнать состояние, подготовить новый выпуск
или продолжить конкретный незавершённый. Если пользователь назвал версию,
работай с ней. Без названной версии для диагностики проверь последний
стабильный выпуск; для нового выпуска сначала определи целевую версию,
ветку и коммит по runbook.

Сверь исходный тег и GitHub release, связанную сборку и публикацию,
тег маркетплейса и ссылки каталогов обоих хостов — Codex и Claude — на ветках
`main` и `next` маркетплейса. Выбирай прогоны по версии и исходному коммиту:
последний запуск workflow может относиться к другому выпуску. Найди первый
незавершённый этап и его причину.

Кандидат `-rc.N` раздаёт только канал `next` (маркетплейс `unica-next`),
другие предвыпуски не публикуются вовсе. Проверь суффикс версии и
`isPrerelease`: для кандидата каталоги `main` не двигаются, а каталоги `next`
после зелёных проверок установки называют его тег; для прочих предвыпусков
отсутствие публикации ожидаемо. Не принимай это за зависшую публикацию и не
обходи повторным запуском или ручным продвижением.

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

- Запрос состояния не разрешает выпуск или его возобновление. Создание и push
  исходного тега, ручной dispatch, повторный запуск публикующего workflow
  и откат требуют явного поручения пользователя на соответствующее действие.
  Уже данное поручение в этой задаче повторно не согласовывай.
- Подпись исходного тега остаётся за пользователем. Не получай и не вводи
  пароль ключа. Если GPG заблокирован, сообщи причину и подготовь точную
  команду для пользователя. Pipeline проверяет происхождение успешной сборки,
  но не доказывает криптографическую проверку подписи тега.
- Опубликованные теги и байты Unica, маркетплейса и `unica-toolchain`
  неизменны. Не двигай и не удаляй теги, не заменяй assets и не используй
  номер заново для других байтов. Ошибочный выпуск исправляется новой версией.
- Каталоги продвигает только `promote` после успешных проверок установки
  и обновления. Не редактируй их вручную и не делай force-push маркетплейса.
  Согласованный откат выполняется по runbook возвратом коммитов продвижения
  на каждой ветке, которую выпуск сдвинул.

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

При изменении упаковки или релизного конвейера запускай проверки на байтах,
извлечённых из собранного архива, на каждой поддерживаемой платформе.
Плагин и каталог проверь клиентом нижней поддерживаемой версии, закреплённой
для этого хоста в workflow. Для кандидата выпуска нужен отчёт оценки
на закреплённой конфигурации 1С: отказ блокирующего сценария запрещает
продвижение. Попадание в кеш не заменяет сборку и эти проверки.

Отчёт `release-proof` подтверждает только фактически исполненный режим:
dry P0 не доказывает установку, обновление, автономный запуск, перезапуск
или откат на опубликованных байтах; `deferred` не означает успех.
Для выпуска эти сценарии проверяются отдельным контуром.

При проверке установки на Codex и Claude открой свежую сессию каждого хоста:
в ней должны обнаруживаться навыки Unica и только публичный MCP-сервер
плагина. Старые закешированные регистрации не подтверждают новую установку.

После разрешённого действия проверь его фактический результат. Зелёная сборка
сама по себе не означает, что версия доступна потребителям: нужны результаты
проверок поставки и установки для выбранного выпуска, а оба каталога должны
указывать на его существующий тег. Сообщи версию, проверенный этап и следующий
шаг со ссылками на прогоны; не выдавай запущенную работу за завершённую.