План реалізації
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, локальні десяткові формати, валюти, акції, паралельні ручні зміни, розширення. Перевірити падіння до й після надсилання, дублікати доставки, прострочене схвалення, відкликаний доступ, доступ іншого клієнта й шкідливі інструкції у файлі. Перевіряти реальний стан, а не лише успіх моків.
У пілоті продемонструвати звірку й компенсацію. Деплой, модель/провайдер, регіон зберігання й строки даних ще не визначені; їх не слід вигадувати в документації. Дивіться план розвитку.