Рабочие процессы одобрения
Одобрение имеет смысл, только если одобренное является именно тем, что выходит в публикацию.
Здесь описан дизайн, а не работающий сервис
Проблема
Одобрения обычно живут вне инструмента, который публикует. Скриншот отправляется клиенту, клиент отвечает «да», а затем текст меняется. Теперь одобрение относится к черновику, которого больше ни у кого нет, а инструмент об этом не знает, поэтому публикует то, что ему дали последним.
Как спроектирован продукт
- Одобрение привязано именно к тому контенту, который был проверен. Редактирование одобренного черновика делает одобрение недействительным и указывает, какое поле изменилось, вместо того чтобы незаметно переносить старое решение дальше.
- Проверяющий может одобрить, запросить изменения или отклонить, и для всего, кроме одобрения, требуется комментарий, поэтому автору никогда не приходится гадать, что исправить.
- Правило живёт в общем слое приложения, поэтому веб-приложение, REST API, сервер MCP, интерфейс командной строки и вебхуки все ему подчиняются. Ни у одной поверхности нет обходного пути вокруг проверки.
Что действительно построено
Состояния одобрения, поверхность проверки, правила повторного одобрения и события аудита за ними построены. Не построен последний шаг, потому что ни один коннектор не прошёл определение готовности, поэтому одобренной публикации пока некуда идти.
Нашел что-то не так на этой странице
Contact channels will be published here before general availability. No legal or support inbox is operating during this preview.