Идеи
Арена решений/design/scoring.md

Оценка вариантов (v0)

Принцип: мало чисел, все объяснимы, все сравнимы между вариантами одной задачи. Сравнивать варианты разных задач нельзя и не нужно.

Что измеряем

Блок Метрика Откуда Вес
Тесты прошло / всего скрытых e2e Playwright, автоматически 50
Требования REQ реализованы по графу или чеклисту (есть код, есть тест, тест прошёл) Twin, пока руками 20
Правила нарушений архитектурных правил из rules.md Twin, пока руками 15
Стоимость время исполнителя, число итераций до «поднимается», токены (для моделей) лог прогона 10
Вес размер клиентского бандла, число зависимостей du, package.json 5

Итог 0..100. Веса на первое время, менять после трёх прогонов, когда станет видно, что реально различает варианты.

Нормировка: тесты и требования это доли, умноженные на вес. Правила: 15 минус 3 за нарушение, не ниже 0. Стоимость и вес: лучший вариант в задаче получает полный вес, остальные пропорционально.

Правила для задачи «магазин» (rules.md)

Пять правил, проверяются графом или глазами за десять минут:

  1. UI-компоненты не обращаются к хранилищу напрямую, только через слой данных.
  2. Цена считается в одном месте. Не больше одной функции, которая умножает цену на количество.
  3. Валидация формы заказа общая для клиента и сервера.
  4. Нет зависимостей ради одной функции (например, lodash ради debounce).
  5. Админка и витрина не делят состояние клиента.

Ручной чеклист до появления Twin

Для каждого варианта, 20 минут:

  • По каждому REQ: есть ли код (grep по id в коммитах и коде), есть ли тест, прошёл ли. Три галочки на требование.
  • По каждому правилу: нарушено или нет, где.
  • Impact: для REQ-shop-08 (пересчёт суммы) посчитать, сколько файлов его реализуют. Чем меньше, тем лучше связность.
  • Записать время и число итераций из лога.

Когда Twin появится, он выдаёт те же пункты. Формат results.json не меняется.

Формат результатов

solutions-arena/results/results.json, одна запись на прогон:

{
  "task": "shop",
  "variant": "claude-fable",
  "axis": "model",
  "baseline": null,
  "date": "2026-11-05",
  "tests": { "passed": 19, "total": 22 },
  "requirements": { "implemented": 20, "tested": 19, "total": 22 },
  "rules": { "violations": 1, "notes": ["R2: пересчёт суммы в двух местах"] },
  "cost": { "minutes": 95, "iterations": 3, "tokens": 410000 },
  "size": { "bundle_kb": 212, "deps": 14 },
  "score": 81,
  "adr": ["ADR-001"]
}

Рядом results/<task>/<variant>.md: человеческие заметки прогона, что удивило, что сломалось. Этот файл сайт показывает как обычную страницу идеи в «Подробнее».

Как это выглядит на сайте идей

Сайт статический и читает только markdown и файлы в папке. Поэтому два уровня:

  1. Таблица в README в разделе Итог, обновляется руками или скриптом tools/results-table.mjs в репо Арены, который из results.json печатает markdown:

    Вариант Ось Тесты REQ Правила Балл
    claude-fable модель 19/22 20/22 1 81

  2. preview/index.html: интерактивная таблица задача × вариант × балл с сортировкой и раскрытием строки до деталей, читает ../results/results.json. Сайт идей покажет кнопку «Открыть превью». Делается после третьего прогона, не раньше.

Чего не делаем в оценке

  • Не оцениваем красоту кода на глаз. Если что-то важно, оно становится правилом в rules.md.
  • Не используем LLM как судью. Судья детерминированный или ты.
  • Не сравниваем баллы между задачами.