Декомпозиция BR 5.1 — KDS Android
Источники
BR 5.1 Бизнес-спека: KDS — Кухонный экран Архитектура: KDS Architecture Research
Затронутые сервисы / репозитории
| Сервис / репо | Порт | Роль | Задачи |
|---|---|---|---|
| Order Service | :3005 | + поля per-item KDS, endpoints для KDS, события | Order Service |
| Catalog Service | :3004 | + поля порогов на kitchen_stations, kds_franchise_settings, события | Catalog Service |
| User Service | :3002 | + таблица kds_devices, permissions, endpoints | User Service |
| POS BFF | :3022 | Новые KDS routes + WebSocket gateway + Kafka consumer | POS BFF |
| erp-kds (NEW) | — | Tauri 2 + React Android-приложение, все 5 экранов | erp-kds |
| erp-admin web | :3020 | Новый раздел «Настройки KDS» + правки «Кухонные станции» | Admin Web |
| Auth Service | :3001 | — | — изменений нет (фильтр permission в pos-bff middleware) |
| Infrastructure | — | + admin-bff обновить, новый ничего | — |
Новый репозиторий
erp-kds— отдельный репо вnearbyErporg. Создаёт пользователь вручную, я скаффолжу при старте Шага 6.
Последовательность выполнения
Зависимости: KDS клиент зависит от endpoints в pos-bff, которые зависят от endpoints в Order/Catalog/User Services.
| Этап | Что | Срок | Параллель |
|---|---|---|---|
| A. Backend сервисы | Order/Catalog/User: миграции + endpoints + события | 1 нед | A1+A2+A3 параллельно |
| B. POS BFF | KDS routes + Kafka consumer + WebSocket gateway | 1 нед | После A |
| C. erp-kds skeleton | Bootstrap Tauri 2 monorepo, базовый layout, Android target | 0.5 нед | Параллельно A/B |
| D. erp-kds экраны | 5 экранов, transport-абстракция, in-app updater | 2 нед | После B (но MockTransport — параллельно) |
| E. erp-admin web | «Настройки KDS» + поля порогов в «Кухонные станции» | 1 нед | После A1+A3 |
| F. Pilot | Деплой APK на тестовый планшет, неделя реального использования в demo-coffee | 1 нед | После D+E |
Итого: ≈ 5–6 недель парных усилий (бэкенд + фронт). Возможна сильная параллель.
Зависимости от других BR
- ✅ BR 1.4.4 (Permissions) — в проде, используем
permissionsобъект-роли - ✅ BR 1.7 (Каталог) —
requires_kitchen+kitchen_station_idуже есть - ✅ BR 2.5 (Статусная модель) —
kitchen_stationsсправочник уже есть, статусы заказаaccepted/readyработают - ✅ BR 1.5 (Permission-based UI gating) — в проде, новые permissions
kds.access,kds.settings.editподхватятся через стандартный механизм
Зависимости pre-deploy
- ⛔ Хостинг для in-app updater manifest и APK — нужен endpoint
https://updates.nirbi.ru/kds/(S3/MinIO bucket, доступный публично) - ⛔ Android-планшет для тестирования — модель уточняется
Риски / открытые вопросы
- WebSocket в pos-bff — текущая версия pos-bff (Fastify) использует
kafkajsconsumer, но WebSocket gateway не реализован. Нужно добавить@fastify/websocketили нативныйwsмодуль. - Tauri 2 на Android — официально поддерживается, но в проде проектов меньше чем для desktop. Нужен 3-5 дневный спайк перед стартом D, чтобы убедиться что SQLite + WebSocket + Audio работают на реальном планшете.
- In-app updater на Android — Tauri-updater plugin требует подписи APK ключом, который должен быть на CI. Нужно настроить GitHub Actions с secret-keystore.
- Хостинг APK — в P0 предлагаю положить в наш MinIO (есть на VPS); manifest endpoint реализуем в pos-bff (
/api/v1/kds/updates/latest). Альтернатива — GitHub Releases (бесплатно, но требует проброса auth). Решим в Шаге 6. - Авто-расчёт
expected_ready_at— берётся какaccepted_at + 15 минв P0 (заглушка). В P1 — usarassembly_time_secondsиз позиций (уже есть в order_items). Зафиксировано в спеке Order Service. - Backfill kitchen_status для legacy заказов — миграция должна выставить
kitchen_status='ready'для всехorder_itemsгдеorders.status IN ('ready','closed','delivered'). Иначе закрытые старые заказы могут «всплыть» на KDS.
Прогресс
- A1. Order Service — миграция + поля + 3 endpoints + событие
order.item.kitchen_status_changed+ автотриггерaccepted→ready - A2. Catalog Service — миграция (kds_franchise_settings + поля на kitchen_stations) + 2 endpoints + событие
catalog.kds_settings.updated - A3. User Service — миграция (kds_devices + permissions) + 5 endpoints + событие
user.kds_device.revoked - B. POS BFF — 8 KDS routes + WebSocket gateway + Kafka consumer на
order.*иuser.kds_device.revoked - C. erp-kds — bootstrap (новый репо, Tauri 2, monorepo, Android target, базовый layout, login)
- D. erp-kds — экраны (Регистрация, PIN, Список, Карточка, Settings) + transport (Cloud + Mock) + in-app updater
- E. erp-admin web — раздел
/kds-settings+ поля порогов в кухонных станциях - F1. Спайк Tauri Android (3-5 дней)
- F2. Деплой APK manifest endpoint + хостинг
- F3. CI/CD GitHub Actions для подписи APK
- F4. Pilot в demo-coffee на 1 неделю
- G. /verify 5.1 — финальная проверка
- H. Деплой backend сервисов на VPS
Sandbox / тестовые данные
- demo-coffee tenant:
demo@nirbi.ru/admin123наerp-test.nirbi.ru - В demo-coffee создать 2 кухонные станции: «Горячий цех», «Бар»
- Привязать товары к станциям (например: «Бургер» → Горячий, «Кола» → Бар)
- Тестовый планшет — Lenovo Tab M10 / любой Android 10+
- APK в P0 — собранный локально, ставится через USB/sideload
- В P1 после CI/CD — через in-app updater