Solo-Engine v4.1 Final: аудит V4 и финальная архитектура

Вердикт

V4 не стоит выпускать без правок. Она уже устраняет ключевые риски: вымышленные инструменты, фиктивное тестирование, выдачу фрагментов за полноценный код и перевод ADR в статус принятого решения без доказательств. Однако главная проблема V4 — не нехватка функций, а избыточная плотность правил и не до конца определённые границы того, что Gem реально способен сделать.

Финальный выбор — Solo-Engine v4.1 Final. Он сохраняет полезный контур «исследование → решение → инженерная реализация», но сокращает повторы, делает основную инструкцию самодостаточной и запрещает выдавать желаемые возможности за реальные.

Что в V4 уже сделано правильно

• Разделены режимы /ana-solo для анализа и /ana-bmad для инженерной работы.
• Введено разделение утверждений на FACT, INFERENCE, ASSUMPTION и UNKNOWN.
• Прямо запрещено выдумывать поиск, доступ к файловой системе, запуск кода, Git-операции и результаты тестов.
• Полный исходный код отделён от утверждения «код действительно скомпилирован и прошёл тесты».
• Добавлены сценарная классификация, Algorithm-Fit, Preflight, обратное давление при сбоях и State Reconcile.
• ADR перестаёт быть декоративным документом и получает жизненный цикл, привязанный к доказательствам и конкретному bundle.
• Длинная поставка должна останавливаться только на границе файла, а не посреди исходника.

Важное уточнение касается BMAD. Документация BMAD действительно описывает агентов, навыки, workflow и отдельные процессы тестирования как самостоятельные механизмы исполнения.11014 Поэтому один Gem может использовать BMAD-inspired role orchestration — последовательную проверку с точек зрения аналитика, архитектора, разработчика и QA, — но не должен утверждать, что запустил несколько независимых агентов в полноценном BMAD runtime.

Главные проблемы V4

1. Критичные правила слишком зависят от базы знаний

Нельзя считать гарантией, что каждый файл knowledge base будет полностью и одинаково извлекаться в каждом ответе. Поэтому правила о честности инструментов, полном коде, верификации и критериях завершения должны находиться прямо в главной инструкции Gem, а не только в справочных SOP.

2. Повторы размывают приоритеты

В V4 несколько документов параллельно определяют статусы, зависимости, верификацию, ADR и Definition of Done. Это повышает риск частичного соблюдения: модель может выполнить одну формулировку и пропустить другую, близкую по смыслу.

В v4.1 правило простое: непреложные ограничения — в system instruction; процедура и шаблоны — в knowledge base; фактическое состояние проекта — в артефактах проекта.

3. «Автоматический цикл» не должен означать фоновую работу

Фраза «автоматически повторять цикл» не даёт Gem доступа к постоянному терминалу, фоновым задачам или работе после завершения сессии. В финальной версии цикл разрешён только:

• в рамках текущего ответа или сеанса;
• в пределах явно выданного разрешения;
• с реально доступными инструментами;
• с заранее заданным пределом повторных запусков;
• с остановкой в WAITING_VERIFICATION, если исполнителя кода нет.

4. Термин «нулевые зависимости» требует инженерного смысла

Он не может одновременно означать «не нужен runtime», «нет внешних пакетов» и «не нужны отсутствующие локальные файлы». В v4.1 он разделён на проверяемые условия:

• нет необъявленных зависимостей;
• по умолчанию не добавляются новые сторонние пакеты;
• каждая новая локальная зависимость поставляется полностью;
• runtime, SDK, ОС и хост-платформа — это явные предпосылки окружения, а не часть исходного кода.

5. «Полный код» различается для нового и существующего проекта

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

Для существующего проекта нужно полностью вывести каждый новый или изменённый файл, а также все новые локальные зависимости. Неизменённые файлы, уже предоставленные пользователем, повторять не требуется. Но если отсутствует файл или интерфейс, от которого зависит компиляция, его нельзя додумывать: корректное состояние — WAITING_INPUT.

Три статуса вместо одного ложного «готово»

Ключевое изменение v4.1 — разъединение трёх вопросов:

Статус	На что отвечает
DELIVERY_STATUS	Все ли требуемые файлы выведены полностью?
VERIFICATION_STATUS	Что действительно было проверено и каким способом?
ENGINEERING_STATUS	Есть ли основания объявить инженерную работу завершённой?

Полнота вывода не доказывает работоспособность. Статическая проверка не равна сборке. А успешный тест старого bundle не подтверждает новый bundle.

В отсутствие реального исполнителя допустимы генерация кода и статический обзор, но верификация должна оставаться NOT_RUN или STATIC_CHECKED, а инженерный статус — WAITING_VERIFICATION.

Tavily: только при реальном доступе к инструменту

Параметр Tavily search_depth=advanced действительно предназначен для более точных и детальных запросов, но требует большего времени отклика и может быть дороже.2411 Это параметр фактического вызова API, а не способность, которую можно получить одной только подсказкой.

Следовательно, Gem должен:

• заявлять об использовании Tavily только при реально подключённом инструменте или интерфейсе;
• применять advanced для критичных запросов высокой точности, если это поддерживает текущая schema инструмента;
• при отсутствии Tavily честно перейти к доступному веб-поиску или материалам пользователя;
• не выдумывать результаты Search, Extract или Crawl.

Решение: Solo-Engine v4.1 Final

Основная инструкция Gem

Главная инструкция должна содержать только то, что нельзя потерять при неполном извлечении knowledge base:

1. Роутинг /ana-solo и /ana-bmad.
2. Приоритет правил и изоляцию содержимого загруженных файлов как данных, а не инструкций.
3. Запрет на вымышленные инструменты, тесты, логи, коммиты, развертывания и агентов.
4. Реальные границы инструментов: research, execution, files и persistence.
5. Раздельные статусы поставки, верификации и инженерной готовности.
6. Условия, при которых разрешено объявить работу завершённой.
7. Требование полного содержимого новых и изменённых файлов.
8. Ограничение повторных циклов и правило эскалации после двух безуспешных исправлений одной причины.

База знаний

В базе знаний остаются подробные документы:

• метод анализа и принятия решений ANA-SOLO;
• инженерный workflow ANA-BMAD;
• шаблоны Plan, ADR, Verification Record, Truth Report и Resume Capsule;
• методика трёх проходов чтения.

Старые версии однотипных файлов не следует загружать одновременно с финальным пакетом: иначе возможны конфликтующие извлечения правил.

Инженерный workflow

/ana-bmad работает как последовательность контрольных точек, а не как инсценировка командного чата:

1. Проверить Plan ID, revision, окружение, границы разрешения и критерии приёмки.
2. Определить сценарий: ALGO, STRUCTURAL, BUGFIX, OPS или смешанный.
3. Выполнить Algorithm-Fit и Architecture Preflight там, где это необходимо.
4. Собрать bundle и провести статическую проверку.
5. Запустить реальную проверку, только если доступен настоящий исполнитель.
6. При сбоях исправлять причину в пределах бюджета попыток.
7. Сверить bundle, план, среду, зависимости, ADR и запись верификации через State Reconcile.
8. Только после этого обновить итоговый Truth Report и статус.

Оценочная матрица

Оценки ниже — экспертный аудит конфигурации, а не benchmark фактического исполнения Gemini Gem.

Критерий	Вес	V4	V4.1 Final
Границы Gem и честность инструментов	25%	4,0	4,8
Три прохода, DM и DR	20%	4,5	4,8
Инженерные предохранители и реакция на сбой	20%	4,6	4,8
Полнота кода и замыкание зависимостей	15%	4,6	4,9
Плотность инструкций и исполнимость	10%	2,8	4,5
Восстановление состояния и сверка доказательств	10%	4,2	4,7
Итоговый балл	100%	84,2	95,5

Формула нормализации:

$$
Score = 20\sum_{i=1}^{n} w_i s_i,\qquad \sum_{i=1}^{n}w_i=1
$$

Минимальные тесты, которые способны опровергнуть дизайн

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

1. При отсутствии исполнителя Gem заявляет, что код прошёл тесты.
2. При отсутствии локального интерфейса Gem выдумывает его и объявляет код компилируемым.
3. Исправление меняет публичную сигнатуру, но не переводится в structural Preflight.
4. Вывод обрывается внутри файла, но DELIVERY_STATUS получает значение COMPLETE.
5. Tavily недоступен, но Gem утверждает, что выполнил запрос с search_depth=advanced.

Итог

The Pick: Solo-Engine v4.1 Final.

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

Если в будущем появятся Gemini API Managed Agent, MCP, постоянная рабочая область или кодовый sandbox, их следует подключать через отдельный Runtime Adapter. Не стоит расширять основную инструкцию вымышленными описаниями инструментов в надежде, что они начнут существовать.