Solo-Engine V4 je silný základ, ale v4.1 Final zpřesňuje hranice, které rozhodují

Verdikt

Solo-Engine V4 má správný směr, ale nedoporučil bych jej nasadit beze změn. Dobře řeší největší selhání AI vývojových workflow: vymyšlené použití nástrojů, fiktivní testování, neúplné ukázky vydávané za hotové řešení a ADR potvrzené bez důkazů.

Slabina V4 není v nedostatku mechanismů. Je jí spíš přílišná hustota pravidel: tytéž stavy, požadavky na ověření, závislosti a dokončení se opakují na více místech. To zvyšuje riziko, že model některou část přehlédne nebo vytvoří rozporný stav.

Doporučený výsledek je Solo-Engine v4.1 Final. Zachovává řetězec výzkum → rozhodnutí → implementace → ověření, ale zpevňuje čtyři klíčové body:

1. nekompromisní pravidla jsou přímo v hlavní instrukci Gemu;
2. podrobné SOP a šablony jsou oddělené ve znalostní bázi;
3. automatizace je omezená na reálně dostupné schopnosti aktuální relace;
4. dodání kódu, ověření a technické dokončení mají oddělené stavy.

Co V4 udělal správně

• Rozděluje analytický režim /ana-solo a technický režim /ana-bmad.
• Odděluje FACT, INFERENCE, ASSUMPTION a UNKNOWN.
• Zakazuje z promptu „vyrobit“ přístup k vyhledávání, souborům, Git repozitáři, terminálu či testovacímu prostředí.
• Rozlišuje úplný výstup kódu od tvrzení, že kód skutečně prošel kompilací a testy.
• Zavádí scénářové brány, Architecture Preflight, Algorithm-Fit, tlak na zastavení při selhání a následné State Reconcile.
• Zachází s ADR jako s rozhodovacím artefaktem s životním cyklem, ne jako s dekorativním dokumentem.
• Při dlouhém výstupu požaduje zastavení pouze na hranici celého souboru, ne uprostřed zdrojového kódu.

Důležitá je i přesná formulace kolem BMAD. Oficiální dokumentace BMAD popisuje agenty, dovednosti a workflow jako konkrétní mechanismy běhu. Jeden Gem proto může používat BMAD-inspirovanou orchestraci rolí, ale neměl by tvrdit, že je ekvivalentem skutečného runtime s několika samostatně běžícími agenty. 11014

Kde V4 potřebuje opravu

1. Kritická pravidla nesmějí záviset jen na znalostní bázi

Nelze předpokládat, že se při každé odpovědi kompletně načtou všechny přiložené dokumenty. Proto musí být přímo v hlavní instrukci Gemu alespoň tyto zásady:

• hranice reálně dostupných nástrojů,
• zákaz předstírání testů a kompilace,
• definice úplné dodávky,
• podmínky pro označení práce jako dokončené.

Znalostní báze má nést pracovní postupy a šablony, nikoli jedinou kopii pravidel, jejichž porušení by znehodnotilo celý výstup.

2. Méně duplicit znamená vyšší šanci na dodržení

V4 opakuje statusy, ověřování, závislosti i podmínky dokončení v několika dokumentech. To působí důkladně, ale v praxi může vzniknout „instrukční šum“: model zachytí jedno ustanovení a jiné, téměř stejné, přehlédne.

V4.1 proto doporučuje jeden autoritativní model stavů v hlavní instrukci a jen detailní aplikaci pravidel v jednotlivých metodikách.

3. „Automatická smyčka“ není běh na pozadí

Samotný prompt nemůže Gemu dát perzistentní terminál, úlohy na pozadí ani možnost pokračovat po odchodu uživatele. Automatická smyčka musí znamenat pouze omezený cyklus:

• v aktuální odpovědi nebo relaci;
• v rozsahu výslovného oprávnění;
• s nástroji, které jsou skutečně dostupné;
• s jasným limitem opakování;
• s přechodem do WAITING_VERIFICATION, pokud není k dispozici vykonavatel kódu.

To není omezení kvality. Je to podmínka důvěryhodnosti.

4. „Nulové závislosti“ potřebují technickou definici

Výraz nelze používat jako zkratku pro několik odlišných tvrzení. V4.1 jej rozděluje na:

• žádné neohlášené závislosti;
• ve výchozím stavu žádné nové závislosti třetích stran;
• všechny nové lokální závislosti jsou součástí dodávky;
• runtime jazyka, SDK, operační systém a hostitelská platforma jsou výslovně uvedené předpoklady prostředí.

Tím se zabrání situaci, kdy je projekt označen jako „bez závislostí“, ale ve skutečnosti předpokládá neznámou verzi SDK nebo nepřiložený lokální modul.

5. Úplný kód má jiný význam u nového a existujícího projektu

Pro nový projekt musí dodávka obsahovat uzavřený minimální celek: konfiguraci sestavení, vstupní bod, zdrojové soubory, nové lokální moduly, testy a nezbytné necitlivé konfigurace.

U existujícího projektu je správný požadavek jiný:

• úplně vypsat každý nový nebo změněný soubor;
• uvést závislé, ale nezměněné soubory z uživatelem dodaného základu;
• nevyžadovat zbytečné opakování celého repozitáře;
• zastavit a vyžádat si chybějící rozhraní, pokud by bez něj bylo nutné hádat kontrakt.

6. Dodávka, ověření a dokončení nejsou totéž

V4.1 má vést tři samostatné osy:

• DELIVERY_STATUS: zda byly všechny potřebné soubory úplně vypsány;
• VERIFICATION_STATUS: zda a jak proběhla skutečná kontrola;
• ENGINEERING_STATUS: zda lze práci technicky označit za dokončenou.

Například kompletně vypsaný balíček bez přístupu ke kompilátoru může mít DELIVERY_STATUS=COMPLETE, ale musí zůstat v ENGINEERING_STATUS=WAITING_VERIFICATION.

7. Tavily musí být schopnost, ne deklarace

Volba search_depth=advanced je skutečný parametr Tavily Search. Dokumentace jej popisuje jako režim pro vysoce relevantní a detailní dotazy za cenu vyšší latence; pro běžnější vyhledávání existují úspornější režimy. 2411

To však neznamená, že prompt může prohlásit, že Tavily použil. Gem smí uvést použití Tavily jen tehdy, když je v relaci skutečně dostupný příslušný nástroj nebo připojené rozhraní. Jinak musí transparentně přejít na dostupné vyhledávání či na poskytnuté materiály.

Srovnání V4 a V4.1 Final

Níže uvedené skóre není benchmark běhu Gemini Gemu. Jde o kvalitativní audit konfigurace na škále 0–5, přepočtený na 100 bodů.

Oblast	Váha	V4	V4.1 Final
Hranice Gemu a pravdivost nástrojů	25 %	4,0	4,8
Tříprůchodové čtení, DM a DR	20 %	4,5	4,8
Technické pojistky a tlak při selhání	20 %	4,6	4,8
Úplnost kódu a uzavřenost závislostí	15 %	4,6	4,9
Hustota instrukcí a snadnost dodržení	10 %	2,8	4,5
Obnova stavu a sladění důkazů	10 %	4,2	4,7
Vážené skóre	100 %	84,2	95,5

Výpočet:

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

Největší zlepšení tedy nevychází z přidávání dalších pravidel. Vychází z odstranění duplicit, přesnějších hranic schopností a ze soběstačné hlavní instrukce.

Rozhodnutí

• Doporučená volba: Solo-Engine v4.1 Final.
• Druhé místo: V4; je vhodná pro interní experiment, ne však jako dlouhodobá konfigurace bez úprav.
• Podmínka budoucí změny: pokud bude řešení později používat spravovaný agentní runtime, MCP nebo trvalý sandbox pro kód, má vzniknout samostatný Runtime Adapter. Není vhodné dál nafukovat hlavní instrukci popisy nástrojů.

Nejtvrdší námitka a odpověď

Námitka: V4 už je dost přísná a další reorganizace je jen kosmetika.

Odpověď: Nejde o teoretickou úplnost. Jde o pravděpodobnost, že se pravidla při dlouhé, vícekrokové práci skutečně dodrží. Když tentýž stav či požadavek žije v hlavní instrukci, metodice i šabloně artefaktu, snadno vznikne lokálně správná, ale globálně rozporná odpověď. V4.1 tento problém snižuje tím, že určuje jediné místo pro autoritativní pravidla.

Pět minimálních testů, které musí finální verze ustát

Následující situace dokážou rychle odhalit, zda konfigurace stále jen simuluje disciplínu:

1. Bez vykonavatele Gem tvrdí, že kód otestoval.
2. Při chybějícím lokálním rozhraní si Gem kontrakt vymyslí a prohlásí řešení za kompilovatelné.
3. Oprava chyby změní veřejný podpis, ale nevyvolá strukturální Preflight.
4. Výstup skončí uprostřed souboru, přesto se stav dodávky označí jako COMPLETE.
5. Tavily není dostupné, ale Gem tvrdí, že provedl dotaz s search_depth=advanced.

Stačí jediný takový případ a hlavní instrukce potřebuje další zjednodušení nebo zpřesnění.

Co má obsahovat finální instalační balíček

Doporučená struktura v4.1 Final je jednoduchá:

Soubor	Umístění	Účel
00-solo-engine-system.md	Instrukce Gemu	Routování, tvrdá omezení a hranice schopností
10-ana-solo.md	Znalostní báze	Výzkum, extrakce hodnoty, DM, DR a krystalizace
20-ana-bmad.md	Znalostní báze	Rozpoznání scénáře, kontrola rolí, implementace a ověření
30-artifacts.md	Znalostní báze	Plán, ADR, záznam ověření, Truth Report a Resume Capsule
40-three-pass-reading.md	Znalostní báze	Jádro tříprůchodového čtení

Starší soubory se stejnou funkcí by neměly zůstávat nahrané souběžně, aby nedocházelo ke konfliktnímu načítání pravidel.

Závěr

V4 už správně chápe, že kvalitní AI workflow nesmí nahrazovat důkazy sebevědomými formulacemi. V4.1 Final tuto zásadu dotahuje do provozně použitelnější podoby: méně opakování, přesnější stavový model a striktní rozdíl mezi tím, co Gem navrhl, dodal, staticky zkontroloval a co bylo skutečně spuštěno.

To je podstatnější než slib „více agentů“, „automatického běhu“ nebo „nulových chyb“. Důvěryhodný systém nehraje, že má schopnosti, které nemá — a přesně říká, co ještě potřebuje ověřit.