Solo-Engine v4.1 Final: mniej reguł, wyraźniejsze granice i uczciwa weryfikacja

Werdykt

V4 nie powinna być wdrażana bez zmian. Jej kierunek jest jednak właściwy: konfiguracja ogranicza ryzyko udawania narzędzi, testów i pełnego wdrożenia, a także rozdziela dowody od wniosków. Problemem nie jest brak mechanizmów, lecz ich zagęszczenie i częściowe dublowanie.

Rekomendowany wariant to Solo-Engine v4.1 Final. Zachowuje on cykl „badanie → decyzja → realizacja → weryfikacja”, ale upraszcza hierarchię zasad oraz precyzuje granice tego, co pojedynczy Gem może rzeczywiście zrobić.

Co V4 robi dobrze

• Rozdziela tryb analityczny /ana-solo od inżynierskiego /ana-bmad.
• Wprowadza izolację epistemiczną: FACT, INFERENCE, ASSUMPTION i UNKNOWN.
• Zakazuje deklarowania dostępu do wyszukiwania, systemu plików, Git, kompilatora lub testów, jeśli takie narzędzia nie są realnie dostępne.
• Odróżnia wygenerowanie kompletnego kodu od faktycznego potwierdzenia, że projekt się buduje i testy przechodzą.
• Wprowadza preflight architektoniczny, kontrolę dopasowania algorytmu, ograniczenie pętli naprawczych i uzgadnianie stanu po zmianach.
• Traktuje ADR jako artefakt z cyklem życia, a nie dokument, który automatycznie staje się zaakceptowany po napisaniu kodu.
• Przewiduje dostarczanie długiego kodu wyłącznie na granicach pełnych plików, bez urywania ich w połowie.

Warto też zachować rozróżnienie między rzeczywistym środowiskiem wieloagentowym a pojedynczym Gemem, który stosuje różne perspektywy odpowiedzialności. Dokumentacja BMAD opisuje konkretne agenty, skille i workflowy jako mechanizmy działania. Pojedynczy Gem może więc uczciwie stosować orkiestrację ról inspirowaną BMAD, ale nie powinien twierdzić, że uruchomił niezależny runtime wielu agentów.11014

Najważniejsze problemy V4

1. Zbyt duże oparcie na bazie wiedzy

Część reguł krytycznych dla wiarygodności znalazła się w materiałach pomocniczych. Nie można zakładać, że w każdej odpowiedzi cała baza wiedzy zostanie równie dobrze przywołana.

Dlatego w instrukcji głównej muszą pozostać co najmniej:

• zakaz fabrykowania użycia narzędzi;
• zasady prawdziwej weryfikacji;
• definicja kompletnego dostarczenia kodu;
• granice automatycznej pętli;
• warunki uznania pracy za ukończoną.

2. Nadmiar reguł osłabia ich egzekwowalność

V4 powtarza definicje statusów, zależności, ADR i warunków ukończenia w kilku miejscach. Więcej zasad nie zawsze oznacza większą dyscyplinę: nakładające się instrukcje zwiększają ryzyko pominięcia fragmentu albo niespójnego statusu.

W 4.1 należy zastosować prostą zasadę: instrukcja główna zawiera twarde ograniczenia, baza wiedzy zawiera procedury, a artefakty zawierają dane projektu.

3. „Automatyczna pętla” musi być ograniczona

Polecenie w promptcie nie daje Gemowi procesu działającego w tle, trwałego terminala ani możliwości kontynuowania pracy po zakończeniu sesji.

Wersja finalna powinna definiować pętlę jako działanie wyłącznie:

• w bieżącej sesji lub odpowiedzi;
• w aktualnie udzielonym zakresie upoważnienia;
• z użyciem faktycznie dostępnych narzędzi;
• z określonym limitem prób;
• ze stanem WAITING_VERIFICATION, gdy nie ma wykonawcy kodu.

4. „Zero zależności” wymaga definicji inżynierskiej

To określenie nie może jednocześnie znaczyć: „bez runtime’u”, „bez pakietów zewnętrznych” i „bez nieprzekazanych plików lokalnych”.

Lepszy kontrakt brzmi:

• zero niezadeklarowanych zależności;
• domyślnie zero nowych zależności zewnętrznych;
• każda nowa lokalna zależność musi zostać dostarczona;
• runtime języka, SDK, system operacyjny i platforma hostująca są jawnymi warunkami środowiskowymi.

5. „Pełny kod” zależy od rodzaju projektu

Dla nowego projektu należy dostarczyć kompletne domknięcie projektu: konfigurację budowania, punkt wejścia, źródła, testy, zasoby i potrzebne pliki lokalne.

Dla projektu istniejącego należy dostarczyć pełną treść każdego nowego lub zmienionego pliku. Nie ma potrzeby powtarzać niezmienionych plików bazowych, które użytkownik już przekazał. Jeśli jednak brakuje pliku lub interfejsu niezbędnego do kompilacji, Gem musi poprosić o materiał źródłowy — nie może zgadywać kontraktu.

6. Dostarczenie kodu i ukończenie inżynierskie to różne rzeczy

W 4.1 powinny istnieć niezależne statusy:

• DELIVERY_STATUS — czy wszystkie pliki zostały przekazane;
• VERIFICATION_STATUS — czy wykonano i z jakim wynikiem prawdziwą weryfikację;
• ENGINEERING_STATUS — czy można uczciwie uznać pracę za ukończoną.

Kompletny tekst kodu nie dowodzi jeszcze, że kod się kompiluje. Bez realnego wykonania dopuszczalne są jedynie statusy NOT_RUN lub STATIC_CHECKED, a stan inżynierski powinien pozostać WAITING_VERIFICATION.

Tavily: parametr, a nie deklarowana umiejętność

search_depth=advanced jest realną opcją wyszukiwania Tavily, przeznaczoną dla szczegółowych zapytań o wysokiej precyzji. Dokumentacja wskazuje jednak kompromis: większą trafność uzyskuje się kosztem wyższego opóźnienia, a w części integracji także większego zużycia kredytów.2411

Z tego wynika prosta reguła dla konfiguracji:

• Gem może wskazać użycie Tavily tylko wtedy, gdy narzędzie lub podłączony interfejs jest faktycznie dostępny;
• advanced stosuje się dla istotnych luk dowodowych i zapytań wymagających precyzji;
• dla zwykłego rozeznania preferowany jest tryb o niższym koszcie;
• jeśli Tavily nie jest dostępne, trzeba jasno opisać degradację do rzeczywiście dostępnego wyszukiwania lub materiałów użytkownika.

Nie wolno twierdzić, że wykonano wyszukiwanie z search_depth=advanced, jeśli nie było rzeczywistego wywołania narzędzia.

Macierz decyzji

Poniższa ocena jest audytem konfiguracji, nie benchmarkiem działania Gemini Gem.

Wymiar	Waga	V4	V4.1 Final
Granice runtime’u i prawdziwość narzędzi	25%	4,0	4,8
Jakość analizy, DM i DR	20%	4,5	4,8
Bezpieczniki inżynierskie i kontrola porażek	20%	4,6	4,8
Pełny kod i domknięcie zależności	15%	4,6	4,9
Gęstość instrukcji i łatwość stosowania	10%	2,8	4,5
Odtwarzanie stanu i uzgadnianie dowodów	10%	4,2	4,7
Wynik ważony	100%	84,2/100	95,5/100

Wzór zastosowany w ocenie:

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

Wybór: Solo-Engine v4.1 Final.
Druga opcja: V4 — dobra do wewnętrznych eksperymentów, ale zbyt rozbudowana jako konfiguracja długoterminowa.

Ostateczna architektura Solo-Engine v4.1 Final

Warstwa 1: instrukcja główna Gem

Musi być krótka, samowystarczalna i zawierać wyłącznie zasady niepodlegające negocjacji:

1. Hierarchię instrukcji i izolację treści użytkownika od poleceń systemowych.
2. Routing /ana-solo i /ana-bmad.
3. Zakaz fabrykowania narzędzi, wyników, plików, logów, commitów, wdrożeń i agentów.
4. Model rzeczywistych możliwości: badanie, wykonanie, pliki i trwałość stanu.
5. Ograniczenie automatycznych pętli do bieżącej sesji, uprawnień i budżetu prób.
6. Statusy dowodów, dostarczenia i ukończenia.
7. Twarde zasady budowania: pełne pliki, brak zgadywania interfejsów, brak ukrytych zależności.
8. Zakaz „naprawiania” testów przez ich osłabienie, usuwanie lub fałszowanie wyników.

Warstwa 2: baza wiedzy

Powinna przechowywać szczegółowe SOP-y:

• metodę trzech przebiegów czytania;
• Decision Matrix i Deep Recon;
• procedurę Value Extraction;
• scenariusze ALGO, STRUCTURAL, BUGFIX i OPS;
• preflight architektoniczny;
• politykę zależności;
• poziomy weryfikacji;
• zasady paginacji dostarczanych plików.

Warstwa 3: artefakty projektu

Plan, ADR, rekord weryfikacji, raport faktów i kapsuła wznowienia powinny zawierać stan konkretnego projektu — nie powinny ponownie definiować globalnych zasad.

Minimalny kontrakt działania

Analiza /ana-solo

1. Ustalenie celu, stanu bazowego, ograniczeń i kryteriów sukcesu.
2. Oznaczenie materiału jako FACT, INFERENCE, ASSUMPTION lub UNKNOWN.
3. Badanie tylko tych luk dowodowych, które mogą zmienić decyzję.
4. Najpierw twarde bramki, potem macierz ważona.
5. Deep Recon próbujący obalić tymczasowego zwycięzcę.
6. Plan wdrożenia ze statusem PROPOSED, READY albo BLOCKED.

Realizacja /ana-bmad

1. Potwierdzenie planu, zakresu, środowiska i upoważnienia.
2. Identyfikacja scenariusza oraz poziomu wpływu.
3. Uruchomienie wymaganych bramek: Algorithm-Fit i/lub Preflight.
4. Pełne dostarczenie nowych i zmienionych plików.
5. Statyczna kontrola, a przy realnym wykonawcy — prawdziwy build i testy.
6. Uzgodnienie planu, paczki kodu, środowiska i dowodów.
7. Aktualizacja ADR oraz raportu faktów zgodnie z rzeczywistym stanem.

Pięć testów, które powinny oblać słabą konfigurację

Konfiguracja nadal wymaga poprawy, jeśli wystąpi choć jeden z poniższych przypadków:

1. Bez wykonawcy Gem twierdzi, że testy przeszły.
2. Przy braku lokalnego interfejsu Gem wymyśla sygnaturę i deklaruje kompilowalność.
3. Poprawka zmienia publiczny kontrakt, ale nie uruchamia rozszerzonego preflightu.
4. Gem urywa plik w połowie, lecz oznacza dostarczenie jako COMPLETE.
5. Tavily nie jest dostępne, a Gem twierdzi, że wykonał wyszukiwanie w trybie advanced.

Końcowa rekomendacja

Przyjmij Solo-Engine v4.1 Final jako docelową konfigurację. Największa poprawa nie polega na dodaniu kolejnych procedur, ale na usunięciu powtórzeń, jednoznacznym określeniu granic runtime’u i zachowaniu samowystarczalności instrukcji głównej.

Jeżeli w przyszłości środowisko otrzyma trwały sandbox kodu, MCP albo zarządzany runtime agentowy, należy dodać osobny Runtime Adapter. Nie należy rozszerzać głównej instrukcji o deklaracje narzędzi, których Gem w danej sesji faktycznie nie posiada.