Files
dev-skills/av-dev/skills/task-track/references/from-review.md
T
av e5dc0a1a39 язык: сняты «провенанс» и «интейк», назван образец стиля
Оба слова стояли в закрытом словаре правила 6 с оговоркой, и обе оговорки
отвергали один русский вариант, а вывод из них делался про все. Отсюда общее
требование к записи словаря: она обязана говорить, чем слово незаменимо, а не
чем плох один из кандидатов. Латинизм, переживший проверку одним синонимом, —
не имя вещи, а непроверенная привычка.

Провенанс заменён двумя словами, потому что смысла было два, и это же его и
держало: происхождение у числа (чем и при каких условиях получено) и откуда у
вопроса и находки (кто нашёл, каким проходом, из какой записи журнала). Слово
стояло и в скелете docs/review.md, уезжающем в репозитории проектов, поэтому
раскладка повышена до версии 4 с записью журнала: правка формы вопроса и
проход grep по docs/.

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

Образец стиля назван прямо и отдельным разделом: научно-популярная книга, не
спецификация и не конспект для себя. Три умолчания — воды нет, сложных
конструкций нет, англицизм исключение с причиной. Находок образец не
порождает: он для того, кто пишет, а вычитка судит по правилам, иначе «звучит
сложно» стало бы находкой и порог правки перестал бы работать.

Журнал решений: темы 70 и 71, Р258–Р264 и С244–С249. Остальной словарь —
триаж, дедуп, чек-лист, дифф, промпт, чекпоинт, синк — не пересматривался, и
это сказано записью: пересмотр меняет язык всего корпуса и делается своей
работой, а не попутно.
2026-08-13 19:43:08 +03:00

13 KiB

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

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

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

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

Штатный отправитель — av-dev:code-reviewav-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). Отображается через довод, а не напрямую: своей шкалы у заведения нет, доводы расстановки перечислены в скилле груминга, и серьёзность попадает ровно в один из них.

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

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

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

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

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

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

Доклад

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