Solo-Engine v4.1 Final: minder regeldruk, scherpere grenzen

Oordeel: V4 niet ongewijzigd uitrollen

V4 kiest de juiste richting. De versie bouwt een serieuze keten van onderzoek, besluitvorming, implementatie en verificatie. Vooral de scheiding tussen feiten, aannames en onbekenden, plus het verbod op gefingeerde toolaanroepen en testruns, zijn essentiële verbeteringen.

Toch is een rechtstreekse uitrol van V4 niet verstandig. Het probleem is niet dat de configuratie te weinig controles bevat, maar dat cruciale regels op meerdere plaatsen terugkomen. Daardoor ontstaat instructiedichtheid: de Gem moet dezelfde status-, afhankelijkheids- en voltooiingsregels in verschillende documenten interpreteren. Dat vergroot juist de kans op een gemiste of tegenstrijdige regel.

De aanbevolen eindversie is daarom Solo-Engine v4.1 Final. Die behoudt de veiligheidsrails van V4, maar maakt de hoofdinstructie zelfstandiger en begrenst de runtimeclaims veel strakker.

Wat V4 al goed doet

• Het onderscheidt /ana-solo voor analyse en besluitvorming van /ana-bmad voor engineering en oplevering.
• Het isoleert FACT, INFERENCE, ASSUMPTION en UNKNOWN, zodat conclusies niet ongemerkt als feiten worden gepresenteerd.
• Het verbiedt het verzinnen van webzoekopdrachten, code-uitvoering, bestanden, Git-acties, testresultaten en bronmateriaal.
• Het maakt terecht onderscheid tussen complete code uitschrijven en aantonen dat die code daadwerkelijk compileert of tests doorstaat.
• Het introduceert preflightcontroles, een beslismatrix, tegenonderzoek via Deep Recon en druk terug op het proces bij herhaald falen.
• Het behandelt ADR’s niet als decoratie: een besluit wordt pas geaccepteerd wanneer de vereiste verificatie en afstemming werkelijk zijn vastgelegd.
• Het voorkomt dat lange codebestanden halverwege worden afgebroken en vervolgens als complete oplevering worden verkocht.

Ook de BMAD-positionering is in de kern juist. De officiële BMAD-documentatie beschrijft agents, skills, workflows en testprocessen als afzonderlijke mechanismen. Een enkele Gem kan die rollen gebruiken als beoordelingsperspectieven, maar mag niet doen alsof er daadwerkelijk meerdere onafhankelijke agents draaien. De juiste omschrijving is daarom BMAD-inspired role orchestration, niet een volwaardige multi-agentruntime.11014

De belangrijkste reparaties in v4.1

1. Harde regels horen in de hoofdinstructie

Een kennisbank is nuttig voor werkwijzen en sjablonen, maar niet gegarandeerd volledig beschikbaar in iedere respons. Daarom moeten de niet-onderhandelbare regels ook in de Gem-instructie zelf staan:

• geen fictieve tools of uitvoerresultaten;
• geen claim dat code is getest zonder uitvoeringsbewijs;
• volledige levering van nieuwe en gewijzigde bestanden;
• duidelijke voorwaarden voor COMPLETE;
• expliciete grenzen van beschikbare tools en sessies.

De kennisbank blijft de juiste plek voor gedetailleerde SOP’s, artefacttemplates en uitgebreide controlelijsten.

2. Een automatische loop is geen achtergrondproces

Een prompt kan geen permanente terminal, achtergrondtaak of sessie-overstijgende uitvoering creëren. In v4.1 betekent een automatische loop uitsluitend een begrensde cyclus:

• binnen de huidige sessie;
• binnen de expliciet verleende autorisatie;
• met werkelijk beschikbare tools;
• met een vastgesteld herhaalbudget;
• en met stoppen op WAITING_VERIFICATION als er geen echte uitvoerder beschikbaar is.

Dat onderscheid is fundamenteel: een model kan een verificatiecommando voorbereiden, maar niet beweren dat het commando is uitgevoerd wanneer er geen uitvoeromgeving bestaat.

3. ‘Nul afhankelijkheden’ krijgt een bruikbare definitie

De term was te dubbelzinnig. V4.1 splitst hem op in controleerbare eisen:

• geen niet-gedeclareerde afhankelijkheden;
• standaard geen nieuwe externe packages;
• alle nieuwe lokale afhankelijkheden worden volledig meegeleverd;
• runtime, compiler, SDK, besturingssysteem en hostplatform zijn expliciete omgevingsvoorwaarden.

Zo wordt voorkomen dat ‘zero dependency’ ten onrechte suggereert dat broncode zonder runtime of platform kan functioneren.

4. Volledige code hangt af van het soort project

Voor een nieuw project betekent compleet: alle bestanden leveren die samen een minimaal uitvoerbare projectsluiting vormen, waaronder configuratie, entrypoint, broncode, tests en noodzakelijke lokale modules.

Voor een bestaand project betekent compleet: elk nieuw of gewijzigd bestand volledig uitschrijven. Ongewijzigde bestanden die de gebruiker al heeft aangeleverd hoeven niet opnieuw te worden afgedrukt. Ontbreekt echter een bestaand interfacebestand dat nodig is voor compilatie, dan moet de Gem om dat bestand vragen in plaats van interfaces te raden.

5. Levering, verificatie en engineeringstatus blijven losgekoppeld

Dit is een van de sterkste onderdelen van v4.1. Drie vragen krijgen elk hun eigen status:

Vraag	Status
Zijn alle toegezegde bestanden volledig geleverd?	DELIVERY_STATUS
Is daadwerkelijk gebouwd of getest?	VERIFICATION_STATUS
Mag de oplossing als engineeringwerk afgerond gelden?	ENGINEERING_STATUS

Volledige code betekent dus niet automatisch een bewezen werkende oplossing. Zonder daadwerkelijke toolchainrun blijft de verificatie bijvoorbeeld NOT_RUN of STATIC_CHECKED, en de engineeringstatus WAITING_VERIFICATION.

Toolclaims: Tavily alleen noemen als Tavily echt beschikbaar is

De voorgestelde regels rond Tavily zijn goed zolang ze capability-based blijven. search_depth=advanced is inderdaad een Tavily-zoekoptie voor gedetailleerde en precisiegerichte zoekopdrachten; daarbij hoort een afweging tussen hogere relevantie en meer latency of kosten.2411

Maar een configuratie-instructie verleent die mogelijkheid niet. De Gem mag pas zeggen dat Tavily is gebruikt wanneer de tool of gekoppelde interface in de sessie werkelijk beschikbaar is. Is dat niet zo, dan moet zij terugvallen op de aanwezige web- of bestandsbronnen en die degradatie expliciet melden.

Beoordelingsmatrix

De onderstaande score is een configuratie-audit, geen benchmark waarin de Gem daadwerkelijk is uitgevoerd.

Dimensie	Gewicht	V4	v4.1 Final
Runtimegrenzen en eerlijk gebruik van tools	25%	4,0	4,8
Kwaliteit van drie leesrondes, DM en DR	20%	4,5	4,8
Engineeringveiligheid en terugdruk bij falen	20%	4,6	4,8
Complete code en afhankelijkheidssluiting	15%	4,6	4,9
Instructiedichtheid en navolgbaarheid	10%	2,8	4,5
Statusherstel en bewijsafstemming	10%	4,2	4,7
Gewogen totaal	100%	84,2	95,5

De berekening gebruikt een gewogen score op een schaal van 0 tot 5:

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

De winst van v4.1 komt dus niet vooral uit meer regels. Zij komt uit minder herhaling, een zelfstandige hoofdinstructie en scherpere definities van wat de Gem daadwerkelijk kan doen.

Eindoordeel

De keuze: Solo-Engine v4.1 Final.

V4 is een goede interne proefversie, maar v4.1 is geschikter als duurzame configuratie. De kern blijft behouden: evidence-first analyse, een beslismatrix, adversarial review, preflightchecks, complete bestanden en een eerlijk verificatieregister.

De doorslaggevende verbetering is geloofwaardigheid. Een Gem mag plannen, code genereren, statisch controleren en een verificatieroute geven. Zij mag alleen niet doen alsof zij tools, agents, werkruimtes of testresultaten bezit die in de actuele sessie niet aantoonbaar beschikbaar zijn.

Als er later een beheerde agentruntime, MCP-koppeling of persistente codesandbox wordt toegevoegd, is de juiste volgende stap een aparte Runtime Adapter. De oplossing is dan niet om de hoofdinstructie verder vol te stapelen met hypothetische toolbeschrijvingen.

Praktische acceptatietests voor de eindversie

De configuratie faalt op haar kernbelofte als een van deze situaties optreedt:

1. Zonder uitvoerder claimt de Gem dat een build of tests zijn geslaagd.
2. Bij een ontbrekende lokale interface verzint zij een contract en presenteert dat als compileerbaar.
3. Een bugfix wijzigt een publieke handtekening zonder op te schalen naar structurele preflightcontrole.
4. Na een afgebroken bestandsuitvoer markeert zij de levering als COMPLETE.
5. Zonder Tavily-tool beweert zij een zoekopdracht met search_depth=advanced te hebben uitgevoerd.

Deze vijf gevallen zijn voldoende als minimale regressietest voor de belangrijkste ontwerpprincipes van v4.1.