ForgePlan: где живут решения вашей команды, если их вообще не теряли

Шесть месяцев открытой разработки инструмента, который превращает решения команды в полноценные артефакты в git. Что такое кладбище решений, как устроен ForgePlan и почему у репозитория одна звезда на GitHub - честный отчёт.

Лид

«А почему мы взяли Postgres вместо Mongo полгода назад?» - спрашивает новый сеньор на ревью. Тишина. Кто-то пытается вспомнить тред в Slack, кто-то открывает Notion. На странице Notion написано «ADR - TBD». Дата создания - ноябрь. Решение принято, обоснование потеряно. Через три недели команда обсудит то же самое заново и придёт к тому же выводу - никто не догадается заглянуть в git-историю полугодовой давности.

Это кладбище решений. У большинства команд оно есть, и большинство команд носят его как родимое пятно - даже не подозревая, что это диагноз. Слова «методологическая дыра» обычно звучат корпоративно. Тут - буквально: между моментом, когда команда что-то решила, и моментом, когда это потребовалось вспомнить, информация теряется.

Меня зовут Илья, и полгода назад я начал делать инструмент, который заставляет фиксировать решения как полноценные артефакты - с обязательной структурой, привязкой подтверждений и оценкой надёжности. Локально, в каталоге .forgeplan/ рядом с кодом. Один бинарь на Rust, открытый код под MIT. Я полгода ем собственный собачий корм - все решения по самому ForgePlan живут в его собственном .forgeplan/. На сегодня там 343 артефакта, 1995 тестов, версия v0.30 и одна звезда на GitHub. Последняя цифра - главная причина, почему я пишу эту статью.

В этом тексте я расскажу: какую боль решает ForgePlan, что именно он делает (без перевода с английского), как попробовать за 60 секунд, какая экосистема выросла вокруг ядра, кому это подходит и кому не подходит, и почему звёзд так мало, хотя продукт работает уже полгода. В конце - куда идём дальше и анонс следующих статей.

Это не реклама. Это первая из трёх статей про открытую разработку, и в ней я говорю прямо: позиционирование у репозитория сейчас сломано, описание не сходится с реальностью, и я знаю как минимум три дыры в дорожной карте, которые открыто разбираю в самом репозитории.

Какую проблему решает ForgePlan

Декабрь, ревью, второй час. Сеньор тыкает в строчку: «А почему мы взяли вот эту библиотеку для авторизации? Я помню, было три варианта обсуждения». Тишина. Я листаю Slack - тред есть, 47 сообщений, четыре реакции, ссылка на Notion. На Notion-странице написано «ADR - TBD». Дата создания - ноябрь. Решение принято, обоснование потеряно. Это не выдумка - это сценарий, который у меня повторился раз пять за карьеру в разных командах.

Артефакты, которые команда производит во время принятия решений, и артефакты, которые она производит во время реализации, обычно живут в разных вселенных. Код версионируется, ревьюится, тестируется, депрекейтится по правилам. Решения получают тред в Slack и надежду, что кто-нибудь вспомнит. Через шесть месяцев приходит новый человек, не находит обоснований, предлагает «давайте перепишем» - и команда тратит три недели на повторное обсуждение того же вопроса.

Стандартные подходы не работают по разным причинам. Notion / Confluence - отдельная вселенная от кода. Ссылка из commit на Notion-страницу через год может вести в никуда (страница перенесена, удалена, проект архивирован). Ревью не цепляет содержимое страницы - никто не проверяет, что обещание совпадает с реализацией. Slack-треды - вообще не источник правды, это устная история, записанная случайным образом. ADR в репо как просто markdown-папка - шаг в правильную сторону, но без структуры превращается в свалку: одни ADR содержат три абзаца, другие - двадцать, у пятого нет статуса, у седьмого нет обоснования, у десятого ссылка на код, который давно переписан.

С появлением AI-агентов в командах эта боль усиливается на порядок. Агент клонирует репозиторий в новую песочницу каждую сессию. У него нет вашего Notion, нет вашего Slack, нет вашей памяти о вчерашнем митинге. Если знание - у вас в голове, для агента его не существует. Если знание - в Slack, для агента его не существует. Только то, что лежит в виде файла в репозитории, - реально.

Дальше - забавный эффект. Дисциплина, которая нужна команде с агентами, полезна и команде без агентов. Просто без агентов давление на дисциплину слабее: команда живёт со штрафом, не замечая его. С агентами штраф становится виден моментально - агент тупит, переспрашивает, делает не то. И оказывается, что условия, которые делают агента полезным, - это те же условия, которые ускоряют живых людей: ясная структура, явные обязательства, отслеживаемое состояние, проверки на этапе сборки.

Я начал ForgePlan, чтобы лечить кладбище решений. Первая версия была про живых людей. Через четыре месяца я заметил, что меня всё чаще приглашают обсудить «как это связано с AI-агентами», и понял: я неосознанно построил такую дисциплину для команд, в которой агенту работать удобно по конструкции, а не по случайному совпадению. Об этом - отдельная статья через две недели. В этой я говорю про базовый случай: команда, которая не хочет терять решения, и не важно, кто их пишет.

Что такое ForgePlan

В одном предложении: локальный инструмент командной строки на Rust, который превращает решения команды в полноценные артефакты в каталоге .forgeplan/ рядом с кодом - со структурой, оценкой надёжности и жизненным циклом.

Подробнее. Любой процесс принятия решений в команде раскладывается на несколько типичных вопросов:

• Что мы строим и зачем? - это PRD (Product Requirements Document, требование к продукту).
• Как мы это построим? - это RFC (Request for Comments, архитектурное предложение с фазами).
• Почему именно так, а не иначе? - это ADR (Architecture Decision Record, запись архитектурного решения).
• Каковы точные контракты? - это Spec (API, модели данных).
• Что объединяет несколько связанных задач? - это Epic (группировка PRD/RFC/ADR).
• Чем мы доказываем, что это работает? - это Evidence (тесты, замеры, ревью).

Это шесть основных типов. Есть ещё четыре вспомогательных - Note (микро-решение со сроком 90 дней), Refresh (перепроверка устаревшего), Problem (зафиксированная проблема), Solution (варианты решения). Все они - обычные markdown-файлы в .forgeplan/, читаемые человеком и агентом без специальных инструментов.

У каждого артефакта есть жизненный цикл:

draft → active → {superseded | deprecated | stale}

Артефакт начинается как черновик. Чтобы он стал активным, нужно пройти проверки: команда forgeplan validate смотрит, заполнены ли обязательные секции; forgeplan score считает оценку надёжности; forgeplan activate блокируется, если первые две провалились. Дальше активный артефакт может быть заменён другим (supersede - «новая версия принята»), снят с поддержки (deprecate - «больше не используем»), или протухнуть (stale - «доказательство истекло, требуется перепроверка»). Удалять артефакты нельзя - они всегда видны в истории.

Оценка надёжности - это R_eff (от reliability effective). Идея простая: общая надёжность артефакта равна самому слабому подтверждению, на которое он опирается. Не среднему, не медиане. Если три EvidencePack - два с прочными замерами, один с устаревшим тестом, - общая оценка тянется к слабейшему. Это не математическая прихоть, а защита от усреднения: одно гнилое звено дискредитирует всю цепь, и инструмент честно об этом говорит. Здесь не нужен никакой матан - достаточно понимать, что усредняющие метрики прячут проблемы, а минимум - нет.

Хранение - локальное, в git. Каталог .forgeplan/ коммитится вместе с кодом. Никаких облаков, никаких подписочных сервисов, никаких ключей API. Семантический поиск по артефактам работает на встроенной модели BGE-M3 (запускается через fastembed, без сети). Для индексации используется LanceDB рядом, но её можно безболезненно пересобрать командой forgeplan scan-import из markdown - потому что markdown тут источник правды, а индекс - производный кэш. Это переход от «у нас есть записанные решения» к «у нас репозиторий как единый источник правды о проекте». Разница не косметическая: в первой формулировке знание зависит от инфраструктуры, во второй - инфраструктура зависит от знания.

Связи между артефактами - типизированные. Не «вот ссылка на другой документ», а явные отношения: informs (одно подсказывает другое), refines (детализирует), contains (входит в состав), supersedes (заменяет). Команда forgeplan graph рисует mermaid-граф всех связей. Команда forgeplan blindspots находит активные решения, у которых нет подтверждений. Команда forgeplan stale показывает артефакты с истёкшим сроком годности. Команда forgeplan health собирает всё это в один взгляд.

Под капотом - три крейта Rust: ядро (~12.8 тысяч строк), интерфейс командной строки (76 команд) и MCP-сервер (73 инструмента, для AI-агентов через Model Context Protocol). Один бинарь, около 41 МБ после сжатия, ставится через brew, скрипт установки или сборкой из исходников.

60-секундное демо

Давайте посмотрим, как это выглядит вживую. Допустим, в команде нужно добавить аутентификацию через OAuth2.

$ forgeplan init -y
✓ Workspace initialized at .forgeplan/

$ forgeplan route "Add OAuth2 authentication"
Depth:      Standard
Pipeline:   PRD → RFC
Confidence: 92%
Next: forgeplan new prd "OAuth2 Authentication"

$ forgeplan new prd "OAuth2 Authentication"
Created: prd-oauth2-authentication (predicted PRD-77?)
Next: forgeplan validate prd-oauth2-authentication

$ forgeplan validate prd-oauth2-authentication
PASS (0 MUST errors)
Next: forgeplan reason prd-oauth2-authentication

$ forgeplan reason prd-oauth2-authentication
Hypothesis 1: Session-based flow      (confidence: 0.6)
Hypothesis 2: JWT with refresh        (confidence: 0.8) ← best supported
Hypothesis 3: Delegated to OAuth proxy (confidence: 0.4)
Next: forgeplan new evidence "PRD-077 verification"

$ forgeplan new evidence "15 tests pass, p95 180ms on benchmark"
$ forgeplan link EVID-118 prd-oauth2-authentication --relation informs
$ forgeplan score prd-oauth2-authentication
R_eff: 1.00  (Adequate)
Next: forgeplan activate prd-oauth2-authentication

$ forgeplan activate prd-oauth2-authentication
✓ prd-oauth2-authentication (draft → active)
Done.

Что здесь произошло. Команда route определила нужную глубину проработки (Standard - 1-3 дня, требуется PRD и RFC). Команда new создала артефакт с короткой меткой (slug). Команда validate проверила обязательные секции. Команда reason запустила раздумье ADI (Abduction → Deduction → Induction): выдвинуть три гипотезы, оценить каждую, выбрать сильнейшую - это защита от анкеринга на первой пришедшей в голову мысли. Команда score посчитала надёжность по самому слабому подтверждению. Команда activate перевела черновик в активное состояние.

Каждая команда в выводе пишет подсказку в следующую через маркер Next: или Done.. Это не косметика - это контракт: документация рабочего цикла генерируется кодом во время выполнения, поэтому она не может разойтись с тем, как реально работает программа. Агенту такая подсказка нужна, чтобы не угадывать; человеку - чтобы не держать в голове 76 команд.

Весь цикл - около минуты живого времени, плюс заполнение тела артефакта (требования, мотивация, цели, ограничения - это то, что, собственно, делает артефакт полезным).

Экосистема: ядро плюс три спутника

ForgePlan-CLI - ядро. Вокруг него выросли три отдельных продукта, которые делают использование удобнее.

forgeplan-web - граф решений в браузере. Отдельное SvelteKit-приложение. Запускается одной командой:

$ npx @forgeplan/web
Server running at http://localhost:5173

Открывается браузер, видно весь ваш .forgeplan/ как интерактивный граф. Артефакты - узлы, связи - рёбра, цвета - типы (PRD, RFC, ADR…), яркость - оценка надёжности, размер - количество входящих связей. Пять режимов раскладки: автоматическая раскладка с физикой (force-directed), полосы по типам (lanes), матрица зависимостей (matrix), радиальная (radial), дерево (tree). Можно фильтровать по статусу, искать по тексту, кликать на узлы и читать содержимое прямо в боковой панели. Всё локально - приложение читает файлы из .forgeplan/ рядом, никуда ничего не отправляет.

forgeplan-hud - статусная строка для Claude Code. Тонкая двухстрочная утилита, которая показывает в нижней части терминала, пока работает агент: какой артефакт сейчас активен, какая у него оценка надёжности, сколько в репозитории сирот (артефактов без связей), сколько протухших. Время работы - около 60 миллисекунд на обновление. Реализовано на bash + jq поверх вывода forgeplan health --json, потому что для такой простой задачи Rust-бинарь - это перебор, а скорость холодного запуска у скрипта оказалась лучше. Маленький инструмент, который убирает 80% переключений контекста: не нужно открывать отдельную вкладку и вводить forgeplan health каждые пару минут.

forgeplan-marketplace - каталог плагинов для Claude Code. Отдельный открытый репозиторий, в нём 12 плагинов, более 60 агентов и 16 навыков (skills). Плагины устанавливаются прямо в Claude Code через встроенный менеджер. Самый крупный - fpl-skills, набор из 15 навыков для работы с методологией: маршрутизация задач по глубине, оформление подтверждений, работа с состояниями жизненного цикла, восстановление инвариантов. Marketplace тоже под MIT, никаких подписок.

Связь у этих четырёх вещей следующая. CLI - единственный обязательный компонент: всё остальное опционально. Web-приложение читает данные, которые уже создал CLI; HUD читает вывод CLI; плагины marketplace вызывают CLI и MCP-сервер CLI. Можно установить только CLI и работать вообще без остального. Можно подключить web-вьюшку, чтобы команда смотрела общий граф на встрече. Можно поставить HUD, если работаете с Claude Code и хотите видеть состояние, не отвлекаясь. Можно подключить плагины, если хотите расширить агентам набор навыков.

Tauri-десктоп - пока в дорожной карте, без даты. Это будет десктоп-обёртка вокруг web-приложения для тех, кто не хочет держать npx процесс отдельно.

Кому подходит и кому НЕ подходит

Подходит, если:

• У вас команда, которая тратит время на повторные обсуждения. Если каждые два месяца возвращается вопрос «а почему мы выбрали X?» - у вас кладбище решений, ForgePlan полезен.
• Вы используете AI-агентов в кодинге (Claude Code, Cursor, Aider, Continue). Агентам критично, чтобы знание лежало в репозитории - для них всё, чего нет в репо, не существует. ForgePlan превращает решения в файлы, которые агент видит автоматически.
• Вы пишете на Rust, Python, TypeScript, Go, Java, C#, Swift - короче, на любом языке. ForgePlan не привязан к стеку, он работает с markdown в .forgeplan/. Сам инструмент написан на Rust, но это деталь реализации.
• Вы храните решения в git или хотите начать. Если вы готовы коммитить markdown - этого достаточно.
• Вы делаете средние и крупные технические решения не реже раза в неделю. Если решений мало - инструмент будет лежать без дела.

НЕ подходит, если:

• Вам нужен облачный сервис с подпиской. ForgePlan локальный, отдельного хостинга нет, синхронизация - через git. Если вашей команде нужен внешний центральный сервис - это не оно.
• Вам нужна замена Jira / Linear. ForgePlan - не управление задачами. У него нет дедлайнов, назначений, спринтов в традиционном смысле. Он отвечает на вопрос «что мы решили и почему», а не «кто что делает к среде». Связка с Jira/Linear возможна (есть отдельный инструмент Orchestra от того же автора), но из коробки этого нет.
• Вам нужна система для не-инженеров. ForgePlan живёт в командной строке и в файловой системе. Web-вьюшка помогает читать, но создавать артефакты удобно только из терминала. Менеджеру продукта без CLI - неуютно.
• Вам нужна готовая интеграция с GitHub Issues или Linear. Двусторонняя синхронизация - на дорожной карте, но её ещё нет.

Если попадаете в «подходит» - следующая секция показывает, как поставить и попробовать.

Что сделано: цифры и честный статус

На момент написания (8 мая 2026):

• 343 артефакта в .forgeplan/ - 60 PRD, 12 ADR, 9 RFC, 4 Spec, 8 Epic, плюс Evidence, Problems, Notes, Refresh.
• 1995 тестов, 0 падений, 0 предупреждений на двух фича-конфигах.
• 76 команд командной строки, 73 MCP-инструмента.
• 3 крейта Rust: forgeplan-core (12.8K строк), forgeplan-cli, forgeplan-mcp.
• v0.30.0 на сегодня, релизный цикл - каждые 2-4 недели.
• Один бинарь, около 41 МБ после сжатия (strip + lto + codegen-units=1 + opt-level=z).
• MIT-лицензия, репозиторий открыт.

И последняя цифра, которую обычно прячут, - одна звезда на GitHub.

Я не делаю вид, что её нет. Причина простая и инженерная: описание репозитория полтора года говорило «Backend and ForgePlan developer tools». Это обещание, которое не сходится с реальностью. Кто ищет «инструменты разработчика бэкенда» - приходит, видит жизненный цикл артефактов, оценку надёжности, граф решений - и уходит, потому что искал не это. Кто ищет дисциплину решений или способ работать с AI-агентами в команде - не приходит, потому что в описании этих слов нет.

Это не «маркетинг подвёл инженерку». Это позиционирование как часть архитектуры. Если описание репозитория говорит одно, а код делает другое - звёзды распределяются в две стороны от истинного соответствия продукта рынку: те, кому нужно, не приходят, а те, кто пришёл, уходят. Я писал описание до того, как у инструмента появилась чёткая аудитория. Сейчас - переписываю.

Эта статья - часть переписывания. Если вы дочитали до сих пор и вам это интересно - значит, описание начинает работать. Раньше до этого момента дочитывали единицы, потому что отсеивались на первой же фразе.

Как попробовать

Установка - одна команда:

brew install ForgePlan/tap/forgeplan

(macOS и Linux. Для Windows - пока сборка из исходников через cargo install --path crates/forgeplan-cli. Готовый бинарь под Windows - в дорожной карте.)

Проверить установку:

forgeplan --version

Зайти в любой git-репозиторий и инициализировать:

cd ~/projects/your-project
forgeplan init -y
forgeplan health

init -y создаст каталог .forgeplan/ со всеми подкаталогами и шаблонами. health покажет, что всё работает - выведет статус Healthy и отсутствие сирот / протухших артефактов.

Дальше - попробовать тот же 60-секундный цикл, что показан выше: route → new prd → validate → reason → score → activate. Каждая команда в конце вывода говорит, что делать следующим шагом - не нужно держать в голове все 76 команд.

Если хочется визуализации:

npx @forgeplan/web

Браузер откроется на localhost:5173, граф будет пустой (вы только что начали), но это базовая точка отсчёта. По мере накопления артефактов граф наполняется.

Полная документация - docs/methodology/FORGEPLAN-GUIDE.md в репозитории. Полный индекс - docs/README.md. Репозиторий: github.com/ForgePlan/forgeplan.

Что дальше

Дорожная карта на ближайшее обозримое будущее - три пункта, не больше:

1. Контракт на спринт как отдельный артефакт. Сейчас PRD - слишком тяжеловесный для дневной задачи (13 обязательных секций, рассуждение с тремя гипотезами, привязка подтверждений). Note - слишком лёгкий, не поддерживает чек-листы и привязку. Промежуточного формата для «обещание команды на 2-3 дня» нет, и я ловлю эту боль каждую неделю.
2. Десктоп-обёртка через Tauri. Web-приложение есть, но запускать npx каждый раз - лишняя ступенька. Десктоп-приложение упростит жизнь тем, кто не хочет держать процесс в фоне.
3. Двусторонняя синхронизация с GitHub Issues / Linear. Сейчас связь между ForgePlan-артефактом и GitHub Issue - только через ссылку в commit-сообщении. Хочется, чтобы PRD автоматически создавал Issue, и наоборот.

Полный список открытых вопросов - в репозитории, в каталоге .forgeplan/problems/ (там сейчас 62 проблемы с разной степенью проработки) и в issues с тегом roadmap.

Эта статья - первая из серии. Дальше:

• Через две недели - лонгрид о более широкой теме: ForgePlan как обвязка для AI-агентов. ForgePlan родился из дисциплины решений, но через четыре месяца оказалось, что ровно те же механизмы делают его удобной средой для агентских задач - пять подсистем walkinglabs (правила, инструменты, окружение, состояние, проверки) маппятся на наши команды один в один. Если эта статья - про то, что ForgePlan делает, та будет - про то, в какую сторону он эволюционирует с приходом агентов.
• Через шесть недель - отчёт «Полгода открытой разработки: пять уроков». Конкретные истории про PROB-034 (день, когда инструмент мне врал), PROB-048 (четыре раунда ревью, чтобы заставить markdown быть авторитетным), PROB-060 (как сломалась нумерация при работе нескольких агентов параллельно). Каждая история - урок методологического масштаба, не просто баг-фикс.

Где можно следить за обновлениями:

• Репозиторий - github.com/ForgePlan/forgeplan (Rust, MIT, релизы каждые 2-4 недели).
• Документация - forgeplan.dev (методология, гайды, индекс артефактов).

Если что-то из этого срезонировало - пишите в issues или в канал. Особенно ценна обратная связь по разделу «кому НЕ подходит»: каждый раз, когда кто-то говорит «я попробовал, не зашло, потому что …», у меня появляется конкретный вопрос для следующего разбора. Открытая разработка живёт честной критикой, не похвалами.