dev-skills/av-dev/skills/task-groom/references/portions.md

Порции, разбор и расстановка

Процедура шагов 2–4 груминга. Рамка и правила — SKILL.md.

Начинается всё с tasks.py check (и check --fix, если дрейф накопился) — результат идёт строкой в доклад.

Шаг 2. Разбор вопросов

tasks.py list --questions — всё, что накопилось. Порядок по каждому вопросу:

1. Проверь, не отвечен ли он уже — решением, документом, соседним изменением, самим ходом сделанной с тех пор работы. Отвеченный вопрос не выносится человеку: это самая частая находка и она не требует ничьего решения.
2. Сформулируй развилку с вариантами и последствием каждого, рекомендация — первым вариантом.
3. Вынеси пачкой через AskUserQuestion, не больше трёх за раз.
4. Запиши ответ в тело задачи, опустоши раздел «Вопросы», сними тег (edit <slug> --rm-tag question), перепиши «зачем»: «Решено: …» на вопрос «почему это лежит в беклоге» уже не отвечает. Опустошение раздела — не уборка, а условие взятия: правило и причина в скилле task-track, references/task-format.md.

Вопросы на верхних строках очереди разбираются вне очереди порции — здесь же, даже если сама задача в порцию переоценки не попала. Иначе правило «задача с открытым вопросом в работу не берётся» создаёт стимул вопрос не записывать, лишь бы не вычеркнуть задачу из ближайшей работы.

Шаг 3. Что перестало быть важным

Цель — выкинуть то, что перестало быть задачей, и вернуть остальному честное состояние. Не «пересмотреть всё», а «пересмотреть порцию до конца».

Порция и правило остановки

• 5–8 задач за порцию. Размер обоснован усталостью, а не пропускной способностью, и менять его не надо — надо брать несколько порций.
• Отбор порций по порядку:
  1. свежее — заведённое с прошлого груминга: оно ещё не проходило ни одной проверки на нужность. Свежесть меряется git'ом, как и залежалость, — датой появления файла в истории;
  2. дальше по залежалости — list --stale;
  3. по потребности — одна секция целиком, один тег (партия ревью), список от человека.
• Останавливайся на границе порции, даже если «ещё чуть-чуть осталось». Между порциями — промежуточный доклад.

Что делать с каждой задачей

Сперва то, что не требует ничьего решения:

1. Проверь, не сделано ли уже. Задача, реализованная попутно в соседнем изменении, — самая частая находка. Смотри код, документацию, историю коммитов по ключевым словам. Удаление «как реализованной» деструктивно и без следа (в REJECTED.md реализованные не пишутся), поэтому порог улики жёсткий: close <slug> --implemented только имея конкретный коммит или строку документа, закрывающие задачу, и ссылка идёт в доклад. Есть лишь косвенные признаки — не удаляй сам, вынеси в пачку вопросов. Сделана частично → задача сжимается до остатка: тело правишь редактором, заголовок и «зачем» — через edit.

2. Проверь, не отменена ли решением. Документ, ADR или архивное изменение мог закрыть вопрос иначе — тогда close <slug> --reason "<ссылка на решение>". Задача закрывается не только коммитом.

3. Проверь пересечения. Две задачи об одном — содержимое в одну, вторую close <slug> --reason "слита с <другой-слаг>". Смотри шире порции: заведение сверяет новое против уже лежащего, но никогда не пересматривает уже лежащее, и две задачи с одной причиной могут лежать рядом месяцами.

4. Пере-кластеризуй по общей причине. Несколько задач, оказавшихся симптомами одного дефекта, сливаются в одну — это находка, которую заведение дать не могло.

5. Гигиена полей — протухшее «зачем», вопрос в прозе, снятый ответ, свойство репозитория в рамках, предписание процесса в теле, тип, разошедшийся с задачей, границы вместо реализации в разделе «Затрагивает». Список и правила — в скилле task-track. Груминг — то самое место, где беклог добирает тип и разделы его схемы: требовать их на входе значило бы выгонять в заметки то, что должно лежать задачей, а к взятию в работу они уже обязательны (ready). Блок здоровья check печатает, сколько записей готово к взятию, — по этому числу и видно, добрал ли груминг.

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

Затем — то, что решает человек:

6. Жива ли она вообще. Контекст мог измениться: ушла зависимость, отпал сценарий, обошли иначе. Здесь и звучит вопрос, выкидывать ли.
7. Тот ли тип. Заводилась починкой, а после разбора оказалось, что поведение никогда и не было заявлено, — это feature. Тип, оставшийся от прошлой формулировки, врёт ровно там, где по нему отбирают, и требует не тех разделов.
8. Задача ли это по-прежнему. Не проходит ready по существу, а не по недописанным разделам → edit <slug> --type research и опустошённый раздел «Вопрос», то есть сырьё; дальше штурм. Разрослась → это несколько задач, дальше декомпозиция.
9. Не подешевела ли она. Сделанная с прошлого раза работа меняет цену других задач: рядом с только что тронутым кодом та же работа стоит меньше. Это довод и на шаге 4 — задача, внезапно подешевевшая, поднимается в очереди не потому, что стала важнее, а потому, что окно открыто.

Храповик на залежавшихся

Сильно залежавшаяся задача — сигнал сама по себе: её либо ни разу не собирались делать, либо нечем взять. Измеряй наблюдаемым — датой последней правки из git (list --stale ставит такие первыми); счётчик «сколько грумингов пережила» нигде не хранится.

Задача из верхних строк --stale, которую и этот заход оставляет без изменений, либо двигается (меняет полку, поднимается в очереди, уходит с причиной), либо остаётся с явно записанной причиной, почему её держим (move <slug> --reason … — без --section секция берётся текущая). Молчаливое «оставить как есть» на давно неподвижной задаче — это решение не принимать решение; запись причины превращает его в осознанное и не даёт тому же вопросу всплыть на следующем груминге.

Шаг 4. Что важно сейчас — расстановка

Разбирается верх очереди, а не весь беклог: первые три-пять строк каждой секции. Ниже пятой строки порядок всё равно перестаёт что-либо значить.

1. Покажи текущий верх — list, по секциям, в том порядке, в каком строки лежат.
2. Спрашивай сравнением, а не оценкой. «Что из этих двух делают раньше» имеет проверяемый ответ, «насколько важна эта задача» — нет. Веди попарно и сверху: что первое, что после него.
3. Двигай командой, с причиной — move <slug> --after <другой> --reason … или move <slug> --first --reason …. Довод берётся из перечня в SKILL.md: сломано сейчас, разблокирует остальное, дешевеет от сделанного, дорожает от ожидания, названо человеком.
4. Проверь верх на готовность — tasks.py ready <слаг> … по первым строкам. Задача, стоящая первой и не проходящая ready, — это очередь, которая врёт: взять её нельзя. Либо дописывается здесь же, либо уступает место.

Пример одной итерации:

Верх секции «Игра», сейчас в таком порядке: board-render-once · draw-before-full-board · move-parse-strict

1. Что делаем первым?
   • draw-before-full-board (рекомендую) — ничья объявляется на неполном поле: игра врёт о результате, это сломано сейчас
   • board-render-once — печать поля дублируется; мешает всякой правке отрисовки, то есть разблокирует остальное
   • оставить как есть
2. move-parse-strict — третьей или выше?
   • Оставить третьей (рекомендую) — ошибка ввода видна игроку сразу
   • Поднять второй: тот же разбор трогает board-render-once, окно открыто

Каждый вариант несёт причину — ту самую, что уедет в --reason.

Что делать, если разбирать нечего

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