feat(search): перебор конфигураций политики и эталонное распределение очереди

[retrobich921]

Что это

Отвечаем на вопрос «а можно ли настроить роутер лучше?» не интуицией, а перебором.
Добавлена команда search, которая гоняет конфигурации политики через настоящий роутер
(не модель поверх модели) на общей батарее очередей, и AssignmentBound, который считает
эталонное распределение той же очереди точным min-cost flow.

Прогнали 113 000 конфигураций в два раунда. Разбор — в docs/search.md.

Главные выводы

1. Дефолтная политика balanced уже на границе Парето. Из 113 000 конфигураций базу
   доминируют единицы, и все на уровне шума: 67.49 → 67.07 п.п. отклонения, конверсия +0.05%.
   Подбирать веса дальше бессмысленно.
2. Кривая размена измерена целиком: +21 п.п. отклонения от целевых долей покупают
   +6.2% конверсии и +8% маржи. Это выбор бизнеса одной строкой в YAML, а не программиста в коде.
3. Жадный онлайновый роутер берёт 92–96% того, что берёт всезнающий пакетный оптимум
   (команда bound). Переписывать выбор на batch-оптимизацию ради этих процентов незачем.
4. Узкое место не в политике, а во входных данных. На реалистичном потоке payflow
   допустим примерно в 2% заявок при цели 35%: дневной лимит выбран на 96.7% (2.9 из 3 млн),
   потолок чека 50 тыс. Снижение traffic_percentage с 35% до 10% даёт −25 п.п. отклонения
   без потери конверсии — в шестьдесят раз больше, чем весь перебор весов.
   Ровно это наш отчёт и рекомендовал сам; перебор рекомендацию не опроверг, а измерил.
5. Аблации: turnover_min не меняет вообще ничего (подтверждает goal_activity и правило
   dead_goal), а cascade_priority и amount_band стоят 4.1 п.п. соблюдения долей ради
   0.7% конверсии — осознанный размен, обе цели из ТЗ.

Что добавлено

lib/payout_router/search/	Battery, Space, Front, Engine, Metrics, Outcome, Candidate
analytics/assignment_bound.rb + min_cost_flow.rb	эталонное распределение очереди как транспортная задача
strategies/share_deficit.rb	доли в заявках (deficit round-robin) вместо процентов
selection.normalization: damped	третий режим нормировки: лечит вырождение pool при двух кандидатах
config/policies/bank_affinity_first.yml	пресет по итогам перебора: +5.2% бэктеста против +4.7% у conversion_first
docs/search.md	разбор перебора: как устроен, что нашёл, что не сработало
docs/criteria.md	сверка с каждым подкритерием трека (100 + 140 + 20): артефакт, команда проверки, честно названные слабые места

Ревизия документации

Сверены с фактическим прогоном все числа во всех .md: 236 спеков, покрытие строк 96.0%,
14 hard-правил, 13 целей, 13 правил рекомендаций, 10 пресетов, 11 политик в compare,
бэктест 72.2 → 75.6, соотношение Ruby/Python 91/9. Раньше в разных файлах стояли 211/213/181 спек,
11/12/13 правил рекомендаций и бэктест «+6.9%», которого давно нет.

Исправлена производительность (в доках стояло ≈2 700 заявок/с с ноутбука разработки, на Ryzen 7 9700X
полный конвейер даёт 10 642 на 50 000 и 10 323 на 200 000) и curl localhost:8080 → 127.0.0.1
(на Windows localhost уходит в IPv6 ::1, и соединение не устанавливается).

Удалён docs/checkpoint2.md — он повторял docs/checkpoint.md и уже разошёлся с ним в цифрах.
Уникальное перенесено туда, где ему место: «задача простыми словами» и таблица «если что-то
не так» — в README (их читает жюри), новые вопросы к экспертам — в docs/checkpoint.md §5.
Дублирующая таблица критериев из docs/plan.md заменена указателем на docs/criteria.md.

Исправлена ошибка в модели эталона

Первая версия AssignmentBound давала оптимум с квотами выше оптимума без них — невозможный
результат. Причина: self-provider был доступен эталону без ограничений, а по модели одобрения он
выглядит лучше всех внешних (нет истории, заявленные 0.95 против откалиброванных 0.62–0.80,
нет лимитов). Квоты выталкивали заявки на него и «улучшали» результат. Теперь эталону разрешено
ровно столько заявок на self-provider, сколько использовал наш роутер — наше распределение заведомо
допустимо в его задаче, и оптимум становится настоящей верхней границей. Инвариант закреплён спеком.

Что честно не сработало

• share_deficit — механика строго сильнее процентной, но в одиночку даёт ровно то же
  распределение, что traffic_share: выбор упирается в допустимость, а не в закон управления.
  В смеси — 1 п.п. Оставлен с нулевым весом, за улучшение не выдаём.
• damped — в финал попадает (208 конфигураций из 473), границу Парето не сдвинула.

Риск для сдачи: нулевой

Дефолтная политика, режим simulation.mode: optimistic и формат attempts не тронуты.
bundle exec rake public перегенерирует routing_decisions.json и routing_report.json
байт в байт такими же, как в main.

Как проверить

$env:PATH = "C:\Ruby40-x64\bin;" + $env:PATH

bundle exec rake            # 236 спеков, 0 падений; RuboCop 164 файла, 0 замечаний
bundle exec rake validate   # скрипт организаторов 29/0/0, наш валидатор 30/0/0
bundle exec rake public     # git status после него должен быть пустым — сдаваемые файлы не изменились

ruby -Ilib bin/payout_router search --samples 60   # ~1 минута: граница Парето и лидеры по метрикам
ruby -Ilib bin/payout_router bound                # эталонное распределение и разрыв с ним
ruby -Ilib bin/payout_router backtest --policy config/policies/bank_affinity_first.yml
ruby -Ilib bin/payout_router strategies            # 14 hard-правил, 13 целей, 10 пресетов

🤖 Generated with Claude Code

https://claude.ai/code/session_01N7LBzBD5qBUzAAPsGTB9Nk