Застосунок

Прийнята архітектура · 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: межі, етапи та подальша робота над контрактом.

Зроблено; працює на машині розробника · 1 жовтня 2026. Лише англійською. Він виконує від початку до кінця одне завдання — підключення магазину, — і це робилося лише з двома локальними тестовими магазинами.

Застосунок — це місце, де власник магазину входить і каже: «так, підключити цей магазин до моєї команди». Чату, каталогу й екранів із цінами в ньому поки немає.

Про назви: в інших файлах репозиторію цю частину називають «сайтом». У цьому розділі застосунок — це застосунок для користувачів, що увійшли, у теці app/, а сайт — публічні сторінки, окрема частина.

Що людина може зробити сьогодні

• Створити акаунт або увійти.
• Підключити магазин. Власник приходить за кнопкою Connect зі свого модуля OpenCart, обирає команду, якщо він власник або адмін у кількох, і підтверджує. Його повертають на сторінку модуля, з якої він прийшов.
• Побачити, що пішло не так. Якщо посилання неповне, уже використане, прострочене або магазин недосяжний, власник бачить пояснення. Посилання назад у магазин показується, лише коли адреса повернення належить тому самому магазину.
• Побачити свої команди й підключені магазини на головній сторінці.

Як влаштовано код

app/slices/
  setup/
    theme/      Tailwind із токенами дизайну, базові компоненти
    pinia/      керування станом
    api/        клієнт API, згенерований з опису API
    error/      перетворює помилку API на повідомлення, зрозуміле людині
    i18n/       переклади; поки лише англійська
  user/
    auth/       вхід і реєстрація, сесія, перевірка «чи увійшов»
  store/
    connect/    сторінка підтвердження підключення магазину
  common/       шапка сторінки, макет і головна сторінка

Кожен слайс — це шар Nuxt: тека зі своєю конфігурацією, сторінками, компонентами, станом і перекладами. Тека стає частиною застосунку, щойно в ній з'являється файл конфігурації; спільного списку, який треба оновлювати, немає. Службові слайси завантажуються першими.

Усередині слайса функції:

• Сторінки тонкі. Сторінка задає маршрут і відображає один компонент.
• Дані отримує компонент Provider. Він є в кожній групі компонентів. Він читає те, що потрібно, звертається до API і вирішує, який компонент відображення показати.
• Компоненти відображення лише відображають. Вони отримують дані й повідомляють, що зробила людина.
• Стан живе у сховищі. Сесія — це сховище Pinia, а не набір розрізнених допоміжних функцій.

Сторінка підключення показує цей прийом. Сторінка відображає один провайдер. Провайдер читає посилання, з яким прийшов власник, просить API підключити магазин і показує або компонент підтвердження, або компонент помилки.

Як застосунок спілкується з API

• Клієнт генерується, а не пишеться. API описує свої маршрути; клієнт застосунку збирається з цього опису під час кожного запуску застосунку в розробці.
• Сесія переживає перезавантаження сторінки без збереження токена. Короткоживучий токен доступу зберігається лише в пам'яті. Довгоживучий — це cookie, яку скрипти сторінки прочитати не можуть і яка надсилається лише на маршрути входу. Після перезавантаження застосунок просить в API свіжий токен доступу.
• Прострочений токен доступу оновлюється один раз, і запит повторюється.
• Сторінка, що вимагає входу, відправляє людину, яка не увійшла, на вхід і потім повертає її — лише на сторінку самого застосунку, ніколи на інший сайт.
• Застосунок повністю працює в браузері. Серверного рендерингу немає; API — окремий сервіс.
• Посилання підключення нікуди не передається. У ньому є адреса сторінки адмінки магазину, тому застосунок забороняє браузеру повідомляти свою адресу іншим сайтам.

Правила для кожного слайса

• Увесь код лежить усередині slices/. У кореневих теках компонентів чи сторінок нічого немає.
• Теки слайсів — в однині.
• Стан — у сховищах, а не в composables.
• Групи компонентів — один рівень вкладеності.
• Кольори, шрифти й форми беруться з прийнятої дизайн-системи через слайс теми, а не зі стилів окремих сторінок.
• Кожен слайс тримає свій файл перекладів поруч зі своїми сторінками й компонентами.

Місця, де застосунок свідомо відходить від CleanSlice, перелічено в огляді.

Ще не зроблено

• Чат, екран «Сьогодні», таблиці перевірки та звіти, описані в концепції.
• Екрани керування командою. API вміє запрошувати людей і змінювати ролі; сторінок для цього в застосунку немає.
• Українська й російська мови. Переклади підключено, але існує лише англійська.
• Скидання пароля й підтвердження email.
• Продакшн-збірка й хостинг.