---
name: execute-tdd-task
description: Выполняет задачу из .qwen/workplace/to_work/ по TDD-циклу (RED→GREEN→REFACTOR) с коммитом и архивацией
source: auto-skill
extracted_at: '2026-07-07T08:20:23.003Z'
---

# Выполнение задачи по TDD-циклу (RED→GREEN→REFACTOR)

Используйте этот навык, когда нужно выполнить задачу из `.qwen/workplace/to_work/`, следуя формальному процессу: прочитать задачу, отметить в работе, пройти TDD-цикл, обновить файл задачи, закоммитить и заархивировать.

Этот навык НЕ про создание задач — для этого есть `plan-to-tasks`. Он про **исполнение** уже созданной задачи.

## Процесс

### 0. Подготовка

- [ ] Прочитать файл задачи из `.qwen/workplace/to_work/TASK-<ID>_...md`
- [ ] Прочитать текущий `TASK_INDEX.md` — запомнить текущий статус задачи
- [ ] Установить статус задачи в `TASK_INDEX.md` на 🔧 In Progress

### 1. 🔴 RED — Написать тесты

Руководствуясь критериями приёмки (Acceptance Criteria) из задачи:

- [ ] Определить, какие тесты нужны для новой функциональности
- [ ] Написать тестовый класс в соответствующем тестовом пакете (обычно `src/test/java/.../inner/unit/`)
- [ ] Следовать конвенциям проекта:
  - `@Tag("inner")` и `@Tag("unit")` для модульных тестов
  - `@DisplayName("...")` на русском для каждого теста
  - AAA Pattern (Arrange → Act → Assert)
  - JUnit 5 assertions (Jupiter)
- [ ] **Запустить компиляцию тестов: `mvn compile test-compile`**
- [ ] Убедиться, что тесты НЕ компилируются (классы ещё не созданы)
- [ ] Зафиксировать ошибки компиляции в разделе RED задачи
- [ ] Отметить чек-боксы RED в файле задачи

### 2. 🟢 GREEN — Реализовать

- [ ] Создать необходимые классы/интерфейсы/методы в `src/main/java/...`
- [ ] Реализовать минимальный код для прохождения тестов
- [ ] **Запустить тесты: `mvn test -Dgroups=inner`**
- [ ] Убедиться, что все тесты проходят (0 failures, 0 errors)
- [ ] Отметить чек-боксы GREEN в файле задачи

### 3. 🔵 REFACTOR — Улучшить

- [ ] Проверить читаемость кода, именование, отсутствие дублирования
- [ ] **Запустить полную чистую сборку: `mvn clean package -DskipTests`**
- [ ] Убедиться, что сборка успешна (BUILD SUCCESS)
- [ ] **Опционально:** запустить все тесты: `mvn test` — убедиться, что регрессии нет
- [ ] Отметить чек-боксы REFACTOR в файле задачи

### 4. Завершить задачу

- [ ] Заполнить чек-лист завершения в файле задачи (все чек-боксы `[x]`)
- [ ] Обновить статус задачи: дата завершения = сегодня, статус = ✅
- [ ] **Закоммитить изменения:**
  ```bash
  git add <все изменённые и новые файлы, относящиеся к задаче>
  git commit -m "TASK-<ID>: <краткое описание>"
  ```
- [ ] **Переместить файл задачи в архив:**
  ```bash
  mv .qwen/workplace/to_work/TASK-<ID>_...md .qwen/workplace/archive/
  ```
- [ ] **Обновить TASK_INDEX.md:**
  - Статус задачи: ✅ Done
  - Дата завершения: YYYY-MM-DD
  - Ссылка на файл: `./archive/TASK-<ID>_...md`
- [ ] Закоммитить архивацию:
  ```bash
  git add .qwen/workplace/archive/TASK-<ID>_...md .qwen/workplace/TASK_INDEX.md
  git commit -m "TASK-<ID>: архивация задачи (завершена)"
  ```

## Работа с существующим кодом (Legacy)

Если задача модифицирует существующие классы (не создаёт новые с нуля):

### Перед RED фазой — Characterization test

- [ ] Написать characterization test — тест, который фиксирует **текущее** поведение модифицируемого класса
- [ ] Убедиться, что characterization test проходит на существующем коде
- [ ] Закоммитить characterization test отдельно (или включить в основной коммит задачи)

### Во время GREEN фазы

- [ ] Внести изменения в существующий код
- [ ] Убедиться, что characterization test всё ещё проходит (регрессии нет)
- [ ] Добавить новые тесты для новой функциональности

## Работа с конфигурацией (Properties/Resources)

Если задача добавляет новые параметры конфигурации:

### RED

- [ ] Написать тесты, которые проверяют чтение новых параметров из `Properties` объекта
- [ ] Включить тесты на граничные случаи: null, пустая строка, пробелы вокруг разделителей

### GREEN

- [ ] Добавить константы ключей в класс конфигурации (например, `AgentRunnerProperties`)
- [ ] Реализовать статические методы чтения, принимающие `Properties` (stateless design — метод ничего не знает об источнике)
- [ ] **Создать/обновить `src/main/resources/...properties`** — шаблон для приложения с комментариями
- [ ] **Обновить `src/test/resources/...properties`** — минимальный файл для тестов
- [ ] Значения по умолчанию — пустые списки, а не fallback на старый код

### REFACTOR

- [ ] Проверить обработку краевых случаев
- [ ] Убедиться, что методы stateless (можно вызывать из любого потока)

## Частые ошибки

| Проблема | Решение |
|----------|---------|
| Тест падает, потому что команда найдена в `PATH`, а не в fallback-путях | Использовать уникальное имя команды, которой точно нет в `PATH` (например, `my-custom-cli-123`) |
| Тест создаёт файл, но он не исполняемый (`Files.isExecutable()` → false) | Вызвать `makeExecutable()`: на Linux — `PosixFilePermission.OWNER_EXECUTE`, на Windows — `file.setExecutable(true)` |
| После удаления старых конструкторов тесты не компилируются | Это ожидаемо для RED фазы. В GREEN — обновить тесты или временно отключить `@Disabled` |
| Новые свойства не подхватываются тестами | Проверить, что файл лежит в `src/test/resources/`, а не только в `src/main/resources/` |

## Важные правила

- **TDD строго:** RED (тесты падают) → GREEN (тесты проходят) → REFACTOR (чистый код)
- **Каждый шаг отмечать чек-боксом** сразу после выполнения
- **Коммитить осмысленно:** отдельно код задачи, отдельно архивацию
- **Не оставлять задачу в `to_work/`** после завершения — обязательно переместить в `archive/`