dev-skills/av-dev-pm/skills/tasks/references/from-review.md

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

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

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

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

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

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

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

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

## Порядок

1. **Возьми выход триажа, а не сырые находки.** Сырой отчёт — это симптомы до
   дедупликации; в нём одна причина размазана по нескольким строкам.
2. **Кластеризуй по причине.** Пять находок об одном отсутствующем инварианте —
   одна задача, а не пять. Класс мелочи (nits, косметика) — **один пакетный
   файл** со списком пунктов, а не файл на каждую запятую.
3. **Дедуп против живых задач и `REJECTED.md`.** Аудит переоткрывает уже
   заведённое и уже выкинутое. Нашлось среди живых — дописываем находку в
   существующий файл. Нашлось в `REJECTED.md` — это сигнал: причина отказа могла
   устареть, выноси пользователю, а не заводи молча заново.
4. **Разложи по целям — там, где цель нужна.** Большинство находок ревью это
   `fix` и `chore`, и **цель им не требуется**: они служат работоспособности, а
   не направлению, и в спринт входят помимо его цели. Придуманная им цель —
   ровно то враньё, от которого спасает род работы.

   Цель обязательна у находки, которая оказалась **новой возможностью**
   (`kind:feature`): нашлось поведение, которого никто не заказывал, и его надо
   либо заказать целью, либо убрать. Подходящей цели нет — заведи её
   (`add --type goal --section направления`) в том же проходе.
5. **Покажи карту до создания файлов.** Кластер → задача / идея / строка в
   пакетный файл / уже заведено / отброшено, и под какую цель — пачкой через
   `AskUserQuestion`. Это тот же барьер, что и «три кандидата» в интейке из
   диалога: массовое заведение файлов без подтверждения — ровно тот отказ, ради
   которого интейк из ревью и выделен. Дешёвая мелочь по явному согласию может
   заводиться и без поштучного вопроса — но карта пользователю предъявляется
   всё равно.
6. **Заводи утверждённое** через `tasks.py add`, с тремя добавками:
   - **тег партии** — `--tag review-ГГГГ-ММ-ДД` (или `audit-<тема>`), чтобы весь
     заход разбора поднимался одной командой `list --tag …`;
   - **род работы** — `--kind`. У находок ревью он **не по умолчанию `fix`**:
     починкой считается расхождение с заявленным поведением, а находка «этого
     свойства никто не заказывал» — это `feature`, находка «не знаем, как
     поведёт себя драйвер» — `research`. Род, розданный оптом, врёт ровно там,
     где по нему потом отбирают;
   - **провенанс в теле** — кто нашёл, каким проходом, с каким свидетельством.
     Без него через месяц не отличить проверенную находку от догадки.
7. `tasks.py check`.

## Куда девается серьёзность, если приоритетов нет

Приоритетов нет, и отображать серьёзность некуда — но **выкидывать её нельзя**.
Правило замены:

- **тяжёлая находка со свидетельством** → задача под ту цель, которой она
  угрожает, и **кандидат в ближайший набор**: серьёзность здесь превращается в
  довод при выборе цели следующего спринта, а не в уровень в файле. Довод
  записывается причиной в мете (`--reason`), иначе к моменту набора его
  никто не вспомнит;
- **находка, ломающая уже идущий спринт**, — не интейк вовсе: см. правило
  вторжения в скилле `session`. В беклог она падает, только если врываться не
  положено;
- **низкая уверенность или нет свидетельства** → идея;
- **мелочь** → строка в пакетный файл;
- **уже починено / развилка решена сейчас** → ничего.

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

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

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

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

## Доклад

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