Что считается результатом участника

D.1 Цель сдачи

Итог работы участника — воспроизводимое backend-решение, которое проходит проверку по критериям B1..B10 и, при наличии, по выбранным допфичам из части C.

D.2 Принцип проверяемости и риск нулевой оценки

Главный критерий оценивания — работоспособность в проверяемом сценарии.

1. Любое заявленное требование должно быть проверяемо на демо с вашими тестовыми данными.
2. Если жюри не может проверить критерий на предоставленных данных/сценариях, по этому критерию может быть выставлено 0 баллов.
3. Если допфича заявлена, но не проверяется воспроизводимо, она не даёт баллов.
4. Все спорные или упрощённые места должны быть явно зафиксированы в документации сдачи.

D.3 Формат 30-минутной проверки

1. Запуск по инструкции и проверка готовности среды.
2. Демонстрация обязательных сценариев B1..B10.
3. Демонстрация выбранных допфич (если заявлены).
4. Короткие вопросы жюри по ограничениям, компромиссам и воспроизводимости.

D.4 Обязательные артефакты сдачи

Артефакт	Какую проблему закрывает	Что должно быть внутри
Runbook запуска и проверки	Без единой инструкции жюри не может воспроизвести запуск	предусловия, переменные окружения, точные команды старта, команды проверок, expected output
Пакет тестовых данных и сценариев демо	Без контролируемых данных нельзя проверить happy-path и edge-case	данные для позитивных/негативных/граничных сценариев, шаги воспроизведения, ожидаемые результаты
Архитектурный пакет диаграмм	Без схем сложно понять границы системы и быстро ориентироваться	C4 Context, C4 Container, C4 Component для одного ключевого контейнера на критичный поток decide -> event -> report/guardrail без детализации до классов
Отчёт по тестированию	Без отчёта нельзя оценить полноту тестов	перечень тестовых наборов, команды запуска, покрытие тестами (line/branch или эквивалент), список ограничений
Набор подтверждений наблюдаемости и эксплуатационной готовности	Без операционных артефактов нельзя оценить B9	примеры структурированных логов, health/readiness проверки, метрики, команды lint/format
Матрица соответствия задание-критерий-реализация	Без трассируемости сложно быстро и однозначно оценить работу	заполненная таблица по шаблону из D.6

D.5 Минимальный набор проверок по блокам критериев

Блок	Что должно быть проверяемо	Какие артефакты подтверждают
B1	запуск по инструкции, рабочее состояние, сквозной happy-path	runbook, сценарий демо, тестовые данные
B2	default/variant, таргетинг, детерминизм, веса	сценарии запросов, фиксированные входные данные, результаты повторных прогонов
B3	корректные переходы статусов, ревью, блокировки запуска	сценарий жизненного цикла, журнал действий/аудит
B4	валидация событий, дедуп, атрибуция по decision_id	каталог событий, негативные примеры, отчёт/лог атрибуции
B5	настройка guardrail, срабатывание, действие, аудит, ограничение участия	конфигурация guardrail, сценарий деградации, запись о срабатывании
B6	отчёт по периоду и вариантам, выбранные метрики, фиксация исхода (rollout/rollback/no effect)	сценарий отчётности, примеры результатов, зафиксированное решение с обоснованием
B7	архитектура и ориентируемость	нейминг, границы модулей, ключевые архитектурные решения, C4 диаграммы без фанатизма, карта репозитория, ограничения/упрощения, матрица соответствия
B8	тестирование	негативные тесты, интеграционные/контрактные тесты, отчёт по тестированию и покрытие (или эквивалент)
B9	эксплуатационная готовность и наблюдаемость	health/readiness, метрики, логи, описание поведения под нагрузкой и роста данных, меры эффективности хранения/чтения
B10	инженерная дисциплина	команды lint/format, конфиги инструментов
FX	рабочий сценарий и ограничения выбранной допфичи	демо-сценарий допфичи, описание границ и рисков

D.6 Шаблон матрицы соответствия

Заполните таблицу и приложите её в составе сдачи. Для каждой выбранной допфичи из части C добавьте отдельные строки FX-1 и FX-2.

ID задания	ID критерия	Проблема/риск	Где реализовано	Как проверяется	Какие данные нужны	Статус
3.4	B2-1	При отсутствии активного эксперимента система возвращает не default, из-за чего ломается контрольный сценарий и сравнение вариантов.	backend/runtime/decide_service	POST /decide для флага без активного эксперимента; ожидается возврат default и корректный decision_id.	Фикстура: флаг с default, отсутствует активный эксперимент, тестовый субъект u-001.	пример

D.7 Границы постановки

1. Конкретный API-дизайн, структура данных и внутренние алгоритмы определяются участником.
2. Для спорных мест важна воспроизводимая логика и понятное обоснование, а не «единственно правильный» формат реализации.
3. Если часть сценариев упрощается, это должно быть явно зафиксировано в документации и матрице соответствия.
4. Где возможно, описывайте решаемую проблему и ограничения, а не только выбранную реализацию.