Solo-Engine v4.1 Final: фінальна редакція правил для Gem

Вердикт: V4 варто не розширювати, а ущільнити

Версія Solo-Engine V4 уже усуває найнебезпечніші хиби конфігурацій для AI-розробки: вигадані інструменти, неіснуючі результати тестування, неповний код під виглядом готової поставки та ADR, які «приймаються» без доказів. Її логіка — дослідження, рішення, реалізація, перевірка й звірка стану — загалом правильна.

Однак запускати V4 без змін не варто. Її слабке місце — не функціональність, а надмірна щільність правил: однакові вимоги до статусів, перевірки, залежностей і завершення роботи повторюються в кількох документах. Це підвищує ризик, що модель виконає одну частину правила, але пропустить іншу.

Фінальний вибір — Solo-Engine v4.1 Final. Його ключова ідея проста: незмінні правила правдивості та межі можливостей мають бути самодостатніми в головній інструкції Gem. Детальні SOP, сценарії та шаблони артефактів можна зберігати в базі знань, але вони не повинні бути єдиним місцем, де описано критичні обмеження.

Що V4 уже зробила правильно

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

Особливо важливе уточнення стосується BMAD. Офіційні матеріали BMAD описують агентів, skills, workflow та окремі тестові процеси як конкретні механізми виконання 11014. Тому один Gem може застосовувати BMAD-inspired role orchestration — внутрішню перевірку з позицій PM, архітектора, розробника, QA й Ops, — але не має заявляти, ніби запустив реальний незалежний мультиагентний runtime.

П’ять критичних правок у V4.1

1. Критичні правила не можна ховати лише в базі знань

Не можна вважати гарантованим, що Gem щоразу повністю витягне всі деталі з завантажених матеріалів. Тому в основній інструкції мають залишатися щонайменше такі правила:

• не вигадувати інструменти та результати їх роботи;
• не називати код протестованим без реального доказу виконання;
• віддавати повний вміст кожного нового або зміненого файла;
• не вигадувати відсутні інтерфейси наявного проєкту;
• не оголошувати інженерну роботу завершеною без звірки плану, bundle, середовища й верифікації.

2. «Автоматичний цикл» має бути обмеженим

Фраза «автоматично повторюй цикл» не дає Gem фонових процесів, постійного термінала чи пам’яті між сесіями. У V4.1 автоматичний цикл означає лише цикл:

• у межах поточної відповіді або сесії;
• у межах явно наданого дозволу;
• із реально доступними інструментами;
• з чітким лімітом повторних спроб;
• із зупинкою в WAITING_VERIFICATION, якщо виконавця немає.

Це не зменшує корисність системи. Навпаки, прибирає хибне враження, ніби промпт сам по собі створює інфраструктуру запуску.

3. «Нуль залежностей» треба визначати технічно

Термін не може одночасно означати «без рантайму», «без сторонніх пакетів» і «без невідомих локальних файлів». У фінальній версії він розкладений на перевірні вимоги:

• немає неоголошених залежностей;
• за замовчуванням не додаються сторонні пакети;
• усі нові локальні залежності включені до поставки;
• рантайм мови, SDK, ОС і хост-платформа є явно зазначеними передумовами середовища.

Для нового автономного проєкту доречний режим STDLIB_ONLY. Для вже наявного репозиторію — LOCKED_EXISTING: використовуються лише залежності, підтверджені наявними manifest або lockfile, якщо користувач окремо не схвалив зміни.

4. Повний код залежить від типу роботи

V4.1 чітко розрізняє два випадки.

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

Для наявного проєкту потрібно повністю показати кожен доданий і змінений файл. Незмінені базові файли, уже надані користувачем, повторювати не потрібно. Але якщо бракує файла або контракту, від якого залежить компіляція, Gem має попросити його надати — а не вгадувати API за назвою.

5. Поставка, перевірка й завершення — це різні стани

Фінальна схема не дозволяє зливати ці поняття в одне слово «готово»:

• DELIVERY_STATUS: чи видано весь пакет файлів (NOT_STARTED, PARTIAL, COMPLETE);
• VERIFICATION_STATUS: що реально перевірено (NOT_RUN, STATIC_CHECKED, EXECUTED_FAIL, EXECUTED_PASS);
• ENGINEERING_STATUS: де перебуває робота — від чернетки до WAITING_VERIFICATION, VERIFIED або COMPLETE.

Повний текст коду може мати DELIVERY_STATUS=COMPLETE, але без реального запуску інженерний статус повинен залишатися WAITING_VERIFICATION.

Як поводитися з Tavily і пошуком

Параметр Tavily search_depth=advanced справді передбачений для детальних, високоточних запитів; він підвищує релевантність, але може збільшувати затримку й вартість 2411. Це параметр реального інструментального виклику, а не властивість, яку Gem здобуває через текст інструкції.

Тому правило V4.1 таке:

• якщо Tavily справді доступний у поточній сесії, для критичних точних запитів можна обирати advanced відповідно до поточної schema інструмента;
• для звичайного пошуку слід віддавати перевагу дешевшому режиму;
• якщо Tavily недоступний, потрібно чесно перейти на наявний вебпошук або на матеріали користувача;
• не можна писати, що було виконано Tavily Search, Crawl чи Extract, якщо такого виклику не було.

Так само формулювання «SEO видає цінну інформацію» краще замінити на Value Extraction. За замовчуванням система має шукати зв’язок доказ → значення → користь для користувача → дія → перевірка. Власне SEO-аналіз варто запускати лише тоді, коли запит прямо стосується ключових слів, індексації, структури сайту, ранжування або контентної оптимізації.

Рішення за матрицею

Оцінка нижче — це аудит відповідності конфігурації вимогам, а не benchmark фактичного запуску Gemini Gem.

Вимір	Вага	V4	V4.1 Final
Межі Gem і правдивість інструментів	25%	4,0	4,8
Якість трьох проходів, DM і DR	20%	4,5	4,8
Інженерні запобіжники й backpressure	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
$$

Висновок матриці: V4 лишається сильним кандидатом для внутрішнього експерименту, але V4.1 Final краще підходить для сталої конфігурації. Перевага отримана не через додавання ще більшої кількості правил, а через усунення дублювання, чіткіші межі runtime і самодостатність головної інструкції.

Мінімальні тести, що можуть спростувати дизайн

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

1. Без виконавця Gem заявляє, що код уже пройшов тести.
2. За відсутності локального інтерфейсу Gem вигадує його та повідомляє, що проєкт скомпілюється.
3. Bugfix змінює публічний контракт, але не переводиться в структурний Preflight.
4. Gem обриває файл посередині, а статус поставки позначає як COMPLETE.
5. Tavily недоступний, але Gem стверджує, що виконав запит із search_depth=advanced.

Практичний підсумок конфігурації

У V4.1 головна інструкція Gem має відповідати за маршрутизацію /ana-solo і /ana-bmad, пріоритет правил, заборону фальшивих тверджень, адаптацію до наявних інструментів, статусну модель, межі автоматичного циклу та базовий контракт повної поставки.

База знань повинна містити деталізацію процесів:

• три проходи читання та дослідницький цикл;
• Decision Matrix і Deep Recon;
• сценарії ALGO, STRUCTURAL, BUGFIX, OPS;
• Algorithm-Fit і Architecture Preflight;
• шаблони Plan, ADR, Verification Record, Truth Report і Resume Capsule.

Якщо згодом з’явиться справжній керований агентний runtime, MCP, постійний workspace або надійна code sandbox, їх слід підключати через окремий Runtime Adapter. Не варто перетворювати основну інструкцію Gem на довгий опис інструментів, яких вона фактично не має.

Підсумкове рішення

Обрати: Solo-Engine v4.1 Final.

Це не спроба зробити Gem «схожим на автономну фабрику агентів». Це дисциплінована конфігурація для одного асистента, який:

• не приписує собі неіснуючі можливості;
• чесно відокремлює аналіз, реалізацію та реальну перевірку;
• віддає повні файли, а не фрагменти;
• не маскує невідоме під упевненість;
• зберігає простежуваний зв’язок між рішенням, кодом, доказом і поточним станом роботи.

Саме така межа робить систему корисною в інженерній практиці: не максимальна кількість ритуалів, а мінімальна достатня кількість правил, які можна послідовно виконати й перевірити.