Процесс, его выполнение и решение
Я разделил описание процесса, конкретный запуск и решение по его результатам. Редактор объясняет, что должно произойти. Инспектор показывает, что выполнилось. Экран согласования даёт человеку доказательства и варианты действий в контрольной точке.
Общий список объединяет оба сценария и выносит задачи, ожидающие человека. Из него можно перейти в редактор или сразу к требующему решения вопросу.

Сделать параллельную работу понятной
После загрузки документов оркестратор запускает Legal, Finance и Compliance Agent параллельно. Их результаты сходятся в Risk Aggregator перед Human Approval. Общие точки подключения, аккуратные маршруты связей и направление выполнения объясняют разветвление.
Узел показывает роль, состояние и выходные данные. При выборе настройки открываются рядом с процессом. В конфигурации агента можно проверить источники, правила проверки, формат результата и условия передачи вопроса человеку.


Проверить вывод по исходному фрагменту
В примере четыре замечания превращаются в два междокументных конфликта. Инспектор сохраняет результаты каждого агента. Экран конфликта сопоставляет исходные фрагменты: 30 дней в основном договоре и 45 дней в графике платежей.
Рядом с каждым фрагментом остаются название документа, страница и пункт. Тот же принцип работает для второго конфликта: лимиты ответственности 100 000 и 250 000 долларов. Специалист может оценить расхождение до выбора действия.



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


Сопоставить сигналы и предложить гипотезу
Второй пример выходит за пределы документов. В сервисе оформления заказов выросло число ошибок. Telemetry, Change и Runbook Agent параллельно проверяют метрики и журналы, недавнее изменение конфигурации и инструкцию восстановления.
Перед всплеском ошибок размер пула соединений изменился с 80 до 8. Интерфейс показывает это как основную гипотезу, а не доказанную причину. Снимок доказательств и ревизия конфигурации привязывают предложенное действие к конкретному состоянию сервиса.


Разрешить одно изменение и проверить результат
Инженер разрешает конкретное изменение DB_POOL_MAX: 8 → 80 для одного сервиса и региона. На экране видны нужная ревизия, свежесть доказательств и срок разрешения — десять минут. Изменение условий или ошибка останавливает выполнение; повторять изменение автоматически нельзя.
После изменения в примере проверяются доля ошибок ниже 0,5%, p95 ниже 500 мс и отсутствие тайм-аутов пула в течение двух минут. История сохраняет согласование и применённую ревизию. Успешная проверка переводит инцидент в Monitoring, но не закрывает автоматически. Все значения на графике демонстрационные.



Принять решение без всего редактора
На телефоне важно понять, что требует внимания, и принять обоснованное решение. Вместо канвы — карточки этапов, краткие доказательства и закреплённое действие. Проверка договора ведёт от статуса к исходным фрагментам и запросу правок. Инцидент — от диагностики к ограниченному разрешению и проверенному результату.






Связанный концепт для проверки решений
HeroUI Figma Kit V3 использован как основа базовых компонентов. Я адаптировал их под продукт и спроектировал узлы процессов, работу с доказательствами, состояния решений и мобильные сценарии. В Figma сохранены редактируемые слои, Auto Layout, варианты компонентов и общие токены. Авторство исходных ресурсов HeroUI сохраняется; в кейсе показаны готовые интерфейсы, а не распространяемый UI-кит.
Следующий шаг — проверить два решения со специалистами: сможет ли договорной юрист объяснить конфликт по приведённым фрагментам, а дежурный инженер — точно назвать границы разрешения. Отдельно нужно проверить, различают ли люди запрос правок и согласование документов, устранение сбоя и закрытие инцидента. Эти проверки пока не проводились.
Что проверять дальше
Критерии будущей проверки. Это не измеренные результаты.
| Задание | Что наблюдать |
|---|---|
| Объяснить конфликт сроков оплаты | Находит ли специалист оба пункта и объясняет ли разницу 30/45 дней? Фиксировать ошибки поиска и обращения за помощью. |
| Назвать границы разрешения | Называет ли инженер параметр, сервис, регион и срок? Фиксировать пропущенные ограничения до согласования действия. |
| Выбрать следующий шаг после проверки | Понимает ли человек, что документы нужно исправить, а инцидент остаётся открытым? Фиксировать ошибочные следующие действия. |





