Огляд

Прийнятий напрям · вирішено 2 жовтня 2026 · нічого не реалізовано

Погоджене рішення — один застосунок і для керівників, і для працівників: у браузері та, поки що, на телефонах через Capacitor, — а за ним один API. Нічого з цього ще не створено.

Один застосунок, дві ролі. Керівник і працівник відкривають той самий застосунок і бачать різні його частини.

З чого це складається

Частина	Що вона робитиме	Статус
Застосунок	Тут керівник описує магазин, перевіряє та публікує графік, а працівник бачить свої зміни й просить про зміни в графіку. Одна кодова база на Nuxt.	Прийнятий напрям, не створено
Мобільний застосунок	Той самий застосунок, упакований для iOS та Android за допомогою Capacitor.	Прийнято на зараз, не створено
API	Зберігає магазини, команди, правила, графіки та запити на зміни; усе, що показує застосунок, надходить із нього. На NestJS.	Прийнятий напрям, не створено
Агент складання графіка та розв'язувач	Перетворюють прохання людей на обмеження, будують графік і пояснюють результат.	Гіпотеза; розв'язувач для першої версії обрано — див. Агент і розв'язувач
Асистент для працівників	Приймає прохання про зміну звичайними словами, перевіряє правила й готує одне рішення для керівника.	Пропозиція — див. Асистент для працівників

Як частини будуть пов'язані — це цільова схема, а не працююча система:

        Керівник               Працівник
            \                     /
      ┌───────────────────────────────┐
      │  Застосунок (Nuxt)            │   браузер · iOS та Android
      │  одна кодова база, дві ролі   │   через Capacitor
      └───────────────┬───────────────┘
                      │
      ┌───────────────┴───────────────┐
      │  API (NestJS)                 │
      └───────┬───────────────┬───────┘
              │               │
     агент складання      асистент
     графіка та           для працівників
     розв'язувач

Один застосунок на телефонах, через Capacitor — поки що

Мобільний застосунок — не другий продукт. Це той самий застосунок, який керівник може відкрити в браузері, упакований для iOS та Android за допомогою Capacitor, а не написаний двічі як нативні застосунки.

Що це означає для людей, які ним користуються:

• Керівник і працівник встановлюють той самий застосунок. Що побачить кожен із них, визначає роль в обліковому записі.
• Керівник може працювати і в браузері. Це той самий застосунок, а не окрема панель адміністратора.
• «Поки що» — частина рішення. Capacitor — вибір для старту, а не назавжди. Що змусить нас його замінити і на що, не вирішено.

Лишається відкритим: як застосунок розповсюджується, як люди дізнаються про новий графік чи про рішення, яке на них чекає, і чи працює щось без зв'язку. Чи зможуть працівники писати ще й із месенджера, яким уже користуються (Telegram, Viber, WhatsApp), — відкрите питання.

Як буде організовано код

NestJS для API та Nuxt для застосунку, організовані за CleanSlice — угодою, за якою побудовано інші наші продукти: код згруповано за можливостями продукту, а не за технічними шарами.

Це вибір інструментів, а не проєкт функцій. Моделі даних, переліку методів API та екранів поки немає.

Агент і розв'язувач

Розставити людей по змінах за жорстких правил — задача оптимізації, і спеціалізовані розв'язувачі добре з нею справляються. Наше робоче припущення: мовна модель сама цієї арифметики не робить. Вона розуміє прохання, перетворює його на обмеження, викликає розв'язувач і пояснює результат. Це гіпотеза, якій потрібен прототип. На сторінці Агент і розв'язувач описано, що таке розв'язувач, які інструменти отримає агент і чому розв'язувач — це сервіс, а не MCP-сервер.

Не вирішено

• База даних і де її розміщено — а отже, і де зберігаються дані працівників; це треба визначити до будь-якого пілоту.
• Яка мовна модель і де працює агент — усередині нашого API чи на зовнішній платформі. Розв'язувач для першої версії обрано (YALPS); див. Агент і розв'язувач.
• Хостинг для застосунку та API. Сьогодні розгорнуто лише цей сайт документації; див. DevOps. Єдиний висловлений намір — що пізніший сервіс розв'язувача працюватиме в Kubernetes поруч з API.
• Вхід у систему і те, як працівника запрошують до магазину.
• Сповіщення.
• Месенджер як другий канал для працівників.
• Інтеграції з касовими системами та лічильниками відвідувачів. Першим способом введення, найімовірніше, будуть таблиці; див. Вхідні дані.
• Окрема панель адміністратора та публічний сайт. Ні те, ні те не спроєктовано.

Куди далі

• Шлях користувача: що керівник і працівник робитимуть у застосунку.
• Агент і розв'язувач: що рахує графік і як агент цим користуватиметься.
• DevOps: що розгорнуто сьогодні.
• Відкриті питання: що вирішено, а що ні.
• Два тижні до демо: план лише для вебу до 18 жовтня; Capacitor — пізніше.