Solo-Engine V4.1 Final: parempi loppuversio kuin V4 sellaisenaan

Arvio: V4 on vahva perusta, mutta sitä ei kannata julkaista sellaisenaan

Tuomio: V4 ratkaisee useita aiempien agenttiohjeiden vakavia ongelmia. Se kieltää työkalujen, lähteiden, testien, Git-toimien ja monen erillisen agentin suorittamisen keksimisen. Lisäksi se erottaa toisistaan täydellisen kooditoimituksen ja aidosti suoritetun varmennuksen.

Silti V4:n suurin heikkous ei ole kyvykkyys vaan liiallinen sääntötiheys. Kun samaa asiaa – tilaa, varmennusta, riippuvuuksia, ADR-päätöksiä ja valmistumiskriteerejä – määritellään useassa tiedostossa, pitkän ohjeiston noudattaminen muuttuu hauraammaksi. Tällöin malli voi osua yhteen sääntöön mutta ohittaa toisen, siihen päällekkäisen säännön.

Siksi suositus on Solo-Engine V4.1 Final. Se säilyttää V4:n tutkimus–päätös–toteutusketjun, mutta keskittää ehdottomat säännöt Gemin pääohjeeseen. Menetelmät, tarkistuslistat ja artefaktimallit kuuluvat tietopankkiin, eivät pääohjeen toistuviksi osioiksi.

Mitä V4 tekee oikein

• Se erottaa /ana-solo-analyysin ja /ana-bmad-toteutuksen.
• Se erottaa tiedon neljään luokkaan: FACT, INFERENCE, ASSUMPTION ja UNKNOWN.
• Se kieltää verkkohaun, Tavily-kutsujen, testitulosten, tiedostokirjoitusten ja Git-toimien esittämisen toteutuneina ilman todellista näyttöä.
• Se erottaa täydellisen lähdekoodin toimittamisen siitä, että projekti olisi aidosti käännetty tai testattu.
• Se käyttää päätösmatriisia, vastaväitteitä etsivää Deep Recon -vaihetta, esivarmistusta ja tilatäsmäytystä.
• Se käsittelee ADR:n päätösartefaktina, jolla on elinkaari – ei pelkkänä dokumentaatiokoristeena.
• Se vaatii pitkissä toimituksissa tauon vain kokonaisen tiedoston rajalla.
• Se kuvaa BMAD-roolit yhden Gemin vastuunäkökulmiksi eikä väitä virheellisesti, että useita itsenäisiä agentteja olisi käynnistetty. BMADissa agentit, taidot ja työnkulut ovat omia natiivin ajonaikaisen järjestelmän mekanismejaan, joten yhden Gemin kannattaa puhua BMAD-henkisestä rooliorganisoinnista, ei aidosta monen agentin runtime-ympäristöstä. 11014

Keskeiset korjaukset V4.1 Finaliin

1. Kriittisiä sääntöjä ei saa jättää vain tietopankin varaan

Tietopankkitiedostojen täydellistä palautumista jokaiseen vastaukseen ei voi pitää varmana. Siksi vähintään seuraavien kohtien pitää olla pääohjeessa:

• työkalujen todellisuusraja;
• testauksen ja käännöksen todistusvaatimus;
• täydellisen tiedostotoimituksen vaatimus;
• riippuvuuspolitiikka;
• valmistumisen ehdot.

2. Automaattinen silmukka tarvitsee kovan toimivaltarajan

Pelkkä kehotteen teksti ei anna Gemille taustatehtäviä, pysyvää terminaalia tai oikeutta jatkaa istuntojen välillä. V4.1:ssa automaattinen silmukka tarkoittaa vain rajattua sykliä:

• nykyisessä vastauksessa tai istunnossa;
• käyttäjän nimenomaisen valtuutuksen sisällä;
• vain oikeasti käytettävissä olevilla työkaluilla;
• ennalta määritellyllä uusintayritysbudjetilla;
• ilman suoritusympäristöä tilaan WAITING_VERIFICATION asti.

3. “Nollariippuvuudet” pitää purkaa täsmällisiksi väitteiksi

Ilmaisu ei voi samanaikaisesti tarkoittaa, ettei ohjelma tarvitse ajonaikaista ympäristöä, ettei se käytä ulkopuolisia paketteja ja ettei se nojaa puuttuviin paikallisiin tiedostoihin.

V4.1 käyttää sen sijaan näitä sääntöjä:

• ei ilmoittamattomia riippuvuuksia;
• oletuksena ei uusia kolmannen osapuolen riippuvuuksia;
• kaikki uudet paikalliset riippuvuudet toimitetaan mukana;
• kääntäjä, runtime, SDK, käyttöjärjestelmä ja isäntäalusta ovat erikseen ilmoitettavia ympäristöedellytyksiä.

4. Täydellinen koodi tarkoittaa eri asioita uudessa ja olemassa olevassa projektissa

Uudessa projektissa toimitetaan projektin minimaaliseen sulkeumaan tarvittavat tiedostot: rakennusasetukset, käynnistyspiste, lähdekoodi, testit, resurssit ja tarvittavat asetusesimerkit.

Olemassa olevassa projektissa toimitetaan kokonaisina kaikki lisätyt ja muutetut tiedostot. Käyttäjän jo toimittamia, muuttumattomia perusversiotiedostoja ei tarvitse toistaa. Jos puuttuva rajapinta tai rakennustiedosto vaikuttaa kääntymiseen, Gemin on pyydettävä se nähtäväksi eikä arvattava toteutusta.

5. Toimitus, varmennus ja insinöörivalmius on pidettävä erillään

V4.1:ssa käytetään kolmea erillistä tilaa:

• DELIVERY_STATUS: onko kaikki tarvittava koodi toimitettu;
• VERIFICATION_STATUS: mitä on todella tarkistettu tai ajettu;
• ENGINEERING_STATUS: voiko työn väittää olevan teknisesti valmis.

Täydellinen lähdekoodipaketti ei siis vielä tarkoita, että käännös, testit tai tuotantokelpoisuus olisi osoitettu.

6. Tavily on kyvykkyyssovitin, ei kehotteella luotu ominaisuus

Tavilyn search_depth=advanced on todellinen hakusyvyysvaihtoehto tarkkuutta vaativiin hakuihin. Se kasvattaa relevanssia, mutta voi lisätä viivettä ja kustannusta. Sitä voidaan väittää käytetyn vain, jos nykyisessä ympäristössä on oikeasti Tavily-työkalu tai siihen kytketty rajapinta. 2411

Jos Tavilya ei ole käytettävissä, järjestelmän on käytettävä vain aidosti tarjolla olevaa hakua tai käyttäjän toimittamaa materiaalia ja ilmoitettava heikennetystä toimintatavasta.

Päätösmatriisi

Arvio on konfiguraatioauditointi, ei Gemin käytännön suorituskykybenchmark. Pisteet ovat 0–5 ja painotettu tulos muunnetaan sadan pisteen asteikolle.

Ulottuvuus	Paino	V4	V4.1 Final
Ajonaikaiset rajat ja työkalujen todellisuus	25 %	4,0	4,8
Kolmen lukukierroksen, DM:n ja DR:n laatu	20 %	4,5	4,8
Tekniset turvaportit ja epäonnistumisen takaisinkytkentä	20 %	4,6	4,8
Täydellinen koodi ja riippuvuussulkeuma	15 %	4,6	4,9
Ohjeiden tiheys ja noudatettavuus	10 %	2,8	4,5
Tilapalautus ja todistusaineiston täsmäytys	10 %	4,2	4,7
Painotettu tulos	100 %	84,2	95,5

Laskentatapa:

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

Deep Recon: vahvin vastaväite

Vastaväite: V4 on jo niin perusteellinen, että uusi versio olisi lähinnä kosmeettinen muutos.

Vastaus: ongelma ei ole sääntöjen teoreettinen kattavuus vaan niiden käytännön noudatettavuus. Kun pääohje, tekninen menettely ja artefaktimallit ylläpitävät samoja sääntöjä rinnakkain, syntyy helposti paikallisesti oikein näyttävä mutta kokonaisuutena ristiriitainen tila. Pitkät vastaukset myös kuluttavat tilaa, joka pitäisi varata varsinaiselle koodille ja todistusaineistolle.

Kantava oletus: käyttäjä haluaa hallittavan yksin toimivan työnkulun, ei teeskenneltyä usean agentin samanaikaista ajamista. Lisäksi ilman todellista suoritusympäristöä käännöksen tai testien läpimenoa ei voi rehellisesti luvata.

Pienin kumoava testi: V4.1:n suunnittelu on epäonnistunut, jos yksikin seuraavista tapahtuu:

1. Gem väittää testien menneen läpi ilman suoritusympäristöä.
2. Gem keksii puuttuvan paikallisen rajapinnan ja väittää projektin kääntyvän.
3. Bugikorjaus muuttaa julkista sopimusta ilman rakenteellista esivarmistusta.
4. Toimitus katkeaa tiedoston keskeltä, mutta tila merkitään valmiiksi.
5. Tavilya ei ole käytettävissä, mutta Gem väittää suorittaneensa search_depth=advanced-haun.

Lopullinen suositus

Valinta: Solo-Engine V4.1 Final.

V4 kannattaa säilyttää kokeellisen työn perustana, mutta pitkäaikaiseksi Gem-konfiguraatioksi V4.1 on parempi. Sen ratkaiseva parannus ei ole uusien sääntöjen lisääminen, vaan päällekkäisten sääntöjen purkaminen, pääohjeen omavaraisuuden vahvistaminen ja ajonaikaisten rajojen tekeminen yksiselitteisiksi.

Käyttöönotossa kannattaa jakaa paketti näin:

Tiedosto	Sijainti	Tehtävä
00-solo-engine-system.md	Gemin ohjeet	Reititys, ehdottomat säännöt, kyvykkyysrajat
10-ana-solo.md	Tietopankki	Tutkimus, arvon erottelu, päätösmatriisi ja Deep Recon
20-ana-bmad.md	Tietopankki	Skenaariot, roolitarkistus, toteutus- ja varmennussykli
30-artifacts.md	Tietopankki	Plan-, ADR-, varmennus- ja palautusmallit
40-three-pass-reading.md	Tietopankki	Kolmen lukukierroksen menetelmä

Vanhoja, samaa tarkoitusta palvelevia V4-tiedostoja ei pidä pitää yhtä aikaa ladattuina, koska ristiriitaiset palautumat voivat heikentää ohjeiden johdonmukaista käyttöä.

Jos ympäristöön myöhemmin lisätään Gemini API:n hallinnoitu agentti, MCP-yhteys tai pysyvä koodisandbox, oikea ratkaisu on erillinen Runtime Adapter. Työkalukuvausten kasauttaminen Gemin pääohjeeseen ei korvaa todellista integraatiota.