Close Task

---
name: close-task
description: Закрытие задачи по методологии SDD - провести feature-ветку через финальный коммит, документ для аналитика, перенос спеки в specs/done/, остановку перед merge (мерж делает владелец сам), запись в историю релизов и комментарий в трекер. Запускать на ветке feature/<prefix>-<N>, когда работа по задаче завершена. Триггер-фразы для запуска без переспроса - «закрывай задачу <prefix>-N», «задача <prefix>-N завершена, закрывай», «закрываем текущую задачу» (текущая = git branch --show-current, имя беседы не использовать). Размытые формулировки («всё, можно закрывать», «завершили») - переспрашивать.
---

# Настройка под проект

> **Заполняется при инициализации шаблона** (см. [`docs/project-init.md`](../../../docs/project-init.md)).
> Пока таблица не заполнена - скилл на первом запуске спрашивает недостающее и предлагает записать сюда.

| Параметр | Значение |
| --- | --- |
| Трекер задач | `<GitHub Issues / GitLab / Jira / YouTrack / нет>` |
| Префиксы задач и их репозитории | `<prj- → публичный <репо>; dev- → приватный <репо>. Если репозиторий один - одна строка>` |
| Ветка разработки | `<пример: develop>` |
| Каталог EDT-проекта | `<Каталог.Имя>` |
| Просмотр задачи | `<пример: gh issue view <N> --repo <репо> --json title --jq .title>` |
| Комментарий к задаче | `<пример: gh issue comment <N> --repo <репо> --body "..."; «нет» - шаг пропускается>` |
| Документ для аналитика | `<да, скилл analyst-doc настроен / нет - шаг пропускается>` |
| Публичная история релизов | `<путь к файлу changelog или «нет» - шаг пропускается>` |
| Версия модуля обработки | `<есть метод Версия() у обработок / нет - шаг пропускается>` |

Если трекера нет вовсе (`нет`), шаги, связанные с задачей, выполняются по номеру из имени ветки, а комментарий в трекер не пишется.

# Назначение

Закрытие задачи - длинный ритуал: проверка версий, финальный коммит, документ для аналитика, перенос спеки в архив, локальный merge в ветку разработки, запись в changelog, комментарий в трекер. Скилл проводит по этому пути по шагам, останавливаясь на критических точках.

# Когда запускать

- На ветке `feature/<prefix>-<N>`, когда работа по задаче завершена и её можно закрывать.
- Не запускать для промежуточных коммитов внутри задачи - для них достаточно обычного `git commit`.
- Не запускать на ветке разработки или релизной - скилл отказывается работать.

# Принципы

- **Merge `feature/<prefix>-<N>` → ветка разработки делает владелец сам.** Скилл готовит ветку, останавливается перед мержем, ждёт подтверждения. Не создавать PR через `gh pr create` для рабочих веток.
- **Перенос спеки в `specs/done/` - отдельным коммитом на feature-ветке** (до мержа), чтобы в ветку разработки спека попала уже архивной.
- Скилл интерактивный: каждый шаг с побочным эффектом - после подтверждения. Никаких автоматических закрытий задач и `git push`.

# Алгоритм

## Шаг 1. Preflight

1. Текущая ветка: `git branch --show-current`. Должна быть `feature/<prefix>-<N>` - извлечь префикс и `<N>`, определить репозиторий по таблице настройки. Иначе - стоп. Если владелец назвал `<N>`, а текущая ветка не соответствует, - сказать про несоответствие, не переключаться самому.
2. Рабочий каталог чистый: `git status --porcelain`. Если есть несохранённые изменения - спросить, надо ли их добавить в финальный коммит, или прервать.
3. **Сверка с `origin` - до всех решений о версии.** Если разработка идёт больше чем на одной машине, ветка разработки на удалённом репозитории могла уйти вперёд, пока задача делалась здесь. Локальный remote-tracking при этом устаревает молча: `git status` покажет только «ahead N» и про отставание не скажет.

   ```bash
   git fetch origin <ветка разработки>
   git rev-list --left-right --count <ветка разработки>...origin/<ветка разработки>   # слева свои, справа чужие
   git show origin/<ветка разработки>:<Каталог.Имя>/src/Configuration/Configuration.mdo | grep '<version>'
   ```

   - Если справа не ноль - ветки разошлись. Сообщить владельцу: до закрытия нужно влить `origin/<ветка разработки>` (мерж делает владелец, как и на шаге мержа). Конфликт почти всегда один - строка `version` в `Configuration.mdo`.
   - **Версию из `origin` запомнить: именно с ней сверяется закрывающий бамп, а не с локальной веткой.** Иначе версия поднимается от устаревшей базы и в ветке разработки оказывается ниже уже смерженной.
4. **Версия модулей обработок** (если в настройке указано, что контракт есть): список изменённых `DataProcessors/*/Ext/ObjectModule.bsl` через `git diff <ветка разработки>...HEAD --name-only`. Для каждого проверить, менялась ли строка с `Версия()` в диффе. Если не менялась - **предупредить**: «Модуль обработки `<X>` правился, но `Версия()` не бампилась. Закрыть задачу всё равно?». Не править автоматически.
5. **Мак-сочетания клавиш** (правило - [`docs/mdo-integrity.md`](../../../docs/mdo-integrity.md) → «Сочетания клавиш»): EDT на macOS сериализует сочетания как `Cmd+`/`Option+`, на Windows модификатор слетает и команда виснет на голой букве. Проверить **весь** `src`, а не только дифф задачи - заодно ловит хвосты чужих правок:

   ```bash
   grep -rnE '<shortcut>[^<]*(Cmd|Option|Command)' --include=Form.form --include='*.mdo' <Каталог.Имя>/src
   ```

   Совпадения нормализовать сразу (`Cmd` → `Ctrl`, `Option` → `Alt`), показать владельцу список правок; они войдут в финальный коммит.

## Шаг 2. Синхронизация документации

Свериться с таблицей «Синхронизация документации» в `CLAUDE.md`: сопоставить `git diff <ветка разработки>...HEAD --name-only` со строками таблицы. По каждому сработавшему пункту - выполнить действие или спросить владельца, делать сейчас или отдельной задачей.

## Шаг 3. Версия конфигурации

1. Открыть `<Каталог.Имя>/src/Configuration/Configuration.mdo`, запомнить текущую версию.
2. Проверить, поднимался ли **закрывающий** сегмент в содержательных коммитах задачи: `git log <ветка разработки>..HEAD -p -- <путь к Configuration.mdo>`.
3. Если поднимался - версия уже закрывающая, ничего не делать.
4. Если нет - **спросить владельца**: «Поднять закрывающий сегмент или остаться на текущей версии?» **Не бампать молча.** Версия может быть уже протестирована в реальной инфобазе на текущем сегменте, либо сегмент зарезервирован.
5. Итоговую версию запомнить - она нужна для комментария в трекер.

## Шаг 4. Финальный коммит

1. Подготовить описание задачи. По умолчанию взять командой просмотра задачи из таблицы настройки, при необходимости сократить/перефразировать. Согласовать с владельцем.
2. Закоммитить (включая бамп `Configuration.mdo`, если делался на шаге 3), формат сообщения - из `CLAUDE.md` → «Ветки и коммиты».
3. **Никакого `Co-Authored-By`.**
4. **Никакого `--no-verify`.**

## Шаг 5. Документ для аналитика

Пропустить, если в настройке `нет`.

Спросить владельца: нужен ли по задаче документ для аналитика или тестировщика - описание изменений глазами пользователя и порядок функционального тестирования? Нужен не всегда: на мелком багфиксе и на внутренней задаче - нет.

Если нужен - запустить скилл [`analyst-doc`](../analyst-doc/SKILL.md). Он кладёт `analyst-doc.md` в каталог задачи; закоммитить отдельным коммитом `<ссылка на задачу> документ для аналитика`. Делается **до** переноса спеки, чтобы документ уехал в `specs/done/` вместе с ней.

## Шаг 6. Перенос спеки в архив

Только если есть папка `specs/<prefix>-<N>/` (не `retro/`, не `superseded`):

1. В `specs/<prefix>-<N>/spec.md` поправить статус на `done`.
2. `git mv specs/<prefix>-<N>/ specs/done/<prefix>-<N>/`
3. Отдельный коммит: `<ссылка на задачу> архивация спеки в specs/done/`.

Если задача затрагивала более одной спеки - перенести все.

## Шаг 7. Точка ожидания - merge

Сказать владельцу:

> Ветка `feature/<prefix>-<N>` готова к мержу в `<ветка разработки>`. Версия: `<версия>`. Команда:
>
> ```
> git switch <ветка разработки> && git merge --no-ff feature/<prefix>-<N>
> ```
>
> Готово к мержу? (нет → доделать на feature-ветке, потом сказать «продолжить»; да → выполнить мерж локально и сказать «смержил»)

**Не делать `git merge` автоматически.** Не делать `git push`. Ждать подтверждения.

Если ответ «нет» - стоп до явного «продолжить». При возобновлении вернуться на шаг 1: состояние могло измениться.

## Шаг 8. История релизов

Пропустить, если в настройке `нет`. Пропустить также для чисто внутренних задач (тех. долг, инфраструктура, документация для AI) - в changelog идут только видимые пользователю изменения.

1. Открыть файл истории релизов из таблицы настройки.
2. Добавить пункт в текущую открытую секцию (секцию-плейсхолдер ближайшего релиза). **Не создавать** новую секцию на каждый бамп версии конфигурации.
3. Описание - пользовательское: что изменилось с точки зрения пользователя продукта, не «отрефакторил X», а «теперь работает Y». Формулировка нейтральная и клиентоориентированная (`CLAUDE.md` → «Публичные формулировки», если раздел есть). Согласовать перед записью.
4. Закоммитить в репозитории, где живёт changelog. Push - не делать, оставить владельцу.

## Шаг 9. Комментарий в трекер

Пропустить, если в настройке `нет`.

Отправить командой из таблицы настройки. Тело:

```text
Выполнено в <версия>

<описание изменений>
```

Для публичного репозитория описание - то же, что и в истории релизов (или близкое), нейтральное. Для приватного можно техничнее. Согласовать перед отправкой.

**Не закрывать задачу автоматически** - закрытие владелец делает сам после мержа в релизную ветку или по своему усмотрению.

## Шаг 10. Финал

Сообщить владельцу:

- Итоговую версию.
- Ссылку на комментарий в трекере (если писался).
- Что `git push` - за владельцем.

# Замечания

- Скилл интерактивный - на каждом шаге с побочным эффектом ждать OK. Особенно: коммит, `git mv`, запись в changelog, комментарий в трекер.
- При ошибке на любом шаге - **не пытаться откатить автоматически**. Сообщить состояние и спросить, что делать.

# Usage examples

| Command | What it does |
|---|---|
| `/close-task` | Закрыть задачу текущей ветки |
| `/close-task prj-42` | Закрыть задачу `prj-42` (сверив с текущей веткой) |