close

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), отчитайся. Не отчитывайся «готово», пока работа не отражена задачей.

Шаги

1. Найти/создать задачу. Есть — взять. Нет — создать по контракту backlog (RICE проставить), сразу в review.
2. Верифицировать (см. ниже) — без этого нечего нести на апрув.
3. Перевести в review: status: review, updated: <сегодня>, отметить выполненные DoD (- [x]); строку в лог сессии карточки проекта (## Что сделано в сессии <YYYY-MM-DD> + ссылка [[tasks/<имя>]], пометка «в review, ждёт апрува»). Это проходит хук (review, не done).
4. Отчитаться по шаблону (ниже) и сказать, что задача ждёт апрува через апрув-поверхность адоптера. Дальше — не трогать статус.
5. Апрув делает человек: через апрув-поверхность ставит done + confirmed: <дата> и коммитит с OGOROD_APPROVE=1. Либо возвращает в работу → doing, дорабатываешь.
6. Огород — документация (если задача меняет продукт или его контракт): изменение касается пользователя → строка в CHANGELOG проекта (что изменилось для пользователя). Затронута архитектура/деплой → техписатель обновляет доку. Релиз-гейт (docs/workflow.md): дока и changelog актуальны и соответствуют реальности.

Если апрува нет и пользователь говорит «доделай X» — задача в doing, дорабатываешь, снова в review.

Шаблон отчёта (при отправке на апрув)

На каждый тикет:

**#<номер> — <название>**
— что сделал: <по пунктам, по делу>
— как проверил: <конкретно: собралось, открыл /x в проде → 200…; что не проверил — прямо>
— статус: review → ждёт апрува

Несколько тикетов — блок на каждый.

Верификация перед апрувом (обязательно)

Закоммитить ≠ сделать. Прежде чем переводить в review, проверь, что работа реально работает:

• Код — собирается и проходит проверки типов; запущенное — запускается; страница/эндпоинт — открывается; фикс — устраняет проблему на деле.
• Деплоили — фича жива в проде (открыл URL / дёрнул эндпоинт).
• Чего проверить не смог — скажи прямо, не выдавай за проверенное.

В отчёте фиксируй, как проверено («собралось + открыл /x в проде → 200»), а не «готово».

Правила

• done ставит только человеческий апрув. Агент — максимум review. Хук блокирует агентский done.
• review без записи в лог сессии не считается полным.
• Не удалять задачу при отмене — status: cancelled.
• Язык — русский.

Самопроверка

• У работы есть задача (в review, если готова к апруву)
• Работа верифицирована; что не проверил — названо прямо
• Статус переведён в review (не done), строка в логе сессии есть
• Пользователю предъявлено, что сделано, и сказано, что задача ждёт апрува
• В done агент не переводил