Mitty Roadmap

Mitty — Employee OS для компаний 50–1000 человек. Основной фокус: связать людей, структуру, поля, согласования, документы и отпуска в работающие пользовательские сценарии.

Снимок составлен по коду и документации: сервер 31c1d1e68, веб-клиент 5ff723d1. «Реализовано» означает наличие в этих версиях кода; выкладка и прохождение пользовательского сценария отдельно не подтверждены. Даты разделов — даты сверки, а не обещания релиза.

• Есть на сервере и в веб-клиенте: каталог людей, профили, оргсхема и отделы, роли и доступ, настраиваемые поля и история значений, согласования и аудит, настройка организации и обзор её состояния.
• Есть на сервере; основные web-экраны предстоит подключить: Time off и документооборот. Маршруты /time-off и /documents пока показывают заглушки.
• Требуется синхронизация веб-клиента с новыми серверными сценариями: вход по email-коду, подтверждение необычного входа, повторная отправка кода и ограничения удаления способов входа.
• Начата серверная связка согласований и документов: построены объект требования документа и передача результата подписания. Весь единый процесс изменений ещё не завершён.

Предлагаемый порядок по текущему разрыву между сервером и клиентом; единая утверждённая очередь работ этим снимком не подтверждается.

1. Сверить и подключить актуальный контракт входа и безопасности аккаунта: email-код, подтверждение входа, повторная отправка, истёкшие ссылки и защита от удаления последнего нужного способа входа.
2. Проверить актуальную связку полей и согласований: замены согласующих, предупреждения о конфликтующих изменениях, перенос даты, история и доступность действий по ролям.
3. Заменить заглушку Time off пользовательскими сценариями: свой баланс и заявка, список отсутствующих, решения руководителя, настройки HR. Учитывать ограничения серверной модели.
4. Заменить заглушку документов сценариями шаблона, отправки, подписания, статуса и получения своего документа; административные функции добавлять по отдельным сценариям.
5. Проверить весь путь разными участниками: сотрудник → руководитель → HR. Зафиксировать совместно проверенные версии сервера и веб-клиента.

Критерий готовности: пользователь завершает сценарий на реальных данных; отказ в доступе, конфликт и повторное действие дают понятный результат; проверки относятся к конкретным версиям обоих проектов.

• Продолжить общий процесс: изменение данных → согласование → необходимый документ → вступление изменения в силу.
• Подключить требования документов к движку согласований, затем общий контекст шаблонов и изменения нескольких полей.
• Перевести Time off на общий движок по существующему плану; наличие отдельного серверного модуля отпусков не означает, что этот переход уже завершён.
• Добавлять документы после применения изменения и на дату вступления, а внешнее подписание вести отдельным этапом.

Критерий готовности: итог согласования и подписания определяет один согласованный исход изменения; участники видят статус и причину остановки, повторная доставка события не применяет изменение дважды.

• Завершить и проверить AWS-настройку базы, хранилища документов, резервных копий и восстановления по действующим инструкциям владельца.
• Проверить сохранность документов, экспорт, удаление данных и завершение обслуживания организации в целевом окружении.
• Выполнить продуктовые проверки по правилам server/front и зафиксировать ограничения перед выпуском.
• Подтвердить облачную конфигурацию и выкладку отдельно от наличия кода и CI-файлов.

Критерий готовности: известны проверенные версии, пройденные сценарии, процедура восстановления и оставшиеся ограничения. Срок публичного запуска определяется после этой проверки.

• AI-онбординг и миграция из других HR-систем поверх существующего Setup Journey.
• Полноценные рабочие графики и смены; расписания внутри Time off не считать готовым модулем управления рабочим временем.
• Подготовка и передача payroll-данных во внешние системы; отдельная спецификация не означает готового расчёта зарплат.
• Stories / Moments, расширенная аналитика и интеграции — по спецификациям и отдельному приоритету.
• Нативные приложения, Telegram, часы и offline — отдельные направления. Их готовность и сроки не выводятся из состояния server/front.

Старые календарные планы сохранены в истории. Обязательства по кварталам, публикации приложений и коммерческим условиям требуют нового подтверждения.

Сверены конфигурации и документация в локальных версиях сервера 31c1d1e68 и веб-клиента 5ff723d1. Работающие облачные ресурсы и production-выкладка не проверялись.

• Сервер: раздельные процессы API, Worker и Scheduler; PostgreSQL, Redis, очереди и наблюдаемость описаны в текущей архитектуре.
• Проверки сервера: verify, интеграционные тесты с реальной PostgreSQL и firewall-проверки включены в GitHub Actions. Наличие workflow не подтверждает успешный запуск на текущем коммите.
• Веб-клиент: pipeline для Cloudflare Pages включает проверки, сборку, тесты и иконки. Фактическая выкладка и облачные секреты не проверены.
• Направление хранения данных: AWS по актуальному продуктовому контексту. Для хранилища документов есть отдельный AWS-runbook; CDN и статические assets рассматриваются отдельно. Cloudflare Pages веб-клиента не означает хранения всех данных в Cloudflare.

1. Выполнить checklist целевого окружения: база, нужные расширения PostgreSQL, хранилище документов, ключи, роли процессов и регион данных.
2. Подтвердить резервную копию и восстановление документов по runbook, проверить соответствие восстановленного файла подписанному результату.
3. Проверить экспорт архива, завершение обслуживания организации и удаление из основного и резервного хранилищ.
4. Сверить запущенные версии API, Worker, Scheduler и веб-клиента; проверить доступность зависимых сервисов и понятные отказы при их недоступности.
5. Зафиксировать фактические результаты CI и сквозных сценариев на этих версиях перед публикацией.

Это checklist к эксплуатации, а не отметка о выполненных облачных работах. Настройка ресурсов производится по действующим правилам и полномочиям владельца.

• Продолжить трек региона хранения данных организации по текущим решениям; не объявлять multi-region готовым по одному описанию архитектуры.
• Подтвердить регулярную проверку восстановления, мониторинг фоновых задач и обработку ошибок доставки/экспорта.
• Обновлять сведения об окружении вместе с релизами и изменениями инструкций, сохраняя источник и дату проверки.
• Общий Harness хранит ссылки на проекты и контекст; продуктовые проверки и deployment остаются в соответствующих репозиториях.

Снимок по серверу 31c1d1e68 и веб-клиенту 5ff723d1 на 20 октября 2026. Реализованный backend, подключённый экран и проверенный пользовательский сценарий — разные статусы. В этом обновлении сверены код и документы; приложения и облачные окружения не запускались.

Направление продукта: международная Employee OS для компаний 50–1000 человек; сначала английский язык, затем многоязычность. Страновые особенности должны задаваться данными и настройками. Старые ориентиры на РФ, фиксированные условия early access и даты запуска не являются текущими подтверждёнными обязательствами.

Реализовано в коде server/front

• Каталог людей и карточки сотрудников, собственный профиль, отделы и оргсхема.
• Настройка ролей, охвата доступа и отображения данных по доступным пользователю возможностям.
• Конструктор полей, настройка профиля, значения полей и их история.
• Экран onboarding/offboarding и серверные процессы с шаблонами и задачами; документы и будущая AI-настройка — отдельные этапы.

Дальше

• Сквозная проверка каталога, профиля, отдела и оргсхемы для сотрудника, руководителя и HR.
• Проверка скрытых данных, будущего ухода сотрудника и изменения доступа в связанных экранах.
• Подключение изменений полей, согласований и документов без расходящихся состояний и повторной ручной настройки.

Реализовано в коде server/front

• Заявки на согласование, путь согласования и настройки правил.
• Изменения полей через согласование, история, перенос даты и обработка устаревших изменений.
• Последние клиентские доработки: замена согласующего отображается как одно место в пути; показано, кто кого заменяет; обновлены формы полей и сообщений согласований.

Следующий шаг

• Сверить клиент с последними серверными контрактами предупреждений, конфликтов, переноса даты и прав на действия.
• Завершить общую связку «требование документа → согласование → подписание → применение изменения».
• Уже есть серверные части первых волн: объект требования документа и получение результата подписания. Полный общий процесс пока не объявляется завершённым.

Сервер реализован; основной web-экран пока заглушка

• Типы отсутствий, политики, балансы, заявки и решения, рабочие шаблоны и календари внутри модели отпусков.
• Уведомления о заявке, изменениях и ограничениях видимости.
• Последние серверные изменения: правила типов, учёт дат изменения рабочего времени и неполной занятости при начислении, расчёт ухода сотрудника.

Следующий шаг

• Web: собственный баланс и заявка, кто отсутствует, очередь решений руководителя, настройки HR и состояния ошибок.
• Связь с общим движком согласований и требованиями документов по плану волн G1/G2.
• Продолжить серверные пункты по балансу в днях при изменении часов и другие явно отложенные сценарии; не считать их закрытыми по наличию учёта неполной занятости.

Известный предел

• Начисление для нерегулярных часов и part-year workers ещё не заявлено как готовое; в действующей продуктовой странице указан ручной ввод HR.
• Рабочие шаблоны для расчёта отпуска не равны модулю смен, табеля и check-in/out.

Сервер реализован; основной web-экран пока заглушка

• Шаблоны, отправка документов, последовательность подписания и получение подписанного результата.
• Проверки сохранности подписанных файлов, замена ключей, архив и процедуры завершения обслуживания организации предусмотрены серверным кодом; настройка облака требует отдельной проверки.
• Требования документов и передача исхода подписания подготовлены как части общего процесса изменений.

Следующий шаг

• Web: шаблоны и настройка, отправка, действия подписанта, статусы и причины ожидания, получение своего документа и архива по доступу.
• Соединить документы с согласованиями, изменениями данных и onboarding/offboarding.
• Внешнее подписание и дополнительные уровни электронной подписи вести отдельными этапами; наличие внутреннего подписания не подтверждает их реализацию.

Есть основа server/front

• Регистрация и вход, управление аккаунтом, компаниями и сессиями; сервер поддерживает пароль, passkeys, Google и корпоративный OpenID Connect.

Серверные обновления требуют завершения клиентских сценариев

• Вход по коду из email, подтверждение входа с нового устройства и повторная отправка кода/письма.
• Обработка истёкших и использованных ссылок до ввода нового пароля.
• Защита от удаления последнего или обязательного для компании способа входа.
• Защита аккаунта через сценарий «Это был не я» с понятным подтверждением действия.

Критерий готовности: весь сценарий проходится с экрана до результата на сервере, включая повтор, истечение срока, ограничения компании и восстановление доступа. Наличие серверного endpoint само по себе не закрывает пункт.

• Обзор организации: серверные источники Setup Journey, состояния системы и приоритетных действий; во фронтенде есть соответствующие компоненты обзора. Полноту данных проверять на целевом окружении.
• Аудит и realtime: серверная инфраструктура и клиентские читатели существуют; изменения полей и согласований должны согласованно отражаться в списках и открытых формах.
• Интеграции: серверный каталог подключений и клиент mitty-ai — основа для развития, не подтверждение рабочих OAuth/sync-провайдеров и AI-операций в production.
• Расширенная аналитика: /analytics пока заглушка. Обзор организации не означает готовых прогнозов, performance-аналитики и отчётности по найму.

Есть спецификации; реализация требует отдельного этапа

• AI-онбординг и миграция данных из других HR-систем.
• Рабочие графики, смены и контракт с внешними payroll-системами.
• Подготовка и передача payroll-данных; собственный расчёт зарплат этим roadmap не обещается.
• Stories / Moments — после текущих хвостов.

Веб-заглушки; готовность модулей не подтверждена

• Найм, performance review, опросы, активы и расширенная аналитика.
• Общие Requests, My team и Home; готовые согласования и обзор организации не закрывают эти отдельные поверхности.
• Billing, офисы, политики и общий конструктор workflows требуют отдельных сценариев; наличие пункта навигации не считается реализацией.

Отдельный приоритет и проверка готовности

• iOS/Android, Telegram, часы, push-действия и offline.
• Публичный запуск, тарифы и коммерческие условия — после подтверждения основных сценариев и отдельного решения о сроках.

Полный список прежних идей и календарных обещаний сохранён в истории этого репозитория. Он не используется как подтверждение реализации.