Задача — это файл в git, а не сообщение в чате
Предисловие. За год плотной работы с ИИ-агентами — пять проектов доехали до продакшна — у нас сложился набор практик. Разбираем по одной. Первая и базовая: где живёт задача.
Приходит, значит, товарищ к агенту: сделай, милый, вот такую фичу. Агент кивает, бодро пишет код, всё замечательно. Проходит два дня. Товарищ открывает новый чат — а там пусто. Агент не помнит ни фичи, ни уговора, ни что «готово» вообще должно было означать. У него каждое утро чистый лист. И сидит наш товарищ, восстанавливает контекст по диффу, как археолог по черепкам.
Причина простая: задача жила в переписке, а переписка не версионируется и сессию не переживает. Поэтому у нас задача — это файл в git, рядом с кодом. Он коммитится вместе с кодом, который его закрывает, и едет в той же feature-ветке.
Структура папок
Всё, что касается задач, лежит в репозитории и отслеживается git (у нас — 294 файла):
task/ ← активные задачи (сейчас в работе) ├── done/ ← закрытые └── history/ ← рефлексия по сессиям (отдельная практика) plans/ ← длинные roadmap'ы
task/— только то, что сейчас в работе. Незакрытое и без хвостов. У нас тут обычно 1–3 файла.task/done/— задача переезжает сюда, как только выполнен Definition of Done. Не после деплоя, а сразу как критерий закрыт. Это архив сделанного: сейчас 121 задача, каждую можно открыть и посмотреть, что и как решали.plans/— большие направления, которые не влезают в одну задачу. Roadmap режется на пачку мелких task-файлов; агент читает общий план, потом берёт из него конкретный кусок. Сейчас 9 роадмапов.task/history/— рефлексия по сессиям. Это уже про память агента, отдельная практика; здесь только упоминаю, чтобы структура была полной.
Имя файла — YYYY-MM-DD_HH-MM-название.md, с датой и временем создания. Даёт хронологию из коробки: задачи сортируются по возникновению, имена не конфликтуют, ничего не перетирается.
Что внутри задачи
Одна задача = одна функция. Она же — одна feature-ветка и один MR. Есть задача на эту фичу — работаем с ней, вторую не заводим: два файла на одно дело — и потом сам не разберёшь, который из них настоящий.
Фазы со статусом. Внутри — шаги, у каждого
[ ]или[x]. Сессия оборвалась — следующая открывает файл и видит, где остановились: что сделано, что ждёт, что готово, но не проверено. Состояние читается из файла, а не восстанавливается по памяти.Definition of Done — перечисляемым списком. Не «сделать фичу», а конкретные пункты: что именно должно работать. Без списка «готово» у каждого своё. Этот же список потом становится чек-листом приёмки: пункт → проверка → PASS/FAIL, любой FAIL — задача не закрыта.
Итоговый блок. В конце — реализовано целиком или нет, что осталось, какие решения приняли и почему.
Скелет реальной задачи из проекта:
# Фаза 7 — калибровка порога confidence **Тип:** chore + small feat **Ветка:** chore/retrieval-calibration **Зависимости:** фаза 6 в проде **Статус:** Шаг 1 готов; Шаги 2-3 ждут трафика ## Прогресс - [x] Шаг 1 — инструментовка. Тесты зелёные. - [ ] Шаг 2 — сбор датасета с прода (ждёт трафика). - [x] Шаг 3 — эвал-команда готова. Осталось прогнать на реальных данных. ## Контекст Почему пороги пока с потолка и что от них зависит.
Что это даёт
Переживает сессию и машину. Контекст не теряется между чатами: новый агент читает файл и продолжает с той же точки.
Едет в ревью вместе с кодом. Ревьюер видит не только дифф, но и зачем он и по каким критериям принимать.
Имеет историю. Кто завёл, когда, что и почему решили — в git-логе, а не в чьей-то памяти. Через полгода понятно без археологии.
Держит остальные практики. Приёмку не сверить, если непонятно, что считалось «сделано». DoD из файла и есть этот критерий.
Мораль простая. Пока в файле не прописано, что считается «готово», любое «готово» — вопрос веры. Вера в хозяйстве вещь неплохая, но к продакшну отношения не имеет. Список превращает её в проверяемый факт.
