dev-skills/av-dev/skills/task-track/references/from-review.md

# Задачи из аудита и ревью

Ревью и аудиты — код-ревью, архитектурный проход, аудит безопасности, любой
разбор другим агентом — порождают находки, часть которых становится задачами.
Это отдельный интейк со своей опасностью, **зеркальной** интейку из диалога.

- Интейк из диалога грешит переполнением: из одной мысли рождается пять файлов.
- Интейк из ревью грешит сваливанием: сорок сырых находок превращаются в сорок
  файлов. Беклог раздувается, а следующая переоценка склеивает их обратно.

Защита от сваливания — та же, что в самом ревью: **кластеризация по причине, а
не файл-на-находку.** Если у ревью был триаж — половина работы уже сделана, бери
его выход. Если нет — триажируй сам, прежде чем заводить.

**Штатный отправитель — `av-dev:code-review`** (и `av-dev:code-resolve`, который
его вызывает): задач он не заводит сам, а отдаёт отложенные находки **списком
урожая** — формулировка, оракул, провенанс — и хранит отчёт триажа вместе с
изменением. Приходит и любой другой разбор, вплоть до пересказа человеком; тогда
триажа нет и шаг 1 порядка делается руками.

## Находка агента — не задача

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

Отсюда фильтр входа, поверх обычного «не делаем сейчас + пожалеем о потере»:

- **Находка со свидетельством**, отложенная к исполнению → **задача**.
  Свидетельство и последствие переносим в тело — это её «почему», то самое, что
  переживает запись.
- **Находка без свидетельства / низкой уверенности** → **сырьё**: `research`, у
  которого раздел «Вопрос» и есть недостающее свидетельство («при каких условиях
  это воспроизводится»). Не `fix`: без `Воспроизведения` его в работу не
  возьмут, и правильно — чинить нечего, пока непонятно, что ломается. Судьба
  сырья — штурм, где либо найдётся подтверждение, либо оно уедет в
  `REJECTED.md`.
- **Уже починено по ходу ревью** → **ничего**. Починенное не заводим.
- **Развилка, решённая при ревью** → ничего; решённая «потом» → задача с
  вопросом в разделе «Вопросы» и тегом `question`.

## Порядок

1. **Возьми выход триажа, а не сырые находки.** Сырой отчёт — это симптомы до
   дедупликации; в нём одна причина размазана по нескольким строкам.
2. **Кластеризуй по причине.** Пять находок об одном отсутствующем инварианте —
   одна задача, а не пять. Класс мелочи (nits, косметика) — **один пакетный
   файл** со списком пунктов, а не файл на каждую запятую.
3. **Дедуп против живых задач и `REJECTED.md`.** Аудит переоткрывает уже
   заведённое и уже выкинутое. Нашлось среди живых — дописываем находку в
   существующий файл. Нашлось в `REJECTED.md` — это сигнал: причина отказа могла
   устареть, выноси пользователю, а не заводи молча заново.
4. **Проставь типы.** Большинство находок ревью это `fix` и `chore`. Находка,
   оказавшаяся **новой возможностью** (`feature`), — отдельный случай: нашлось
   поведение, которого никто не заказывал, и решение тут не «завести задачу», а
   «заказать или убрать». Выноси такую пользователю отдельно от прочих.
5. **Покажи карту до создания файлов.** Кластер → задача / сырьё / строка в
   пакетный файл / уже заведено / отброшено — пачкой через
   `AskUserQuestion`. Это тот же барьер, что и «три кандидата» в интейке из
   диалога: массовое заведение файлов без подтверждения — ровно тот отказ, ради
   которого интейк из ревью и выделен. Дешёвая мелочь по явному согласию может
   заводиться и без поштучного вопроса — но карта пользователю предъявляется
   всё равно.
6. **Заводи утверждённое** через `tasks.py add`, с тремя добавками:
   - **тег партии** — `--tag review-ГГГГ-ММ-ДД` (или `audit-<slug>`), чтобы весь
     заход разбора поднимался одной командой `list --tag …`;
   - **тип** — `--type`, и он **не по умолчанию `fix`**: починкой считается
     расхождение с заявленным поведением, а находка «этого свойства никто не
     заказывал» — это `feature`, находка «не знаем, как поведёт себя драйвер» —
     `research`. Тип, розданный оптом, врёт ровно там, где по нему потом
     отбирают, **и требует не тех разделов**: каждому `fix` придётся заполнить
     `Воспроизведение`, а у находки без свидетельства его нет;
   - **провенанс в теле** — кто нашёл, каким проходом, с каким свидетельством.
     Без него через месяц не отличить проверенную находку от догадки.
7. `tasks.py check`.

## Куда девается серьёзность находки

Уровня серьёзности в записи нет — но **выкидывать её нельзя**: серьёзность
отображается **в позицию в очереди**, потому что приоритет и есть порядок строк
в беклоге (правило 4 [SKILL.md](../SKILL.md)). Отображается через довод, а не
напрямую: своей шкалы у интейка нет, доводы расстановки перечислены в
[скилле груминга](../../task-groom/SKILL.md#приоритет-как-его-расставляют), и
серьёзность попадает ровно в один из них.

**Всё это — про доработку.** На стройке порядок строк значит зависимость, и
`--first` там означает «ни от чего не зависит», а не «важнее всех»: находка,
поднятая наверх, встанет перед собственной зависимостью. Место находке на стройке
называет зависимость — `move --after <шаг, после которого её можно делать>`, — а
серьёзность идёт **причиной в мете** и разбирается ближайшим пересмотром плана
(`task-track`, «Пересмотр плана стройки»). Груминга там нет, и откладывать «до
него» некуда.

- **тяжёлая находка со свидетельством о сломанном сейчас** → задача
  **первой строкой секции**: `move <слаг> --first
  --reason «сломано сейчас: …»`. Это довод «что сломано сейчас» из перечня
  груминга — единственный, который не требует сравнения с соседями по очереди,
  потому что сломанное дорожает само. Позицию всё равно назначает человек, и
  здесь он её уже назначил: верх очереди для такой находки предъявляется картой
  шага 5, а не проставляется молча;
- **тяжёлая находка о риске, а не о поломке** (дорожает от ожидания,
  разблокирует остальное) → в конец секции, а довод — причиной в мете
  (`--reason`). Позицию назначит человек на ближайшем груминге, сравнив её с
  верхом очереди; без записанного довода сравнивать он будет с нуля;
- **находка, которая не ждёт груминга вовсе** (необратимый ущерб, покраснела
  проверка, которую проект назвал сломанным), — не интейк: это работа прямо
  сейчас, а в беклог она падает, только если ждать всё-таки можно;
- **низкая уверенность или нет свидетельства** → сырьё (`research` с пустым
  разделом «Вопрос»): его место в очереди производно от типа — конец секции;
- **мелочь** → строка в пакетный файл;
- **уже починено / развилка решена сейчас** → ничего.

Словарей серьёзности много, и отображать их механически не на что: при сомнении
— вопрос пользователю, а не догадка.

## Поимённая сверка

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

Границы покрытия отчёта — то, что ревью проверить **не смогло**, — не находки и
в задачи не идут: у них нет предмета. Их место в докладе, не в беклоге.

## Доклад

- Источник (какое ревью/аудит, сколько находок на входе).
- Свёрнуто в задачи: N кластеров из M находок, со слагами и тегом партии.
- Что не заведено и почему: починено инлайн, уже заведено, стало сырьём, ушло в
  `REJECTED.md`.
- Поимённая сверка: находок на входе N, исход есть у N.
- `tasks.py check`.