Команда Pipeline

/dr-plan

Создание детального плана реализации с анализом безопасности

Обзор

/dr-plan генерирует детальный план реализации в datarim/tasks.md, следуя расширенному процессу проектирования (Фазы 4-6). Определяет целевую задачу, разбивает работу на конкретные шаги, определяет интерфейсы, моделирует угрозы, захватывает живые фикстуры для вывода внешних инструментов и формирует план, готовый к выполнению.

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

/dr-plan

Что делает

  1. Определение задачи — применяет правило Task Resolution для определения задачи (из аргумента или через диалог при нескольких активных задачах).
  2. Анализ контекста — читает tasks.md, activeContext.md и PRD-файлы из datarim/prd/.
  3. Стратегическая проверка (обязательна для L3-4, опциональна для L2) — оценивает ценность, риск и стоимость.
  4. Детальное проектирование (Фаза 4) — декомпозиция компонентов, проектирование интерфейсов, трассировка потоков данных и моделирование угроз.
  5. План реализации (Фаза 5) — обновляет tasks.md с описанием безопасности, архитектуры, детальным дизайном, шагами, планом тестирования и стратегией отката.
  6. Валидация технологий — документирует выбор стека, проверяет зависимости.
  7. Аудит install/deploy-скриптов (обязателен при затрагивании install.sh, скриптов синхронизации или деплоя) — проверяет фильтры типов файлов в скрипте. При несовпадении расширяет фильтр или создаёт follow-up задачу.
  8. Kill-критерии для исследований (для сравнительных задач) — отсеивает кандидатов по данным исследования до начала тестирования.
  9. Гигиена планирования — все агрегатные числа в плане должны происходить из исходных таблиц со ссылками.
  10. Захват фикстур (обязателен при парсинге CLI / подпроцессов / API) — захватывает реальный сэмпл и сохраняет в datarim/tasks/{TASK-ID}-fixtures.md. Предпочитает машиночитаемый вывод (--json) парсингу текста.

Паттерн exit code CLI-агентов

Многие CLI-агенты (Claude Code, Cursor, Gemini/Codex) возвращают exit code 0 даже когда JSON-вывод содержит is_error: true. При захвате фикстур всегда захватывайте оба случая. Парсеры должны проверять is_error/subtype в JSON, а не полагаться на exit code.

Аргументы

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

Результат

Обновляет: datarim/tasks.md. Может создавать: datarim/tasks/{TASK-ID}-fixtures.md.

Контрольная точка перехода

Перед переходом к следующему этапу проверяет:

  • Требования документированы
  • Компоненты и файлы определены
  • Аудит install/deploy-скриптов выполнен (при необходимости)
  • Фикстуры захвачены (при парсинге внешних инструментов)
  • Все числа в плане из исходных таблиц
  • Критерий готовности тестируем и явен
  • Границы указаны (что не делаем)
  • Стек валиден
  • Стратегия отката жизнеспособна

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

> /dr-plan

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

Чтение контекста...
  PRD: PRD-authentication.md

Стратегическая проверка:
  Ценность: Высокая
  Риск: Средний
  Стоимость: 2-3 дня
  Вердикт: Продолжаем

Захват фикстур:
  Захвачен вывод Claude CLI: success + error
  Сохранено: datarim/tasks/AUTH-0001-fixtures.md
  Заметка: exit code 0 в обоих случаях — парсер использует поле is_error

Генерация плана...
  Компоненты: 8 файлов (4 новых, 4 изменённых)
  API-эндпоинты: 5
  Миграции БД: 2
  Тест-кейсы: 14

План записан в datarim/tasks.md
Следующий шаг: /dr-do или /dr-design

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

  • /dr-prd — предыдущий этап: требования
  • /dr-design — углублённое проектирование для L3-4
  • /dr-do — следующий этап: реализация