V4.1 ska göra Solo-Engine mer ärlig om verktyg, testning och färdig kod

Bedömningen i korthet

V4 har rätt grundidé, men bör inte tas i drift oförändrad. Versionen löser flera centrala trovärdighetsproblem: den förbjuder påhittade verktygsanrop och testresultat, skiljer kodfragment från en faktisk komplett leverans och hindrar att ADR-beslut får status som godkända utan underlag.

Den största svagheten är i stället styrningen: regler, statusar och villkor upprepas i flera dokument. Det riskerar att späda ut de viktigaste kraven. Slutrekommendationen är därför Solo-Engine v4.1 Final: behåll kedjan forskning → beslut → implementation → verifiering, men lägg de icke förhandlingsbara reglerna i Gem-instruktionen och flytta detaljerade rutiner och mallar till kunskapsbasen.

Vad V4 redan gör väl

• Den skiljer mellan /ana-solo för analys och /ana-bmad för ingenjörsarbete.
• Den håller isär FACT, INFERENCE, ASSUMPTION och UNKNOWN.
• Den förbjuder modellen att låtsas ha sökt på webben, kört kod, skrivit filer eller använt Git.
• Den skiljer leverans av komplett kod från bevis på att koden faktiskt kompilerar och testerna passerar.
• Den inför scenarioklassning, Algorithm-Fit, Preflight, felåterkoppling och State Reconcile.
• Den behandlar ADR som ett beslut med livscykel, inte som dekorativ dokumentation.
• Den tillåter sidindelning av långa leveranser, men bara mellan kompletta filer.

BMAD:s officiella dokumentation beskriver agenter, skills, arbetsflöden och testflöden som konkreta mekanismer i ramverket. Därför bör en ensam Gem beskrivas som BMAD-inspirerad rollorkestrering – inte som en faktisk driftmiljö med flera oberoende agenter. 11014

De viktigaste ändringarna i V4.1

1. Kärnreglerna ska stå i huvudinstruktionen

Det går inte att utgå från att alla filer i en kunskapsbas alltid hämtas in fullt ut i varje svar. Krav på komplett kod, sanningsenlig verifiering, verktygsgränser och villkor för ”klart” måste därför finnas direkt i huvudinstruktionen.

2. Automatisk loop får inte betyda bakgrundskörning

En prompt kan inte ge en Gem tillgång till beständiga terminaler, bakgrundsjobb eller arbete mellan sessioner. I V4.1 betyder automatisk loop endast en avgränsad cykel:

• i den aktuella sessionen,
• inom användarens uttryckliga behörighet,
• med verktyg som faktiskt är exponerade,
• med en tydlig budget för omförsök,
• och med status WAITING_VERIFICATION när någon verklig exekveringsmiljö saknas.

3. ”Noll beroenden” får en ingenjörsmässig definition

Uttrycket kan annars misstolkas. V4.1 delar upp kravet i:

• inga odeklarerade beroenden,
• inga nya tredjepartsberoenden som standard,
• alla nya lokala beroenden ska levereras komplett,
• språkets runtime, SDK, operativsystem och värdplattform är uttryckliga miljöförutsättningar.

4. Komplett kod beror på projekttyp

För ett nytt projekt ska leveransen innehålla den minsta fullständiga projektmängden: byggkonfiguration, startpunkt, källkod, test, nödvändiga resurser och verifieringsväg.

I ett befintligt projekt ska varje ny eller ändrad fil levereras i sin helhet. Oförändrade basfiler som användaren redan lämnat behöver inte skrivas ut igen. Saknas däremot en befintlig fil eller ett gränssnitt som krävs för kompilering, ska assistenten be om det i stället för att hitta på ett API.

5. Leverans, verifiering och ingenjörsstatus hålls isär

V4.1 använder tre separata spår:

• DELIVERY_STATUS: om alla filer har levererats,
• VERIFICATION_STATUS: om en faktisk kompilering eller testkörning har skett,
• ENGINEERING_STATUS: om arbetet verkligen får beskrivas som färdigt.

Att kod har skrivits ut är alltså inte samma sak som att projektet är färdigverifierat.

Tavily ska vara en verklig kapacitet – inte en formulering i prompten

Tavily har ett dokumenterat alternativ, search_depth=advanced, för detaljorienterade frågor med hög relevans. Det innebär dock högre latens och kan också innebära högre kostnad. Parametern ska bara nämnas som använd när ett verkligt Tavily-verktyg eller ett anslutet API faktiskt finns tillgängligt. 2411

Om Tavily inte är åtkomligt ska assistenten använda den forskning eller de filer som faktiskt finns och tydligt redovisa nedgraderingen. Den får inte hävda att en avancerad Tavily-sökning genomförts enbart för att instruktionen nämner den.

Beslutsmatris: V4 mot V4.1 Final

Bedömningen nedan är en statisk konfigurationsgranskning, inte ett benchmark där Gem har körts i produktion.

Dimension	Vikt	V4	V4.1 Final
Driftsgränser och verkliga verktyg	25 %	4,0	4,8
Tre läsningar, DM och DR	20 %	4,5	4,8
Ingenjörsskydd och felåterkoppling	20 %	4,6	4,8
Komplett kod och beroendeslutning	15 %	4,6	4,9
Instruktionstäthet och följsamhet	10 %	2,8	4,5
Statusåterställning och bevisavstämning	10 %	4,2	4,7
Viktad totalsumma	100 %	84,2	95,5

Beräkningen använder en viktad femgradig skala, normaliserad till 100:

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

Valet: Solo-Engine v4.1 Final.

Tvåan: V4 fungerar som underlag för interna experiment, men har för mycket överlappande styrning för att vara en långsiktig standard.

Minsta test som kan fälla slutversionen

Den föreslagna utformningen bör underkännas eller förstärkas om något av följande sker:

1. Assistenten påstår att kod är testad trots att ingen exekveringsmiljö finns.
2. Den hittar på ett saknat lokalt gränssnitt och säger att projektet ska kompilera.
3. En buggfix ändrar ett offentligt kontrakt utan att få en strukturell Preflight-granskning.
4. Leveransen avbryts mitt i en fil, men får ändå status COMPLETE.
5. Tavily saknas, men assistenten hävdar att den har använt search_depth=advanced.

Slutlig rekommendation

V4.1 Final bör införas med en enkel princip: färre upprepade regler, hårdare sanningskrav och tydligare gränser för vad Gem faktiskt kan göra.

Om lösningen senare får en hanterad agentmiljö, MCP-anslutningar eller en beständig kodsandbox bör funktionerna läggas i en särskild Runtime Adapter. De bör inte byggas in som påstådda förmågor i själva Gem-prompten.

Det gör systemet mer användbart i praktiken: analysen kan vara ambitiös, kodleveransen komplett och arbetsflödet strukturerat – utan att modellen låtsas ha kört verktyg, testat program eller drivit flera agenter när den inte har gjort det.