Chat Agent 2.5: адресная поставка

Это порядок поставки исходников, не подтверждение работающей версии. Модели, GPU, nats_box, nats_ui, pgweb_mcp, подписки ASR и страницы данных сохраняются. Никакие пользовательские данные при обновлении не удаляются.

1. Собрать и проверить Agent, Gateway, Audio Ingress и Front штатными component jobs на одном SHA. Перед поставкой сохранить digest каждого прежнего образа в закрытом журнале release. Проверить один экземпляр Agent и остановку задач по stop-first.
2. Job consolidate model into Agent проверяет состав стека, готовность и отсутствие чужого drain. Штатный drain ждёт нуля активных команд, аудиоподключений и replay. Если drain не удался, допуск восстанавливается; микрофон самостоятельно не прерывается.
3. Старый chat-agent_src_llm масштабируется до нуля. Проверяется отсутствие задач и ответчиков chat.agent.health.llm. Agent обновляется первым: он получает прежние VLLM_URL и VLLM_MODEL; health должен ответить ровно один раз с владельцем chat-agent_src_agent.
4. Последовательно обновляются Gateway, Ingress и Front с проверкой digest, revision, replicas и health. Допуск открывается после проверок. Только после этого удаляется chat-agent_src_llm; stack deploy --prune не применяется.
5. При ошибке после остановки LLM допуск остаётся закрытым, старый сервис остаётся остановленным для адресного отката. Сначала вернуть прежние digest и конфигурацию только изменённых приложений под drain. Прежде чем включить старый LLM, остановить новый Agent/вернуть его прежний образ и убедиться, что chat.agent.health.llm не отвечает. Затем вернуть прежнюю единственную реплику LLM, проверить очереди/health и открыть допуск. Не запускать два владельца одновременно. После успешного удаления LLM его восстановление требует прежнего DRS из baseline SHA, спроецированного только на src_llm.
6. Пакет расширения 2.5.0 сохраняет ID, permissions и CSP. Перезагрузка установленного расширения ручная. Локальная сборка и просмотр fixture не подтверждают активацию панели пользователя.

Ручная очистка

Кнопка Monitor находится в выбранной сессии. До подтверждения выполняется только preview. Удаление идёт ограниченными транзакциями с квитанцией фиксированной выборки; отмена останавливает следующие порции. Контракт и защищённые данные. На production кнопку не нажимают для проверки поставки; проверки удаления выполняются в отдельной тестовой базе.

Протокол браузерного аудио — v4/Opus. Клиент v3 получает требование обновления. Старый PCM-архив сохраняет метаданные и явное сообщение о неподдерживаемом воспроизведении/повторе. PCM после декодирования Opus, ASR, waveform и временный WAV остаются.