Рабочая плоскость

Большая часть этой документации посвящена тому, до чего может дотянуться агент: карте доступа, разрешениям и расхождению между Permitted и Observed. Эта страница посвящена другой половине — тому, как агенты и сессии координируют саму работу. До сих пор остальная часть сайта описывала её лишь как список команд и событий.

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

Что такое рабочий элемент

Рабочий элемент — это единица работы с владельцем, состоянием и долговечной записью. Это не сообщение в чате и не тикет в чужом трекере: он находится в том же хранилище, что и аудиторский журнал. Поэтому позднее можно выяснить, что с ним произошло, теми же средствами, что и для всего остального, записываемого управляющей плоскостью.

Вокруг него находятся три примитива:

Примитив	Что он делает
Сообщение	Один участник долговечно передаёт информацию другому, а не транслирует её в журнал, который никто не читает
Подтверждение	Получатель записывает, что принял в работу сообщение. «Прочитано» и «отвечено» перестают означать одно и то же
Передача	Владение рабочим элементом переходит другому участнику вместе с причиной перехода

На подтверждении стоит остановиться. Координация гораздо чаще нарушается из-за того, что сообщение увидели, но не отреагировали на него, чем из-за того, что оно не было доставлено. Система, которая не умеет различать эти случаи, не может сказать вам, какой из них произошёл.

Что реально сегодня, а что нет

1 · Координация ограничена одним workflow, а публичная плоскость коммуникации намеренно не подключена. Сообщения, подтверждения и передачи реальны внутри выполнения самого workflow. Общая плоскость коммуникации между всеми сущностями не подключена — и это не упущение, которое ещё предстоит заметить: тест запуска проверяет, какие источники полномочий может подключать boot, и завершается с ошибкой при появлении любого другого (cmd/olivares/communicationauthorityboot_test.go, TestBootWiresExactCommunicationRequestAuthoritySourcesOnly). Случайное подключение даёт красный тест, а не сюрприз в рабочей среде.

2 · Диспетчеризация между агентами монтируется только при наличии авторизованного адресата. Исполнитель удалённой работы создаётся с расположенным перед ним шлюзом согласования (cmd/olivares/wire.go); пути, который отправляет работу произвольному участнику только потому, что файл конфигурации вежливо об этом попросил, не существует.

3 · Shadow-режим и окончательные полномочия над работой НЕ СУЩЕСТВУЮТ. Не «скоро», не «частично»: они отсутствуют. Сегодня развёртывание не может отдать рабочей плоскости последнее слово над сессией, и ничто в продукте не следует понимать как предложение такой возможности. Любая гипотетическая реализация должна сопровождаться доказательством работы — окном сравнения с существующими источниками, а не увеличением номера версии.

Почему ограничения записаны здесь

Потому что альтернатива хуже для вас. Страница, которая описывает дизайн и позволяет обнаружить границу только при интеграции, отнимет у вас вторую половину дня. Страница, которая назовёт отсутствующую половину «дорожной картой», сделает ровно то заявление, от которого этот проект отказывается. Страница Честность и ограничения задаёт общее правило; здесь оно применяется к самой новой поверхности продукта.

Куда перейти дальше

Обзор модулей — место оркестрации среди остальных модулей.
Справочник по оркестрации — модуль, которому принадлежит выполнение workflow.
Справочник по шине событий — события, испускаемые рабочей плоскостью, в виде контракта AsyncAPI.
Создание управляемого workflow — практический путь после того, как вы узнали, что плоскость делает и чего она не делает.