# Калибровка проходов

Без измерения набор проходов растёт монотонно и вырождается в театр: каждый
кажется полезным, потому что иногда что-то говорит. Калибровка отвечает на
единственный вопрос — **ловит ли проход дефект своего класса**.

## Процедура (инъекция дефекта)

1. Взять **реальный коммит** из истории (`git log --oneline`), лучше
   архивированный change с непустым диффом.
2. Внести в него **один** дефект того класса, который проход обязан ловить по
   своему charter'у. Дефект должен быть правдоподобным — таким, какой реально
   пишет модель, а не карикатурой (`panic("TODO")` не считается).
3. Прогнать **только этот проход** на подготовленном диффе — **три раза**,
   каждый в чистом контексте.
4. Зафиксировать: нашёл `n/3`, число находок всего, число ложных.
5. Вердикт:

| Результат | Вердикт | Что делаем |
|---|---|---|
| нашёл 3/3 или 2/3, ложных немного | `keep` | ничего |
| нашёл 1/3 или 0/3 | `retune` | правим charter — сужаем вход, убираем чек-лист, добавляем оракул |
| `retune` уже был дважды подряд | `drop` | удаляем проход |
| находит, но ложных больше трети от всех находок | `retune` | триаж съедает больше, чем экономит проход |

**`retune` не более двух раз подряд.** Проход, не находящий дефект своего класса
в 2 из 3 прогонов после двух правок промпта, — это театр. Удалять, а не
бесконечно править формулировки: каждая итерация правки промпта стоит дороже,
чем отсутствие прохода.

**Существующий проход не удаляется без замера.** Сначала калибровка, потом
решение — иначе удаляется то, что работало, а остаётся то, что громче.

## Пробы дефектов по проходам

Проба — заготовка инъекции. Список пополняется из
[журнала проскочивших дефектов](../../../../docs/review/journal.md): реальный
проскочивший дефект — лучшая проба, какая вообще возможна, потому что
синтетические смещены в сторону тех, которые уже умеешь придумывать.

| Проход | Класс дефекта для инъекции | Заготовка пробы |
|---|---|---|
| `jellybit-review-gate` | отсутствующая верификация | убрать тест на изменённую ветку, оставить код рабочим |
| `jellybit-review-specs` | поведение вне спеки | добавить незаказанный фолбэк-дефолт при пустом ответе LLM |
| `jellybit-review-rubric` | нарушенное свойство узла | в клиенте внешнего API убрать таймаут/протяжку `context` |
| `jellybit-review-reimpl` | форма решения | размазать решение по трём слоям там, где хватало одной функции |
| `jellybit-review-idiom` | «распространённое» вместо идиоматичного | завести интерфейс с одной реализацией ради мока |
| `jellybit-review-negative` | отсутствующее | убрать `state transition` из новой стадии воркера |
| `jellybit-review-architecture` | второй способ | завести вторую точку генерации id мимо `internal/ident` |
| `jellybit-review-adversary` | построенный путь | принять внешний id без `ident.Parse` до запроса в БД |
| `jellybit-review-ops` | деградация зависимости | убрать обработку недоступности qBittorrent в фоновом цикле |
| `jellybit-review-triage` | шум | подать 20 находок, из них 15 вкусовщина и 3 дубля — проверить потолок и дедуп |

Метрик сверх этого не заводим. Precision, корреляция между проходами, стоимость
прогона в токенах — всё это красиво звучит и никем не считается вручную; набор
показателей, который не собирают, создаёт впечатление измеряемости и тем вреден.
Работает ровно один механизм: инъекция дефекта и вердикт. Если корреляция двух
проходов действительно бросается в глаза — это видно по полю `Найдено проходом`
в триажированных отчётах и без отдельной метрики.

## Когда калибровать

- при заведении нового прохода — **до** включения в профиль по умолчанию;
- при правке charter'а существующего — иначе непонятно, правка помогла или нет;
- при появлении записи в журнале проскочивших дефектов — калибруем тот проход,
  который должен был поймать;
- планово — нет. Календарная калибровка ради галочки сама превращается в театр.