Две недели до демо
План · написан 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 за пределами демо.
- Агент и солвер: четыре инструмента и первый риск солвера для проверки.
- Путь пользователя: предлагаемый путь управляющего и сотрудника.
- Открытые вопросы: где ещё нужны решение или доказательства.