Files
dev-skills/av-dev-pipeline/skills/review-pipeline/references/calibration.md
T
av 9219f4a5cd добавлены плагины av-dev-tasks и av-dev-pipeline
Пара плагинов с намеренно проведённой границей: av-dev-tasks отвечает
за то, что делаем и в каком порядке, av-dev-pipeline — за то, как ведём
одну задачу. Зависимости между ними нет: управление задачами работает и
с ручным исполнением, пайплайн — на проекте с любым учётом задач.

- av-dev-tasks — преемник av-dev-backlog: цели вместо приоритетов,
  спринт под одну цель с заморозкой набора, различение вопроса и
  блокера, каденция «вопросы — разбор — переоценка — набор».
  Раскладка docs/tasks с items/, PLAN.md, BACKLOG.md, SPRINT.md,
  REJECTED.md; проверенное из av-dev-backlog перенесено, не переписано.
- av-dev-pipeline — вынос того, что лежало копиями в healthlog и
  jellybit (3628 строк) и уже разошлось: цикл SDD, конвейер ревью с
  обязательным триажем, прогон нескольких задач разом. Проектная
  специфика вынесена в файл-бриф, charter'ы несут метод.

Коммит фиксирует состояние на момент ревью: три прохода нашли
блокирующие дефекты (нет шага, заводящего бриф; git rebase на занятой
worktree ветке; sprint drop пишет наполовину) — они чинятся следующими
коммитами. Сохранено как база, от которой видно правки.
2026-08-03 11:01:29 +03:00

7.7 KiB
Raw Blame History

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

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

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

  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 прогонов после двух правок промпта, — это театр. Удалять, а не бесконечно править формулировки: каждая итерация правки промпта стоит дороже, чем отсутствие прохода.

Существующий проход не удаляется без замера. Сначала калибровка, потом решение — иначе удаляется то, что работало, а остаётся то, что громче. Обратный пример уже был: проход про идиоматичность стоял в списке на удаление как «вкусовщина», а замер показал, что он зарабатывает экспериментами против поведения библиотеки и драйвера, — и находка, воспроизведённая числом, отменила решение, принятое по ощущению.

Состав проходов принадлежит плагину, а не проекту

Проходы общие. Проект не может удалить проход — он может не звать его, и тогда это идёт строкой «не запускался» в границы покрытия, как любой другой пропуск. Молча сузить состав нельзя: пропуск прохода не отличим от прохода без находок.

Отсюда два следствия:

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

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

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

Проход Класс дефекта для инъекции Заготовка пробы
review-gate отсутствующая верификация убрать тест на изменённую ветку, оставить код рабочим
review-specs поведение вне спеки добавить незаказанный фолбэк-дефолт на пустом входе
review-code нарушение прозаической конвенции увести штатный отказ мимо единой точки трансляции ошибки
review-rubric нарушенное свойство узла у клиента внешнего сервиса убрать таймаут и протяжку context
review-reimpl форма решения размазать решение по трём слоям там, где хватало одной функции
review-architecture второй способ завести вторую точку генерации id мимо единой
review-adversary построенный путь принять внешний идентификатор без разбора до запроса в хранилище
review-ops деградация окружения убрать обработку недоступности внешней зависимости в фоновом цикле
review-triage шум подать 20 находок, из них 15 вкусовщина и 3 дубля — проверить потолок и дедуп

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

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

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