Два тижні до демо
План · написано 4 жовтня 2026 · орієнтири, не зобов'язання · роботу ще не розпочато
Мета — MVP лише в браузері, який можна показати 18 жовтня 2026: запропоноване демо провело б один вигаданий магазин від чернетки графіка до вихідного для працівника із затвердженням зміни керівником.
За два тижні треба зрозуміти, чи варто розвивати весь шлях: графік, який люди розуміють, і зміну, яку вони можуть погодити.
Власник визначив мету й межі: один застосунок, дві ролі, кожну зміну затверджує керівник. Перший розв'язувач — YALPS; стек — API на NestJS і застосунок на Nuxt, організовані за CleanSlice. Це прийняті напрями, а не реалізації. Демо — лише веб: Capacitor буде пізніше, месенджери до цього плану не входять. Усе інше нижче — пропозиції; дати є орієнтирами.
Що означає «можна показати»
Запропоноване демо працювало б у браузері на ноутбуці: один ілюстративний магазин із заздалегідь заповненими даними та перемикання ролей замість входу. Запропонований сценарій за порядком:
- Керівник відкрив би магазин і побачив уже заповнені команду, правила та погодинну відвідуваність.
- Він попросив би графік на наступний тиждень. З'явилася б чернетка з погодинним покриттям відносно відвідуваності, видимими нестачею людей і понаднормовими годинами та коротким поясненням: «Бен починає о 10:00, бо в обідній пік потрібні троє людей».
- Він змінив би одну річ словами — «дай Хлої менше змін із закриттям» — і побачив би зміну чернетки. Додатково, якщо вистачить часу: прибрати першим за браку часу.
- Він опублікував би графік.
- Демонстратор перемкнувся б на працівника, побачив його зміни та запитав асистента: «Можна мені вихідний у суботу?»
- Асистент знайшов би, хто може підмінити без порушення відпочинку, годин чи доступності, запропонував би варіант із найменшими змінами та запитав колегу.
- Демонстратор перемкнувся б на колегу й погодився, потім — на керівника, який побачив би одну готову зміну й затвердив її однією дією.
- Опублікований графік оновився б для всіх.
Усі люди й числа в демо були б вигаданими; реального магазину немає. Ілюстративні адреси пошти використовували б example.com, наприклад [email protected]. Репліки — ілюстрація, а не результат роботи системи.
Що входить і не входить до плану
Пропонується включити: вісім кроків вище, причому крок 3 — додатковий; заздалегідь заповнені дані одного магазину приблизно з дюжиною працівників, на один тиждень, із погодинною відвідуваністю та чотирма шаблонами ковзних змін. Вхідні правила охоплювали б доступність, відсутності, мінімальний відпочинок, максимальні години за тиждень і тривалість зміни. Демо також обмежувало б роботу однією зміною на день, вимагало хоча б одного працівника з ключами в усі години роботи та показувало потрібну кількість людей щогодини. Список «що чекає на ваше рішення» всередині застосунку замінив би сповіщення.
Не входить до цього плану: Capacitor і все мобільне; месенджери; реєстрація, запрошення та облікові записи (замість них — перемикання ролей); реальне трудове право будь-якої країни; імпорт таблиць (замість нього — готові дані, імпорт лише за наявності часу); інтеграції з касами й лічильниками відвідувачів; більше одного магазину; панель адміністратора; публічний сайт; хостинг і розгортання продукту. Запропоноване демо запускалося б локально через make dev. Нічого не затверджувалося б автоматично.
Робота за порядком
План передбачає одного розробника з агентами в робочих копіях Orca, одне завдання на копію. Якщо це припущення хибне, дати зсуваються. Запропоновані пакети робіт нижче залежать від попередніх основ; це не обіцянки денного виробітку.
Тиждень 1 — з'являється графік: 6–10 жовтня
| Пакет робіт | Залежить від | Запропонований результат |
|---|---|---|
| День 1: рішення та каркас | Підтвердження варіантів нижче | Підготувати API й застосунок поруч із документацією в цьому репозиторії на зарезервованих у реєстрі портах кореневої копії: 4182 для API та 4180 для застосунку. Розширити make dev і скрипти робочих копій для запуску обох компонентів, у кожній робочій копії — на її виділених портах. Порожня сторінка зверталася б до порожнього API. |
| Магазин у даних | Рішень і каркаса першого дня | Описати магазин, ролі, працівників, доступність, відсутності, правила, погодинну відвідуваність, шаблони змін, графік, зміни та запити на зміни; заповнити їх для ілюстративного магазину. |
| Розв'язувач | Готових даних і погоджених правил | Поставити YALPS за чотирма інструментами зі сторінки Агент і розв'язувач: скласти графік, перевірити зміну, знайти підміну, пояснити відмову. Показувати непокриті години, а не приховувати: допускати видиму нестачу покриття зі штрафом під час порівняння чернеток, зберігаючи жорсткі правила. Спершу довести, що тиждень для дюжини людей узагалі розв'язується; сторінка розв'язувача називає це першим ризиком прототипу. |
| Екрани керівника | Даних магазину, потім розв'язувача для генерації | Показувати магазин, команду, правила й відвідуваність із простими правками; створювати чернетку, порівнювати покриття за годинами й публікувати. |
Тиждень 2 — люди розмовляють із застосунком: 13–17 жовтня
| Пакет робіт | Залежить від | Запропонований результат |
|---|---|---|
| Пояснення | Результатів розв'язувача й подробиць відмови | Агент перетворював би результати на короткі пояснення з кроку 2, а відмови — на «які години, яке правило, що допоможе». |
| Екрани працівника й асистент | Опублікованого графіка та інструментів перевірки й підміни | Мої зміни, чат і шлях від запиту до пропозиції підміни та запитання колезі. |
| Затвердження | Пропозиції підміни та екранів працівника | Колега міг би погодитися, керівник — вирішити однією дією; графік оновлювався б. Обидві ролі отримали б список очікуваних рішень. |
| Зміни словами для керівника — додатково | Робочих генерації, пояснень і перевірки правил | Крок 3: зміна чернетки на прохання словами. |
| Дані, сценарій і репетиція демо — 16–17 жовтня | Поєднаного сценарію вище | Двічі пройти вісім кроків, виправити збої та записати, що прибрали. Якщо крок 3 прибрано, позначити його пропуск в обох репетиціях. |
| Документація | Підтвердження того, що справді запускається | Оновити Архітектуру, DevOps і статуси продуктових сторінок на «реалізовано, не перевірено від початку до кінця» лише для того, що справді працює. Статус усього іншого не змінювати. |
18 жовтня 2026 — цільова дата показу. Жоден пакет робіт ще не розпочато.
Запропоновані рішення для підтвердження в перший день
Кожен рядок — пропозиція; підтвердити в перший день. Жоден не закриває відкриті питання продукту загалом.
| Вибір | Пропозиція | Навіщо | Ціна подальшої заміни |
|---|---|---|---|
| База даних | PostgreSQL через Prisma, як в інших наших продуктах; перед використанням зарезервувати порт бази в реєстрі. | Звичний спосіб зберігати дані демо. | Переписати доступ до даних, перенести наявні дані й переглянути локальний запуск. |
| Мовна модель | Claude API лише для розуміння запитів і пояснень. Модель не складала б і не затверджувала графік. Залишити шаблонні пояснення як запасний варіант. | Перевірити діалог і зберегти можливість показу без мережі. | Адаптувати обробку запитів і пояснень, наново перевірити розмови демо. |
| Модель графіка | Чотири шаблони змін на день, як на сторінці проблеми, замість вільних початку й кінця; один тиждень за раз. | Обмежити перший експеримент з огляду на ризик розміру задачі зі сторінки розв'язувача. | Переробити модель складання графіка, початкові дані й перевірки покриття. |
| Згода й затвердження | Згода колеги та затвердження керівника всередині застосунку з перемиканням ролей; нічого нікуди не надсилати. | Показати все погодження без облікових записів і зовнішньої доставки. | Реальні користувачі й доставка потребували б перевірок доступу та нового процесу погодження. |
Ризики й що прибрати першим
- YALPS не впорається з реалістичним магазином за прийнятний час. Спробувати грубішу модель, потім менший магазин, потім highs-js — запасний варіант зі сторінки розв'язувача. Час розв'язання ми не вимірювали.
- Мовна модель ненадійна в день показу. Використати шаблонні пояснення та заздалегідь заданий шлях асистента для одного демонстраційного запиту; повідомити про запасний варіант під час показу.
- Бракує часу. Прибирати в такому порядку: зміни словами для керівника; побажання та справедливість як м'які правила; імпорт таблиць (якщо додали понад основне); правки відвідуваності; усе косметичне. Жорсткі правила й затвердження керівником залишаються.
- Демо нікого не переконало. Це результат, а не провал. Записати його у Відкриті питання.
Критерій готовності до 18 жовтня
Мета — вісім кроків від початку до кінця на заповненому магазині після make dev, двічі поспіль, у виконанні людини, яка не створювала демо; make check має бути зеленим, а документація — описувати наявне. Якщо додатковий крок 3 прибрано, сценарій має прямо це сказати; решта кроків однаково мають пройти двічі. Це орієнтир, а не твердження, що сьогодні щось працює.
Куди далі
- Архітектура: прийнятий напрям застосунку й API за межами демо.
- Агент і розв'язувач: чотири інструменти й перший ризик розв'язувача для перевірки.
- Шлях користувача: запропонований шлях керівника та працівника.
- Відкриті питання: де ще потрібні рішення чи докази.