Backlog Task

---
name: backlog-task
description: Побочная находка (чужой баг, дыра в покрытии, устаревший абзац) - таской в бэклог, не чинить сейчас: важность, пути, критерий готовности. Не для правки в пару строк. Прием в канон - `harvest-canon`.
---

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

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

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

## Общая норма для .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`, дата - когда нашли; одноименный не перезаписывать - добавь суффикс. Дата в имени дает порядок и возраст находки без открывания файла: полугодовалая таска "стоит" почти всегда означает, что она не нужна.

## Формат файла

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

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

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

## Что не так

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

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

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

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

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

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

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

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

| Уровень | Что означает |
| --- | --- |
| `блокер` | мешает работе или врет пользователю прямо сейчас |
| `важно` | задевает деньги, безопасность или то, что видит клиент, но терпит |
| `стоит` | заметно только нам: дубли, мертвый код, хрупкая проверка |
| `когда-нибудь` | косметика, которую не жаль не сделать никогда |

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

| Источник | Исходный уровень | Важность бэклога по умолчанию |
| --- | --- | --- |
| code-reviewer | critical / major / minor | блокер / важно / когда-нибудь |
| qa-browser | critical / high / medium / low | блокер / важно / стоит / когда-нибудь |
| codex-audit (режим audit) | blocker / risk / ok | блокер / важно / таска не создается |
| Приоритет серии canon | P0 / P1 / P2 | блокер / важно / стоит, только предварительно с проверкой последствия |

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

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

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

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

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

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

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

```bash
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`, без переименования.

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

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