V4.1 Final strammer inn Solo-Engine: færre regler, tydeligere grenser

Kort vurdering

V4 har et godt utgangspunkt: Den tar tak i noen av de vanligste svakhetene i AI-støttet utviklingsarbeid — påståtte verktøykall som aldri skjedde, tester som ikke er kjørt, ufullstendige kodeutdrag presentert som ferdige leveranser og ADR-er som blir «godkjent» uten tilstrekkelig belegg.

Anbefalingen er likevel å ikke ta V4 i bruk uendret. Den foreslåtte etterfølgeren, Solo-Engine v4.1 Final, forsøker å gjøre systemet mer etterprøvbart ved å samle de viktigste sperrene i hovedinstruksen og flytte detaljerte prosedyrer og maler til kunnskapsbasen.

Det sentrale grepet er enkelt: Et system bør ikke hevde mer enn miljøet faktisk gjør mulig å dokumentere.

Hva V4 allerede løser

V4 har flere klare styrker:

• Den skiller mellom /ana-solo for analyse og beslutningsarbeid, og /ana-bmad for implementasjon og verifisering.
• Den bruker et skille mellom FACT, INFERENCE, ASSUMPTION og UNKNOWN, slik at antakelser ikke presenteres som dokumenterte forhold.
• Den sier eksplisitt at søk, filsystem, Git, kompilering og testkjøring ikke kan oppfinnes gjennom en prompt.
• Den skiller mellom å levere komplette kildefiler og å kunne dokumentere at koden faktisk bygger og passerer tester.
• Den innfører kontrollpunkter som preflight, feilhåndtering med tilbakepress og avstemming mellom plan, leveransepakke og verifikasjon.

V4s bruk av BMAD bør imidlertid beskrives presist. BMADs egen dokumentasjon omtaler agenter, ferdigheter og arbeidsflyter som konkrete mekanismer, inkludert egne testarbeidsflyter.11014 En enkelt Gem kan derfor bruke BMAD-inspirert rolleorkestrering, men bør ikke hevde at flere uavhengige agenter faktisk har kjørt parallelt uten at en slik runtime finnes.

Hvor V4 fortsatt er uklar

Hovedinstruksen kan ikke lene seg for tungt på kunnskapsbasen

Kritiske regler — som forbudet mot å dikte opp verifikasjon, krav til komplette filer og grensene for verktøybruk — bør stå i selve hovedinstruksen. Det er ikke sikkert at alle detaljer i en opplastet kunnskapsbase blir hentet inn og brukt i hver eneste respons.

Mange regler kan gi svakere, ikke sterkere, etterlevelse

V4 gjentar til dels regler om status, avhengigheter, ADR-er og ferdigkriterier på tvers av flere dokumenter. Det øker risikoen for motstridende status eller at en viktig regel overses i et langt svar.

V4.1 Final forsøker derfor å skille mellom:

• ufravikelige regler i hovedinstruksen
• arbeidsprosedyrer i kunnskapsbasen
• sporbare maler for plan, ADR, verifikasjonslogg og statusrapport

«Automatisk løkke» må ha en faktisk grense

En instruks om automatisk arbeid gir ikke i seg selv tilgang til bakgrunnsjobber, vedvarende terminal eller videre arbeid etter at samtalen er avsluttet. I V4.1 Final begrenses løkker til:

• inneværende svar eller økt
• brukerens eksplisitte autorisasjon
• verktøy som faktisk er tilgjengelige
• et definert antall reelle implementerings- og verifikasjonsforsøk

Når ingen ekte utfører eller kompilator er tilgjengelig, skal status stoppe ved WAITING_VERIFICATION — ikke ved «ferdig».

«Null avhengigheter» må bety noe konkret

Begrepet kan ellers blandes sammen med fravær av runtime, tredjepartspakker eller manglende lokale filer. V4.1 Final deler det opp:

• ingen uoppgitte avhengigheter
• normalt ingen nye tredjepartsavhengigheter
• alle nye lokale avhengigheter skal følge med leveransen
• språk-runtime, SDK, operativsystem og vertsplattform er dokumenterte miljøforutsetninger

Det er en viktig forskjell: Kildekode kan leveres komplett uten at systemet samtidig kan garantere et bestemt SDK, en kompilator eller et eksternt driftsmiljø.

Leveranse er ikke det samme som ferdigstillelse

Den viktigste statusendringen i V4.1 Final er å skille tre spørsmål som ofte blandes sammen:

Statusområde	Spørsmål
DELIVERY_STATUS	Er alle nødvendige nye eller endrede filer levert?
VERIFICATION_STATUS	Er bygg, test eller annen kontroll faktisk utført?
ENGINEERING_STATUS	Kan arbeidet med rimelighet omtales som teknisk ferdig?

For et nytt prosjekt betyr «komplett kode» at hele det minste kjørbare prosjektet leveres: konfigurasjon, inngangspunkt, kildefiler, tester, lokale moduler og nødvendig verifikasjonsoppsett.

I et eksisterende prosjekt er kravet annerledes: Alle endrede og nye filer skal leveres i sin helhet, mens uendrede filer som brukeren allerede har lagt ved, ikke trenger å gjentas. Hvis en manglende eksisterende fil eller et API er avgjørende for at løsningen skal bygge, skal systemet be om grunnlaget i stedet for å gjette grensesnittet.

Tavily må være en reell kapasitet, ikke en påstand

Tavily dokumenterer search_depth=advanced som et alternativ for høy relevans og mer presise, detaljerte søk, med høyere ventetid som avveining.2411 Det er nyttig som en kapasitetsregel, men bare dersom Tavily faktisk er koblet til i den aktuelle økten.

V4.1 Final legger derfor opp til en enkel sannhetsregel:

• Er Tavily tilgjengelig, kan systemet bruke parameteren i tråd med det faktiske verktøyskjemaet.
• Er Tavily ikke tilgjengelig, må systemet bruke andre reelt tilgjengelige kilder eller opplyse om at det ikke kan utføre søket.
• Det er ikke tillatt å skrive at et «advanced»-søk er utført bare fordi prompten nevner det.

Det samme prinsippet gjelder nettlesing, MCP, filskriving, Git-operasjoner og kodekjøring.

Vurderingsmatrise: fra V4 til V4.1

Den interne konfigurasjonsvurderingen i forslaget gir V4 84,2 av 100 og V4.1 Final 95,5 av 100. Dette er ikke et runtime-benchmark, men en manuell, vektet vurdering av hvor godt konfigurasjonen dekker kravene.

Dimensjon	V4	V4.1 Final
Verktøygrenser og etterrettelighet	4,0	4,8
Analyse, beslutningsmatrise og motprøving	4,5	4,8
Tekniske sperrer og håndtering av feil	4,6	4,8
Komplett kode og avhengighetslukking	4,6	4,9
Instruksjonstetthet og etterlevelse	2,8	4,5
Statusgjenoppretting og bevisavstemming	4,2	4,7

Den foreslåtte konklusjonen er derfor at forbedringen ikke først og fremst kommer av flere regler. Den kommer av mindre duplisering, skarpere definisjoner og bedre avgrensning mot den faktiske kjøreflaten.

Minimumstester som kan avsløre om oppsettet feiler

Et slikt system bør tåle enkle negative tester. Konfigurasjonen er ikke robust hvis den:

1. hevder at kode er testet når ingen utfører finnes
2. finner opp et manglende lokalt grensesnitt og hevder at løsningen kan kompilere
3. endrer en offentlig signatur uten å utvide preflight-kontrollen
4. stopper midt i en fil, men markerer leveransen som komplett
5. hevder å ha brukt Tavily med search_depth=advanced uten tilgang til Tavily

Enhver av disse feilene betyr at grensen mellom intensjon og faktisk dokumentert handling fortsatt er for svak.

Endelig anbefaling

Velg Solo-Engine v4.1 Final.

V4 bør beholdes som grunnlag, fordi den allerede har en sterk forsknings-, beslutnings- og ingeniørsløyfe. Men den bør strammes inn før langsiktig bruk:

• samle sannhetsregler i hovedinstruksen
• reduser gjentakelser på tvers av dokumenter
• avgrens automatisering til den aktive, autoriserte og verktøydekkede økten
• skill mellom kodeleveranse, verifikasjon og teknisk ferdigstillelse
• beskriv enkelt-Gem-arbeid som rollebasert BMAD-inspirasjon, ikke som en faktisk fleragent-runtime

Hvis løsningen senere flyttes til en plattform med vedvarende kode-sandkasse, MCP eller administrerte agenter, bør den få en egen runtime-adapter. Det er bedre enn å fylle hovedinstruksen med beskrivelser av verktøy systemet kanskje ikke har.