DevRails — контролируемая фабрика агентов, поставленных на рельсы.

Продукт: DevRails 26 · Версия: 0.1.1

DevRails 26 работает вместе с Codex или Claude,  превращая разработку проектов в движение по рельсам лучших классических практик разработки,  удерживая текущее состояние процесса в долгосрочной памяти, чтобы  Вы могли прерваться  даже в неподходящий момент, закрыв текущую сессию и  позднее  продолжить в новом чате без существенных потерь.

Фреймворк ориентирован на джунов-вайбкодеров, которые ещё слабо разбираются во всех нюансах разработки небольших проектов до ~100 тыс. строк кода.

** Основные цели фреймворка:**

1. Формирование фундамента проекта в виде design specs, contracts, schemas, etc, что даст  устойчивую долгосрочную пддержку.
2. Поддержка бесшовного процесса разработки с возможностью продолжения в новой сессии в большинстве случаев обрыва старой или утери текущего конткста сессии.

🎛️ Как пользоваться

После развёртывания DevRails в папке проекта (находящегося на стадии идеи или частично реализованного) — разработка превращается в мягко направляемое агентами, но полностью контролируемое Вами путешевствие по всем необходимым этапам разработки от мозгового штурма до финальных e2e-тестов.

Первая фаза, формируем brief конституцию и PRD, это осноные файлы ДНК проекта.

Вторая фаза подготовки спецификаций. Сначала мы закладываем каркас SDD спеков, потом раскладываем проект на эпики и фичи, и участично разработанного илиже дальше для каждой фичи создаем подробные SDD контракты, схемы и пр., то создаст надежный фундамент для будущей генерации кода.

Третья фаза - раскладываем фичи на таски, формируя карточки и дополнительные спецификации, помогающие дешевым моделям (типа luna) выполнять задачи в качественно сформированных рамках. Тут есть 2 пути: автономный - разложить все фичи на таски и запустить выполнение тасок в /autopilot, или же ручной но более надежный путь - раскладываем по одной фиче на таски, выполняем таски через /exe, верифицируем в 1-3 прохода . Иногда бывает, что в процессе имплементации таски всплывают  непредвиденные ранее нюансы, и агент направляет вас на пересмотр спецификаций, что может повлечь за собой изменение последущих фич, поэтому фичи лучше реализовывать по одной, это главное преимущество ручного режима. Ну и токены конечно в ручном режиме жгутся экономней.

Четвертая фаза, как правило, это одна из последних фичей - общие тесты всей системы.

💾 В процессе работы flow создает кучу бюрократической писанины, порой существенно больше, чем сама таска имеет веса. Но именно благодаря той бюрократии нам практически не страшны обрывы сессии, в новом чате работа продолжится с последнего чекпоинта.

🌱 Канонический Greenfield flow ( проект создается с нуля)

Запускаем команды по одной и следуем инструкциям.

**0. Если идея в зачаточном состоянии
 -> /brainstrorm

**1. Оформляем идею**
 -> /brief
 -> /constitution
 -> /write-prd

**2. Подготовка спецификаций(C4 + SDD) и scaffold проекта**
  -> /spec-init
  -> /prd-to-features
  -> /review-feat-plan 
  -> /spec-design                    
  -> /foundation-to-tasks

**3. Раскладываем фичи на таски и выполняем 
  -> /feature-to-tasks FT-<NNN>
  -> /review-tasks-plan FT-<NNN>
  -> /exe + /verify 
    -> /red-verify

🏗️ Канонический Brownfield flow (внедряем DevRails в уже разрабатываемый проект)

Brownfield — существующий проект, в который нужно внести изменения.

/map-codebase
  -> получить PRD/delta
  -> /constitution, если principles ещё не ratified|partial
  -> /write-prd --delta
  -> /spec-init
  -> /prd-to-features
  -> /review-feat-plan при применимом gate
  -> /spec-design
  -> /foundation-to-tasks --verify-existing, только если baseline proof нужен
  -> /feature-to-tasks FT-<NNN>
  -> /review-tasks-plan FT-<NNN>
  -> execution

/map-codebase сначала фиксирует реальное состояние кода. Затем агент работает с уже переданным описанием изменений — delta. Без PRD или delta команда не создаёт функции и задачи продукта.

Если существующий проект уже собирается, запускается и имеет достаточные проверки, отдельная очередь FT-000 обычно не нужна. Если это не доказано, /foundation-to-tasks --verify-existing создаст только минимальные проверочные задачи.

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

Для каждой функции используется маршрут:

/feature-to-tasks FT-001
  -> /review-tasks-plan FT-001
  -> /exe TASK-...
  -> /verify TASK-...
  -> /red-verify TASK-..., если таска сложная

• /feature-to-tasks дополняет техническое описание функции и создаёт задачи;
• /review-tasks-plan проверяет, что задачи покрывают функцию и готовы к выполнению. Он возвращает APPROVE или REJECT и ничего не исправляет;
• /architecture-review помогает этой проверке оценить границы системы и зависимости, но не выносит итоговое решение;
• /mb-doctor механически проверяет наличие обязательных файлов и подтверждений.

🛠️ Уровни риска задач

Каждая задача получает уровень риска:

• T0 — безопасная правка документации;
• T1 — небольшое локальное изменение кода или теста;
• T2 — API, данные, состояние, миграция или несколько модулей;
• T3 — безопасность, рабочая система, платежи, необратимые действия или риск потери данных.

T2/T3 выполняются по TDD: сначала тест, затем реализация.

Чем выше риск, тем строже проверка:

• T0/T1 обычно достаточно выполнить через /exe;
• T2 проходит /exe -> /verify, а готовая функция — итоговый /red-verify;
• T3 проходит /exe -> /verify -> /red-verify.

Подробнее о проверках и RED/GREEN — в howItWorks.md.

🤖 Ручной и автоматический режимы

👤 Ручной режим

Оператор выбирает задачу и запускает /exe TASK-.... Если агенту прямо поручены и выполнение, и закрытие простой T0/T1 задачи, он может завершить её одной командой после подходящей локальной проверки.

▶️ /autopilot

Последовательно выполняет уже созданную и одобренную очередь продуктовых задач. Перед запуском должны быть закрыты базовые задачи FT-000, а /mb-doctor --strict должен пройти успешно. /autopilot не создаёт требования, функции или начальную очередь и никогда не выполняет FT-000.

Для одной задачи доступны первая попытка и два повтора. Если причина сбоя неясна, /autopilot может запустить отдельную диагностику через /debug. Диагностика не добавляет новую попытку: после третьего неудачного выполнения четвёртого не будет.

✨ /autonomous

**Это тестовый режим, я им еще не пользовался. ** Проводит весь процесс от переданного краткого описания продукта (Product Brief), PRD или описания изменений до конечного результата. Если нужен FT-000, /autonomous выполняет его сам, а готовые продуктовые задачи передаёт /autopilot.

Если не хватает решения оператора или обязательного подтверждения, автоматический запуск останавливается и сообщает причину и точную команду для продолжения. По умолчанию задачи выполняются последовательно.

🎭 Роли агентов

• GENERAL — обычный агент верхнего уровня. Без явного запроса оператора он не запускает дополнительных агентов;
• ORCHESTRATOR — координирует работу и назначает отдельным агентам исследование, реализацию, проверку или архитектурное проектирование;
• ARCHITECT — проектирует архитектуру и технические спецификации, сопоставляя пользу решения со стоимостью реализации и возникающими рисками;
• Explorer, Implementer и Reviewer — назначаемые роли для исследования, реализации и независимой проверки.

Роль фиксируется при запуске и не меняется в ходе работы. /kiss-architect позволяет применить правила Architect к текущему архитектурному решению, не меняя роль и полномочия агента.

🚀 Установка

Скачайте DevRails к себе и в папке запустите команду:

node scripts/install-framework.mjs

Установщик предложит выбрать проект, в который вы хотите развернуть весь мемори банк.

После установки в Codex или Claude Code и запустите /cold-start, это проверит состояние проекта и запустит следующий шаг синхронизации\разработки.

📦 Что появится в проекте

• .agents/skills/ и .claude/skills/ — 35 команд DevRails для Codex и Claude Code;
• .memory-bank/ — общая память проекта: архитектура, спеки, декомпозиция в задачи и код;
• .protocols/ — записи о ходе выполнения и проверки задач;
• .tasks/ — отчёты и подтверждения выполненной работы;
• PAPERCUTS/ — заметки о мелких помехах рабочего процесса; каталог PAPERCUTS/TECHDEBTS/ создаётся вместе с ним для последующего использования;
• /tech-debt — отчёт о техническом долге;
• AGENTS.md — тут ключевые инструкции по работе всего Workflow. Если имеете свой AGENTS.md, позаботьтесь чтобы слить оба файла в один;
• scripts/mb-lint.mjs и scripts/mb-doctor.mjs — автоматические проверки структуры и готовности проекта.

📚 Подробнее

Все существующие команды и подробное описание структуры репозитория находится в howItWorks.md. Схема Greenfield-пути находится в GREENFIELD_WORKFLOW.md.