Цикл рассуждений ADI

Почему это важно

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

ADI (Абдукция -> Дедукция -> Индукция) - это структурированный подход, позволяющий избежать этой ловушки. Он заставляет вас генерировать несколько вариантов, предсказывать их последствия и проверять эти предсказания на основе доказательств - всё это до написания единой строки кода. Десять минут ADI могут сэкономить десять дней переделок.

Почему ADI?

Большинство архитектурных решений принимаются на основе интуиции. ADI заставляет вас генерировать альтернативы, проверять предсказания и приходить к обоснованным выводам.

Обязательно для глубины Deep и Critical. Рекомендуется для Standard.

Три фазы

1. Абдукция - “Что могло бы сработать?”

Сгенерируйте 3+ гипотезы, которые могли бы решить проблему. Не просто ваша первая идея - заставьте себя подумать об альтернативах. Цель состоит в том, чтобы преодолеть эффект привязки: склонность фиксироваться на первом пришедшем в голову решении.

forgeplan reason PRD-001

Пример вывода:

Hypothesis 1: JWT tokens with refresh rotation
Hypothesis 2: Session-based auth with Redis
Hypothesis 3: OAuth2 delegation to external provider

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

2. Дедукция - “Что должно быть правдой?”

Для каждой гипотезы выведите 2-3 проверяемых предсказания. Если этот подход сработает, какие измеримые результаты мы увидим? Именно здесь проявляется неясность - если вы не можете сформулировать конкретные предсказания, вы недостаточно хорошо понимаете подход.

H1 predictions:
  - Token validation < 1ms (no DB call)
  - Refresh rotation prevents token theft
  - Stateless = horizontal scaling works

H2 predictions:
  - Session lookup < 5ms (Redis)
  - Server restart doesn't lose sessions
  - Session store becomes single point of failure

H3 predictions:
  - Zero auth code to maintain internally
  - External dependency for critical path
  - User experience depends on third-party uptime

Хорошие предсказания конкретны и фальсифицируемы. “Это будет быстро” - это не предсказание. “Валидация токена менее 1 мс без вызовов базы данных” - это предсказание, его можно измерить.

3. Индукция - “Подтверждают ли это доказательства?”

Проверьте предсказания на основе доступных доказательств. Оцените каждую гипотезу:

Гипотеза	Вердикт	Доказательство
H1: JWT	поддерживает	Бенчмарк: валидация 0.3 мс, OWASP рекомендует ротацию
H2: Redis	ослабляет	Redis добавляет сложность инфраструктуры, хранилище сессий является SPOF
H3: OAuth2	поддерживает	Делегирует риск аутентификации, но добавляет внешнюю зависимость

На этом этапе решение больше не является интуитивным - это информированное сравнение. Вы всё ещё можете выбрать H1, но теперь вы знаете компромиссы и у вас есть доказательства в его поддержку. Через шесть месяцев, когда кто-то спросит “почему JWT?”, вывод ADI ответит на этот вопрос.

От ADI к решению

Как только вы оценили гипотезы, дальнейший путь обычно становится ясным:

Все гипотезы сходятся: высокая уверенность, продолжайте с самым сильным вариантом
Два жизнеспособных варианта с разными компромиссами: задокументируйте оба в ADR, выберите тот, который соответствует вашим приоритетам
Нет явного победителя: вам нужно больше доказательств. Запустите PoC, проведите бенчмарк или проконсультируйтесь с экспертом, прежде чем принимать обязательства.

Команда

# Выполнить рассуждение ADI для артефакта
forgeplan reason PRD-001

# С контекстом базы знаний FPF
forgeplan reason PRD-001 --fpf

Флаг --fpf обогащает запрос соответствующими концепциями фреймворка FPF из базы знаний. Это полезно для решений, которые включают Trust Calculus, ограниченную рациональность или компромиссы между исследованием и эксплуатацией.

ADI напрямую соответствует разделам FPF B.3 (Trust Calculus) и B.5 (Абдукция / Дедукция / Индукция) - это основа рассуждений First Principles Framework. Вы можете просмотреть эти разделы из CLI:

forgeplan fpf section B.5       # Полный текст определения цикла ADI
forgeplan fpf search "abduction hypothesis"

Когда использовать

Глубина	ADI обязателен?
Тактическая	Нет
Стандартная	Рекомендуется
Глубокая	Обязательно
Критическая	Обязательно + ревью

Для глубины Standard ADI рекомендуется, но не является обязательным. Если у вас есть два чётких подхода и быстрого сравнения достаточно, неформальный ADI (даже просто мысленное упражнение) вполне приемлем. Для Deep и Critical пропуск ADI является нарушением методологии, потому что стоимость неправильного решения слишком высока, чтобы полагаться на интуицию.

Пример ADI из реального мира

Задача: Выбрать встраиваемую базу данных для хранения артефактов проекта (структурированные данные + векторные эмбеддинги).

Абдукция (3 гипотезы):

SQLite + отдельный векторный индекс (FAISS)
LanceDB (таблицы + векторы в одном движке)
PostgreSQL с расширением pgvector

Дедукция (предсказания для каждой гипотезы):

H1 (SQLite + FAISS):

Зрелая экосистема, десятилетия стабильности
Две отдельные системы для поддержки и синхронизации
Векторный индекс должен быть перестроен при изменениях схемы

H2 (LanceDB):

Единый движок для структурированных и векторных запросов
Более молодой проект, стабильность API неопределённа
Данные в открытом формате Lance (с возможностью миграции)

H3 (PostgreSQL + pgvector):

Требует запуска серверного процесса
Конфликтует с требованием “local-first, single binary”
Надёжный опыт использования в продакшене

Индукция (проверка доказательств):

H3 исключена: требует сервера, нарушает ограничение local-first
H1 против H2: бенчмарк LanceDB показывает 10 тыс. запросов артефактов менее чем за 100 мс (CL2). SQLite проверен, но сложность синхронизации двух систем является бременем для поддержки.
Решение: H2 (LanceDB) - простота единого движка перевешивает риск зрелости экосистемы; открытый формат данных предоставляет запасной путь для миграции.

Весь этот анализ занял 15 минут и сэкономил недели потенциальных переделок, если бы был сделан неправильный выбор.

Распространённые ошибки

Генерация фальшивых гипотез. Если ваши три гипотезы - это “правильный ответ”, “соломенное чучело” и “ещё одно соломенное чучело”, вы не используете ADI - вы рационализируете уже принятое решение. Каждая гипотеза должна быть подлинным претендентом.
Пропуск Дедукции. Переход напрямую от “вот три варианта” к “я выбираю этот” обходит самый ценный шаг. Дедукция заставляет вас чётко сформулировать, как выглядит успех для каждого варианта, и именно здесь всплывают скрытые предположения.
Использование ADI для тактических задач. Если исправление - это изменение одной строки, ADI является избыточным. Приберегите его для решений, где ошибка обходится дорого.
Не записывать вывод ADI. Рассуждение ценно только тогда, когда оно зафиксировано. Когда вы запускаете forgeplan reason, вывод сохраняется вместе с артефактом. Не делайте ADI в уме и не пропускайте команду.
Отношение к ADI как к одноразовому событию. Если после вашего первоначального ADI появляются новые доказательства (например, бенчмарк показывает неожиданные результаты), запустите его снова. ADI - это не церемония, это инструмент мышления, который вы используете всякий раз, когда вам нужна ясность.

Связанные материалы

CLI: forgeplan reason, forgeplan fpf, forgeplan fpf-search
Руководство по базе знаний FPF - как работает контекст B.3/B.5
Доказательства и R_eff - что потребляет Индукция
Роутинг и Глубина - где ADI становится обязательным