Відкриті питання

Здебільшого не вирішено · востаннє переглянуто 11 жовтня 2026

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

Що вже вирішено

• Лише рітейл (25 вересня 2026). Жодних ресторанів, складів чи універсального планування персоналу. Див. Огляд.

• Один застосунок для керівників і працівників, на телефонах — поки що через Capacitor (2 жовтня 2026). Див. Архітектуру.

• API на NestJS і застосунок на Nuxt, організовані за CleanSlice — на цих інструментах побудовано інші наші продукти (2 жовтня 2026). Див. Архітектуру.

• YALPS як розв'язувач для першої версії (2 жовтня 2026). Згодом, найімовірніше, Google OR-Tools окремим сервісом у Kubernetes — це намір, а не рішення. Див. Агент і розв'язувач. Створено в API 19 жовтня 2026 за інтерфейсом, який можуть перебрати HiGHS чи OR-Tools; не розгорнуто. З 10 листопада 2026, на прохання власника, тиждень розв'язує HiGHS, а YALPS лишається запасним; чи замінить HiGHS його остаточно, не вирішено (Агент і розв'язувач).

• Агент працює на Agentfy — через його партнерський серверний чат і один MCP-сервер, який запускає Shiffty (5 жовтня 2026). Вбудований віджет Agentfy не використовується, а чат малюється всередині застосунку Shiffty. Див. Інтеграцію з Agentfy.

• Один агент на магазин; одна компанія — одна команда Agentfy (5 жовтня 2026). Керівник і працівники магазину говорять з тим самим агентом, кожен від свого імені. Див. Інтеграцію з Agentfy.

• У першій версії працівник належить рівно до одного магазину; керівник може вести кілька (5 жовтня 2026). 11 жовтня 2026 замінено пунктом нижче: тепер і керівник має один магазин.

• Агент магазину створюється автоматично, коли створюється магазин (5 жовтня 2026). Для цього оператор Agentfy має це ввімкнути; див. що має бути правдою спершу.

• Власний вхід Shiffty, а не Neon Auth (6 жовтня 2026). Пошта й пароль, які зберігає API Shiffty, як в інших наших продуктах. Див. Екрани.

• Власник, його магазини, керівники магазинів і люди кожного керівника (11 жовтня 2026). Див. Хто на кого працює нижче.

• Графіки показуються в часовому поясі магазину, а не того, хто дивиться (11 жовтня 2026). Кожен магазин має часовий пояс; дні, «сьогодні» й час його графіка — час магазину, хоч би де був той, хто дивиться. Див. Структура даних.

• Одна сітка графіка для всіх, із фільтром (14 жовтня 2026). Тиждень магазину показує його керівників і працівників в одній таблиці, спершу керівників, а фільтр вибирає, чиї рядки показано, — за роллю, за керівником, якому підпорядковуються, за людиною й за ділянкою. Години, підсумки й попередження лишаються по всьому магазину, хоч би що було відфільтровано. Це скасовує попереднє рішення власника (11 жовтня 2026) тримати графіки команди й керівників окремо, на двох вкладках, ніколи не додаючи. Див. Екрани.

• Жодного асистента в застосунку, доки він не готовий; жодної заміни Agentfy (14 жовтня 2026). З 14 по 19 жовтня 2026 вкладка Assistant кожної ролі казала «In development» і що все робиться вручну на інших вкладках; посилання, які відкрили б асистента, було приховано, і не показувалися ні демо за сценарієм, ні чат. Локальну заміну Agentfy в API та її таблиці видалено, і це лишається чинним; справжня інтеграція лишається. Частину про асистента замінено 19 жовтня 2026 пунктом нижче.

• Асистента знову ввімкнено, назавжди (19 жовтня 2026). Власник уручну пройшов увесь ланцюжок з локальним Agentfy і знову ввімкнув асистента. Його показують, коли API каже, що він доступний людині, — Shiffty підключено до Agentfy, чат увімкнено й агент її магазину готовий, — а інакше вкладка Assistant каже чому й хто може це виправити. Демо за сценарієм видалено, запасного варіанта за сценарієм немає. Після входу людина потрапляє на вкладку Assistant, коли вона доступна, а інакше на Schedules (власник, керівник) або My shifts (працівник); власник, у якого до 20 жовтня 2026 асистента не було, завжди потрапляв на Schedules, а тепер теж потрапляє на вкладку Assistant, коли його асистент доступний. Створено, перевірено лише з локальним Agentfy, не розгорнуто. Див. Інтеграцію з Agentfy і Екрани.

• Що може асистент і як (19 жовтня 2026). Зрештою асистент магазину робить усе, що увійшлий керівник чи працівник може зробити в застосунку, з правами цієї людини й за тими самими правилами, що й застосунок, зокрема деактивацію людей чи видалення змін там, де людині це дозволено. Він не схвалює й не відхиляє запити на зміни й не публікує графіки — поки що; коли додасться розв'язувач, агент будуватиме графіки й вирішуватиме щодо запитів, а доти інструментів для цього немає. Асистента для власника чи для всієї компанії немає: один агент на магазин, а власник робить свої справи в застосунку (замінено 20 жовтня 2026, нижче). Інструменти пишуться вручну, кожен завбільшки із задачу, а не генеруються з API. Перший крок — один каталог інструментів і дев'ять інструментів читання — створено, не розгорнуто. Див. Інструменти агента.

• Асистент для власника (20 жовтня 2026). Це замінює «асистента для власника чи для всієї компанії немає» від 19 жовтня 2026 (вище). Власник отримує власного асистента — один агент на компанію, поруч з агентами магазинів — з усім, що власникові дозволено робити в застосунку: усі магазини, керівники теж. Кожна зміна — картка, яку підтверджує власник, з повторною перевіркою під час підтвердження; для читання картка не потрібна. Публікувати тиждень дозволено лише власникові, як картку, яку власник підтверджує; асистент керівника й далі не може публікувати. Хто питає і що йому дозволено, береться лише з увійшлого власника, ніколи не від моделі. Створено, перевірено тестами, звірено лише з локальним Agentfy, не розгорнуто. Див. Інструменти агента та Інтеграцію з Agentfy.

• Розв'язувач будує тижні й зважує запити; публікація лишається за людьми (19 жовтня 2026). Власник додав розв'язувач, якого викликає агент: він пропонує тиждень для команди магазину й зважує запит на зміну, а агент може підготувати схвалення чи відхилення керівника. Це знімає «жодних інструментів для схвалення й відхилення, доки немає розв'язувача» з пункту вище — як інструменти рівня propose: керівник підтверджує кожну картку в застосунку, і підтвердження виконує звичайне схвалення чи відхилення або записує тиждень у чернетку. Публікація тижня лишається дією людини, без інструмента; так само скасування рішення. Створено в API, перевірено на демо-магазинах із початкових даних; три його інструменти в каталозі агента; не розгорнуто. Див. Агент і розв'язувач та Інструменти агента.

• Агент читає описи людей в обмеження для розв'язувача (20 жовтня 2026). Агент перетворює те, що опис людини прямо каже про те, коли чи де вона працює, на обмеження для розв'язувача — кожне зі словами, з яких його взято, — і керівник бачить кожне, і кожне пропущене, на картці до підтвердження; хибне прочитання виправляє керівник. Поля доступності в профілі людини можуть з'явитися згодом; не вирішено. Створено в API та застосунку, перевірено, один раз перевірено з локальним Agentfy; не розгорнуто. Див. Агент і розв'язувач.

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

Реалізовано лише вхід, ролі, запрошення, графіки, запити на зміни й чат асистента, і лише частково — див. Що створено. Розміщений Agentfy не під'єднано; асистента перевіряли лише з локальним.

Хто на кого працює

Вирішено власником 11 жовтня 2026:

• Один власник, багато магазинів; у магазині можуть бути керівники; у кожного керівника — свої люди. Працівник підпорядковується конкретному керівникові того самого магазину або — з 23 жовтня 2026, за рішенням власника, — жодному: магазин може вести сам власник із кількома працівниками, і тоді щодо запитів цих працівників вирішує власник.
• Компанія — це бізнес власника (наприклад, мережа Morgan Retail). Списку компаній, з якого треба вибирати, немає: кожна людина має рівно одне місце — власник свою компанію, усі інші один магазин. Це замінює «керівник може вести кілька магазинів» (5 жовтня 2026).
• Самі реєструються лише власники. Керівники й працівники приєднуються за запрошенням від власника (з 19 жовтня 2026 керівник теж запрошує працівників до свого магазину); до 15 жовтня 2026 лист не надсилався і власник передавав посилання сам — відтоді воно надсилається листом (SHIF-25), і його, як і раніше, можна передати.
• Власник входить лише після схвалення адміністратором платформи (рішення власника проєкту від 23 жовтня 2026). Реєстрація — це заявка на приєднання; доки її не схвалять, власник не може увійти, і йому кажуть чому. Схвалення робить компанію активною і підключає її асистента, який відтоді й створює команду компанії в Agentfy. Того ж дня, у відповідях на питання щодо зміни: відхилений заявник може подати заявку знову з тією самою поштою; адміністратор платформи може вимкнути схвалену компанію (ніхто з неї не входить, нічого не видаляється) й увімкнути знову; лист адміністраторам про нову заявку каже лише, хто її подав. Запрошення не змінилися. Створено; див. Що створено.
• Наявні тестові дані можна було видалити, а демо-компанію заново створює скрипт заповнення на машині розробника.

Чому: саме так влаштовані магазини, які ми маємо на увазі, — власник вирішує щодо керівників, керівник — щодо своїх людей, — і прототипи для трьох ролей намальовано саме так. Що керівник може затверджувати і для кого, випливає з цього і буде створено пізніше, разом із запитами на зміни.

Ринок

• Чому ми, а не Deputy чи схожі інструменти? Див. огляд ринку, конкурентне середовище та Deputy і наш підхід. Автоматичне складання графіків — уже стандарт, а великі постачальники вже заявляють обмін змінами природною мовою з погодженням керівника. Нам потрібна причина, зрозуміла керівникові магазину, а не перелік функцій, і знайти її треба раніше, ніж Deputy чи схожий інструмент додасть чат для працівників.
• З якого сегмента рітейлу почати? Галузь вирішено: лише рітейл. Відкрито інше: окремі магазини чи невеликі мережі, продуктові чи інші формати.
• З якої країни почати? З огляду на наш досвід природні кандидати — Україна та її сусіди, і, як показує конкурентне середовище, розмовного інструмента для графіків там поки немає. Трудові правила та звички щодо месенджерів у різних країнах різні, тож цей вибір визначить першу версію.
• Хто платить і скільки? Ціну ще не визначено. Інструменти для малого бізнесу коштують $2–9 за користувача на місяць або $30–120 за точку, тож ціну доведеться обґрунтовувати зекономленими годинами керівника.

Перевірка проблеми

• Скільки часу керівники зараз витрачають на складання графіків?
• Як часто графік змінюється після публікації і хто цим займається?
• Скільки коштує типовому магазину надлишок і нестача персоналу?

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

Продукт

• Агент чи розв'язувач. Наше робоче припущення: агент перетворює запити на обмеження, а розв'язувач складає графік. Див. Складання графіка та Агент і розв'язувач. Це треба підтвердити прототипом.
• Месенджер як другий канал. Перший канал — наш власний застосунок. Чи зможуть працівники писати ще й із Telegram, Viber або WhatsApp, не вирішено. Див. Асистент для працівників.
• Інструменти асистента: вибори, зроблені під час створення кроку 1 (19 жовтня 2026, на підтвердження власнику). Дозвіл розмови тепер зберігає можливості («schedule.read», «requests.submit»), а не назви інструментів. store_people не показує адрес пошти людей. Надсилання свого підтвердженого запиту лишається прямою дією, як і було. Два наступні кроки впиралися в права того дня: опис магазину та його години змінював лише власник, і деактивація людей, зміна їхнього керівника та запрошення були теж його. Власник дав керівникам ці права для працівників їхнього магазину 19 жовтня 2026 (вище), і з кроку 3, створеного того ж дня, вони стали інструментами. Див. Інструменти агента.
• Розв'язувач: вибори, зроблені під час його створення (19 жовтня 2026, на підтвердження власнику). Правило 11 год відпочинку — жорстке для змін, які додає розв'язувач, а вручну лишається попередженням. Ваги цілі — каса-години без касира й прогалини без чергового 10 000 за годину, переробка 100 за годину, змінена зміна 40, справедливість 8 і 1 — наш вибір, а не вимірювання. Рішення, підтверджене з картки асистента, записується як рішення керівника («person»), а не «асистента». План керівника не чіпає рядків керівників, які належать власникові, тож прогалини без чергового керівника називаються, але не закриваються. Див. Агент і розв'язувач.
• Вхід у демо. У плані на 18 жовтня замість справжнього входу — перемикач ролей; чи лишиться так, треба підтвердити — тепер, коли мінімальний справжній вхід уже є (6 жовтня 2026). Див. Два тижні до демо.
• Усе технічне, крім інструментів. Хостинг, мовна модель, сповіщення і те, де зберігаються дані працівників. Див. Архітектуру.
• Затвердження. У демо кожну зміну затверджує керівник. Чи влаштує це керівників, ще треба з’ясувати; автоматичне затвердження до плану не входить.
• Дані про відвідуваність. Які джерела насправді є в магазинів. Див. Вхідні дані. З 14 жовтня 2026 звичайну кількість чеків по годинах можна ввести вручну; чи можуть магазини її вивантажувати і як вона перетвориться на кількість людей, досі відкрите питання; стале співвідношення чеків на касира в денному вигляді (16 жовтня 2026) — одна відповідь, власникові її ще підтвердити.
• Описи магазинів і людей та хто їх бачить (зроблено 14 жовтня 2026, чекає підтвердження власника). Магазин і кожна людина мають опис простим текстом — контекст для майбутнього асистента; поки його ніщо не читає. Три рішення ухвалено під час розробки, і вони чекають власника: людина ніколи не бачить власного опису, а керівник бачить лише описи працівників свого магазину, не інших керівників (приватність); керівник описує будь-якого працівника магазину, а не лише своїх людей; погодинне навантаження магазину редагують не лише власник, а й керівники магазину, бо вони знають його відвідуваність. Див. Структуру даних.
• Одна сітка та її фільтр (зроблено 14 жовтня 2026, чекає на підтвердження власника). Під час розробки ухвалено три рішення. Керівник бачить ті самі рядки, що й раніше — керівників свого магазину теж, лише для перегляду, — тож нічого не розширено; чи мають керівники й далі бачити рядки інших керівників — питання до власника. Список тижнів магазину тепер показує зміни, години й понаднормові всіх разом, бо в сітці більше немає груп. Під час переходу до іншого магазину роль і ділянка у фільтрі зберігаються, а вибрані люди й керівник скидаються: вони належать до попереднього магазину. Див. Екрани.
• Розділені зміни (зроблено 14 жовтня 2026, чекає на підтвердження власника). Тепер людина може мати кілька змін в один день, наприклад 12:00–14:00 і 18:00–20:00; зміни одного дня можуть торкатися, але не перетинатися. Відкрито: чи правильна межа — три на день (вибрана під час розробки); чи потрібен мінімальний проміжок між змінами одного дня (зараз його немає); і чи може людина взяти вихідний лише на частину розділеного дня — зараз вихідний і заміна беруть кожну зміну дня, а обмін та інші години стосуються однієї зміни. Див. Структуру даних.
• Причина при кожному відхиленні (правило власника, зроблено 14 жовтня 2026). Керівник або власник, відхиляючи запит на зміну, мусить пояснити чому, від 3 до 500 символів (межі підтверджено власником 14 жовтня 2026), і працівник це бачить. Відкрито для власника: чи має колега, який відмовляється підмінити або помінятися, теж мати змогу назвати причину — необов'язкову, адже колега не вирішує, — чи все лишається як зараз, без неї; і те, що Undo стирає причину, тож при новому відхиленні її питають знову. Див. Структуру даних.
• Хто схвалив зміну (правило власника, зроблено 14 жовтня 2026). Графік, «Мої зміни», діалог зміни та списки запитів кажуть, хто схвалив зміну, або «Approved automatically». Рішення записує, як його ухвалено, — людиною, автоматично чи асистентом, — хоча зараз вирішує лише людина. Вирішено власником (14 жовтня 2026): керівники бачать, хто змінював графік — власник і кожен керівник магазину бачать на сітці, хто схвалив кожну зміну, тож керівник бачить і «Approved by Alex Morgan» на зміні іншого керівника; працівники бачать це на своїх змінах, у «Моїх змінах». Відкрито для власника: чи має щось схвалюватися автоматично взагалі і які зміни; і те, що минулі рішення без людини вважаються автоматичними (таких немає: досі схвалення мусило називати людину). Див. Структуру даних.
• Денний вигляд і аркуш місяця (зроблено 16 жовтня 2026, чекає підтвердження власника). Під час створення зроблено три вибори. Як люди рахуються по годинах: у людино-годинах — людина входить у годину тією частиною, яку вона там перебуває, мінус перерва з відомим початком; перерва без часу початку не віднімається, тож ця людина вважається присутньою всю зміну. Потрібно кас = чеки ÷ чеків на касира за годину, з округленням угору, не менше однієї, поки магазин відкритий, — нове налаштування магазину, 80, доки не змінять, його редагують власник і керівники магазину, як погодинне навантаження. Договір за місяць = години на тиждень × днів у місяці ÷ 7, тож частково покритий тиждень рахується за своїми днями в місяці; вихідні рахуються лише в тижнях, що мають графік. Див. Структуру даних.

Ризики

• Трудове законодавство. Правила різняться залежно від країни та договору. Хто відповідає, якщо згенерований графік якесь із них порушить?
• Дані працівників. Доступність, відсутності та особисті причини — чутлива інформація. Де зберігаються дані і хто їх бачить, треба визначити ще до будь-якого пілоту.
• Довіра. Керівник, який не розуміє, чому агент обрав саме таку зміну, переробить усе вручну.

Наступний крок

Наступний крок — двотижневий план демо: MVP лише в браузері до 18 жовтня 2026 на заздалегідь заповнених даних одного вигаданого магазину. Кожну зміну затверджував би керівник. Це замінює найближчу пропозицію почати з реальних даних магазину; перевірка з реальним магазином залишається подальшою роботою, а не наявним пілотом.