Находка - в бэклог, а не в текущий диф

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

Третий путь: вынуть находку из головы в файл и продолжить свою задачу.

Общая норма для .AI-проекта

Если есть .AI/project.json, каждая текущая задача получает Markdown-файл до выполнения, включая задачу пользователя. Это учет выполняемой работы, а не ее откладывание. Найди существующего владельца, иначе создай файл в проектном бэклоге (docs/backlog/ по умолчанию). Укажи стабильный ID, цель, ограничения, критерии готовности, сделанное, проверки, блокеры и следующий шаг; обновляй по ходу работы. План может быть связанным документом. После критериев готовности перенеси владельца в docs/done/, сохранив ID. Нормы ниже определяют, когда отдельно откладывать побочную находку; они не отменяют файл текущей задачи.

Когда заводить таску

Заводи, если верно все:

• находка не входит в то, о чем просил пользователь;
• она переживет сессию - это не "надо не забыть дописать тест через десять минут";
• ее починка осмысленна отдельно: у нее свой диф, своя проверка, свой смысл в истории.

Когда НЕ заводить

• Правка на пару строк в файле, который ты и так правишь, и она по смыслу часть задачи - просто сделай. Файл-таска дороже самой правки.
• Это и есть задача пользователя - не откладывай то, о чем просили.
• Уже заведено - сперва посмотри, что лежит в бэклоге. Дубли обесценивают его быстрее всего.
• Находка требует решения пользователя, а не работы (развилка, выбор политики, деньги) - такое не в бэклог, а в ответ пользователю: бэклог для работы, а не для вопросов.
• Это крупная отложенная работа со своими этапами - у нее свой артефакт с задачами и сроками, а не строчка в бэклоге (в проектах, где подключено tasks-tracking.md, - по нему). Не мельчи ее до находки и не раздувай бэклог до нее.
• Нужен порядок шагов с критерием на каждом - это план-файл (planner, docs-maintenance.md), а не таска. Таска описывает, что не так; план описывает, как идти. Путать их дорого: план с одним пунктом бесполезен, таска с десятью шагами не читается.
• Находка - про переиспользуемый прием или про дефект самого канона - она идет вверх, в канон (harvest-canon), а не вбок в бэклог. Признак простой: чинить надо в этом проекте - бэклог; чинить надо у всех - канон.

Стоп-гейт остается прежним. Опасная находка - утекший секрет, дыра в безопасности, потеря данных - не откладывается: про нее говорят пользователю сразу (secrets-handling.md). Бэклог для того, что может подождать.

В сам файл секрет не переносится. Таска требует точных путей, воспроизведения и сырого вывода - и все это уезжает в коммитимый файл, который потом читают посторонние. Токены, ключи, куки, персональные данные и дампы чужой переписки маскируются в таске так же, как везде (secrets-handling.md). Соблазн приложить сырой вывод максимален как раз на находках "проверка обманывает" - там он и опаснее всего.

Где лежит бэклог

docs/backlog/ в том проекте, где будет жить починка - там ее найдет чистая сессия, и файл поедет вместе с проектом. Папки нет - создай.

Чужое рабочее дерево молча не трогай. Находка относится к соседнему репозиторию или к проекту другого клиента - сессия работает в своем корне, и файл там никто не ждет. Два пути: назвать находку пользователю и завести файл в чужом проекте с его "ок", либо положить таску в свой бэклог со ссылкой на чужой проект в поле "Где". Второе дешевле и почти всегда достаточно.

Имя файла: YYYY-MM-DD-<слаг>.md, дата - когда нашли; одноименный не перезаписывать - добавь суффикс. Дата в имени дает порядок и возраст находки без открывания файла: полугодовалая таска "стоит" почти всегда означает, что она не нужна.

Формат файла

Держи шапку машиночитаемой - по ней потом делается разбор без открывания каждого файла.

# <Что не так, одной фразой>

**Важность:** <блокер|важно|стоит|когда-нибудь>
**Где:** <проект и точные пути, лучше с номерами строк>
**Нашлось:** <в какой задаче всплыло - одной строкой>

## Что не так

Симптом и следствие. Не "плохой код", а что именно сломается или кого это кусает.

## Что сделать

Конкретные шаги. Если решение неочевидно - назвать варианты и тот, который считаешь верным.

## Как проверить

Команда, тест или наблюдаемый признак, по которому видно, что готово.

## Чего не делать

Границы: что рядом трогать не надо и почему. Этот раздел спасает чистую сессию от расползания.

Важность выбирай по последствию, а не по ощущению:

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

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

Главное требование: файл самодостаточен

Чистая сессия не увидит ни этого разговора, ни того, что ты уже понял. Все, что она знает, - в файле. Поэтому:

• пути точные, а не "где-то в сервисе синка";
• то, что ты выяснил по дороге, вписано, а не подразумевается: почему очевидное решение не работает, какая проверка обманывает, что уже пробовали;
• воспроизведение, если находка про поведение, - командой или шагами;
• ссылки на смежные файлы и на изменение, из которого это выпало.

Проверка себе: отдал бы ты этот файл человеку, который проект видит впервые? Если нет - дописывай.

Разбор бэклога

Список без открывания файлов:

d=docs/backlog
if [ ! -d "$d" ]; then echo "бэклог не заведен"
elif ! ls "$d"/*.md >/dev/null 2>&1; then echo "бэклог пуст"
else grep -H "^\*\*Важность:\*\*" "$d"/*.md
fi

Отдельного индекс-файла не заводить: он гниет, а грепом важность видна всегда. Пустой вывод разбирай как три состояния, а не как одно: папки нет (бэклог не заводили), папка есть и пуста (разобрали), папка есть и не читается (это не "пусто", см. silent-failure.md).

Сделанную таску переложить в docs/done/ - туда же, куда уезжают закрытые планы (docs-maintenance.md), отдельного done внутри бэклога не заводить. Одна папка на все завершенное: иначе на вопрос "это вообще делали?" приходится смотреть в два места. Перекладывать, а не удалять - по файлу потом восстанавливается, почему сделано именно так; в git-проекте через git mv, без переименования.

В конце сессии - назвать одной строкой

Завел таски - скажи пользователю, что отложил и с какой важностью, по строке на штуку. Молча отложенное неотличимо от забытого, а решение "делать сейчас или потом" остается за ним: он может сказать "нет, это чини сразу".

Модель и текущие назначения

Перед новым заданием и запуском применяй маршрутизацию моделей: свежий MODELS выше канонического дефолта. Границы данных и полномочий этого навыка сохраняются.