Files
dev-skills/av-dev-pm/skills/tasks/references/from-review.md
T
avandClaude Opus 5 5b80ac8ff9 секции PLAN.md: «линия» и «кусты» стали «порядком» и «темами»
Метафора требовала расшифровки при каждом употреблении, и в текстах она и
расшифровывалась: «звено упорядоченной линии продукта», «тематический куст —
цель, в последовательность не встающая». Если название приходится объяснять
рядом с каждым употреблением, объясняет не название.

Новые имена называют ровно то свойство, которым секции различаются: в первой
очередь значима и обоснована прозой, во второй порядка нет вовсе.

Заголовки строчные, как ядро/инфра в беклоге: имя секции одновременно значение
для --section, и проза приведена к тому же виду, чтобы «--section Порядок» не
выглядело правильным написанием.

Версия канона не меняется: canon.md называет файл PLAN.md и о его секциях не
говорит — их дом заголовки ## индекса, умолчание живёт в tasks.py.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-03 17:14:37 +03:00

9.0 KiB

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

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

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

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

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

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

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

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

Порядок

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

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

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

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

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

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

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

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

Доклад

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