add questions

.gitignore

@@ -0,0 +1 @@
+.claude/

ARCHITECTURE.md

@@ -0,0 +1,225 @@
+# HotelTask - Архитектура системы
+
+## Обзор системы
+
+```mermaid
+flowchart TB
+    subgraph ClientLayer["Client Layer"]
+        WebAdmin["Web Admin<br/>(TypeScript, React)"]
+        MobileApps["Mobile Apps"]
+        TelegramBot["Telegram Bot"]
+    end
+
+    subgraph APIGateway["API Gateway Layer"]
+        REST["REST API"]
+        gRPC["gRPC"]
+        WebSocket["WebSocket"]
+    end
+
+    subgraph ServiceLayer["Service Layer (Python)"]
+        tasks["tasks-service<br/>Управление задачами"]
+        users["users-service<br/>Управление пользователями"]
+        connections["connections-service<br/>Связи между адаптерами"]
+        notification["notification-service<br/>Уведомления"]
+        fileStorage["file-storage-service<br/>Файлы"]
+        audit["audit-service<br/>Аудит"]
+        scheduler["scheduler-service<br/>Расписание"]
+        permissions["permissions-service<br/>Права доступа"]
+        events["events-service<br/>Мероприятия"]
+    end
+
+    subgraph DataLayer["Data Layer"]
+        PostgreSQL[(PostgreSQL<br/>Основная БД)]
+        Redis[(Redis<br/>Кэш)]
+        S3[(S3<br/>Файлы)]
+    end
+
+    subgraph MessageBroker["Message Broker"]
+        Kafka["Apache Kafka"]
+    end
+
+    subgraph AdapterLayer["Adapter Layer (Python)"]
+        PMSAdapter["PMS Adapter"]
+        ERPAdapter["ERP Adapter"]
+        ResonlineAdapter["Resonline Adapter"]
+        TelegramAdapter["Telegram Bot Adapter"]
+        CustomAdapter["Custom Adapter #N"]
+    end
+
+    subgraph ExternalSystems["External Systems"]
+        PMS["PMS"]
+        ERP["ERP"]
+        Resonline["Resonline"]
+    end
+
+    %% Client -> API Gateway
+    WebAdmin --> REST
+    MobileApps --> REST
+    MobileApps --> WebSocket
+    TelegramBot --> REST
+
+    %% API Gateway -> Services
+    REST --> tasks
+    REST --> users
+    REST --> connections
+    gRPC --> tasks
+    gRPC --> users
+    WebSocket --> notification
+
+    %% Services -> Data
+    tasks --> PostgreSQL
+    users --> PostgreSQL
+    connections --> PostgreSQL
+    audit --> PostgreSQL
+    scheduler --> PostgreSQL
+    permissions --> PostgreSQL
+    events --> PostgreSQL
+
+    notification --> Redis
+    tasks --> Redis
+
+    fileStorage --> S3
+
+    %% Services <-> Kafka
+    tasks <--> Kafka
+    notification <--> Kafka
+    connections <--> Kafka
+
+    %% Kafka <-> Adapters
+    Kafka <--> PMSAdapter
+    Kafka <--> ERPAdapter
+    Kafka <--> ResonlineAdapter
+    Kafka <--> TelegramAdapter
+    Kafka <--> CustomAdapter
+
+    %% Adapters -> External Systems
+    PMSAdapter --> PMS
+    ERPAdapter --> ERP
+    ResonlineAdapter --> Resonline
+```
+
+---
+
+## Описание сервисов
+
+| Сервис | Назначение | Ключевые функции |
+|--------|------------|------------------|
+| **tasks-service** | Ядро системы | CRUD задач, статусы, назначение исполнителей, история изменений |
+| **users-service** | Управление пользователями | Регистрация, авторизация, профили, привязка к отелям |
+| **connections-service** | Маршрутизация событий | Настройка связей "событие A → система B", реестр адаптеров |
+| **permissions-service** | Права доступа | RBAC, роли, проверка разрешений |
+| **notification-service** | Уведомления | Push, email, SMS, Telegram, in-app |
+| **file-storage-service** | Файлы | Загрузка/скачивание фото и документов в S3 |
+| **audit-service** | Аудит | Логирование всех действий в системе |
+| **scheduler-service** | Планировщик | Создание задач по расписанию (cron) |
+| **events-service** | Мероприятия | Декомпозиция мероприятий на задачи, генерация "функшн" |
+
+---
+
+## Слои системы
+
+### Client Layer
+Клиентские приложения для взаимодействия с системой:
+- **Web Admin** (React, TypeScript) — админка для управления системой
+- **Mobile Apps** — мобильные приложения для сотрудников
+- **Telegram Bot** — бот для управления задачами
+
+### API Gateway Layer
+Точки входа для клиентов:
+- **REST API** — основной API для веб и мобильных клиентов
+- **gRPC** — высокопроизводительное межсервисное взаимодействие
+- **WebSocket** — real-time уведомления
+
+### Service Layer
+Микросервисы на Python (FastAPI), каждый отвечает за свою domain-область.
+
+### Data Layer
+- **PostgreSQL** — основное хранилище данных
+- **Redis** — кэширование, сессии
+- **S3** — файловое хранилище (фото, документы)
+
+### Message Broker
+**Apache Kafka** — асинхронный обмен сообщениями между сервисами и адаптерами.
+
+### Adapter Layer
+Адаптеры для интеграции с внешними системами. Каждый адаптер:
+- Преобразует данные внешней системы в стандартный формат
+- Работает как по push, так и по pull модели
+- Изолирует логику интеграции от бизнес-логики
+
+### External Systems
+Внешние системы отеля: PMS, ERP, системы управления уборкой и другие.
+
+---
+
+## Потоки данных
+
+### Клиенты → API Gateway
+| Источник | Назначение | Данные |
+|----------|------------|--------|
+| Web Admin | REST API | Запросы на управление задачами, пользователями, настройками |
+| Mobile Apps | REST API | Запросы на работу с задачами, профилем |
+| Mobile Apps | WebSocket | Подписка на real-time уведомления |
+| Telegram Bot | REST API | Команды от пользователей бота |
+
+### API Gateway → Сервисы
+| Источник | Назначение | Данные |
+|----------|------------|--------|
+| REST API | tasks-service | CRUD операции с задачами |
+| REST API | users-service | Авторизация, управление профилями |
+| REST API | connections-service | Настройка связей между адаптерами |
+| gRPC | tasks-service, users-service | Межсервисные синхронные вызовы |
+| WebSocket | notification-service | Подключения клиентов для push-уведомлений |
+
+### Сервисы → Хранилища данных
+| Источник | Назначение | Данные |
+|----------|------------|--------|
+| tasks-service | PostgreSQL | Задачи, статусы, история изменений |
+| users-service | PostgreSQL | Пользователи, профили, привязки к отелям |
+| connections-service | PostgreSQL | Правила маршрутизации, реестр адаптеров |
+| permissions-service | PostgreSQL | Роли, права доступа |
+| audit-service | PostgreSQL | Журнал действий |
+| scheduler-service | PostgreSQL | Расписания, шаблоны задач |
+| events-service | PostgreSQL | Мероприятия, шаблоны декомпозиции |
+| notification-service | Redis | Очереди уведомлений, статусы доставки |
+| tasks-service | Redis | Кэш часто запрашиваемых задач |
+| file-storage-service | S3 | Фотографии, документы, вложения |
+
+### Сервисы ↔ Kafka
+| Сервис | Публикует | Подписан на |
+|--------|-----------|-------------|
+| tasks-service | События задач (создание, изменение статуса) | Команды на создание задач от адаптеров |
+| notification-service | — | События задач для отправки уведомлений |
+| connections-service | Маршрутизированные события | Входящие события от адаптеров |
+
+### Kafka ↔ Адаптеры
+| Адаптер | В Kafka | Из Kafka |
+|---------|---------|----------|
+| PMS Adapter | Бронирования, статусы номеров, данные гостей | Запросы на изменение статуса номера |
+| ERP Adapter | Данные о материалах, заявки | Списания, обновления остатков |
+| Resonline Adapter | Статусы уборки | Задачи на уборку |
+| Telegram Bot Adapter | Сообщения от гостей | Уведомления для отправки |
+
+### Адаптеры → Внешние системы
+| Адаптер | Внешняя система | Данные |
+|---------|-----------------|--------|
+| PMS Adapter | PMS | Синхронизация бронирований и статусов номеров |
+| ERP Adapter | ERP | Синхронизация складских данных |
+| Resonline Adapter | Resonline | Синхронизация задач уборки |
+
+---
+
+## Технологический стек
+
+| Компонент | Технология |
+|-----------|------------|
+| Backend | Python 3.11+ (FastAPI) |
+| Frontend | TypeScript, React |
+| База данных | PostgreSQL 15+ |
+| Кэш | Redis 7+ |
+| Файловое хранилище | S3-compatible (AWS S3 / MinIO) |
+| Message Broker | Apache Kafka |
+| API | REST, gRPC, WebSocket |
+| Аутентификация | JWT / OAuth2 |
+| Контейнеризация | Docker |
+| Оркестрация | Kubernetes |

BUSINESS_REQUIREMENTS.md

@@ -0,0 +1,148 @@
+# HotelTask - Бизнес-требования
+
+> **MVP** — Таск-менеджер для сотрудников отеля.
+> Платформа, состоящая из ряда сервисов, которые решают повседневные задачи, эффективно распределяют ресурсы объекта размещения, а также предоставляют аналитику для улучшения.
+
+---
+
+## 1. Пользователи и роли
+
+Система должна поддерживать следующие роли:
+
+### Администратор системы
+- Управление пользователями
+- Настройка ролей и прав доступа
+- Просмотр всех задач и отчетов
+
+### Менеджер / Супервайзер
+- Создание и распределение задач
+- Контроль статусов выполнения
+- Приоритизация задач
+
+### Линейный сотрудник
+- Просмотр назначенных задач
+- Изменение статуса задачи
+- Добавление комментариев и отметок о выполнении
+
+### API-интерфейс
+- Постановка задач для сотрудников
+- Изменение статуса задачи
+
+---
+
+## 2. Управление пользователями
+
+Система должна обеспечивать:
+- Регистрацию и авторизацию пользователей
+- Назначение ролей пользователям
+- Редактирование профиля пользователя
+- Деактивацию пользователей
+
+---
+
+## 3. Управление задачами
+
+### Создание задачи
+
+Система должна позволять создавать задачу с указанием:
+
+| Поле | Описание |
+|------|----------|
+| **Название** | Краткое название задачи |
+| **Описание** | Детальное описание задачи |
+| **Тип задачи** | Уборка, ремонт, обслуживание гостей и т.д. |
+| **Приоритет** | Низкий / Средний / Высокий / Срочный |
+| **Срок выполнения** | Дедлайн задачи |
+| **Исполнитель** | Ответственный сотрудник |
+| **Супервайзер** | Ответственный менеджер |
+
+### Операции с задачами
+
+- Редактировать задачу
+- Удалять задачу *(при наличии прав)*
+- Назначать и переназначать исполнителей
+- Включать трекинг времени задачи
+
+### Статусы задач
+
+| Статус | Описание |
+|--------|----------|
+| **Новая** | Задача создана, ожидает выполнения |
+| **В работе** | Сотрудник приступил к выполнению |
+| **Ожидает** | Задача приостановлена (ждет чего-то) |
+| **Выполнена** | Задача завершена |
+| **Пауза** | Временно отложена |
+| **Отменена** | Задача отменена |
+
+> Сотрудник должен иметь возможность менять статус своих задач.
+
+---
+
+## 4. Уведомления
+
+Система должна отправлять **push-уведомления**:
+- Сотруднику — о назначении новой задачи
+- Менеджеру — о завершении задачи
+- Напоминания — о приближении срока выполнения
+
+---
+
+## 5. Комментарии и вложения
+
+Система должна позволять:
+- Добавлять комментарии к задачам
+- Прикреплять фотографии или файлы *(например, фото выполненной уборки)*
+- Просматривать историю изменений задачи
+
+---
+
+## 6. Поиск и фильтрация
+
+Система должна обеспечивать:
+
+**Поиск:**
+- По названию задачи
+- По описанию задачи
+
+**Фильтрация:**
+- По статусу
+- По приоритету
+- По сотруднику
+- По дате выполнения
+- По типу задачи
+
+---
+
+## 7. Отчеты и аналитика
+
+Система должна предоставлять:
+- Отчет по выполненным задачам за период
+- Статистику по сотрудникам
+- Статистику по типам задач
+- Процент просроченных задач
+
+---
+
+## 8. Доступ с разных устройств
+
+Система должна:
+- Корректно работать в веб-браузере
+- Поддерживать мобильные устройства *(адаптивный интерфейс)*
+- Иметь мобильное приложение
+
+---
+
+## 9. Интеграции
+
+### PMS (Property Management System)
+
+Система должна взаимодействовать с внешними PMS:
+- Получать бронирования с информацией о гостях и номерах
+- Получать статус номера
+- Изменять статус номера
+
+### Консьерж Resonline
+
+Система должна взаимодействовать с сервисом Консьерж Resonline:
+- Получать данные о заказе в номер
+- Передавать статус заказа

CLAUDE.md

@@ -0,0 +1,36 @@
+# HotelTask - Точка входа для агента
+
+## Промт
+
+Ты работаешь над проектом **HotelTask** — единой платформой управления задачами для отелей.
+
+**Проблема:** В отелях разные подразделения (ресепшен, горничные, техслужба, ресторан) используют разрозненные приложения и мессенджеры. Это ненадежно, информация теряется, ресепшен перегружен.
+
+**Решение:** Система-ядро (Task Manager) со стандартизированным контрактом задач. Внешние системы (PMS, ERP, Housekeeper) подключаются через адаптеры. Коммуникация через Apache Kafka. В админке настраиваются связи между системами.
+
+**Стек:** Python (FastAPI), PostgreSQL, Redis, Kafka, React (админка).
+
+---
+
+## Файлы проекта
+
+| Файл | Зона ответственности |
+|------|---------------------|
+| [CLAUDE.md](CLAUDE.md) | Точка входа агента, промт |
+| [CONTEXT.md](CONTEXT.md) | Память между сессиями, текущий статус |
+| [ROADMAP.md](ROADMAP.md) | Этапы разработки, границы MVP |
+| [BUSINESS_REQUIREMENTS.md](BUSINESS_REQUIREMENTS.md) | Бизнес-требования, роли, функционал |
+| [REQUIREMENTS.md](REQUIREMENTS.md) | Структурированные FR/NFR |
+| [ARCHITECTURE.md](ARCHITECTURE.md) | Архитектура, сервисы, потоки данных |
+
+---
+
+## Инструкции
+
+**При работе над аналитикой/разработкой** изучи:
+1. [CONTEXT.md](CONTEXT.md) — восстанови контекст
+2. [ROADMAP.md](ROADMAP.md) — пойми на каком этапе проект
+3. [BUSINESS_REQUIREMENTS.md](BUSINESS_REQUIREMENTS.md) + [REQUIREMENTS.md](REQUIREMENTS.md) — требования
+4. [ARCHITECTURE.md](ARCHITECTURE.md) — архитектура
+
+После изучения скажи: "Изучил, жду инструкций"

CONTEXT.md

@@ -0,0 +1,43 @@
+# HotelTask - Контекст проекта
+
+## Текущий статус
+
+**Этап:** Проектирование (в процессе)
+
+Подробности по этапам и границам MVP см. в [ROADMAP.md](ROADMAP.md)
+
+---
+
+## Что сделано
+
+- [x] Собраны бизнес-требования
+- [x] Структурированы FR/NFR
+- [x] Определены роли пользователей
+- [x] Определен scope MVP
+- [x] Высокоуровневая архитектура (9 микросервисов)
+
+## Что в работе
+
+- [ ] Схема БД (ERD)
+- [ ] API контракты (OpenAPI)
+- [ ] Модель данных Task
+
+---
+
+## Ключевые технические решения
+
+| Решение | Выбор | Обоснование |
+|---------|-------|-------------|
+| Backend | Python (FastAPI) | Быстрая разработка, async support |
+| DB | PostgreSQL | Надежность, JSON support |
+| Cache | Redis | Скорость, pub/sub |
+| Message Broker | Apache Kafka | Надежная доставка, масштабируемость |
+| Frontend | React + TypeScript | Популярность, типизация |
+| Auth | JWT | Stateless, масштабируемость |
+| Storage | S3-compatible | Стандарт для файлов |
+
+---
+
+## Заметки для следующей сессии
+
+*(Здесь агент может оставлять заметки для себя)*

NOTIONS.md

@@ -0,0 +1,464 @@
+Проработка:
+- Прототипы интерфейсов
+- Контракты API (swagger)
+- Пользовательские сценарии (use cases)
+- Sequence диаграммы
+- Сервис лицензий, или какой-то способ модульной поставки сервисов? Может с помощью helm чартов?
+- UI спецификация? Обработка ошибок на UI
+- Система логирования бека, фронта, дебагинг, мониторинг, алертнинг
+- Схема деплоя. Ставимся в кластер? А что если нет кластера? Как упаковывать коробку?
+- Аналитика фичей по отдельности, разделить MVP на небольшие кусочки, поставлять фичи этапами
+- Нагрузочное тестирование
+
+
+Вопросы от Леши:
+- Оценка временных затрат
+- Оценка денежных затрат (человеческий ресурс от минимум до комфорт, дать диапазон с ролями, стоимостью по сотрудникам)
+
+---
+
+## Архитектурные решения
+
+### ADR-001: Стратегия работы с данными PMS
+
+**Контекст:**
+Система интегрируется с PMS (и другими системами) для получения данных о гостях, номерах и бронированиях. Нужно определить, как работать с этими данными.
+
+#### Варианты
+
+**Вариант 1: Pass-through (запрос по требованию)**
+
+Каждый раз запрашиваем данные из PMS когда нужно.
+
+| Плюсы | Минусы |
+|-------|--------|
+| Данные всегда актуальные | Зависимость от доступности PMS |
+| Не нужно хранить и синхронизировать | Задержки на каждый запрос |
+| Нет проблем с консистентностью | Нет истории (кто был в номере вчера?) |
+
+**Вариант 2: Полная репликация**
+
+Храним копию данных, синхронизируем по событиям или периодически.
+
+| Плюсы | Минусы |
+|-------|--------|
+| Работаем автономно при падении PMS | Сложность синхронизации |
+| Быстрый доступ к данным | Возможны расхождения данных |
+| Есть история | Дублирование хранилища |
+
+**Вариант 3: Гибридный**
+
+Храним только то, что нужно для задач + кэшируем справочники.
+
+*Что храним у себя:*
+- Ссылку на номер/гостя (ID из PMS)
+- Снапшот данных на момент создания задачи (имя гостя, номер комнаты)
+- Историю задач с контекстом
+
+*Что запрашиваем из PMS:*
+- Актуальный статус номера (грязный/чистый/занят)
+- Текущие бронирования
+- Справочник номеров (с кэшированием)
+
+#### Вопросы для принятия решения
+
+1. **Автономность** — должна ли система работать при недоступности PMS?
+2. **История** — нужно ли знать "для какого гостя делали задачу месяц назад"?
+3. **Частота изменений** — как часто меняются данные в PMS (заезды/выезды)?
+4. **API PMS** — поддерживает ли PMS push-уведомления (webhooks) или только pull?
+5. **Объём** — сколько номеров/гостей в типичном отеле?
+6. **Сценарий** — горничной нужен актуальный статус номера или достаточно того, что было при создании задачи?
+
+#### Решение
+
+*Ожидает обсуждения*
+
+---
+
+### ADR-002: Мультитенантность
+
+**Статус:** Открыт
+
+**Контекст:**
+В NFR-SCALE-003 указано, что система должна поддерживать несколько отелей на одной инсталляции. Нужно определить архитектуру изоляции данных.
+
+#### Варианты
+
+**Вариант 1: Shared Database + tenant_id**
+
+Все отели в одной БД, данные разделены по `hotel_id`.
+
+| Плюсы | Минусы |
+|-------|--------|
+| Простота развёртывания | Риск утечки данных между отелями |
+| Легко делать кросс-отельную аналитику | Сложнее масштабировать отдельный отель |
+| Экономия ресурсов | Один отель может "положить" всех |
+
+**Вариант 2: Database per Tenant**
+
+Отдельная БД на каждый отель.
+
+| Плюсы | Минусы |
+|-------|--------|
+| Полная изоляция данных | Сложность управления миграциями |
+| Можно масштабировать независимо | Больше ресурсов |
+| Проще соответствовать требованиям безопасности | Сложнее кросс-отельная аналитика |
+
+**Вариант 3: Schema per Tenant**
+
+Одна БД, но отдельная schema на отель.
+
+| Плюсы | Минусы |
+|-------|--------|
+| Баланс изоляции и простоты | Ограничения PostgreSQL на количество schema |
+| Проще бэкапы отдельных отелей | Всё ещё shared resources |
+
+#### Вопросы для принятия решения
+
+1. **Количество отелей** — сколько отелей планируется на одной инсталляции?
+2. **Требования безопасности** — есть ли требования к физической изоляции данных?
+3. **Кросс-отельная аналитика** — нужны ли отчёты по всем отелям сразу?
+4. **Модель продаж** — SaaS (много мелких) или Enterprise (мало крупных)?
+
+#### Решение
+
+*Ожидает обсуждения*
+
+---
+
+### ADR-003: API Gateway — готовое решение или самописный
+
+**Статус:** Открыт
+
+**Контекст:**
+В архитектуре указан API Gateway Layer, но не определено — это готовое решение или часть кода. От этого зависит где происходит аутентификация, rate limiting, routing.
+
+#### Варианты
+
+**Вариант 1: Готовое решение (Kong / Traefik / AWS API Gateway)**
+
+| Плюсы | Минусы |
+|-------|--------|
+| Готовый rate limiting, auth, metrics | Дополнительная зависимость |
+| Battle-tested | Может быть избыточно для MVP |
+| Меньше кода | Vendor lock-in (для облачных) |
+
+**Вариант 2: Самописный на FastAPI**
+
+| Плюсы | Минусы |
+|-------|--------|
+| Полный контроль | Нужно писать и поддерживать |
+| Нет лишних зависимостей | Rate limiting, auth — своими руками |
+| Гибкость | Риск ошибок безопасности |
+
+**Вариант 3: Nginx + Lua / OpenResty**
+
+| Плюсы | Минусы |
+|-------|--------|
+| Высокая производительность | Lua — дополнительный язык |
+| Проверенное решение | Сложнее отлаживать |
+
+#### Вопросы для принятия решения
+
+1. **Где аутентификация?** — Gateway проверяет JWT или каждый сервис сам?
+2. **Rate limiting** — нужен ли в MVP?
+3. **Инфраструктура** — есть ли уже Kubernetes Ingress / Load Balancer?
+4. **Команда** — есть ли опыт с Kong/Traefik?
+
+#### Решение
+
+*Ожидает обсуждения*
+
+---
+
+### ADR-004: Разделение users-service и permissions-service
+
+**Статус:** Открыт
+
+**Контекст:**
+В архитектуре есть два отдельных сервиса: `users-service` (пользователи, профили) и `permissions-service` (RBAC, роли). Возможно это избыточно для MVP.
+
+#### Варианты
+
+**Вариант 1: Два отдельных сервиса (текущий)**
+
+| Плюсы | Минусы |
+|-------|--------|
+| Чёткое разделение ответственности | Overhead на межсервисное взаимодействие |
+| Можно развивать независимо | Сложнее для MVP |
+| Permissions можно переиспользовать | Больше точек отказа |
+
+**Вариант 2: Объединить в один auth-service**
+
+| Плюсы | Минусы |
+|-------|--------|
+| Проще для MVP | Может разрастись |
+| Меньше latency | Сложнее разделить потом |
+| Один источник правды о пользователе | — |
+
+#### Вопросы для принятия решения
+
+1. **Сложность RBAC** — насколько сложная система прав планируется?
+2. **Переиспользование** — будут ли другие системы использовать permissions-service?
+3. **MVP scope** — что минимально необходимо для запуска?
+
+#### Решение
+
+*Ожидает обсуждения*
+
+---
+
+### ADR-005: WebSocket масштабирование
+
+**Статус:** Открыт
+
+**Контекст:**
+`notification-service` использует WebSocket для real-time уведомлений. При нескольких инстансах сервиса нужен механизм доставки сообщения на нужный инстанс.
+
+#### Варианты
+
+**Вариант 1: Sticky Sessions**
+
+Клиент всегда идёт на один и тот же инстанс.
+
+| Плюсы | Минусы |
+|-------|--------|
+| Просто реализовать | Неравномерная нагрузка |
+| Не нужен pub/sub | При падении инстанса — переподключение |
+
+**Вариант 2: Redis Pub/Sub**
+
+Все инстансы подписаны на Redis, сообщение доставляется всем.
+
+| Плюсы | Минусы |
+|-------|--------|
+| Равномерная нагрузка | Дополнительная зависимость |
+| Отказоустойчивость | Больше трафика |
+
+**Вариант 3: Kafka → все инстансы**
+
+Каждый инстанс читает из Kafka и отправляет своим клиентам.
+
+| Плюсы | Минусы |
+|-------|--------|
+| Уже есть Kafka | Дублирование сообщений |
+| Персистентность | Нужна фильтрация на клиенте |
+
+#### Вопросы для принятия решения
+
+1. **Количество инстансов** — сколько реально будет в production?
+2. **Частота сообщений** — сколько уведомлений в секунду?
+3. **Критичность доставки** — что если уведомление не дошло?
+
+#### Решение
+
+*Ожидает обсуждения*
+
+---
+
+### ADR-006: Scheduler — гарантия единственного выполнения
+
+**Статус:** Открыт
+
+**Контекст:**
+`scheduler-service` создаёт задачи по расписанию. При нескольких инстансах может создать дубликаты.
+
+#### Варианты
+
+**Вариант 1: Distributed Lock (Redis/PostgreSQL)**
+
+Только один инстанс выполняет задачу.
+
+| Плюсы | Минусы |
+|-------|--------|
+| Гарантия единственности | Сложность реализации |
+| Отказоустойчивость | Lock может "застрять" |
+
+**Вариант 2: Leader Election**
+
+Один инстанс — лидер, остальные в standby.
+
+| Плюсы | Минусы |
+|-------|--------|
+| Простая логика в коде | Нужен механизм выбора лидера |
+| — | Single point of failure |
+
+**Вариант 3: Один инстанс scheduler'а**
+
+Просто не масштабируем этот сервис.
+
+| Плюсы | Минусы |
+|-------|--------|
+| Максимально просто | Нет отказоустойчивости |
+| — | Для MVP может быть достаточно |
+
+#### Вопросы для принятия решения
+
+1. **Критичность** — что если задача не создалась вовремя?
+2. **Частота** — как часто запускаются scheduled задачи?
+3. **MVP** — нужен ли scheduler в MVP вообще? (В ROADMAP он в этапе 3)
+
+#### Решение
+
+*Ожидает обсуждения*
+
+---
+
+### ADR-007: Консистентность данных между сервисами
+
+**Статус:** Открыт
+
+**Контекст:**
+При создании задачи нужно: сохранить в БД, отправить уведомление, записать в аудит. Что если одна из операций упадёт?
+
+#### Проблемы
+
+1. **Частичное выполнение** — задача создана, но уведомление не отправлено
+2. **Дубликаты** — retry создал задачу дважды
+3. **Порядок событий** — аудит записал раньше, чем задача реально создалась
+
+#### Варианты
+
+**Вариант 1: Saga Pattern**
+
+Цепочка компенсирующих транзакций.
+
+**Вариант 2: Outbox Pattern**
+
+Сначала пишем в локальную таблицу outbox, потом отдельный процесс отправляет в Kafka.
+
+**Вариант 3: Event Sourcing**
+
+Храним события, состояние вычисляется.
+
+#### Вопросы для принятия решения
+
+1. **Критичность** — насколько критична потеря уведомления?
+2. **Идемпотентность** — как обрабатывать повторные запросы?
+3. **Сложность** — готовы ли усложнять архитектуру ради гарантий?
+
+#### Решение
+
+*Ожидает обсуждения*
+
+---
+
+### ADR-008: Жизненный цикл файлов
+
+**Статус:** Открыт
+
+**Контекст:**
+К задачам прикрепляются файлы (фото уборки). Нужно определить что с ними происходит при удалении/архивации задачи.
+
+#### Вопросы для принятия решения
+
+1. **Удаление задачи** — удалять файлы или оставлять?
+2. **Архивация** — нужно ли переносить старые файлы в "холодное" хранилище?
+3. **Дедупликация** — один файл может быть привязан к нескольким задачам?
+4. **Квоты** — есть ли лимит на размер файлов / количество на задачу?
+5. **Доступ** — как генерировать URL? Presigned URLs или через API?
+
+#### Решение
+
+*Ожидает обсуждения*
+
+---
+
+### ADR-009: gRPC vs REST — когда что использовать
+
+**Статус:** Открыт
+
+**Контекст:**
+В архитектуре указаны оба протокола. Нужно определить границы применения.
+
+#### Вопросы для принятия решения
+
+1. **Внешний API** — только REST или gRPC тоже?
+2. **Межсервисное** — всё через gRPC или только критичные вызовы?
+3. **Команда** — есть ли опыт с gRPC?
+4. **Клиенты** — мобильные приложения будут использовать gRPC?
+
+#### Потенциальное решение
+
+- **REST** — внешний API (клиенты, адаптеры)
+- **gRPC** — межсервисное взаимодействие (tasks ↔ permissions)
+
+#### Решение
+
+*Ожидает обсуждения*
+
+---
+
+### ADR-010: Отсутствующие компоненты в архитектуре
+
+**Статус:** Открыт
+
+**Контекст:**
+При анализе выявлены компоненты, которые не описаны, но могут быть необходимы.
+
+#### Что не описано
+
+| Компонент | Зачем нужен | Критичность для MVP |
+|-----------|-------------|---------------------|
+| **Health checks** | Kubernetes liveness/readiness probes | Высокая |
+| **Circuit Breaker** | Защита от каскадных отказов | Средняя |
+| **Rate Limiting** | Защита от DDoS/abuse | Средняя |
+| **Service Discovery** | Как сервисы находят друг друга | Высокая (если не K8s) |
+| **Distributed Tracing** | Отладка цепочек вызовов | Низкая для MVP |
+| **Config Service** | Централизованная конфигурация | Низкая |
+| **Secret Management** | Хранение credentials | Высокая |
+
+#### Вопросы для принятия решения
+
+1. **Kubernetes** — будет ли K8s? Если да, многое решается из коробки
+2. **MVP scope** — что из этого критично для первого релиза?
+
+#### Решение
+
+*Ожидает обсуждения*
+
+---
+
+### ADR-011: Безопасность Kafka
+
+**Статус:** Открыт
+
+**Контекст:**
+Через Kafka ходят данные о задачах, гостях, бронированиях. Нужно определить уровень защиты.
+
+#### Вопросы для принятия решения
+
+1. **Шифрование** — нужен ли TLS между сервисами и Kafka?
+2. **Аутентификация** — SASL или открытый доступ внутри кластера?
+3. **Авторизация** — ACL на топики (кто может читать/писать)?
+4. **Сетевая изоляция** — Kafka только во внутренней сети?
+
+#### Решение
+
+*Ожидает обсуждения*
+
+---
+
+### ADR-012: Версионирование API
+
+**Статус:** Открыт
+
+**Контекст:**
+API будет развиваться. Нужна стратегия обратной совместимости.
+
+#### Варианты
+
+| Подход | Пример | Плюсы | Минусы |
+|--------|--------|-------|--------|
+| URL versioning | `/api/v1/tasks` | Явно, просто | Дублирование кода |
+| Header versioning | `Accept: application/vnd.api.v1+json` | Чистые URL | Сложнее тестировать |
+| Query parameter | `/api/tasks?version=1` | Просто | Некрасиво |
+
+#### Вопросы для принятия решения
+
+1. **Клиенты** — кто будет потреблять API? Только свои или внешние?
+2. **Частота изменений** — как часто планируются breaking changes?
+
+#### Решение
+
+*Ожидает обсуждения*

README.md

@@ -1,2 +0,0 @@
-- [Вопросы](/Вопросы.md)
-- [Анализ требований](/Анализ%20требований.md)

REQUIREMENTS.md

@@ -0,0 +1,252 @@
+# Требования к приложению HotelTask
+
+## Содержание
+1. [Функциональные требования](#1-функциональные-требования-fr)
+2. [Нефункциональные требования](#2-нефункциональные-требования-nfr)
+
+---
+
+## 1. Функциональные требования (FR)
+
+### 1.1 Управление пользователями (FR-USER)
+
+| ID | Требование | Приоритет | MVP |
+|----|------------|-----------|-----|
+| FR-USER-001 | Система должна обеспечивать регистрацию пользователей | High | Да |
+| FR-USER-002 | Система должна обеспечивать авторизацию пользователей | High | Да |
+| FR-USER-003 | Система должна поддерживать назначение ролей пользователям | High | Да |
+| FR-USER-004 | Система должна позволять редактировать профиль пользователя | Medium | Да |
+| FR-USER-005 | Система должна позволять деактивировать пользователей | Medium | Да |
+| FR-USER-006 | Система должна поддерживать привязку пользователя к подразделению | High | Да |
+
+### 1.2 Роли и права доступа (FR-ROLE)
+
+| ID | Требование | Приоритет | MVP |
+|----|------------|-----------|-----|
+| FR-ROLE-001 | Система должна поддерживать роль "Администратор системы" с полным доступом | High | Да |
+| FR-ROLE-002 | Система должна поддерживать роль "Менеджер/Супервайзер" для управления задачами | High | Да |
+| FR-ROLE-003 | Система должна поддерживать роль "Линейный сотрудник" для выполнения задач | High | Да |
+| FR-ROLE-004 | Система должна поддерживать API-доступ для внешних систем | High | Да |
+| FR-ROLE-005 | Система должна позволять настраивать гранулярные права доступа | Medium | Нет |
+
+### 1.3 Управление задачами (FR-TASK)
+
+| ID | Требование | Приоритет | MVP |
+|----|------------|-----------|-----|
+| FR-TASK-001 | Система должна позволять создавать задачу с названием и описанием | High | Да |
+| FR-TASK-002 | Система должна поддерживать типы задач (уборка, ремонт, обслуживание и т.д.) | High | Да |
+| FR-TASK-003 | Система должна поддерживать приоритеты задач (низкий, средний, высокий, срочный) | High | Да |
+| FR-TASK-004 | Система должна позволять указывать срок выполнения задачи | High | Да |
+| FR-TASK-005 | Система должна позволять назначать ответственного сотрудника | High | Да |
+| FR-TASK-006 | Система должна позволять назначать супервайзера задачи | Medium | Да |
+| FR-TASK-007 | Система должна позволять редактировать задачу | High | Да |
+| FR-TASK-008 | Система должна позволять удалять задачу (при наличии прав) | Medium | Да |
+| FR-TASK-009 | Система должна позволять переназначать исполнителей | High | Да |
+| FR-TASK-010 | Система должна поддерживать трекинг времени выполнения задачи | Medium | Нет |
+| FR-TASK-011 | Система должна позволять создавать встречную задачу | Medium | Нет |
+
+### 1.4 Статусы задач (FR-STATUS)
+
+| ID | Требование | Приоритет | MVP |
+|----|------------|-----------|-----|
+| FR-STATUS-001 | Система должна поддерживать статус "Новая" | High | Да |
+| FR-STATUS-002 | Система должна поддерживать статус "В работе" | High | Да |
+| FR-STATUS-003 | Система должна поддерживать статус "Ожидает" | High | Да |
+| FR-STATUS-004 | Система должна поддерживать статус "Выполнена" | High | Да |
+| FR-STATUS-005 | Система должна поддерживать статус "Пауза" | Medium | Да |
+| FR-STATUS-006 | Система должна поддерживать статус "Отменена" | Medium | Да |
+| FR-STATUS-007 | Сотрудник должен иметь возможность менять статус своих задач | High | Да |
+
+### 1.5 Уведомления (FR-NOTIFY)
+
+| ID | Требование | Приоритет | MVP |
+|----|------------|-----------|-----|
+| FR-NOTIFY-001 | Система должна уведомлять сотрудника о назначении новой задачи (push) | High | Да |
+| FR-NOTIFY-002 | Система должна уведомлять менеджера о завершении задачи | High | Да |
+| FR-NOTIFY-003 | Система должна отправлять напоминания о приближении срока выполнения | Medium | Да |
+| FR-NOTIFY-004 | Система должна поддерживать настройку типов уведомлений для пользователя | Low | Нет |
+
+### 1.6 Комментарии и вложения (FR-ATTACH)
+
+| ID | Требование | Приоритет | MVP |
+|----|------------|-----------|-----|
+| FR-ATTACH-001 | Система должна позволять добавлять комментарии к задачам | High | Да |
+| FR-ATTACH-002 | Система должна позволять прикреплять фотографии к задачам | High | Да |
+| FR-ATTACH-003 | Система должна позволять прикреплять файлы к задачам | Medium | Да |
+| FR-ATTACH-004 | Система должна сохранять историю изменений задачи | Medium | Да |
+
+### 1.7 Поиск и фильтрация (FR-SEARCH)
+
+| ID | Требование | Приоритет | MVP |
+|----|------------|-----------|-----|
+| FR-SEARCH-001 | Система должна обеспечивать поиск задач по названию | High | Да |
+| FR-SEARCH-002 | Система должна обеспечивать поиск задач по описанию | Medium | Да |
+| FR-SEARCH-003 | Система должна обеспечивать фильтрацию по статусу | High | Да |
+| FR-SEARCH-004 | Система должна обеспечивать фильтрацию по приоритету | High | Да |
+| FR-SEARCH-005 | Система должна обеспечивать фильтрацию по сотруднику | High | Да |
+| FR-SEARCH-006 | Система должна обеспечивать фильтрацию по дате выполнения | Medium | Да |
+| FR-SEARCH-007 | Система должна обеспечивать фильтрацию по типу задачи | Medium | Да |
+
+### 1.8 Отчеты и аналитика (FR-REPORT)
+
+| ID | Требование | Приоритет | MVP |
+|----|------------|-----------|-----|
+| FR-REPORT-001 | Система должна предоставлять отчет по выполненным задачам за период | Medium | Нет |
+| FR-REPORT-002 | Система должна предоставлять статистику по сотрудникам | Medium | Нет |
+| FR-REPORT-003 | Система должна предоставлять статистику по типам задач | Medium | Нет |
+| FR-REPORT-004 | Система должна предоставлять процент просроченных задач | Medium | Нет |
+
+### 1.9 Интеграции (FR-INT)
+
+| ID | Требование | Приоритет | MVP |
+|----|------------|-----------|-----|
+| FR-INT-001 | Система должна получать бронирования из PMS с информацией о гостях и номерах | High | Да |
+| FR-INT-002 | Система должна получать статус номера из PMS | High | Да |
+| FR-INT-003 | Система должна изменять статус номера в PMS | High | Да |
+| FR-INT-004 | Система должна взаимодействовать с Консьерж Resonline | Medium | Нет |
+| FR-INT-005 | Система должна поддерживать подключение произвольных адаптеров | High | Да |
+| FR-INT-006 | Адаптер должен регистрировать поддерживаемые типы событий | High | Да |
+
+### 1.10 Управление связями между системами (FR-CONN)
+
+| ID | Требование | Приоритет | MVP |
+|----|------------|-----------|-----|
+| FR-CONN-001 | Система должна позволять настраивать маршрутизацию событий между адаптерами | High | Да |
+| FR-CONN-002 | Система должна предоставлять интерфейс для настройки связей (событие из А -> Б, В, Г) | High | Да |
+| FR-CONN-003 | Система должна хранить реестр подключенных адаптеров и их возможностей | High | Да |
+
+### 1.11 Планировщик задач (FR-SCHED)
+
+| ID | Требование | Приоритет | MVP |
+|----|------------|-----------|-----|
+| FR-SCHED-001 | Система должна поддерживать создание регулярных/периодических задач | Medium | Нет |
+| FR-SCHED-002 | Система должна автоматически создавать задачи по расписанию | Medium | Нет |
+
+### 1.12 Модуль мероприятий (FR-EVENT)
+
+| ID | Требование | Приоритет | MVP |
+|----|------------|-----------|-----|
+| FR-EVENT-001 | Система должна позволять описывать мероприятие | Low | Нет |
+| FR-EVENT-002 | Система должна автоматически декомпозировать мероприятие на задачи | Low | Нет |
+| FR-EVENT-003 | Система должна поддерживать массовое создание связанных задач | Low | Нет |
+| FR-EVENT-004 | Система должна формировать документ "функшн" на основе данных мероприятия | Low | Нет |
+
+### 1.13 Специализированный интерфейс горничных (FR-HOUSE)
+
+| ID | Требование | Приоритет | MVP |
+|----|------------|-----------|-----|
+| FR-HOUSE-001 | Система должна предоставлять интерфейс с пошаговым процессом уборки | Medium | Нет |
+| FR-HOUSE-002 | Система должна требовать фото до и после уборки | Medium | Нет |
+| FR-HOUSE-003 | Система должна фиксировать время начала и окончания уборки | Medium | Нет |
+
+### 1.14 Интерфейс для гостей (FR-GUEST)
+
+| ID | Требование | Приоритет | MVP |
+|----|------------|-----------|-----|
+| FR-GUEST-001 | Система должна предоставлять интерфейс для гостей (бот/веб) | Low | Нет |
+| FR-GUEST-002 | Система должна предоставлять набор базовых услуг с кнопками | Low | Нет |
+| FR-GUEST-003 | Система должна автоматически создавать задачи из запросов гостей | Low | Нет |
+
+---
+
+## 2. Нефункциональные требования (NFR)
+
+### 2.1 Производительность (NFR-PERF)
+
+| ID | Требование | Значение |
+|----|------------|----------|
+| NFR-PERF-001 | Время отклика API при стандартной нагрузке | < 500ms |
+| NFR-PERF-002 | Время отклика API для критических операций | < 200ms |
+| NFR-PERF-003 | Прогнозируемое количество пользователей на отель | 20-50 |
+| NFR-PERF-004 | Одновременных подключений на отель | до 100 |
+| NFR-PERF-005 | Пропускная способность системы | 1000 задач/час на отель |
+
+### 2.2 Доступность (NFR-AVAIL)
+
+| ID | Требование | Значение |
+|----|------------|----------|
+| NFR-AVAIL-001 | Доступность системы (SLA) | 99.5% |
+| NFR-AVAIL-002 | Допустимое время простоя в месяц | < 3.6 часа |
+| NFR-AVAIL-003 | RTO (Recovery Time Objective) | 1 час |
+| NFR-AVAIL-004 | RPO (Recovery Point Objective) | 15 минут |
+
+### 2.3 Масштабируемость (NFR-SCALE)
+
+| ID | Требование | Описание |
+|----|------------|----------|
+| NFR-SCALE-001 | Система должна поддерживать горизонтальное масштабирование сервисов | Микросервисная архитектура |
+| NFR-SCALE-002 | Система должна поддерживать добавление новых адаптеров без изменения ядра | Plugin architecture |
+| NFR-SCALE-003 | Система должна поддерживать мультитенантность | Несколько отелей на одной инсталляции |
+
+### 2.4 Безопасность (NFR-SEC)
+
+| ID | Требование | Описание |
+|----|------------|----------|
+| NFR-SEC-001 | Все API-запросы должны быть аутентифицированы | JWT/OAuth2 |
+| NFR-SEC-002 | Передача данных должна быть зашифрована | HTTPS/TLS 1.3 |
+| NFR-SEC-003 | Пароли должны храниться в зашифрованном виде | bcrypt/argon2 |
+| NFR-SEC-004 | Система должна вести журнал аудита | audit-service |
+| NFR-SEC-005 | Система должна поддерживать RBAC | Ролевая модель доступа |
+| NFR-SEC-006 | Система должна защищать от основных OWASP уязвимостей | SQL injection, XSS, CSRF |
+
+### 2.5 Совместимость (NFR-COMPAT)
+
+| ID | Требование | Описание |
+|----|------------|----------|
+| NFR-COMPAT-001 | Веб-интерфейс должен корректно работать в современных браузерах | Chrome, Firefox, Safari, Edge (последние 2 версии) |
+| NFR-COMPAT-002 | Веб-интерфейс должен быть адаптивным | Mobile-first design |
+| NFR-COMPAT-003 | Мобильное приложение должно поддерживать Android | Android 8.0+ |
+| NFR-COMPAT-004 | Мобильное приложение должно поддерживать iOS | iOS 14+ |
+
+### 2.6 Поддерживаемость (NFR-MAINT)
+
+| ID | Требование | Описание |
+|----|------------|----------|
+| NFR-MAINT-001 | Код должен быть покрыт unit-тестами | > 70% coverage |
+| NFR-MAINT-002 | Система должна предоставлять метрики для мониторинга | Prometheus-compatible |
+| NFR-MAINT-003 | Система должна предоставлять структурированные логи | JSON format |
+| NFR-MAINT-004 | Документация API должна быть в формате OpenAPI | Swagger/OpenAPI 3.0 |
+| NFR-MAINT-005 | Модульная структура для возможности продажи отдельных модулей | Loosely coupled services |
+
+### 2.7 Локализация (NFR-L10N)
+
+| ID | Требование | Описание |
+|----|------------|----------|
+| NFR-L10N-001 | Интерфейс должен поддерживать русский язык | Primary |
+| NFR-L10N-002 | Интерфейс должен поддерживать английский язык | Secondary |
+| NFR-L10N-003 | Система должна поддерживать добавление новых языков | i18n ready |
+
+### 2.8 Инфраструктура (NFR-INFRA)
+
+| ID | Требование | Технология |
+|----|------------|------------|
+| NFR-INFRA-001 | База данных | PostgreSQL |
+| NFR-INFRA-002 | Кэширование | Redis |
+| NFR-INFRA-003 | Файловое хранилище | S3-compatible |
+| NFR-INFRA-004 | Очередь сообщений | Apache Kafka |
+| NFR-INFRA-005 | Backend-сервисы | Python |
+| NFR-INFRA-006 | Web Admin Frontend | TypeScript, React |
+| NFR-INFRA-007 | API Gateway | REST API, gRPC, WebSocket |
+
+### 2.9 Надежность доставки сообщений (NFR-MSG)
+
+| ID | Требование | Описание |
+|----|------------|----------|
+| NFR-MSG-001 | Гарантия доставки сообщений | At-least-once delivery |
+| NFR-MSG-002 | Сообщения должны сохраняться при недоступности получателя | Kafka persistence |
+| NFR-MSG-003 | Система должна поддерживать retry-механизм | Exponential backoff |
+| NFR-MSG-004 | Система должна поддерживать dead-letter queue | DLQ для необработанных сообщений |
+
+---
+
+## 3. Глоссарий
+
+| Термин | Описание |
+|--------|----------|
+| PMS | Property Management System - система управления отелем |
+| Адаптер | Компонент, обеспечивающий интеграцию с внешней системой |
+| Событие | Стандартизированное сообщение, передаваемое между системами через Kafka |
+| Задача | Единица работы в системе с назначенным исполнителем и статусом |
+| Функшн | Документ с описанием мероприятия и задач для служб отеля |
+| Хаускипинг | Служба уборки номеров |
+| Хаусмен | Сотрудник, отвечающий за перестановку мебели и оборудования |

ROADMAP.md

@@ -0,0 +1,142 @@
+# HotelTask - Дорожная карта
+
+## Текущий статус: Проектирование
+
+---
+
+## Этап 0: Аналитика
+**Статус:** Завершен
+
+- [x] Собраны бизнес-требования
+- [x] Структурированы FR/NFR
+- [x] Определены роли пользователей
+- [x] Определен scope MVP
+
+---
+
+## Этап 1: Проектирование
+**Статус:** В процессе
+
+- [x] Высокоуровневая архитектура
+- [ ] Схема БД (ERD)
+- [ ] API контракты (OpenAPI)
+- [ ] Модель данных Task
+
+---
+
+## Этап 2: MVP
+**Статус:** Ожидает
+
+### Что входит в MVP:
+
+**Управление пользователями:**
+- Регистрация и авторизация
+- Роли: Администратор, Менеджер/Супервайзер, Линейный сотрудник
+- Привязка к подразделениям
+
+**Управление задачами:**
+- CRUD операции с задачами
+- Все статусы: новая, в работе, ожидает, выполнена, пауза, отменена
+- Типы задач, приоритеты, сроки
+- Назначение исполнителей
+
+**Уведомления:**
+- Push-уведомления о новых задачах
+- Уведомления о завершении задач
+
+**Комментарии и вложения:**
+- Комментарии к задачам
+- Прикрепление фото и файлов
+- История изменений
+
+**Поиск и фильтрация:**
+- Поиск по названию и описанию
+- Фильтры по статусу, приоритету, сотруднику, дате
+
+**Интерфейсы:**
+- Веб-интерфейс (адаптивный)
+
+**Интеграции:**
+- Базовая интеграция с PMS
+- Система адаптеров
+- Управление связями между системами
+
+### Разработка MVP:
+- [ ] Инфраструктура (Docker, Kafka, PostgreSQL, Redis)
+- [ ] tasks-service
+- [ ] users-service
+- [ ] permissions-service
+- [ ] notification-service
+- [ ] file-storage-service
+- [ ] API Gateway
+- [ ] Web Admin
+- [ ] PMS Adapter
+
+---
+
+## Этап 3: Расширение функционала
+**Статус:** Планируется
+
+### 3.1 Аудит и аналитика
+- audit-service
+- Отчет по выполненным задачам за период
+- Статистика по сотрудникам
+- Статистика по типам задач
+- Процент просроченных задач
+
+### 3.2 Планировщик
+- scheduler-service
+- Создание регулярных/периодических задач
+- Автоматическое создание задач по расписанию
+
+### 3.3 Трекинг времени
+- Время начала и окончания задачи
+- Учет времени выполнения
+
+---
+
+## Этап 4: Специализированные модули
+**Статус:** Планируется
+
+### 4.1 Модуль мероприятий (Events Management)
+- events-service
+- Описание мероприятия
+- Автоматическая декомпозиция на задачи
+- Массовое создание связанных задач
+- Формирование документа "функшн"
+
+### 4.2 Специализированный интерфейс горничных
+- Пошаговый процесс уборки
+- Обязательное фото до и после
+- Фиксация времени уборки
+
+### 4.3 Складской модуль
+- Учет материалов по службам
+- Списание при выполнении задач
+
+---
+
+## Этап 5: Расширение каналов
+**Статус:** Планируется
+
+### 5.1 Мобильные приложения
+- Android приложение (8.0+)
+- iOS приложение (14+)
+
+### 5.2 Интерфейс для гостей
+- Telegram-бот / веб-приложение
+- Базовые услуги с кнопками
+- Автоматическое создание задач из запросов
+
+### 5.3 Голосовой ввод
+- Транскрипция голосовых сообщений в текст
+
+### 5.4 Интеграция с AI
+- Обработка свободных текстовых запросов
+
+---
+
+## Что НЕ входит в ближайшие планы:
+- Гранулярные права доступа (кастомные permissions)
+- Настройка типов уведомлений для пользователя
+- Интеграция с Консьерж Resonline

Анализ требований.md

@@ -1,255 +0,0 @@
-[Назад](/README.md)
-
-# Анализ требований
-
-## Приложение: Таск менеджер
-
-### Потребители:
-- Горничные (хаускипинг)
-- Техническая (инженерная) служба
-- ИТ служба
-- Ресторанная служба
-- Ресепшен
-- Хаусмены
-- Менеджеры по продажам
-
-**Прогнозируемое количество пользователей:** 20-50 на отель
-
----
-
-### Проблемы и требования:
-
-#### **Проблема 1: Отсутствие единой системы для передачи задач между подразделениями**
-
-**AS-IS (как есть):**
-- Ресепшен выступает посредником между всеми службами
-- Передача задач через звонки и мессенджеры (WhatsApp)
-- Информация может теряться, забываться
-- Ресепшен перегружен, особенно в часы пик (например, при заезде группы)
-
-**TO-BE (как должно быть):**
-- Автоматизированная система для передачи задач
-- Каждое подразделение имеет прямой доступ к системе
-- Возможность создать задачу и передать ее напрямую нужному подразделению
-- Ресепшен убирается как обязательный источник синхронизации
-
-**Базовый функционал (MVP):**
-- Создание задачи
-- Передача задачи нужному подразделению
-- Принятие задачи исполнителем
-- Отметка о выполнении
-- Возможность создать встречную задачу (если требуется)
-
----
-
-#### **Проблема 2: Невозможность документировать выполнение задач с помощью фото/видео**
-
-**AS-IS:**
-- Фотографии отправляются через мессенджеры (WhatsApp)
-- Нет централизованного хранения
-- Сложно найти историю выполненных работ
-
-**TO-BE:**
-- Возможность прикрепления фотографий к задаче
-- Применимо для всех служб:
-  - **Горничные:** фото до и после уборки
-  - **Техническая служба:** фото выполненного ремонта (труба, унитаз и т.д.)
-  - **ИТ служба:** фото расставленного оборудования
-- Возможность показать результат заказчику
-- Фиксация состояния объекта
-
-**Требование:** Возможность прикрепления файлов и фотографий к задачам
-
----
-
-#### **Проблема 3: Сложность ввода информации в процессе работы**
-
-**AS-IS:**
-- Много времени тратится на набор текста
-- Сотрудники вынуждены писать длинные сообщения
-
-**TO-BE:**
-- Голосовой ввод с автоматической транскрипцией в текст
-- Ускорение процесса создания и комментирования задач
-
-**Требование:** Интеграция системы распознавания речи (голосовые сообщения → текст)
-**Примечание:** Потребуется использование платных сервисов (западных или отечественных)
-
----
-
-#### **Проблема 4: Отсутствие автоматизации повторяющихся задач**
-
-**AS-IS:**
-- Регулярные задачи (раз в неделю, месяц) создаются вручную каждый раз
-
-**TO-BE:**
-- Автоматическое создание периодических задач по расписанию
-- Применимо для:
-  - Горничных (регулярная уборка определенных зон)
-  - Технической службы (плановое обслуживание оборудования)
-
-**Требование:** Функционал создания регулярных задач с настройкой расписания
-
----
-
-#### **Проблема 5: Отсутствие учета расходных материалов**
-
-**AS-IS:**
-- Информация о материалах не фиксируется нигде
-- Невозможно отследить остатки и планировать закупки
-- Не хранится в других системах (в PMS такой информации нет)
-
-**TO-BE:**
-- Складской модуль внутри системы
-- Учет материалов по службам:
-  - **Горничные:** полотенца (разных видов), косметика
-  - **Техническая служба:** лампочки, расходники
-- Первоначальный ввод остатков
-- Списание при выполнении задач
-- Понимание объемов работы (например, работы прачки)
-
-**Требование:** Модуль учета материалов
-**Примечание:** Это НЕ MVP, но важная часть. Может использоваться не только в Таск менеджере.
-
----
-
-## Приложение: Модуль управления мероприятиями (Events Management)
-
-### Потребители:
-- Менеджеры по продажам
-- Служба хаусменов
-- ИТ служба
-- Ресторанная служба
-- Инженерная служба
-
----
-
-### Проблемы и требования:
-
-#### **Проблема 6: Неэффективное управление задачами для мероприятий**
-
-**AS-IS:**
-- Менеджер по продажам вручную составляет "фанкшн" или "меморандум" (Word документ)
-- В документе описываются все задачи для разных служб:
-  - Застройка зала (расстановка столов, стульев)
-  - Предоставление оборудования (проектор, экран)
-  - Организация кофе-брейка
-  - Перестройка зала
-- Документ рассылается службам
-- Задачи могут быть упущены или не замечены
-- Отсутствует единый контроль выполнения
-
-**TO-BE:**
-- Менеджер описывает мероприятие в системе один раз
-- Система автоматически создает задачи для каждой службы
-- Автоматическая генерация "фанкшн"
-- Все задачи отслеживаются в единой системе
-- Массовое создание связанных задач для разных подразделений
-
-**Требование:** 
-- Возможность массового создания задач (bulk task creation)
-- Описание мероприятия с автоматической декомпозицией на задачи
-- Привязка задач к конференц-залам и времени
-- Формирование документа "фанкшн" на основе введенных данных
-
-**Примечание:** Функционал, который можно продавать отдельным модулем. Пока не решен полноценно ни одной существующей системой.
-
----
-
-## Приложение: Горничные (расширенный модуль для Таск менеджера)
-
-### Потребители:
-- Горничные
-
----
-
-### Проблемы и требования:
-
-#### **Проблема 7: Отсутствие контроля процесса уборки номеров**
-
-**AS-IS:**
-- Горничная получает распечатку номеров из PMS
-- Выполняет уборку
-- Сообщает о завершении устно или через мессенджер
-- Нет фиксации времени начала/окончания уборки
-- Нет фото-подтверждения качества
-
-**TO-BE:**
-- Горничная видит номер в приложении
-- Нажимает "Начать уборку"
-- Фотографирует номер до уборки
-- Выполняет уборку
-- Фотографирует номер после уборки
-- Отмечает завершение
-
-**Требование:** Специализированный интерфейс для горничных с пошаговым процессом уборки и обязательным фотографированием
-
----
-
-## Приложение: Интерфейс для гостей (Guest Interface)
-
-### Потребители:
-- Гости отеля
-
----
-
-### Проблемы и требования:
-
-#### **Проблема 8: Перегрузка ресепшена запросами от гостей**
-
-**AS-IS:**
-- Гость звонит на ресепшен с запросом (принести халат, тапочки и т.д.)
-- Ресепшен записывает запрос
-- Ресепшен создает задачу в Таск менеджере или пишет в WhatsApp
-- При большой загрузке (заезд группы):
-  - Трубки не берутся
-  - Запросы забываются
-  - Теряется информация о номере
-
-**TO-BE:**
-- Гость самостоятельно создает запрос через:
-  - Telegram-бота
-  - Готовый консьерж-сервис
-  - Другой интерфейс
-- Базовые услуги доступны по кнопкам (принести халат, тапочки и т.д.)
-- Возможна интеграция с AI для обработки свободных запросов
-- Задача автоматически попадает нужному подразделению
-- Ресепшен разгружается
-
-**Требование:** 
-- Интерфейс для гостей (бот/веб-приложение)
-- Набор базовых услуг с кнопками
-- Автоматическое создание задач в Таск менеджере
-- Опционально: интеграция с AI для обработки текстовых запросов
-
-**Примечание:** Может быть интеграцией с существующим консьерж-сервисом, который нужно будет доработать
-
----
-
-## Общие требования к архитектуре:
-
-1. **Модульная структура:** Возможность продажи отдельных модулей
-2. **Базовый функционал может быть бесплатным:** Freemium-модель для привлечения пользователей
-3. **Единая точка доступа:** Все службы работают в одном приложении, а не в разных мессенджерах
-4. **Масштабируемость:** Архитектура должна поддерживать добавление новых модулей
-
----
-
-## Список всех подразделений (требуется уточнить полный список):
-- Хаускипинг (горничные)
-- Техническая (инженерная) служба
-- ИТ служба
-- Ресторанная служба
-- Ресепшен
-- Хаусмены
-- Служба консьержа
-- Прачечная
-
----
-
-## Следующие шаги:
-1. Уточнить полный список подразделений
-2. Детализировать требования для каждого подразделения
-3. Определить приоритеты функций (MVP vs расширенный функционал)
-4. Создать архитектуру с учетом модульности
-5. Получить доступ к тестовой среде существующих систем

Вопросы.md

@@ -1,27 +0,0 @@
-[Назад](/README.md)
-
-## Вопросы:
-
-1. Список всех потребителей приложения Task Manager. Кто потенциально может им начать пользоваться?
-
-##### Текущий список:
-- Хаускипинг (горничные)
-- Техническая (инженерная) служба
-- ИТ служба
-- Ресторанная служба
-- Ресепшен
-- Хаусмены
-- Служба консьержа
-- Прачечная
-
-
-2. Какие проблемы для каждого подразделения закрывает Task Manager?
-
-##### Общие:
-- Передача задач от подразделения к подразделению
-
-##### Хаускипинг (горничные)
-- ???
-
-##### ???
-- ???