Рабочие процессы одобрения
Одобрение имеет смысл, только если одобренное является именно тем, что выходит в публикацию.
Здесь описан дизайн, а не работающий сервис
Проблема
Одобрения обычно живут вне инструмента, который публикует. Скриншот отправляется клиенту, клиент отвечает «да», а затем текст меняется. Теперь одобрение относится к черновику, которого больше ни у кого нет, а инструмент об этом не знает, поэтому публикует то, что ему дали последним.
Как спроектирован продукт
- Одобрение привязано именно к тому контенту, который был проверен. Редактирование одобренного черновика делает одобрение недействительным и указывает, какое поле изменилось, вместо того чтобы незаметно переносить старое решение дальше.
- Проверяющий может одобрить, запросить изменения или отклонить, и для всего, кроме одобрения, требуется комментарий, поэтому автору никогда не приходится гадать, что исправить.
- Правило живёт в общем слое приложения, поэтому веб-приложение, REST API, сервер MCP, интерфейс командной строки и вебхуки все ему подчиняются. Ни у одной поверхности нет обходного пути вокруг проверки.
Что действительно построено
Состояния одобрения, поверхность проверки, правила повторного одобрения и события аудита за ними построены. Не построен последний шаг, потому что ни один коннектор не прошёл определение готовности, поэтому одобренной публикации пока некуда идти.
Questions
Does this workflow run today?
Not end to end. No connector is verified in production, so nothing described on this page publishes anywhere yet. The section on what is actually built says which parts exist.
Will it use unofficial ways to post?
No. Publishing goes only through each platform's official API. There is no browser automation, no scraping and no automated engagement.
Нашел что-то не так на этой странице
Contact channels will be published here before general availability. No legal or support inbox is operating during this preview.