Планирование и перепланирование проектных задач

Аргумент: $ARGUMENTS — режим работы (опционально).

Определение режима

Режим init — планирование с нуля

Шаг 1. Полный сбор документации

КРИТИЧЕСКИ ВАЖНО: прочитай ВСЮ документацию проекта. Не пропускай файлы.

1. Получи список файлов в docs/ через Glob
2. Прочитай каждый файл:
   • .md файлы — через Read
   • .docx файлы — через Bash с python-docx:

     python3 -c "from docx import Document; doc = Document('docs/file.docx'); [print(p.text) for p in doc.paragraphs if p.text.strip()]"

   • .xlsx файлы — через Bash с openpyxl:

     python3 -c "import openpyxl; wb = openpyxl.load_workbook('docs/file.xlsx', data_only=True); ..."

   • .pdf файлы — через Read (с параметром pages)
3. Если python-docx / openpyxl не установлены — установи через pip3 install

Шаг 2. Анализ документации — ЧТО извлечь

Из документации нужно извлечь и систематизировать:

Из технического задания (ТЗ):

• Все модули/компоненты системы с описанием
• Все метрики и KPI с формулами расчёта
• Все API-интеграции (WB API, OpenAI, Telegram, Google Sheets и т.д.)
• Структуру БД (таблицы, поля, связи)
• Все команды/меню интерфейса (Telegram бот, Google Sheets и т.д.)
• Все сценарии использования (user stories, примеры)
• Критерии приёмки по каждому этапу
• Требования к безопасности (шифрование, изоляция, compliance)
• Технологический стек
• Out of scope — чтобы не планировать лишнее
• Риски и митигации
• Нефункциональные требования (производительность, отказоустойчивость)

Из договора:

• Этапы работ с дедлайнами (абсолютные даты от даты подписания)
• Обязанности заказчика — что должен предоставить и когда (п. 2.3)
• Обязанности исполнителя — что должен поставить (п. 2.1)
• Порядок приёмки — акты, сроки ответа (п. 5)
• Раунды правок — сколько бесплатно (п. 3.3)
• Гарантийный период (п. 6.2)
• Стоимость и порядок оплаты (п. 4)
• Контактные лица с обеих сторон

Из референсов (если есть):

• Структура аналогичных систем (листы, столбцы, модули)
• UX-паттерны (как пользователь взаимодействует)
• Что можно адаптировать под наш проект

Шаг 3. Верификация полноты — ДО генерации плана

Перед делегированием planner-агенту проверь, что ничего не пропущено:

Чеклист верификации:

• Каждый модуль из ТЗ → будет как минимум 1 задача
• Каждый пункт меню/команда → будет задача
• Каждый сценарий использования → покрыт задачами
• Каждая интеграция (API) → задача на клиент + задача на использование
• Каждая таблица БД → покрыта миграцией
• Deployment pipeline → задачи (local → staging → production)
• Зависимости от заказчика → задачи-блокеры (EXT-*)
• Акты приёмки по этапам → задачи
• Документация (техдок, пользовательская, администрирование) → задачи
• Тестирование → задачи (unit, integration, e2e, нагрузочное, security)
• Compliance (152-ФЗ, GDPR и т.д.) → учтён в задачах
• Еженедельные отчёты (если в договоре) → задача/процесс

Шаг 4. Генерация плана — ДЕЛЕГИРОВАТЬ агенту planner

Agent(subagent_type="planner", prompt="
  Режим: init.

  [ПОЛНОЕ содержимое всех документов — передавай ДАННЫЕ, не ссылки]

  Включи обязательно:
  1. Задачи-блокеры от заказчика (EXT-*)
  2. Deployment pipeline (Docker → staging → production)
  3. Акты приёмки по этапам договора
  4. Все команды/меню из ТЗ как отдельные задачи
  5. Тесты: unit (в каждой задаче через tdd_anchors) + отдельные интеграционные/e2e
  6. Документацию: техдок, пользовательская, инструкция по администрированию
")

КРИТИЧЕСКИ ВАЖНО: передавай агенту полное содержимое документов, а НЕ ссылки на файлы. Агент не должен сам искать контекст.

Шаг 5. Аудит плана на соответствие документации

После получения плана от агента проведи ручную проверку:

1. Модули ТЗ → задачи: каждый модуль покрыт? Нет пропущенных?
2. Интерфейс → задачи: каждая команда/кнопка/меню покрыта?
3. Сценарии → задачи: каждый use case реализуем через запланированные задачи?
4. Договор → задачи: этапы, акты, блокеры от заказчика, delivery items?
5. Deployment → задачи: где разрабатываем (local), где тестируем (staging), где деплоим (production)?
6. Тестирование → задачи: каждый модуль тестируется?
7. Безопасность → задачи: шифрование, изоляция, compliance?

Если найдены пробелы — НЕ ГЕНЕРИРУЙ план заново. Допиши недостающие задачи.

Шаг 6. Показать план пользователю

Покажи:

1. Milestones с дедлайнами
2. Waves внутри каждого milestone
3. Количество задач и оценку в часах
4. Критический путь
5. Блокеры от заказчика (отдельным списком)
6. Deployment pipeline (3 фазы)
7. Открытые вопросы / ADR pending
8. Риски

Дождись подтверждения. НЕ применяй без подтверждения.

Шаг 7. Применение (после подтверждения)

1. Записать dev-infra/tasks/tasks.json
2. Обновить dev-infra/memory/progress.md
3. Обновить dev-infra/memory/active-context.md
4. Обновить dev-infra/memory/decisions.md (ADR)
5. Предложить коммит

Режим replan

Шаг 1. Загрузить контекст

• Документация (docs/)
• Текущие задачи (dev-infra/tasks/tasks.json)
• Прогресс (dev-infra/memory/progress.md)
• Техдолг (dev-infra/memory/tech-debt.md)
• Решения (dev-infra/memory/decisions.md)

Шаг 2. Аудит — ДЕЛЕГИРОВАТЬ агенту planner

5 проверок: Coverage, Deadline, Dependency, Staleness, Tech-debt

Шаг 3. Показать отчёт + предложения, дождаться подтверждения

Шаг 4. Применить изменения (Edit, не перезапись)

Режим validate

Шаги 1-2 как в replan, но показать только отчёт без предложений.

Linear Sync

Non-blocking. Если Linear MCP недоступен или linear-mapping.json не настроен — пропустить.

1. Проверь наличие dev-infra/config/linear-mapping.json и что linear.team заполнен
2. После init или replan — если были созданы новые задачи:
   • Предложи пользователю: «Созданы новые задачи. Синхронизировать в Linear? (/sync-linear)»
   • Не запускай sync автоматически — только предложи

Антипаттерны (из реального опыта)