Definition of Done (DoD)

Критерии приемки — это финальный чек-лист готовности, который гарантирует, что задача не просто написана в коде, а полностью интегрирована во все 6 слоев вашей архитектуры

Сводный регламент Definition of Done (DoD) симулятора

Задача считается полностью выполненной и готовой к релизу в продакшн-контур только при условии выполнения 100% критериев из следующих технологических блоков:

1. Слой Контрактов и Валидации (API / Data Contracts)

• Все входящие JSON-структуры строго валидируются через Pydantic на стороне backend-api (FastAPI).
• К любым текстовым параметрам, вводимым пользователем руками (включая dish_name), применен лимит длины (\(\le 120\) символов) на шлюзе.
• Ошибки валидации типов данных возвращают клиенту код HTTP 422 Unprocessable Entity с маппингом из error-directory.
• Новые типы системных ошибок зарегистрированы в PostgreSQL Auth DB эндпоинта /api/v1/auth/error-directory.

2. Слой Интеграции ИИ и Безопасности (AI / Censorship Layer)

• Реализована Fail-Fast логика в censorship-control-worker: при обнаружении мата (is_clean = False) транзакция немедленно блокируется.
• Abuse Counter: Нарушения цензуры корректно инкрементируются в In-Memory Redis.
• Реализован сценарий блокировки: при достижении критического порога нарушений аккаунт получает статус SUSPENDED через gRPC к auth-service.
• Модуль Ollama (Llama) возвращает строго структурированный JSON-пакет расходов с каноничными именами продуктов на языке app_lang.

3. Слой Архитектуры Баз Данных (Database-per-Service)

• Все миграции написаны в виде изолированных DDL-скриптов и содержат рабочий сценарий отката (Rollback / Down script).
• Таблицы остатков еды поддерживают партионный учет (FIFO) и не суммируются автоматически при вводе без вызова метода merge.
• Маскировка минусов: В СУБД холодильника сохраняются реальные отрицательные балансы для HOME контура, но геттеры fridge-service на лету подменяют их на 0 для фронтенда.
• Созданы и проверены через EXPLAIN индексы по home_group_id для быстрой выгрузки состояния полок.

4. Слой Бизнес-Логики и Стриминга (Business & Stream Layer)

• Потоковые воркеры (PurchaseStreamWorker) корректно оркеструют WebSocket/gRPC сессии и завершают их по событию CLOSE_STREAM.
• Вызовы между микросервисами (например, cook-service \(\rightarrow\) fridge-service) выполняются строго по протоколу gRPC, а не HTTP.
• В логике списания соблюдено ветвление space_type: в режиме HOME разрешен уход баланса в минус, в режиме OFFICE — выдается ошибка HTTP 422.

5. Слой Сквозного Аудита и Наблюдаемости (BUPAR & Observability)

• Каждое ключевое изменение баланса эмитит событие в топик fridge-stock-mutations.
• Сервис BUPAR асинхронно вычитывает все мутации и корректно регистрирует шаги графа процессов (FOOD_CONSUMED, FOOD_WASTED, SHORTAGE_RECONCILED).
• В stdout каждого контейнера пишутся структурированные логи, содержащие сквозной идентификатор трессировки X-Request-ID и параметр app_lang.
• Логи успешно индексируются в Grafana Loki и доступны для сквозного поиска по X-Request-ID от Edge-слоя до базы данных.

6. Слой Тестирования и Покрытия (Quality Assurance)

• Написаны unit-тесты на логику работы бинарного цензора (тест-кейсы со словарями мата для RU, KZ, EN).
• Общее покрытие кода тестами (test coverage) для нового функционала составляет \(\ge 80\%\).
• Написаны интеграционные тесты, эмулирующие асинхронный Fire-and-Forget контракт B2B-вебхуков от магазинов.