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