Официант не держит в голове прайс, состав блюд, налоги и бонусы. Он нажимает кнопки в терминале, а терминал помнит всё. Forgeplan - это POS-терминал для методологий: четыре способа работы в одной плоскости, чтобы человек выбирал содержание, а механика была снаружи.
POS-аналогия
Когда официант принимает заказ, он не держит в голове прайс, состав блюд, налог на добавленную стоимость, дисконтные карты и бонусы постоянных клиентов. Он нажимает кнопки в POS-терминале, а терминал помнит всё.
Роль официанта - выбрать блюдо, уточнить пожелания клиента, унести напиток. Роль терминала - правильно оформить, посчитать сумму, применить нужную скидку, отправить заказ на кухню, выпустить чек. Эти две роли разделены, и именно поэтому ресторан масштабируется: новый официант учится за час, потому что не нужно запоминать прайс.
В разработке мы традиционно требуем от инженера держать в голове и прайс, и блюда, и налог. Какой формат у PRD? Сколько разделов? Куда положить запись решения? Как связать её с тестами? Когда переоценивать архитектурный выбор? Каждая команда заново изобретает свой набор привычек, и каждый новый разработчик тратит первые недели на «вход в нашу культуру решений».
Я хочу разобрать, как выглядит «POS-терминал для методологий разработки» и почему его роль - не «ещё одна методология сверху», а инструмент, который держит уже существующие методы в одной плоскости и снимает с человека механическую работу.
Что забирает Forgeplan
В предыдущих постах серии я разбирал разные методы работы: BMAD для проектирования функций через четыре фазы; OpenSpec для дисциплинированной работы со спецификациями через дельта-формат и граф зависимостей; принцип ADI для генерации трёх версий перед фиксацией; формулу R_eff для оценки надёжности решений через самое слабое звено доказательств.
Каждый из этих методов разработан отдельно, у каждого свои авторы и сообщества. Но в реальной работе они дополняют друг друга: BMAD проектирует функцию, ADI выбирает один из трёх архитектурных вариантов, OpenSpec фиксирует контракт между компонентами, формула R_eff оценивает надёжность всего этого набора.
Forgeplan - инструмент, который собирает эти четыре подхода в один процесс работы. Конкретно:
- Шаблон PRD из 13 разделов BMAD встроен в команду
forgeplan new prd. Создаётся файл с уже размеченной структурой. - Формат дельта-спецификации OpenSpec встроен в команду
forgeplan new spec. ADDED / MODIFIED / REMOVED - готовая структура. - Структура DDR с шестью секциями (включая условия пересмотра) встроена в команду
forgeplan new adr. Архитектурное решение создаётся как файл с обязательной секцией триггеров пересмотра. - Оценка F/G/R для каждого доказательства встроена в формат
evidence-документа. Когда создаёшь доказательство, заполняешь три оси и уровень контекстного соответствия.
Эти форматы не выдуманы заново - они взяты из публичных источников: BMAD, OpenSpec, идеи трёхосной оценки доказательств из работ по принятию решений. Forgeplan просто собирает их в один процесс и не даёт пропустить обязательное.
Что остаётся человеку
POS-терминал не выбирает за официанта, что приготовить - он лишь оформляет выбор. Forgeplan не пишет за команду содержание решений - он лишь даёт правильный формат для записи.
За человеком остаётся:
- Содержание решения. Какой архитектурный вариант выбрать. Какие альтернативы рассмотреть. По каким причинам отвергнуть одни и принять другие.
- Бизнес-контекст. Какие компромиссы допустимы, какие - нет. Какой клиент важен. Где границы рамок.
- Понимание команды. Кто умеет работать с какой технологией. Где у вас прокачано, где - слабо.
- Финальный выбор. Среди трёх версий, которые сгенерировал AI, и пяти, которые предложил тимлид, - какая верна для этого конкретного контекста.
Это не мало. Это вся содержательная часть работы. Forgeplan просто снимает механическую - не даёт пропустить разделы, не даёт забыть условие пересмотра, не даёт активировать решение без доказательств.
Десять типов записей, шесть в активном ходу
В Forgeplan живёт десять типов записей. Это звучит как «много для усвоения», но в реальной работе шесть из них покрывают 95% задач, а остальные четыре - для специфических случаев.
Шестёрка в активном ходу:
- PRD (Product Requirements Document) - продуктовое требование с 13 разделами. Что делаем и зачем.
- RFC (Request for Comments) - архитектурное предложение с этапами реализации. Как делаем.
- ADR (Architecture Decision Record) - запись архитектурного решения с шестью секциями. Почему именно так.
- Spec - спецификация поведения системы с дельта-форматом. Контракт между компонентами.
- Epic - группа PRD/RFC/ADR, объединённая общей задачей. Когда задача слишком большая для одного PRD.
- Evidence - доказательство с оценкой F/G/R и уровнем контекста. На что опираемся.
Четыре ситуативных:
- Problem - запись о проблеме с контекстом, до выбора решения.
- Solution - рассмотрение двух-трёх вариантов решения проблемы.
- Note - микро-решение с автоматическим истечением через 90 дней.
- Refresh - повторная оценка устаревшего решения.
Каждая запись - markdown-файл в каталоге .forgeplan/. Связи между ними фиксируются в frontmatter: parent: PRD-018, informs: ADR-001, supersedes: ADR-005. Файлы хранятся в репозитории кода - те же ветки, тот же сценарий просмотра, те же сообщения коммитов.
Маршрутизация: какой набор записей вам нужен
Один из самых частых вопросов в командах: «А нужен ли тут PRD?». Это вопрос, на который команды любят тратить часы обсуждений. Forgeplan-команда forgeplan route "ваша задача" отвечает за полсекунды.
Логика маршрутизации основана на четырёх уровнях глубины задачи:
- Tactical: тривиальная задача, обратимая в течение дня. Один файл, один разработчик. Ни записей, ни ADR. Просто код + сообщение коммита.
- Standard: функция на 1-3 дня с одним содержательным выбором. PRD + RFC.
- Deep: необратимая задача на 1-2 недели с архитектурным решением. PRD + Spec + RFC + ADR. ADI (трёхверсионный анализ) - обязателен.
- Critical: межкомандная задача, стратегия. Epic + множество PRD + множество Spec + множество RFC + множество ADR. ADI + ревью.
Команда forgeplan route не «нашла окончательную истину» - она избавила команду от спора, который не двигает работу. Если разработчик и менеджер не согласны с рекомендацией - они спорят пять минут и решают по-своему. Но в 80% случаев рекомендация принимается, и команда экономит час обсуждения «нужен ли тут PRD».
Проверки перед утверждением
В одной команде forgeplan validate происходят три независимые проверки:
- Формат документа (источник - BMAD). Все 13 разделов PRD заполнены? Метрики успеха выражены числами с порогами? Нет «утечки реализации» из требований в технические решения?
- Согласованность спецификаций (источник - OpenSpec). Все ссылки между спецификациями валидны? Дельта-изменения имеют причину? Нет рассогласования между спецификациями и реализацией?
- Достаточность альтернатив (источник - принцип ADI/FPF). В ADR минимум три рассмотренных варианта? Каждый отвергнутый - с причиной отказа?
Не «бюрократия» - конкретные ошибки с указанием, что и где починить. «PRD-018: раздел “Метрики успеха” содержит фразу ‘улучшим пользовательский опыт’ без числового порога». «ADR-005: рассмотрено только два варианта, минимум три». «Spec-012: ссылка на Spec-008 указывает на устаревшую версию».
Команды, которые работали с проверочными списками для сборки кода (линтеры, форматтеры), быстро понимают аналогию. forgeplan validate - это линтер для решений.
Активация как точка невозврата
После forgeplan activate файл становится неизменяемым. Изменения возможны только через создание нового файла, который явно заменяет старый - через команду forgeplan supersede.
Это даёт честную историю решений: видно, что было решено тогда, что - потом, в каком порядке. Не «перезаписанный файл без следов», а timeline. Через два года можно открыть ADR-005, увидеть «заменён ADR-019 в апреле 2027 по причине X», и пойти к ADR-019 за актуальной версией. ADR-005 - открыт для чтения, но помечен как исторический.
Без этой механики команды теряют исторический контекст. Кто-то перезаписывает старый ADR новым, и через год невозможно ответить «почему мы сначала выбрали JWT, а потом переключились на сессии». Файл показывает только финальное состояние. С механикой supersede - оба ADR доступны, видны причины переходов, и любое решение можно отследить во времени.
Конкретный пример: streaming-конечная точка для Vault
Команда Vault внедряет конечную точку GET /query/stream - стриминговый ответ от модели для длинных запросов. Полный путь через Forgeplan:
forgeplan route "Add streaming endpoint GET /query/stream" - отвечает «уровень deep, нужны PRD, Spec, RFC, ADR, ADI обязателен».
forgeplan new prd "Streaming endpoint for model queries" - создаёт PRD-018 с 13 разделами, готовый к заполнению. Менеджер проекта за 30 минут заполняет цель, аудиторию, метрики (первый токен за 800 мс, общее время ответа за 5 секунд), функциональные требования, не-цели (не делаем кэширование стриминга в MVP), риски (медленный поставщик модели задерживает первый токен).
forgeplan validate PRD-018 - три проверки, обнаруживает «раздел крайних случаев пустой». Менеджер добавляет три крайних случая.
forgeplan reason PRD-018 - генерирует три гипотезы для архитектурного решения: SSE (Server-Sent Events), WebSockets, HTTP/2 push. Для каждой - проверяемое следствие.
forgeplan new rfc "Streaming via SSE" - создаёт RFC-007 с описанием реализации. Связь с PRD-018 проставляется автоматически через parent: PRD-018.
forgeplan new adr "Use SSE for streaming responses" - создаёт ADR-012 с шестью секциями: контекст, три варианта, доказательства, выбор, отвергнутые альтернативы, условия пересмотра.
forgeplan new evidence "SSE benchmark on staging" - после реализации. Замер показывает p50 первого токена 180 мс. Заполняется F=7, G=8, R=8, CL3 (свой замер на нашей нагрузке).
forgeplan link EVID-001 ADR-012 --relation informs - связь доказательства с решением.
forgeplan score ADR-012 - R_eff = 0.9, все три проверки зелёные.
forgeplan activate ADR-012 - решение переходит в активное состояние. Файл больше нельзя редактировать напрямую - только через forgeplan supersede.
Через шесть месяцев условие пересмотра срабатывает: трафик вырос в десять раз, p95 первого токена приблизился к 700 мс. Forgeplan-команда forgeplan stale показывает ADR-012 как кандидат на пересмотр. Команда садится, читает старые альтернативы, либо обновляет (renew с новой меткой условия) либо принимает новое решение (supersede). Цикл замыкается.
Что почитать дальше
Это седьмой пост в серии. Предыдущие шесть пройдены - каждый из них разобрал один аспект работы с решениями. Forgeplan - это инструмент, который их собирает в один процесс.
В следующем посте (капстон серии) я разберу полный цикл на одной реальной задаче: от строки в чате до записи решения с условием пересмотра. Семь шагов на одной функции - как все методы из серии складываются вместе.
Если хотите попробовать Forgeplan сейчас - он лежит в открытом доступе на GitHub. Это инструмент командной строки на одном бинарнике, ставится через cargo install forgeplan или скачивается готовый. Локально, без облака, без подписки. Каталог .forgeplan/ живёт в репозитории, синхронизация - через git. Полный набор интерактивных разборов десяти типов записей - на /guides.
Предыдущие посты серии: