Команда /dr-do — реализация с тестами первыми
Как /dr-do следует строгому TDD-циклу, обрабатывает находки в процессе реализации, применяет ворота сетевой безопасности перед каждым коммитом и синхронизирует файл описания задачи с тем, что было построено.
Планирование заканчивается, когда начинается реализация. Команда /dr-do — это место, где агент-разработчик Datarim берёт план, дизайн-документы и бриф оператора и превращает их в работающий код. Ключевая дисциплина — разработка через тестирование: сначала пишется тест, он не проходит, затем пишется код, чтобы тест прошёл, и цикл повторяется.
Перед написанием единственной строки команда выполняет предполётную проверку для задач уровней 3 и 4. Она подтверждает, что план реализации существует, необходимые дизайн-документы готовы, зависимости доступны и проект собирается чисто в текущем состоянии. Начинать реализацию на сломанном фундаменте умножает стоимость каждого последующего шага.
Что она делает
TDD-цикл в основе команды работает на уровне метода или заглушки. Для каждого юнита тест пишется до кода реализации. Тест не проходит — подтверждая, что он действительно что-то тестирует — затем пишется реализация для достижения зелёного статуса. Этот паттерн применяется вне зависимости от размера изменения, потому что именно он выявляет больше всего ошибок с наименьшими затратами.
В процессе реализации команда может столкнуться с пробелами: импорт, который не разрешается; API, ведущий себя иначе, чем задокументировано; отсутствующая функциональность в зависимости. При появлении пробела протокол обнаружения пробелов порождает агента-исследователя, который изучает конкретную проблему и добавляет находки в файл инсайтов задачи. Если пробел фундаментальный — неверный стек или невозможное требование — реализация останавливается и рекомендуется /dr-prd для пересмотра требований. В противном случае реализация продолжается с обновлённым контекстом.
Перед каждым коммитом, затрагивающим сетевую конфигурацию — маппинг портов Docker Compose, конфигурацию Redis или PostgreSQL, файлы сокетов systemd — запускаются ворота сетевой безопасности. Они проверяют, что новые листенеры привязаны к loopback или Tailscale-адресам, а не к публичным интерфейсам. Ворота fail-closed: отсутствующая или некорректная конфигурация считается нарушением, не прохождением.
Один конкретный пример
Задача реализовать фоновое задание для генерации инвойсов проходит такой путь. Предполётные проверки подтверждают: библиотека очередей установлена, база данных доступна. Первый тест проверяет, что задание, созданное в очереди, появляется в БД со статусом status: pending — тест не проходит, таблицы ещё нет. Пишется миграция, тест проходит. Второй тест проверяет, что воркер забирает задание и обновляет статус — тест не проходит, воркер не реализован. Воркер написан, тест проходит. Возникает пробел: email-клиент для отправки имеет другой API, чем в документации. Агент-исследователь подтверждает текущую версию SDK и обновляет файл инсайтов. Реализация продолжается с исправленным API-вызовом. Коммит не затрагивает сетевую конфигурацию — ворота безопасности пропускаются.
Место в пайплайне
Команда запускается после /dr-plan и /dr-design (при необходимости). Когда все проверки в чеклисте перехода пройдены — реализация завершена, тесты проходят, регрессий нет, файл описания обновлён — пайплайн направляет к /dr-qa для задач уровней 3 и 4 или прямо к архивированию для более простых.
Файл описания задачи обновляется на протяжении всей реализации. Заметки о прогрессе, решения дизайна, принятые в процессе кодирования, и все обнаруженные пробелы попадают туда. Именно по этому файлу /dr-qa понимает, что было построено, не перечитывая всю историю git.
Общую картину пайплайна даёт пост что такое Datarim; что происходит после реализации — в описании команды /dr-qa, проверяющей реализацию против всех артефактов, созданных выше по пайплайну.