Критерии оценивания

1. Процесс оценивания

30-минутная беседа с жюри.

В этой беседе нужно:

1. Показать заранее подготовленные данные/сценарии, на которых видно, как работают сервисы.
2. Подтвердить ключевые обязательные критерии на демо.
3. Ответить на уточняющие вопросы жюри по реализации и ограничениям.

Порядок проверки в беседе:

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

1.1 Принцип проверяемости

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

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

1.2 Что подготовить заранее (обязательные артефакты)

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

2. Как считается итог

• Максимум: 100 баллов.
• Обязательная часть: 80 баллов.
• Дополнительные фичи: максимум 20 баллов.
• Формула: итог_100 = баллы_обяз + баллы_доп.

3. Обязательные критерии (80 баллов)

B1. Запуск и воспроизводимость (10)

ID	Критерий (бинарно)	Выполнено, если	Не выполнено, если	Балл
B1-1	Система должна описывать предусловия запуска.	В инструкции перечислены обязательные зависимости/переменные/сервисы.	Нет явных предусловий или они неполные.	2
B1-2	Система должна содержать команду(ы) запуска.	В инструкции есть точные команды старта без догадок.	Команды отсутствуют или неоднозначны.	2
B1-3	Система должна запускаться только по инструкции.	Система поднимается без скрытых ручных шагов.	Для запуска нужны неописанные ручные действия.	2
B1-4	Система должна подниматься в рабочее состояние.	Сервисы стартуют и доступны.	Сервисы не стартуют или падают на старте.	2
B1-5	Система должна проходить сквозной happy-path.	Проходит путь «выдача варианта -> событие -> результат».	Сквозной сценарий не воспроизводится.	2

B2. Feature Flags и выдача вариантов (10)

ID	Критерий (бинарно)	Выполнено, если	Не выполнено, если	Балл
B2-1	Система должна возвращать default, если активного эксперимента нет.	Для флага без активного эксперимента возвращается default.	Возвращается вариант эксперимента при его отсутствии.	2
B2-2	Система должна возвращать default, если пользователь не проходит правило участия.	При непройденном таргетинге возвращается default.	Пользователь вне таргетинга получает вариант.	2
B2-3	Система должна возвращать variant, если эксперимент применим.	Для подходящего пользователя возвращается вариант.	При применимости возвращается default.	2
B2-4	Система должна быть детерминированной при неизменной конфигурации.	Повторные запросы одного субъекта дают одинаковый результат.	Результат меняется без изменения условий.	2
B2-5	Система должна учитывать веса вариантов в раздаче.	Фактическое распределение близко к заданным весам.	Распределение системно не соответствует весам.	2

B3. Эксперименты: жизненный цикл и ревью (10)

ID	Критерий (бинарно)	Выполнено, если	Не выполнено, если	Балл
B3-1	Система должна поддерживать переход draft -> in_review.	Переход выполняется штатно.	Переход отсутствует или даёт неверный статус.	2
B3-2	Система должна поддерживать переход in_review -> approved при соблюдении условий.	При выполнении условий статус становится approved.	Даже при выполнении условий статус не меняется корректно.	2
B3-3	Система должна блокировать запуск без достаточного числа одобрений.	До порога запуск блокируется.	Эксперимент запускается без нужных одобрений.	2
B3-4	Система должна блокировать недопустимые переходы статусов.	Запрещённые переходы не выполняются.	Можно выполнить переход вне правил.	2
B3-5	Система должна применять политику ревью к конкретным ролям/группам.	Одобрять могут только назначенные роли/пользователи.	Неназначенный пользователь может повлиять на ревью.	2

B4. События и атрибуция (10)

ID	Критерий (бинарно)	Выполнено, если	Не выполнено, если	Балл
B4-1	Система должна валидировать типы полей входящего события.	Событие с неверным типом поля отклоняется.	Невалидные типы принимаются как валидные.	2
B4-2	Система должна валидировать обязательные поля события.	Событие без обязательных полей отклоняется.	Неполное событие принимается.	2
B4-3	Система должна дедуплицировать дубликаты событий.	Дубликат не меняет итоговый расчёт.	Дубликат учитывается как новое событие.	2
B4-4	Система должна сохранять связь экспозиции с decision_id.	Экспозиция содержит корректный decision_id.	Экспозиция не связана с решением.	2
B4-5	Система должна атрибутировать конверсию только при валидной связи с экспозицией.	Конверсия без пары «решение/экспозиция» не учитывается.	Конверсия учитывается без подтверждённой экспозиции.	2

B5. Устойчивость и safety-механики (10)

ID	Критерий (бинарно)	Выполнено, если	Не выполнено, если	Балл
B5-1	Система должна хранить metric_key для guardrail-правила.	У guardrail явно задана метрика контроля.	Метрика контроля не задана или невалидна.	1
B5-2	Система должна хранить порог guardrail-правила.	У guardrail явно задан порог срабатывания.	Порог не задан или не используется.	1
B5-3	Система должна обнаруживать факт превышения порога guardrail.	При деградации правило фиксируется как сработавшее.	Превышение есть, но система его не обнаруживает.	2
B5-4	Система должна выполнять выбранное действие после срабатывания guardrail.	Выполняется пауза/откат по правилу.	Действие не выполняется или не соответствует правилу.	2
B5-5	Система должна фиксировать срабатывание guardrail в аудите.	В истории есть запись с метрикой/порогом/временем/действием.	Срабатывание не отражено в истории.	2
B5-6	Система должна ограничивать постоянное участие пользователя в экспериментах.	Политика ограничения участия применяется повторно.	Ограничение не применяется.	2

B6. Отчётность и принятие решения (10)

ID	Критерий (бинарно)	Выполнено, если	Не выполнено, если	Балл
B6-1	Система должна поддерживать фильтр отчёта по периоду.	Можно задать окно времени, и отчёт перестраивается.	Фильтр периода отсутствует или не влияет.	2
B6-2	Система должна показывать отчёт в разрезе вариантов.	Для каждого варианта доступны отдельные показатели.	Есть только агрегат без разреза вариантов.	2
B6-3	Система должна показывать выбранные метрики эксперимента.	В отчёте отображаются метрики из конфигурации.	В отчёте нет части выбранных метрик.	2
B6-4	Система должна поддерживать фиксацию исхода эксперимента (rollout/rollback/no effect).	Исход можно выбрать и сохранить.	Исход нельзя зафиксировать или набор исходов неполный.	2
B6-5	Система должна сохранять обоснование принятого решения.	К решению сохраняется комментарий/обоснование.	Решение сохраняется без объяснения.	2

B7. Архитектура и ориентируемость (9)

ID	Критерий (бинарно)	Выполнено, если	Не выполнено, если	Балл
B7-1	Система должна иметь понятный нейминг сущностей и интерфейсов.	По названиям сущностей, эндпоинтов, событий, метрик и ключевых полей можно понять назначение без «внутренних знаний».	Нейминг создаёт двусмысленность и требует догадок.	1
B7-2	Система должна иметь явные границы модулей.	Ответственности модулей разделены и не смешаны.	Границы модулей неочевидны или ответственности смешаны.	1
B7-3	Система должна иметь заполненную матрицу соответствия задание-критерий-реализация.	Матрица заполнена и по ней можно быстро найти: где реализовано, как проверить и какие данные нужны по ключевым критериям.	Матрица отсутствует или не помогает проверке (пустая/формальная/ссылки нерабочие).	1
B7-4	Система должна фиксировать ключевые архитектурные решения.	В документации есть список ключевых решений и их риски/ограничения, и это согласуется с кодом/демо.	Решения не зафиксированы или противоречат фактической реализации.	1
B7-5	Система должна иметь C4 Context диаграмму.	Есть C4 L1 Context: внешние акторы/системы и границы платформы.	Диаграмма отсутствует или не помогает понять границы.	1
B7-6	Система должна иметь C4 Container диаграмму.	Есть C4 L2 Container: основные контейнеры/сервисы, их ответственности и ключевые взаимодействия.	Диаграмма отсутствует или не помогает понять разбиение на сервисы/контейнеры.	1
B7-7	Система должна иметь ограниченную детализацию C4 Component для критичного пути.	Есть C4 L3 Component для одного ключевого контейнера, покрывающая критичный путь decide -> event -> report/guardrail. Без детализации до классов и без попытки описать весь проект.	Детализации нет или она не помогает объяснить критичный путь.	1
B7-8	Система должна иметь карту репозитория для быстрого ориентирования.	В документации есть карта репозитория: точки входа, основные папки/модули и где смотреть критичный поток.	Карта отсутствует и по репозиторию сложно ориентироваться.	1
B7-9	Система должна явно фиксировать ключевые ограничения и упрощения.	В документации перечислены ключевые ограничения/упрощения и где они проявляются в демо/коде.	Ограничения не зафиксированы или всплывают только в вопросах.	1

B8. Тестирование (3)

ID	Критерий (бинарно)	Выполнено, если	Не выполнено, если	Балл
B8-1	Система должна иметь негативные тесты.	Есть хотя бы один негативный тест.	Негативные сценарии не проверяются тестами.	1
B8-2	Система должна иметь интеграционные/контрактные тесты критичного пути.	Есть тест межмодульного/контрактного взаимодействия.	Нет тестов на критичное взаимодействие.	1
B8-4	Система должна иметь отчёт по тестированию с измеримым покрытием (или эквивалентом).	Есть отчёт по тестированию с командами запуска и показателем покрытия (или эквивалентом), который можно проверить.	Отчёт отсутствует или непроверяем (команды/покрытие не воспроизводимы).	1

B9. Эксплуатационная готовность и наблюдаемость (6)

ID	Критерий (бинарно)	Выполнено, если	Не выполнено, если	Балл
B9-1	Система должна иметь проверку readiness с однозначным поведением.	/ready отвечает 200, когда приложение готово принимать запросы, и достигается не позднее 180 секунд после старта. Если 180 секунд истекли, жюри вправе запускать проверки в текущем состоянии системы.	Проверка отсутствует, неработоспособна или поведение не соответствует договору.	1
B9-2	Система должна иметь проверку liveness с однозначным поведением.	/health отвечает 200, когда процесс жив.	Проверка отсутствует, неработоспособна или возвращает неверный код.	1
B9-3	Система должна экспортировать базовые метрики.	На демо можно увидеть точку экспорта метрик и примеры значений. Есть минимум: счётчики запросов и ошибок (или эквивалент) и хотя бы одна продуктовая метрика, связанная с выдачей/событиями/отчётом.	Метрики отсутствуют или по демо нельзя понять, что именно и где измеряется.	1
B9-4	Система должна писать структурированные логи.	Логи имеют стабильный формат полей.	Логи неструктурированные.	1
B9-6	Система должна учитывать нагрузку и рост данных.	Есть механизм поведения под ростом нагрузки/объёма.	Поведение при росте данных не описано/не реализовано.	1
B9-7	Система должна иметь меры эффективности хранения/чтения.	Для горячих путей есть индексы/лимиты/оптимизация.	Горячие пути без мер оптимизации.	1

B10. Инженерная дисциплина (2)

ID	Критерий (бинарно)	Выполнено, если	Не выполнено, если	Балл
B10-1	Система должна иметь автоматизированный линтинг.	Есть штатная команда линтинга.	Линтинг не автоматизирован.	1
B10-2	Система должна иметь автоматизированное форматирование кода.	Есть штатная команда/конфиг форматтера.	Форматирование не автоматизировано.	1

4. Дополнительные фичи (до 20 баллов)

• К оценке принимаются до 3 допфич из части C.
• Каждая допфича даёт до 7 сырых баллов.
• Итог по допфичам: баллы_доп = min(20, сырые_баллы_доп).

Критерии оценки каждой выбранной допфичи

ID	Критерий (бинарно)	Выполнено, если	Не выполнено, если	Балл
FX-1	Система должна реализовывать рабочий сценарий выбранной допфичи.	На демо проходит целевой сценарий допфичи.	Сценарий не воспроизводится или работает частично.	4
FX-2	Система должна фиксировать ограничения и условия применения допфичи.	В документации описаны границы/риски и это согласуется с демо.	Документация формальна или противоречит поведению.	3

5. Шаблон матрицы соответствия (обязательно заполнить)

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

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