/dr-do

Обзор

/dr-do — этап выполнения. Агент-разработчик определяет целевую задачу, берёт план реализации из tasks.md и строит его по принципам строгого TDD: написать тест, убедиться в провале, написать код, убедиться в прохождении. Каждый метод — не более 50 строк, в области видимости — не более 7-9 объектов. При обнаружении неизвестных (ошибка импорта, неожиданный ответ API) Gap Discovery (Step 7.5) автоматически запускает агента-исследователя для изучения конкретного пробела без выхода из потока реализации.

Использование

/dr-do

Что делает

1. Определение задачи — применяет правило Task Resolution для определения, какую задачу реализовывать (из аргумента или через диалог).
2. Загрузка правил качества — читает ai-quality.md и применяет правила TDD, стаббинга, когнитивной нагрузки.
3. Чтение плана — загружает план реализации из datarim/tasks.md для определённой задачи.
4. Предполётная проверка (только L3-L4) — проверяет полноту плана, наличие документов проектирования, доступность зависимостей и работоспособность проекта.
5. Цикл TDD — для каждого изменения: написать проваливающийся тест, реализовать минимальный код для прохождения, при необходимости рефакторить.
6. Следование паттернам — соблюдает datarim/patterns.md и datarim/style-guide.md.
7. Gap Discovery (Step 7.5) — при обнаружении неизвестного (ошибка импорта, неожиданный ответ API, несоответствие документации) запускается агент-исследователь для изучения конкретного пробела. Результаты дописываются в datarim/insights/INSIGHTS-{task-id}.md. Фундаментальные пробелы (неправильный стек, невозможное требование) останавливают реализацию и рекомендуют вернуться к /dr-prd.
8. Обновление прогресса — записывает детали реализации в datarim/progress.md.

Обработка ревью-фидбека

Когда автоматическое или ручное ревью возвращает замечания, каждое классифицируется и обрабатывается:

• Критическое / блокирующее — исправляется в текущем MR до мержа. Без обсуждений.
• Предупреждение / предложение, которое дёшево и строго лучше (1-5 строк, без новых абстракций) — исправляется inline в текущем MR. Примеры: уточнить string match, убрать alert(), добавить null-guard.
• Предупреждение / предложение, требующее проектирования — откладывается в новый элемент бэклога с конкретным триггером (например, «через 14 дней после деплоя»).
• Отклонение — только с техническим обоснованием, причина записывается в MR-тред.

Результат обработки (fix / defer / reject) каждого замечания логируется в MR-треде.

Аргументы

Нет. Работает с текущей активной задачей (через Task Resolution).

Результат

Изменения кода в проекте. Обновляет: datarim/progress.md. Может обновлять: datarim/backlog.md (отложенные замечания из ревью).

Правила качества

• Максимум 50 строк на метод
• Максимум 7-9 объектов в области видимости
• Тесты до кода (TDD)
• Один стаб/метод за раз

Пример сессии

> /dr-do

Определение задачи: AUTH-0001 (Уровень 3)

Предполётная проверка...
  Документ плана: OK
  Документы проектирования: OK
  Зависимости: OK
  Проект собирается: OK

Шаг 1/8: Auth middleware
  Пишу тест: auth.middleware.test.ts
  Тест не проходит (ожидаемо)
  Реализую: auth.middleware.ts
  Тест проходит

Прогресс: 8/8 шагов выполнено
Все 14 тестов проходят
Обновлён datarim/progress.md

Следующий шаг: /dr-qa

Связанные команды

• /dr-plan — предыдущий этап: планирование
• /dr-design — предыдущий этап: проектирование (L3-4)
• /dr-qa — следующий этап для L3-4
• /dr-archive — следующий этап для L1-2 (рефлексия выполняется как Step 0.5)