План реализации
ARCHIVE
Архивное исследование / черновик. Не является актуальным контрактом реализации. Смотрите REST 1.0 и актуальную концепцию.
Принятая архитектура · 1 октября 2026, вариант 2
Agentfy содержит harness; API Store Deputy предоставляет единый MCP; OpenCart-модуль — защищённый REST/JSON API. Store Deputy проверяет подключения, контекст сотрудника/покупателя, права, согласования и аудит, не создавая второй harness. Connect → вход/регистрация → безопасное подключение → автоматическое создание агента в Agentfy с MCP Store Deputy → возврат в модуль. В app: команды, агенты, аккаунт, биллинг и чат с каждым агентом.
Это заменяет предыдущее решение того же дня про MCP непосредственно в модуле. Код и прототипы ниже ещё не реализуют новую интеграцию. Сессии покупателей и настоящая корзина OpenCart имеют отдельную проверяемую привязку; cookie остаётся в магазине. См. решение о едином MCP: границы, этапы и оставшаяся работа над контрактом.
Целевой дизайн, а не существующая архитектура Store Deputy. Ничего из описанного ниже дизайна каталога, одобрений и задач не сделано. Что есть сегодня — аккаунты, команды и подключение магазина, только на машине разработчика, — описано в разделе Архитектура. Код Agentfy изучен для возможного повторного использования; интеграция и сквозная работа не проверены.
Построить небольшой торговый слой исполнения на Agentfy с версионированным коннектором OpenCart и детерминированным исполнителем задач. Модель понимает намерение и объясняет исключения; обычный код проверяет и применяет изменения.
Распределение ответственности
| Компонент | Ответственность | Граница |
|---|---|---|
| Кабинет продавца | Сегодня, чат, проверка, отчёт, подключение | Ответ модели сам по себе не разрешает изменение |
| Agentfy | Возможное использование разговоров, агентов и инструментов, секретов команды, расписания | После контрактных и интеграционных тестов; не дублировать платформу и не переносить код спекулятивно |
| Торговый домен | Магазин, сопоставления ID, цены, предложения, одобрения, результаты | Определяет коммерческое значение задачи |
| Сервис исполнения | Устойчивые состояния, идемпотентность, условные записи, повторы/сверка, отмена | Обеспечивает разрешения независимо от инструкций модели |
| Расширение/коннектор OpenCart | Аутентифицированные узкие операции поддерживаемого магазина | Сохраняет хуки и проверки платформы, не открывает произвольный SQL или админдействия |
| Журнал операций | Намерение, попытка, одобрение, проверка и восстановление каждой позиции | Надёжно сохраняется до начала записи |
Целевой поток: намерение владельца → структурированное предложение → проверка политик → одобрение → исполнение коннектором → авторитетное повторное чтение → отчёт. Модель не отвечает за учёт частичных записей.
Что подтверждает обзор платформы
В Agentfy есть схема AgentMcpServer в agent/app: владелец-команда, имена секретов, разрешения исходящих подключений, кеш обнаруженных инструментов. Документация среды описывает очередь, воркеры и события. Это кандидаты на повторное использование, найденные в коде, а не доказательство готовности одобрений, изоляции, отмены или торгового аудита.
Технический эксперимент должен проверить вызов инструмента на тестовом магазине, отозванные ключи, доступ другого клиента, тайм-ауты и восстановление фоновой работы после потери воркера. Схема или README не заменят тесты. Пакет с коннектором, навыками и именами необходимых ключей остаётся предложением.
Стратегия интеграции OpenCart
Предпочтительно небольшое устанавливаемое расширение с отдельным отзывным ключом и фиксированными схемами операций. Выбрать одну ветку версий по магазинам участников, не обещать совместимость со всеми версиями и расширениями. До реализации проверить фактические API и хуки. Руководство расширений OpenCart описывает механизм, но не доказывает наличие полного API записи каталога для нашего объёма.
Контракт на стороне магазина описан в черновике Bridge Protocol v1: один подписанный протокол, небольшой мост для каждой платформы и манифест возможностей.
Предлагаемые инструменты: store.describe, catalog.find, stock.read, order.status, price.prepare, price.apply, operation.get. Это названия контрактов, а не готовые эндпоинты. price.apply принимает серверную ссылку на одобренную задачу, а не новую произвольную цену от модели.
Использовать доступ к данным и события платформы. Клики в админпанели не являются основным механизмом записи; LLM не пишет прямой SQL. Для собственной логики цен, опций, групп покупателей и общих каталогов следует указать точную поддерживаемую часть и блокировать остальное.
Контракты данных, которые нужно определить
StoreConnection: платформа/версия, возможности, область доступа, валюта, часовой пояс, ссылка на ключ и состояние синхронизации.CatalogMapping: ID поставщика и товара/опции, происхождение сопоставления, неоднозначность. Уникальность SKU нужно проверять.ChangeProposal: неизменные входы, точные значения до/после, точность, налоги/валюта, версия политики, исключения.Approval: пользователь, хеш/версия предложения, область операции и срок.JobItem: ключ операции, ожидаемое старое состояние, статус попытки, удалённый отчёт, проверенное состояние, причина конфликта.
Варианты, суммы с налогами и без, группы клиентов, даты спеццен и округление — требования домена. Если остатками управляет ERP, чтение магазина может не быть авторитетным. Ответ должен называть источник и время.
Соответствие CleanSlice
Для предложения использованы рекомендации CleanSlice MCP по зависимостям. Группировать возможности по бизнес-функциям: доменные сервисы зависят от интерфейсов шлюзов, адаптеры превращают внешние записи в доменные типы. Предлагаемые области: подключение, каталог, предложение, одобрение, задача. Размещение кода и границы согласуются во время эксперимента; документ не предполагает создание нового бэкенда. Слайсы, которые существуют сегодня, описаны на странице API.
Будущий WooCommerce-адаптер нужно сверить с нативной документацией MCP: это developer preview, используется WordPress MCP adapter, старый Woo-эндпоинт устарел. Документация плагинов маркетплейса может отличаться; не переносить предположения об аутентификации между адаптерами.
Тесты до реальных записей
Контролируемые магазины: отсутствующие/дублирующиеся SKU, локальные десятичные форматы, валюты, акции, параллельные ручные изменения, расширения. Проверить падения до и после отправки, дубликаты доставки, просроченное одобрение, отозванный доступ, доступ другого клиента и вредоносные инструкции в файле. Проверять реальное состояние, а не только успех моков.
В пилоте продемонстрировать сверку и компенсацию. Деплой, модель/провайдер, регион хранения и сроки данных ещё не определены; их не следует выдумывать в документации. См. план развития.