| name | close |
| description | Закрыть задачу в vault — но done ставит только человек (апрув через апрув-поверхность адоптера). Используй, когда работа по задаче готова к закрытию ИЛИ когда сделал что-то значимое без задачи (заведи постфактум, предъяви, отправь на подтверждение). |
| user_invocable | true |
close
Зафиксировать завершённую работу и отправить её на человеческий апрув. Потолок агента — review. done ставит только человек — через апрув-поверхность адоптера (например, кнопку в его дашборде). Самодостаточно: можно дать любому агенту.
Главное правило: агент не закрывает
Статусная машина: todo → doing → review → done (+ blocked, cancelled).
- Закончил работу → переводишь задачу в
review, не в done.
done пишет только человеческий апрув (апрув-поверхность адоптера, напр. кнопка в его дашборде; апрув-сервис коммитит с OGOROD_APPROVE=1).- Это не на доверии: pre-commit-хук (
scripts/check-task-close.py, core.hooksPath .githooks) механически блокирует любой агентский коммит, переводящий задачу в done. Не пытайся обойти — потолок review существует именно для надёжности фреймворка.
Прозовое «не закрывай сам» уже нарушалось — поэтому теперь это потолок, а не просьба.
Когда вызывать
- Работа по задаче из беклога готова → верифицируй, переведи в
review, предъяви отчёт.
- Сделал что-то значимое без задачи (фича, фикс, деплой, новый файл/страница/скилл, редизайн, миграция — в т.ч. в инфра/мета-проектах: сам vault, дашборд, скиллы) → заведи задачу постфактум по контракту
backlog со status: review (не done), отчитайся. Не отчитывайся «готово», пока работа не отражена задачей.
Шаги
- Найти/создать задачу. Есть — взять. Нет — создать по контракту
backlog (RICE проставить), сразу в review.
- Верифицировать (см. ниже) — без этого нечего нести на апрув.
- Перевести в
review: status: review, updated: <сегодня>, отметить выполненные DoD (- [x]); строку в лог сессии карточки проекта (## Что сделано в сессии <YYYY-MM-DD> + ссылка [[tasks/<имя>]], пометка «в review, ждёт апрува»). Это проходит хук (review, не done).
- Отчитаться по шаблону (ниже) и сказать, что задача ждёт апрува через апрув-поверхность адоптера. Дальше — не трогать статус.
- Апрув делает человек: через апрув-поверхность ставит
done + confirmed: <дата> и коммитит с OGOROD_APPROVE=1. Либо возвращает в работу → doing, дорабатываешь.
- Огород — документация (если задача меняет продукт или его контракт): изменение касается пользователя → строка в
CHANGELOG проекта (что изменилось для пользователя). Затронута архитектура/деплой → техписатель обновляет доку. Релиз-гейт (docs/workflow.md): дока и changelog актуальны и соответствуют реальности.
Если апрува нет и пользователь говорит «доделай X» — задача в doing, дорабатываешь, снова в review.
Шаблон отчёта (при отправке на апрув)
На каждый тикет:
**#<номер> — <название>**
— что сделал: <по пунктам, по делу>
— как проверил: <конкретно: собралось, открыл /x в проде → 200…; что не проверил — прямо>
— статус: review → ждёт апрува
Несколько тикетов — блок на каждый.
Верификация перед апрувом (обязательно)
Закоммитить ≠ сделать. Прежде чем переводить в review, проверь, что работа реально работает:
- Код — собирается и проходит проверки типов; запущенное — запускается; страница/эндпоинт — открывается; фикс — устраняет проблему на деле.
- Деплоили — фича жива в проде (открыл URL / дёрнул эндпоинт).
- Чего проверить не смог — скажи прямо, не выдавай за проверенное.
В отчёте фиксируй, как проверено («собралось + открыл /x в проде → 200»), а не «готово».
Правила
done ставит только человеческий апрув. Агент — максимум review. Хук блокирует агентский done.review без записи в лог сессии не считается полным.- Не удалять задачу при отмене —
status: cancelled.
- Язык — русский.
Самопроверка
