BR 5.1 — KDS Android — кухонный экран MVP

Статус — драфт

Требования сформированы. Не начинать реализацию — сначала проходит /process-br 5.1 через все слои workflow. Перед запуском процесса — пройти открытые вопросы §7 с пользователем.

Серия BR 5.X

Это первая BR серии «KDS». В серии:

BR 5.1 (этот) — Cloud-режим Android-приложения, multi-station, in-app updater

BR 5.2 (план) — LAN-hub mode: POS Desktop как локальный сервер, работа без интернета

BR 5.3 (план) — Full offline-first с SQLite-репликацией и event-log sync

BR 5.4 (план) — Принтеры per-станция (ESC/POS)

BR 5.5 (план) — Bump bar

BR 5.6 (план) — Курсы подачи (горячее/холодное/десерт)

BR 5.7 (план) — Кастомные звуковые файлы per-франшиза

BR 5.8 (план) — Фильтры заказов по типу/каналу

BR 5.9 (план) — Английский UI / i18n

Контекст

В BR 2.5 был сознательно введён справочник «Кухонные станции» без реализации KDS-экрана — это была отложенная Phase 2. Сейчас стартуем эту фазу.

Что есть на входе:

✅ Каталог-товары имеют requires_kitchen (boolean) и kitchen_station_id (FK → справочник станций)
✅ Order Service хранит заказы и позиции, статусная модель работает
✅ POS Desktop (Tauri 2 + React под Windows) собран и используется кассирами
✅ POS BFF работает как агрегатор для POS клиента
✅ Архитектурный research проведён — см. KDS Phase 2 — Hardware и Architecture Research

Что нужно решить этой BR: Дать кухне/бару Android-планшет с Tauri-приложением, которое в реальном времени показывает заказы для выбранной станции и позволяет повару отмечать готовность позиций.

Архитектурный курс (зафиксирован):

В P0 KDS подключается к облаку напрямую (через интернет к pos-bff — как POS Desktop)
Транспорт-слой написан с абстракцией (IKdsTransport), чтобы в BR 5.2 добавить LAN-режим (через POS Desktop как hub) без рефакторинга UI
Полный offline-first (SQLite-реплика на устройстве) — не в этой BR, делается в BR 5.3

Цель

Дать поварам/барменам Android-планшет с приложением, которое в реальном времени отображает заказы для их станции и позволяет отмечать готовность позиций. Сократить «шум на кухне», убрать бумажные чеки, повысить скорость и точность подачи.

§1. Скоуп

1.1. Что входит (P0)

Мобильное приложение:

Tauri 2 приложение с Android target (cargo tauri android build) — APK для установки
Окно разработки под Windows (cargo tauri dev) — для работы фронтенд-разработчика без планшета
Тот же стек что POS Desktop: Rust + React + TypeScript

Авторизация:

PIN-логин на устройстве (как в POS) → JWT-сессия
Выбор одной или нескольких станций при логине (галочки из списка станций франшизы) — например маленькая ТТ может выбрать «Кухня + Бар» на одном планшете
Обязательный PIN после reboot устройства; auto-resume сессии после короткого sleep/wake
Auto-логаут через 30 минут неактивности

Список заказов:

Live-обновляющийся список активных заказов с фильтром по выбранным станциям
Отображение: имя/номер заказа, тип (зал/самовывоз/доставка), время до готовности, позиции выбранных станций
Карточки или горизонтальный/вертикальный список (выбирается в Settings)
Цвет карточки по времени до плановой готовности (зелёный/жёлтый/красный)
Звуковое уведомление о новом заказе (повторяется до открытия)

Карточка заказа:

Все позиции выбранных станций с модификаторами и комментарием гостя
Если выбрано несколько станций — позиции группируются по станциям, каждая со своей кнопкой «Готово»
Позиции других станций (не выбранных) отображаются серым (контекст), без управления
Тап на «?» рядом с блюдом → модалка с техкартой (через Catalog Service)

Управление статусами:

Тап на позицию → переключение pending → preparing → ready
Откат ready → preparing запрещён (если ошибка — отмена через POS кассиром)
Кнопка «Готово» на станцию (внутри карточки заказа) — активна когда все позиции этой станции готовы → закрывает заказ для этой станции

Settings:

Звук вкл/выкл, выбор мелодии (из встроенного набора), интервал повтора
Цветовые пороги (берутся из админки франшизы; на устройстве можно переопределить локально)
Layout заказов (карточки / список)
«Держать экран включённым»
Переключатель транспорта (Облако / Локальная сеть / Авто) — в P0 рабочий только «Облако», остальные disabled с подсказкой «Будет в BR 5.2»

In-app обновление APK:

Кнопка «Проверить обновления» в Settings
Tauri-updater plugin: проверяет новую версию на нашем endpoint (GitHub Releases или собственный CDN), скачивает APK, ставит
Auto-check каждые 24 часа в фоне (опционально, настраивается)
Это упрощает выкатку патчей во время пилота — не нужно бегать по ТТ с флешкой

Связь:

WebSocket к pos-bff для live-обновлений
REST polling fallback (каждые 5 сек) при потере WS
Красный баннер «Нет связи» при дисконнекте; кэш заказов в памяти продолжает отображаться

1.2. Что НЕ входит (отложено)

❌ LAN-hub режим (POS Desktop как локальный сервер на :8080) — BR 5.2
❌ Полный offline-first (SQLite-репликация state, event-log sync) — BR 5.3
❌ Печать кухонных чеков на ESC/POS принтерах — BR 5.4
❌ Возврат / отмена заказа с кухни — требует финансовой логики, риск в MVP
❌ Курсы подачи (горячее/холодное/десерт) — BR 5.6
❌ Bump bar (USB HID контроллер) — BR 5.5
❌ Загрузка кастомных звуковых файлов на устройство (per-франшиза мелодии) — звуки настраиваются выбором из встроенного набора, P1+ загрузка своих
❌ iOS-сборка — только Android в P0
❌ Hub failover / auto-promotion — Phase 3+
❌ Анимации в стиле kiosk — функциональный минимум, не UI-конкурс

§2. Сценарии использования

2.1. Утренний запуск кухни

Повар приходит к 7:00, ставит планшет на крепление, включает
Открывает KDS-приложение (или оно уже открыто после ночи)
Вводит свой PIN, выбирает станцию «Горячий цех» из списка (одну галочку)
Видит экран «Ожидание заказов» (либо логотип франшизы, либо приветствие — финализируется в спеке)

2.1а. Маленькое кафе с одним планшетом на кухню+бар

Бариста-повар включает планшет в маленьком кафе
Логин по PIN, выбирает галочки «Кухня» и «Бар»
На экране все заказы обоих станций; в карточке позиции группируются «Кухня: …» и «Бар: …»
Может закрыть «Кухню» отдельно (эспрессо готов), потом «Бар» (сэндвич готов) — у каждой группы своя кнопка «Готово»

2.2. Новый заказ от кассира

Кассир пробивает заказ «Карбонара + Цезарь + Колу» в POS Desktop
POS отправляет заказ → Order Service → Kafka событие order.created
POS BFF (Kafka consumer) получает событие, делает фильтр «есть ли позиции для подключённых станций», пушит через WebSocket подписчикам
KDS на станции «Горячий цех» получает событие → ≤2 сек на экране появляется зелёная карточка с «Карбонара» (Цезарь — на станции «Холодный цех», Кола — на «Бар»)
Звучит звуковой сигнал, повторяется каждые 30 сек пока повар не откроет карточку

2.3. Готовка

Повар открывает карточку «Стол 5 — заказ #1234»
Звук перестаёт повторяться
Тапает «В работе» на «Карбонара» → позиция становится синей
Готовит, по готовности тапает «Готово» → позиция становится зелёной с галочкой
Кнопка «Готово» вверху карточки становится активной (все позиции ready)
Тап → заказ уезжает с экрана → POS видит «готов к подаче»

2.4. Просрочка

Заказ висит дольше плановой готовности (expected_ready_at)
За 5 мин до срока — карточка становится жёлтой
После срока — красной + тревожный звуковой сигнал
Повар видит, ускоряется или связывается с менеджером

2.5. Просмотр техкарты

Новый стажёр не помнит рецепт «Карбонары»
В карточке тапает «?» рядом с блюдом
Открывается модалка с техкартой (название, ингредиенты, последовательность, фото если есть)
Возврат к карточке заказа

2.6. Потеря соединения

Wi-Fi отключился (перезагрузка роутера, smoke-проверка)
KDS показывает красный баннер «Нет связи» (3 сек)
Текущие заказы продолжают отображаться (кэш в памяти)
Повар продолжает работу, тапает «Готово» на позиции — действие записывается в очередь
Wi-Fi вернулся → KDS отправляет очередь действий → синхронизация → баннер «Связь восстановлена»

2.7. Конец смены

Повар тапает «Меню» → «Logout»
Сессия закрывается, экран PIN-логина

§3. Архитектура (бизнес-уровень)

3.1. Высокоуровневая схема

┌─────────────────┐
│ Android планшет │   HTTPS REST + WSS
│  (Tauri 2 KDS)  │ ─────────────────────►  ┌─────────────┐
└─────────────────┘                          │   POS BFF   │ ◄──── Kafka events
                                             │ (Node + WS) │       (order.created,
                                             └──────┬──────┘        order.item.*)
                                                    │
                                              REST через cluster
                                                    │
                                             ┌──────▼──────┐
                                             │ Order Svc   │
                                             │ Catalog Svc │
                                             │ User Svc    │
                                             └─────────────┘

KDS подключается к публичному https://erp-test.nirbi.ru/api/v1/pos/...
Авторизация: JWT (PIN-логин → выдаёт JWT с permission kds.access)
Live-обновления: WebSocket-канал wss://erp-test.nirbi.ru/api/v1/pos/kds/stream?station_id=...
REST для CRUD: см. план файлов в §9

3.2. Endpoints в POS BFF (новые)

Решение: добавляем в существующий pos-bff

Не выделяем отдельный kds-bff в P0. KDS-routes идут в pos-bff/src/routes/kds.ts. Если разрастётся — выделим в P1+.

Метод	Path	Назначение
POST	`/api/v1/pos/auth/pin`	Логин по PIN, выдача JWT (если ещё нет — может уже существовать в pos-bff)
GET	`/api/v1/pos/kds/orders?station_ids=A,B&status=active`	Активные заказы для одной или нескольких станций (csv)
WS	`/api/v1/pos/kds/stream?station_ids=A,B`	Live-стрим событий (новый заказ, изменение статуса)
PATCH	`/api/v1/pos/orders/{id}/items/{itemId}/status`	Смена статуса позиции (`preparing`/`ready`)
PATCH	`/api/v1/pos/orders/{id}/kds-status?station_id=...`	Закрыть заказ для одной станции (все позиции этой станции готовы)
GET	`/api/v1/pos/catalog/products/{id}/recipe`	Техкарта блюда (proxy в Catalog Service)
GET	`/api/v1/pos/kitchen-stations`	Список станций для выбора при логине
GET	`/api/v1/pos/kds/settings`	Настройки KDS франшизы (звуки/цвета/пороги)
GET	`/api/v1/kds/updates/latest`	Последний APK для in-app updater (или GitHub Releases proxy)

3.3. Транспорт-абстракция в коде KDS

interface KdsTransport {
  login(pin: string): Promise<{ jwt, employee, availableStations[] }>
  listKitchenStations(): Promise<KitchenStation[]>      // для multi-select при логине
  listOrders(stationIds: string[]): Promise<Order[]>
  subscribeOrderStream(stationIds: string[], onEvent): Unsubscribe
  setItemStatus(orderId, itemId, status): Promise<void>
  setKdsStatusForStation(orderId, stationId, status): Promise<void>
  getRecipe(productId): Promise<Recipe>
  getKdsSettings(): Promise<KdsFranchiseSettings>       // звуки/цвета/пороги
  checkForUpdate(): Promise<{ hasUpdate, downloadUrl, version, notes } | null>
}

Реализации:

CloudTransport — P0, через pos-bff (HTTPS + WSS)
MockTransport — для разработки UI без сети (in-memory data, time-based simulator для нового заказа)
LanTransport — P1, в BR 5.2 (через POS Desktop hub в LAN)

В Settings выбор: Облако / Локальная сеть / Авто (auto fallback). В P0 — только «Облако», остальные disabled.

3.4. Что нужно от Order Service

Большинство уже есть (заказы, статусы), но возможно потребуется:

Поле expected_ready_at на заказе (для расчёта цвета по времени)
Внутренний endpoint GET /internal/orders?station_id=...&active=true для pos-bff
Публикация Kafka событий order.created, order.item.status_changed если ещё не публикуются

Точное состояние проверяется на этапе бэкенд-контрактов (Шаг 2 Workflow).

§4. Бизнес-правила

Одно устройство — одна или несколько станций (multi-select при логине). Можно сменить набор через Logout → новый логин с другими галочками.
Заказ виден если хотя бы одна позиция требует одну из выбранных станций: product.requires_kitchen=true AND product.kitchen_station_id IN (selected) AND order.status IN ('confirmed', 'in_progress'). Позиции невыбранных станций в карточке отображаются серым (контекст), без управления.
Статусы позиций: pending → preparing → ready. Откат ready → preparing запрещён на KDS. Если ошибка — отмена через POS кассиром.
Кнопка «Готово» на станцию (внутри карточки заказа) доступна когда все позиции этой станции в статусе ready. У каждой выбранной станции в карточке свой блок и своя кнопка. Когда все станции отмечены готовыми — заказ уезжает с экрана.
Live-обновления ≤2 сек от момента изменения в Order Service до отображения на KDS.
При потере соединения: красный баннер сверху «Нет связи». Заказы продолжают отображаться (кэш в памяти), действия пользователя складываются в очередь и синхронизируются после reconnect.
Звук + визуальное оповещение на новый заказ. Звук повторяется каждые N секунд (настраивается, default 30 сек) пока заказ не открыт.
Цвет карточки по времени до плановой готовности expected_ready_at — пороги настраиваются per-станция в админке франшизы, например: «Бар: жёлтый за 2 мин, красный после 0; Кухня: жёлтый за 7 мин, красный после 0». Дефолты:
- Зелёный: > 5 мин до срока
- Жёлтый: ≤ 5 мин
- Красный: просрочка (now > expected_ready_at) На устройстве можно переопределить локально.
Авто-логаут через 30 минут неактивности.
Поведение при reboot/sleep устройства:
- После reboot устройства — обязательный повторный PIN (security)
- После sleep/wake (короткий блок экрана) — auto-resume сессии, если не истёк JWT
- После авто-логаута 30 мин — PIN
Только одна сессия на устройство: новый PIN-логин закрывает старую сессию.
Permission kds.access обязателен — без него попытка PIN-логина возвращает 403. Кассир без kds.access не может работать с KDS.
Multi-tenancy соблюдается: в JWT есть franchise_id, BFF фильтрует заказы и станции только этой франшизы. Пересечение между франшизами невозможно.
Регистрация устройства: при первом логине устройство регистрируется в отдельной таблице kds_devices (id устройства, franchise_id, current_user_id, last_seen_at, app_version). Это используется для удалённого logout и аудита.

§5. Hardware

5.1. Минимальные требования к планшету

Android 10+ (API 29+)
10–13” экран, рекомендуется 1280×800 или выше
3+ ГБ RAM
32+ ГБ хранилища
Wi-Fi 5GHz (рекомендуется) или Ethernet через USB-C адаптер для надёжности

5.2. Рекомендованный список (для саппорта)

Сегмент	Модель	Примерная цена
Бюджет	Lenovo Tab M10 (3rd Gen), Xiaomi Redmi Pad SE	15–20K руб
Mid	Samsung Galaxy Tab A9+, Huawei MatePad 11	25–35K руб
Industrial (жирные кухни)	ELO Touch Tablet (IP54)	60K+ руб

Финальный список будет в спеке после теста на 1–2 моделях.

5.3. Что владелец докупает

Крепление-монтаж (стенное / подвесное / на штатив) — 1.5–5K руб
Зарядное устройство 2А+ с кабелем — 1–2K руб
Опционально: USB-Ethernet адаптер для надёжного соединения — 1K руб
Опционально: UPS для роутера и hub-POS

§6. Ролевая модель

Действие	Владелец франшизы	Владелец партнёра	Менеджер	Повар/Бариста	Кассир
Логин в KDS-приложение	✅	✅	✅	✅	❌
Видеть заказы своей станции	✅	✅	✅	✅	❌
Менять статус позиции	✅	✅	✅	✅	❌
Закрыть заказ как готовый	✅	✅	✅	✅	❌
Изменить настройки KDS на устройстве	✅	✅	✅	❌	❌
Видеть финансы / возвраты	❌	❌	❌	❌	❌

6.1. Новые permissions

kds.access — позволяет логиниться в KDS-приложение и менять статус позиций
kds.settings.edit — позволяет менять настройки на устройстве (звуки, цвета, layout)

Сотрудник может иметь и pos.access, и kds.access одновременно — например менеджер.

6.2. Как раздаются permissions

Через раздел «Роли» в Админке Франшизы (см. Роли). Создаётся роль «Повар» с kds.access, привязывается к сотрудникам. Менеджер получает обе.

§7. Принятые решения

Все 11 вопросов из draft-версии BR закрыты пользователем 2026-04-29

#	Вопрос	Решение
1	Один или несколько BFF	Добавляем KDS-routes в существующий `pos-bff`. Файл `bff/src/routes/kds.ts`. Если разрастётся — выделим отдельный `kds-bff` в P1+.
2	Несколько станций на устройстве в P0	Включено в P0. Multi-select при логине. Маленькие ТТ кладут один планшет на «Кухня + Бар».
3	Заказы на самовывоз/доставку	Показывать всё в P0, фильтры по типу заказа — P1+.
4	Цвета и звуки	Настраиваемые per-франшиза в админке. Endpoint `GET /api/v1/pos/kds/settings` отдаёт текущие. На устройстве — локальное переопределение.
5	Авто-обновление приложения	Sideload через in-app updater (кнопка «Проверить обновления» в Settings + опц. auto-check каждые 24ч). Tauri-updater plugin или собственный механизм через GitHub Releases / наш CDN. Это упрощает выкатку патчей во время пилота.
6	Время уведомлений / цветовые пороги	Настраиваемые per-станция в админке франшизы (раздел «Кухонные станции» → поля `yellow_threshold_minutes`, `red_threshold_minutes`).
7	Что показывать когда заказов нет	Пустой экран с надписью «Ожидание заказов» + название выбранных станций (минималистично, без лишнего шума). Дизайнер может добавить лого франшизы — финализируется в фронт-спеке.
8	Reboot vs sleep	После reboot — обязательный PIN. После sleep/wake — auto-resume если JWT не истёк. После 30 мин неактивности — PIN.
9	Где KDS логируется	Отдельная таблица `kds_devices` (device_id, franchise_id, current_user_id, last_seen_at, app_version). Используется для аудита, удалённого logout, лимитирования сессий.
10	Звуковые файлы	Встроенные в APK (набор из 3–5 мелодий). Per-франшиза кастомизация = выбор из встроенного набора + загрузка своих файлов отложена в P1+.
11	Языки UI	Только русский в P0.

Sideload + in-app updater — что это и как

Sideload — установка APK файла напрямую на устройство, минуя Google Play. У нас в любом случае такой путь, потому что приложение для собственных клиентов франшизы (не публичное, не нужна модерация).

In-app updater: Tauri 2 имеет официальный плагин @tauri-apps/plugin-updater, работающий и на Windows, и на Android. Принцип:

Приложение читает https://updates.nirbi.ru/kds/latest.json → получает версию + URL APK + signature
Если версия новее текущей — показывает кнопку «Обновить»
Тап → скачивает APK → ставит (Android требует пользовательского подтверждения, но без флешки)

Для P0 — ручная кнопка «Проверить обновления» в Settings. Auto-check каждые 24 часа можно включить опционально. Это значит: разработчик собрал новый APK → залил в наше хранилище → все планшеты во всех ТТ подхватили в течение суток (или вручную при тапе).

§8. Фазинг

Фаза	Что	Срок	Кто
A. POS BFF — KDS endpoints	REST + WebSocket для KDS, Kafka consumer на `order.*`, фильтрация по station	1 неделя	Бэкенд
B. Order Service — расширение	Endpoint `/internal/orders?station_id=`, статусы позиций, события в Kafka (если нет)	1 неделя	Бэкенд (параллельно A)
C. erp-kds — Tauri скелет	Новый репо, Tauri 2 + React + Android target, базовый layout, login	1 неделя	Фронтенд
D. KDS — UI и логика	Карточки заказов, статусы, фильтры, цвета, звуки, техкарта, settings	2 недели	Фронтенд
E. KDS — транспорт-абстракция и e2e	`IKdsTransport`, `CloudTransport`, `MockTransport`, e2e через интернет	1 неделя	Фронтенд
F. Pilot и smoke	Деплой APK, установка на реальный планшет в demo-coffee, неделя реального использования	1 неделя	Все

Итого: ~5–6 недель парных усилий (бэкенд + фронт). Фазы A+B можно делать параллельно с C, потом D зависит от B (контракт).

§9. План работ — файлы под создание/правку

CREATE при `/process-br 5.1`

EDIT при `/process-br 5.1`

CODE (после `/verify 5.1`)

erp-pos-bff — новые routes для KDS (/api/v1/pos/kds/*), Kafka consumer на order.*, WebSocket gateway
erp-order-service — внутренние endpoints, Kafka события (если нужны)
erp-catalog-service — миграция kitchen_stations (поля yellow_threshold_minutes, red_threshold_minutes), API расширения
erp-user-service — таблица kds_devices, endpoint регистрации устройства
erp-admin/web — раздел «KDS-настройки» в админке (per-станция пороги, звуки франшизы), список зарегистрированных KDS-устройств
erp-kds — новый репо: apps/kds, packages/api-client, packages/domain, packages/ui (структура как erp-pos-desktop). Tauri 2 с targets Android + Windows.
In-app updater инфраструктура: https://updates.nirbi.ru/kds/latest.json + хранилище APK (S3/MinIO bucket) + signing keys
CI/CD: GitHub Actions — Android signing, APK release pipeline, публикация manifest для updater

§10. Verification

После реализации (на erp-test.nirbi.ru + demo-coffee tenant):

Создать сотрудника-повара с permission kds.access через админку
Скачать APK, установить на тестовый Android-планшет
Войти в KDS по PIN, выбрать станцию «Горячий цех»
На POS Desktop: пробить заказ с товаром, привязанным к «Горячему цеху»
≤2 сек на KDS появляется заказ + звуковое уведомление
Тапнуть «В работе» на позиции → меняет цвет на синий
Тапнуть «Готово» на позицию → меняет на зелёный с галочкой
Тапнуть «Готово» на весь заказ → заказ уезжает с экрана
На POS у кассира — статус заказа обновился до «готов к подаче»
Отключить Wi-Fi на планшете → красный баннер «Нет связи», текущие заказы остаются
Включить Wi-Fi → баннер «Связь восстановлена», синхронизация
Тестировать просрочку — карточка краснеет, тревожный звук
Тестировать просмотр техкарты — модалка открывается с рецептом
Logout → возврат на PIN-экран
Login другим сотрудником → его станция, его заказы
Multi-station: logout, заново login с галочками «Кухня + Бар» — на экране заказы обеих станций, в карточке группировка, две кнопки «Готово»
Per-станция пороги: в админке «Кухонные станции» поставить «Бар: жёлтый = 2 мин, красный = 0 мин» — на устройстве для бар-заказов цвет соответствует
Per-франшиза звуки: в админке выбрать другую мелодию для «нового заказа» → на устройстве при следующем заказе звучит новая
Reboot устройства: перезагрузить планшет → требует PIN заново
Sleep/wake: заблокировать экран → разблокировать → сессия восстановлена
In-app updater: собрать новый APK с минорным изменением → залить в updates.nirbi.ru/kds/ → на устройстве в Settings «Проверить обновления» → должен показать «Доступна версия X.Y.Z» → тап «Обновить» → APK ставится

§11. Что входит в следующие BR (на будущее)

Чтобы зафиксировать границу скоупа и backlog:

BR	Что	Когда
BR 5.2	KDS LAN-hub mode: POS Desktop поднимает axum-сервер на :8080, KDS подключается по LAN, работа без интернета	P1 (после P0 в проде)
BR 5.3	KDS Offline-first: SQLite-реплика на каждом устройстве, event-log sync, конфликт-резолюшн	P2
BR 5.4	Принтеры per-станция: ESC/POS принтеры через USB/Ethernet, конфиг per-станция в админке	P1
BR 5.5	Bump bar: USB HID-контроллер для high-volume кухонь	P2
BR 5.6	Курсы подачи (горячее/холодное/десерт) — порядок отображения позиций в карточке + последовательная готовка	P2
BR 5.7	Кастомные звуковые файлы per-франшиза (загрузка через админку) — расширение P0 настройки звуков	P2
BR 5.8	Фильтры заказов по типу (зал/самовывоз/доставка) и каналу (POS/web/Yandex)	P1
BR 5.9	Английский UI и i18n-инфраструктура	P2

§12. Ссылки

KDS Architecture Research — детальный анализ паттернов (Toast, iiko, Yuma, Square) и hardware
BR 2.5 — справочник kitchen_stations и requires_kitchen
Кухонные станции — текущая спека
Order Service
Catalog Service
Репозитории
YumaKitchen — обработка заказов (reference)
YumaKitchen — настройки (reference)
YumaKitchen — установка (reference)

ERP Platform Docs

Проводник

KDS Android — кухонный экран MVP

BR 5.1 — KDS Android — кухонный экран MVP

Контекст

Цель

§1. Скоуп

1.1. Что входит (P0)

1.2. Что НЕ входит (отложено)

§2. Сценарии использования

2.1. Утренний запуск кухни

2.1а. Маленькое кафе с одним планшетом на кухню+бар

2.2. Новый заказ от кассира

2.3. Готовка

2.4. Просрочка

2.5. Просмотр техкарты

2.6. Потеря соединения

2.7. Конец смены

§3. Архитектура (бизнес-уровень)

3.1. Высокоуровневая схема

3.2. Endpoints в POS BFF (новые)

3.3. Транспорт-абстракция в коде KDS

3.4. Что нужно от Order Service

§4. Бизнес-правила

§5. Hardware

5.1. Минимальные требования к планшету

5.2. Рекомендованный список (для саппорта)

5.3. Что владелец докупает

§6. Ролевая модель

6.1. Новые permissions

6.2. Как раздаются permissions

§7. Принятые решения

Sideload + in-app updater — что это и как

§8. Фазинг

§9. План работ — файлы под создание/правку

CREATE при /process-br 5.1

EDIT при /process-br 5.1

CODE (после /verify 5.1)

§10. Verification

§11. Что входит в следующие BR (на будущее)

§12. Ссылки

Вид графа

Оглавление

Обратные ссылки

CREATE при `/process-br 5.1`

EDIT при `/process-br 5.1`

CODE (после `/verify 5.1`)