avandClaude Opus 5
228b6c7eee
Осей было две — тип записи (goal/idea/task) и род работы (kind:<род> тегом), — и ортогональность у них была фальшивой: из двенадцати клеток произведения законны шесть. У цели род запрещён, у задачи обязателен, у идеи пуст и на практике не ставится. Плюс «алгоритм работы над записью такого типа» крепится не к task, а к fix и research, то есть к роду: ось, к которой пишется алгоритм, и была настоящим типом. Схлопнуто в одну ось из пяти значений: goal | feature | fix | chore | research. Тип idea упразднён отдельно и по другой причине: он значил не род работы, а незаполненность, а состояние типом быть не может — оно меняется по мере того, как запись дописывают, а тип меняют командой. Теперь состояние выводится из заполненности: research без раздела «Вопрос» это сырьё. В спринт не берётся, как и прежняя идея, лежит в конце категории, отбирается list --raw. Дом типа — поле меты «Тип» первой строкой, эмодзи в H1 производна. Прежнее «отдельного поля типа нет: два места для одного факта разъезжаются» отменено собственным аргументом: он был против префикса плюс поля, а при переносе дома место остаётся одно. Эмодзи стоит в H1, а не в строке индекса, чтобы инвариант «заголовок в индексе дословно» остался нетронутым. Поле места названо по типу: «Секция» у цели (часть роадмапа, состояние очереди), «Категория» у задачи (полка домена, куда её вернёт sprint drop). Одинаковое переименование закрепило бы конфляцию; какое поле обязательно, решает тип — то самое, ради чего затевалась правка. Два новых обязательных раздела выросли из правил, которые были записаны и которые нечем было проверить. «Не воспроизводится — это research, а не fix» стояло в каноне: теперь есть раздел «Воспроизведение». Приёмка разведки — «записанный ответ, а не изменённый код» — тоже стояла, но sprint take требовал от research два-пять критериев с оракулами, и они писались ради проверки; вместо них «Вопрос» и «Куда ляжет ответ». Сортировка «по важности» из заметок не взята: она требует, чтобы кто-то важность поддерживал, а это приоритет, от которого отказалось правило 4. Взято только «сырьё в конец категории» — этот порядок выводится из типа и заполненности, а не назначается человеком, и потому проверяется машиной. TYPE_SCHEMA кормит и body_template, и schema_verdict: иначе add кладёт то, на чём sprint take потом откажет. check --fix мигрирует за один проход — kind:/[goal]/[idea] в поле «Тип», эмодзи в заголовок, «Секция» → «Категория», сырьё в конец. Тип, которого неоткуда взять, не угадывается: feature от chore машина не отличает, такие записи уходят в НЕОДНОЗНАЧНО поимённо. Попутно закрыт класс отказов в --fix: шагов, правящих мету, стало пять, и второй, перечитавший файл с диска, стирал правку первого. Общий stage() поверх отложенных правок; до этого корректность держалась на том, что шагов было мало. Устав на тип отдельным файлом — references/task-<тип>.md, пять штук: схема, алгоритм, что видит машина и что человек. Агент task-form получил правило «тип сходится с тем, что в записи написано» с проверяемыми расхождениями. Обкатано на демо-наборе из 13 записей: миграция за один проход, второй прогон даёт ноль починок; fix без «Воспроизведения» и сырьё в спринт не идут, годная feature берётся. DECISIONS тема 27 (ААББ–ЛЛММ, следствия 101–104). Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
115 lines
10 KiB
Markdown
115 lines
10 KiB
Markdown
# Задачи из аудита и ревью
|
||
|
||
Ревью и аудиты — код-ревью, архитектурный проход, аудит безопасности, любой
|
||
разбор другим агентом — порождают находки, часть которых становится задачами.
|
||
Это отдельный интейк со своей опасностью, **зеркальной** интейку из диалога.
|
||
|
||
- Интейк из диалога грешит переполнением: из одной мысли рождается пять файлов.
|
||
- Интейк из ревью грешит сваливанием: сорок сырых находок превращаются в сорок
|
||
файлов. Беклог раздувается, а следующая переоценка склеивает их обратно.
|
||
|
||
Защита от сваливания — та же, что в самом ревью: **кластеризация по причине, а
|
||
не файл-на-находку.** Если у ревью был триаж — половина работы уже сделана, бери
|
||
его выход. Если нет — триажируй сам, прежде чем заводить.
|
||
|
||
## Находка агента — не задача
|
||
|
||
Мнение агента — **гипотеза, пока у неё нет свидетельства** (падающий тест,
|
||
воспроизводимый шаг, положение гайда). Согласие нескольких находок само по себе
|
||
достоверность не повышает: это один источник, высказавшийся несколько раз.
|
||
|
||
Отсюда фильтр входа, поверх обычного «не делаем сейчас + пожалеем о потере»:
|
||
|
||
- **Находка со свидетельством**, отложенная к исполнению → **задача**.
|
||
Свидетельство и последствие переносим в тело — это её «почему», то самое, что
|
||
переживает запись.
|
||
- **Находка без свидетельства / низкой уверенности** → **сырьё**: `research`, у
|
||
которого раздел «Вопрос» и есть недостающее свидетельство («при каких условиях
|
||
это воспроизводится»). Не `fix`: без `Воспроизведения` его в спринт не
|
||
возьмут, и правильно — чинить нечего, пока непонятно, что ломается. Судьба
|
||
сырья — штурм, где либо найдётся подтверждение, либо оно уедет в
|
||
`REJECTED.md`.
|
||
- **Уже починено по ходу ревью** → **ничего**. Починенное не заводим.
|
||
- **Развилка, решённая при ревью** → ничего; решённая «потом» → задача с
|
||
вопросом в разделе «Вопросы» и тегом `question`.
|
||
|
||
## Порядок
|
||
|
||
1. **Возьми выход триажа, а не сырые находки.** Сырой отчёт — это симптомы до
|
||
дедупликации; в нём одна причина размазана по нескольким строкам.
|
||
2. **Кластеризуй по причине.** Пять находок об одном отсутствующем инварианте —
|
||
одна задача, а не пять. Класс мелочи (nits, косметика) — **один пакетный
|
||
файл** со списком пунктов, а не файл на каждую запятую.
|
||
3. **Дедуп против живых задач и `REJECTED.md`.** Аудит переоткрывает уже
|
||
заведённое и уже выкинутое. Нашлось среди живых — дописываем находку в
|
||
существующий файл. Нашлось в `REJECTED.md` — это сигнал: причина отказа могла
|
||
устареть, выноси пользователю, а не заводи молча заново.
|
||
4. **Разложи по целям — там, где цель нужна.** Большинство находок ревью это
|
||
`fix` и `chore`, и **цель им не требуется**: они служат работоспособности, а
|
||
не направлению, и в спринт входят помимо его цели. Придуманная им цель —
|
||
ровно то враньё, от которого спасает тип.
|
||
|
||
Цель обязательна у находки, которая оказалась **новой возможностью**
|
||
(`feature`): нашлось поведение, которого никто не заказывал, и его надо
|
||
либо заказать целью, либо убрать. Подходящей цели нет — заведи её
|
||
(`add --type goal --section Направления`) в том же проходе.
|
||
5. **Покажи карту до создания файлов.** Кластер → задача / сырьё / строка в
|
||
пакетный файл / уже заведено / отброшено, и под какую цель — пачкой через
|
||
`AskUserQuestion`. Это тот же барьер, что и «три кандидата» в интейке из
|
||
диалога: массовое заведение файлов без подтверждения — ровно тот отказ, ради
|
||
которого интейк из ревью и выделен. Дешёвая мелочь по явному согласию может
|
||
заводиться и без поштучного вопроса — но карта пользователю предъявляется
|
||
всё равно.
|
||
6. **Заводи утверждённое** через `tasks.py add`, с тремя добавками:
|
||
- **тег партии** — `--tag review-ГГГГ-ММ-ДД` (или `audit-<тема>`), чтобы весь
|
||
заход разбора поднимался одной командой `list --tag …`;
|
||
- **тип** — `--type`, и он **не по умолчанию `fix`**: починкой считается
|
||
расхождение с заявленным поведением, а находка «этого свойства никто не
|
||
заказывал» — это `feature`, находка «не знаем, как поведёт себя драйвер» —
|
||
`research`. Тип, розданный оптом, врёт ровно там, где по нему потом
|
||
отбирают, **и требует не тех разделов**: каждому `fix` придётся заполнить
|
||
`Воспроизведение`, а у находки без свидетельства его нет;
|
||
- **провенанс в теле** — кто нашёл, каким проходом, с каким свидетельством.
|
||
Без него через месяц не отличить проверенную находку от догадки.
|
||
7. `tasks.py check`.
|
||
|
||
## Куда девается серьёзность, если приоритетов нет
|
||
|
||
Приоритетов нет, и отображать серьёзность некуда — но **выкидывать её нельзя**.
|
||
Правило замены:
|
||
|
||
- **тяжёлая находка со свидетельством** → задача под ту цель, которой она
|
||
угрожает, и **кандидат в ближайший набор**: серьёзность здесь превращается в
|
||
довод при выборе цели следующего спринта, а не в уровень в файле. Довод
|
||
записывается причиной в мете (`--reason`), иначе к моменту набора его
|
||
никто не вспомнит;
|
||
- **находка, ломающая уже идущий спринт**, — не интейк вовсе: см. правило
|
||
вторжения в скилле `session`. В беклог она падает, только если врываться не
|
||
положено;
|
||
- **низкая уверенность или нет свидетельства** → идея;
|
||
- **мелочь** → строка в пакетный файл;
|
||
- **уже починено / развилка решена сейчас** → ничего.
|
||
|
||
Словарей серьёзности много, и отображать их механически не на что: при сомнении
|
||
— вопрос пользователю, а не догадка.
|
||
|
||
## Поимённая сверка
|
||
|
||
Интейк считается выполненным, только если **каждая** находка триажа получила
|
||
исход: слаг заведённой задачи, ссылку на существующую, строку пакетного файла
|
||
или запись «не заведена: причина». Нулевой урожай при непустом отчёте триажа
|
||
виден сразу — и это единственный способ отличить «находок не было» от «не стал
|
||
заводить». Список составляет не тот, кто отчитывается о заведении.
|
||
|
||
Границы покрытия отчёта — то, что ревью проверить **не смогло**, — не находки и
|
||
в задачи не идут: у них нет предмета. Их место в докладе, не в беклоге.
|
||
|
||
## Доклад
|
||
|
||
- Источник (какое ревью/аудит, сколько находок на входе).
|
||
- Свёрнуто в задачи: N кластеров из M находок, со слагами, целями и тегом партии.
|
||
- Что не заведено и почему: починено инлайн, уже заведено, ушло в идеи, в
|
||
`REJECTED.md`.
|
||
- Поимённая сверка: находок на входе N, исход есть у N.
|
||
- `tasks.py check`.
|