Hovedpoenget: Skill kostnadene før du reduserer testingen

En gjennomgang av BMAD V4.2 peker på at unødvendige kostnader kan oppstå når hvert lite steg behandles som en egen testfase, testkommandoen også klargjør miljøet, og store mengder testutdata gjentas eller sendes videre i samtalen.

Anbefalingen er derfor ikke å svekke isolasjonen eller kutte ut viktige tester. Den er å skille mellom miljøklargjøring, validering og dokumentasjon, og å velge testomfang etter hva som faktisk er endret.

Dette er en skrivebordsbasert metodegjennomgang med forslag til regelendringer. Den innebærer ikke at regler er endret, tester kjørt, programvare distribuert eller planer godkjent.

Hva dokumentasjonen viser – og ikke viser

Ingen generell regel om full testmatrise etter hvert plaster

BMADs globale regler sier at relevant validering skal utføres for hvert steg. De sier ikke at hver kodeendring må kjøres gjennom en full matrise i containere. Ingeniørreglene åpner også for godkjent miljø på vertsmaskinen eller i en container, og ber om at testene velges ut fra endringens omfang. Se 02-bmad-core.md og 01-bmad-engineer-core.md.

Et strengere krav finnes i en tidligere prosjektplan, der det står at endringer skal verifiseres fysisk etter hvert steg. Det står i eksportens planbestemmelser. Det er derfor mer presist å si at prosjektplanen kan ha gjort testingen mer finmasket enn de globale reglene krever – ikke at BMAD generelt pålegger ny installasjon og full testmatrise etter hver endring.

En observert installasjon, men ingen måling av gjentatte nedlastinger

En enkelt logg viser at 14 pakker ble installert før testhendelsen. Avslutningen oppgir 198,1 MiB for 31 pakker totalt. Det dokumenterer ikke at 198,1 MiB ble lastet ned, eller pakket ut på nytt, i denne kjøringen – og heller ikke at det skjer hver gang.

Operasjonen startet rundt kl. 14.04.04, og testhendelsen begynte kl. 14.04.09.330. Det gir omtrent 5,3 sekunder før teststart. Testene på pakkenivå tok rundt 2,72 sekunder, mens hele operasjonen varte i omtrent åtte sekunder. Loggen gjør det ikke mulig å fordele forberedelsestiden nøyaktig mellom installasjon, oppstart, kompilering og kontroll av mellomlagring.

Konklusjonen bør derfor være avgrenset: Testinngangen har en synlig forberedelseskostnad, men kildene tallfester ikke hvor mye av tiden selve installasjonen står for.

Testutdataene kan være en like stor utfordring som installasjonen

Installasjonsdelen av loggen er på rundt 16 linjer. Testdelen gjentar derimot flere typer hendelser – blant annet start- og beståttmeldinger både som tekst og som strukturerte hendelser. Den tilgjengelige loggen inneholder også rundt 76 000 tegn med utelatelsesmarkører.

Å skjule installasjonsutdata vil derfor ikke alene løse problemet. Samtidig kan man ikke ut fra en samtaleeksport eller et grensesnitt slå fast at alt som vises, faktisk ble tatt med i modellens forespørsel. Det er heller ikke grunnlag for å beregne tokenkostnaden fra materialet som foreligger.

Kompilering og testing er skilt i noen kjøringer, men ikke nødvendigvis i livsløpet

Eksporten inneholder flere separate kall for kompilering og testing, med ulike containeridentiteter. Likevel bruker testinngangen en Go-testkommando som kan innebære byggeforberedelser.

Selve isolasjonsskriptet er ikke tilgjengelig i materialet. Derfor kan man ikke fastslå om installasjonen skjer i skriptet, i containerens inngangspunkt eller i et annet lag. Det er rimelig å skille mellom tre påstander: installasjon er observert i én logg, flere containerkjøringer finnes i historikken, og gjentatt installasjon ved hver kjøring er ennå ikke verifisert.

Fire livsløp som bør holdes fra hverandre

Reglene blir lettere å følge når de skiller mellom:

1. Isolasjon: Én testkjøring skal ikke forurense kildekoden, vertsmaskinen eller neste kjøring.
2. Verktøymiljø: Kompilator, systembiblioteker og godkjente avhengigheter endres når miljøet endres – ikke ved hver endring i programlogikken.
3. Validering: Testene som må kjøres på nytt, bestemmes av hvilke endringer som gjør tidligere bevis ugyldige.
4. Dokumentasjon: Resultater skal registreres, men en vanlig oppdatering av status bør ikke i seg selv gjøre alle funksjonstester ugyldige.

Prosjektplanen krever både kontroll av oppdatert dokumentasjon og gjentatte oppdateringer av kjørehistorikken. Dette kan gi en nyttig beskyttelse mot uautoriserte endringer. Men hvis kontraktsgrunnlaget og testresultatene ikke holdes atskilt, kan det oppstå en runddans: Resultatet registreres, dokumentasjonen endres, testene kjøres på nytt, og resultatet registreres igjen. Kildene viser en slik strukturell risiko, ikke at en uendelig løkke faktisk har oppstått.

Det er viktig å skille mellom to ting: Et uforanderlig verktøymiljø kan gjenbrukes uten at et skittent testmiljø beholdes. Og et nytt, midlertidig testmiljø trenger ikke å innebære at verktøyene installeres på nytt.

Sikkerhetskrav bør dessuten beskrives som grenser som kan kontrolleres, heller enn som «absolutt sikkerhet». For eksempel kan kravene forby ekstern nettverkstilgang og uautorisert varig lagring, samtidig som de tillater begrenset midlertidig lagring og bestemte testartefakter. En godkjent kjøring med Go race detector dekker bare stiene som faktisk ble kjørt; den beviser ikke at programmet aldri har datakappløp. 9

En tredelt modell for testing

Dette er en anbefalt arbeidsmodell, ikke en beskrivelse av funksjonalitet som allerede er innført.

Nivå	Formål	Når det brukes
L0 – låst kjøremiljø	Inneholder godkjente verktøy, systembiblioteker og avhengigheter. Miljøidentitet, verktøyversjoner og sikkerhetsinnstillinger registreres.	Forberedes på nytt når miljøgrunnlaget endres – ikke fordi programkoden endres.
L1 – løpende utviklingstester	Kjører relevante enhets- og modultester, og nødvendig målrettet regresjon, for en meningsfull endring.	Kjøres for hver semantisk endringspakke i godkjent isolasjon.
L2 – kontroll før leveranse	Kontrollerer den fryste kandidaten med fasens påkrevde testmatrise, separat måling av RSS uten instrumentering og avstemming av dokumentasjon.	Kjøres ved faseavslutning eller før godkjent levering.

L0: Gjenbruk miljøet, ikke et uryddig testoppsett

• Bruk et miljø med fast identitet. Testinngangen skal ikke installere systempakker, hente containerbilder eller løse avhengigheter på nett.
• Hvis miljøet, verktøyene eller avhengighetene mangler, skal kjøringen stoppe og melde at miljøet ikke er klart. Den skal ikke koble seg på nettet for å fylle hullene automatisk.
• Gi klargjøring en egen godkjenning og et eget tidsbudsjett. Ikke skjul den inne i testkommandoen.
• Behold krav om skrivebeskyttet kildekode, stengt ekstern nettilgang, minste nødvendige rettigheter og begrenset midlertidig lagring. Ikke monter inn legitimasjon, kontrollsokler for vertsmaskinen eller irrelevante kataloger.
• Skill mellomlagring etter prosjekt, verktøykjede, plattform og tillitsgrense. At et mellomlager treffes, betyr bare at beregningsresultater gjenbrukes – ikke at testene har bestått.

L1: Lettvektskjøring betyr ikke kjøring utenfor sandkassen

Den dokumenterte godkjenningen avgrenser valideringen til offline-kjøring i isolerte containere. Den gir derfor ikke i seg selv grunnlag for å gjøre tester på vertsmaskinen til standardvalg.

Et bedre standardvalg er en raskere testsløyfe med de samme sikkerhetsbegrensningene. Kjøring på vertsmaskinen bør kreve særskilt godkjenning og tydelige vilkår – ikke innføres i stillhet for å spare tid.

L2: Kontroller en fryst kandidat, ikke installer miljøet på nytt

• Knytt fasekontrollen til et fast øyeblikksbilde av kildekode og tester, avhengigheter, kjøremiljø, konfigurasjon og valideringssett.
• Mål RSS i en egen kjøring uten instrumentering. Registrer resultat for datakappløp og ressursbruk separat. Den tidligere prosjektplanen har allerede et slikt krav for ressurskontroll.
• Hvis relevante innganger endres etter sluttkontrollen, skal gamle resultater ikke uten videre brukes på den nye kandidaten. Det kan være tilstrekkelig å kjøre de berørte testene på nytt dersom det kan dokumenteres at resten av bevisene fortsatt gjelder. Hvis ikke må omfanget utvides.

Når bør testomfanget endres?

En nyttig regel bør styres av hva som har endret seg, ikke av antall filer eller verktøykall.

Endring eller hendelse	Anbefalt handling	Ikke utløst automatisk
Implementasjon og tester for én og samme atferd er ferdige	Kjør relevant L1-validering én gang	Ny L0-bygging eller full L2-matrise
Låser, samtidige oppslag, avbryting eller frigjøring av ressurser endres	Legg til målrettede tester for datakappløp og livsløp i den aktuelle endringspakken	Å utsette all kontroll for datakappløp til slutt
Grensesnitt mellom moduler eller delte avhengigheter endres	Utvid testene til berørte kallkjeder	Å teste bare filen som ble endret uten å vurdere påvirkningen
Verktøykjede, systemavhengighet eller isolasjonsinnstilling endres	Kontroller L0 på nytt og vurder hvilke bevis som fortsatt gjelder	Å installere manglende komponenter i testinngangen
Kandidaten fryses før faselevering	Kjør fasens påkrevde L2-matrise	Å gjenta hele matrisen etter hvert mellomliggende plaster
Bare kjørehistorikk eller statusnotater oppdateres	Kontroller dokumentasjonsfullstendighet og krav til dokumentasjon	Å kjøre funksjonstester og RSS-målinger på nytt automatisk

En semantisk endringspakke betyr her en atferdsendring som kan valideres selvstendig, sammen med tilhørende tester. Den kan bestå av flere presise kodeendringer. L1 må være bestått før arbeidet går videre til en avhengig pakke. Målet er verken å samle opp en ubegrenset mengde utestet arbeid eller å dele jobben mekanisk etter hvert verktøykall.

Forslag til regelendringer

1. Presiser den globale regelen for testing

Regelen i 02-bmad-core.md, del 3, kan erstattes med en bestemmelse som slår fast at:

• Fysisk validering betyr faktisk kjøring i et godkjent miljø med etterprøvbare resultater. Det betyr ikke at grunnmiljøet må bygges på nytt etter hver endring.
• Før arbeidet starter, defineres meningsfulle endringspakker, fasegrenser, relevante tester og vilkår for å utvide testomfanget. Hver pakke får L1; fasekontrollen bruker L2.
• Miljøklargjøring, kompilering, testkjøring og opprydding skal ha egne innganger, budsjetter og resultater. Testinngangen skal ikke installere systempakker, hente containerbilder eller laste ned avhengigheter i det skjulte.
• Manglende miljø, kompilering, testfeil, tidsavbrudd, null testtreff, ødelagte bevis og mislykket opprydding skal registreres som ulike typer feil. Påkrevde kontroller må være bestått før fasen kan gå videre.
• Et rødt testresultat stanser fremdrift mot neste fase, men ikke feilsøking og retting innenfor den godkjente arbeidsrammen. Å gjenta samme feilende kommando, fjerne tester eller lempe på sikkerheten er ikke en godkjent snarvei til grønt resultat.
• Resultater knyttes til de faktiske inngangene og testdekningen. De kan bare gjenbrukes når det er dokumentert at inngangene og vilkårene fortsatt gjelder. Ved gjenopptak av en eldre oppgave må godkjenning og gjeldende bevis bekreftes på nytt.

2. La ingeniørreglene følge samme nivåinndeling

I 01-bmad-engineer-core.md, del 3, bør det presiseres at ingeniørmodus følger L0/L1/L2 uten automatisk å gjøre hver redigering til en full leveransekontroll.

Hver validering bør forklare hva som ble endret, hvorfor de valgte testene er relevante, og hva som eventuelt gjorde det nødvendig å utvide omfanget. Filantall alene er ikke et risikomål. Hvis kompilering og testkjøring må holdes adskilt, må testfasen bruke et identifiserbart kompilert artefakt i stedet for å starte en ny, skjult byggeprosess.

Tidsbudsjettene bør deles mellom kompilering, testing og opprydding, og en eventuell samlet tidsgrense må omfatte alle trinnene den skal dekke – inkludert oppstart og en rimelig avslutningsfrist. Endringer i sikkerhetsgrenser, miljøklargjøring og utrulling av programvare må ha separate godkjenninger. Å opprette en testcontainer er ikke det samme som å distribuere programvaren.

3. Innfør en egen avtale for testutdata

Fullstendige diagnostikklogger og sammendraget som sendes inn i samtalekonteksten, bør behandles som to forskjellige ting. Rålogger kan lagres som sporbare artefakter i en godkjent kanal med tydelig grense for lagringstid og størrelse. De bør ikke automatisk sendes videre i sin helhet.

Et foreløpig forslag er å begrense sammendrag ved beståtte tester til 2 KiB og sammendrag ved feil til 8 KiB. Dette er startverdier for utprøving – ikke en etablert standard eller en grense som er målt fram i denne gjennomgangen.

Sammendraget bør minst oppgi identiteten til testen, nivået, hvor mange tester som ble truffet og fullført, feil og hoppede tester, varighet, avslutningsstatus og resultatet av oppryddingen. Ved for lange utdata må forkortingen merkes tydelig; et ufullstendig sammendrag må ikke presenteres som komplett.

Strukturerte testhendelser bør parses, telles og slås sammen. Det er ikke nok å fjerne tekstlinjer som inneholder ord som «feil». Manglende sluttmelding, parsefeil, null treff, uforklarte hopp eller utilgjengelige testartefakter skal hindre godkjenning – også når prosessens returkode er null. Miljøoppstart er ikke bevis på at funksjonene virker, men diagnostikk ved mislykket oppstart må fortsatt beholdes.

Denne filtreringen må skje før resultatet legges inn i modellens samtalehistorikk. Å be modellen «ignorere loggen», eller å skjule den i brukergrensesnittet, oppfyller ikke det kravet.

4. Oppdater planmalen slik at kravene ikke må gjettes

Verifikasjonsmatrisen i implementation-plan.template.md bør angi nivå, utløsende hendelse, forventet dekning og hva kontrollen ikke dekker. Hvert punkt bør også oppgi godkjent miljø, om nødvendig klargjøringsmateriell finnes, tidsbudsjett for klargjøring, kompilering, testing og opprydding, samt hvilke innganger som gjør tidligere bevis ugyldige.

Malen bør dessuten si hvor sammendrag og råartefakter lagres, hvor lenge de beholdes, og hva som skal skje ved miljøfeil, testfeil eller mangelfull dokumentasjon. Skilj kontraktsgrunnlaget fra resultatene: Å lagre et resultat skal ikke i seg selv starte den samme funksjonsvalideringen på nytt. Samtidig må kontroll av fullstendige filsignaturer beholdes for å beskytte mot uautoriserte endringer.

Praktisk rekkefølge for innføring

1. Oppdater regler og planmal først. Definer L0, L1 og L2, hva som regnes som en endringspakke, hvor mye utdata som kan sendes videre, og når bevis må fornyes. Kontroller både Roo- og native innganger, slik at de ikke tolker reglene ulikt.
2. Endre deretter testkjøreren. Forhåndsklargjør verktøyene, skill klargjøring fra testing, og lag strukturerte sammendrag. Å dempe installasjonsutdata alene er ikke tilstrekkelig.
3. Test endringen i liten skala. Kjør flere endringspakker i samme miljø. Kontroller at testfasen ikke installerer systempakker, at vanlige statusoppdateringer ikke utløser L2, og at sammendragene holder seg innenfor grensen. Prøv også med vilje å utløse testfeil, null treff, tidsavbrudd og mislykket opprydding – alle skal fortsatt hindre godkjenning.

Et allerede vedtatt styringsdokument fordeler ansvaret for vertsplattformen. Denne forbedringen bør ikke gjeninnføre en endeløs sirkel der en agent må bevise sine egne fullmakter på nytt, eller gi inntrykk av at en tekstlig regelendring alene har verifisert klientens faktiske oppførsel.

Kort sagt: Fjern unødvendig miljøklargjøring og støyende utdata før du vurderer å redusere testfrekvensen. Behold isolasjonen, og ikke kompenser for svakheter i kjøreverktøy eller uklare regler ved å kutte viktig dekning for datakappløp og sikkerhet.

Hovedpoenget: Skill kostnadene før du reduserer testingen

En gjennomgang av BMAD V4.2 peker på at unødvendige kostnader kan oppstå når hvert lite steg behandles som en egen testfase, testkommandoen også klargjør miljøet, og store mengder testutdata gjentas eller sendes videre i samtalen.

Anbefalingen er derfor ikke å svekke isolasjonen eller kutte ut viktige tester. Den er å skille mellom miljøklargjøring, validering og dokumentasjon, og å velge testomfang etter hva som faktisk er endret.

Dette er en skrivebordsbasert metodegjennomgang med forslag til regelendringer. Den innebærer ikke at regler er endret, tester kjørt, programvare distribuert eller planer godkjent.

Hva dokumentasjonen viser – og ikke viser

Ingen generell regel om full testmatrise etter hvert plaster

BMADs globale regler sier at relevant validering skal utføres for hvert steg. De sier ikke at hver kodeendring må kjøres gjennom en full matrise i containere. Ingeniørreglene åpner også for godkjent miljø på vertsmaskinen eller i en container, og ber om at testene velges ut fra endringens omfang. Se 02-bmad-core.md og 01-bmad-engineer-core.md.

Et strengere krav finnes i en tidligere prosjektplan, der det står at endringer skal verifiseres fysisk etter hvert steg. Det står i eksportens planbestemmelser. Det er derfor mer presist å si at prosjektplanen kan ha gjort testingen mer finmasket enn de globale reglene krever – ikke at BMAD generelt pålegger ny installasjon og full testmatrise etter hver endring.

En observert installasjon, men ingen måling av gjentatte nedlastinger

En enkelt logg viser at 14 pakker ble installert før testhendelsen. Avslutningen oppgir 198,1 MiB for 31 pakker totalt. Det dokumenterer ikke at 198,1 MiB ble lastet ned, eller pakket ut på nytt, i denne kjøringen – og heller ikke at det skjer hver gang.

Operasjonen startet rundt kl. 14.04.04, og testhendelsen begynte kl. 14.04.09.330. Det gir omtrent 5,3 sekunder før teststart. Testene på pakkenivå tok rundt 2,72 sekunder, mens hele operasjonen varte i omtrent åtte sekunder. Loggen gjør det ikke mulig å fordele forberedelsestiden nøyaktig mellom installasjon, oppstart, kompilering og kontroll av mellomlagring.

Konklusjonen bør derfor være avgrenset: Testinngangen har en synlig forberedelseskostnad, men kildene tallfester ikke hvor mye av tiden selve installasjonen står for.

Testutdataene kan være en like stor utfordring som installasjonen

Installasjonsdelen av loggen er på rundt 16 linjer. Testdelen gjentar derimot flere typer hendelser – blant annet start- og beståttmeldinger både som tekst og som strukturerte hendelser. Den tilgjengelige loggen inneholder også rundt 76 000 tegn med utelatelsesmarkører.

Å skjule installasjonsutdata vil derfor ikke alene løse problemet. Samtidig kan man ikke ut fra en samtaleeksport eller et grensesnitt slå fast at alt som vises, faktisk ble tatt med i modellens forespørsel. Det er heller ikke grunnlag for å beregne tokenkostnaden fra materialet som foreligger.

Kompilering og testing er skilt i noen kjøringer, men ikke nødvendigvis i livsløpet

Eksporten inneholder flere separate kall for kompilering og testing, med ulike containeridentiteter. Likevel bruker testinngangen en Go-testkommando som kan innebære byggeforberedelser.

Selve isolasjonsskriptet er ikke tilgjengelig i materialet. Derfor kan man ikke fastslå om installasjonen skjer i skriptet, i containerens inngangspunkt eller i et annet lag. Det er rimelig å skille mellom tre påstander: installasjon er observert i én logg, flere containerkjøringer finnes i historikken, og gjentatt installasjon ved hver kjøring er ennå ikke verifisert.

Fire livsløp som bør holdes fra hverandre

Reglene blir lettere å følge når de skiller mellom:

1. Isolasjon: Én testkjøring skal ikke forurense kildekoden, vertsmaskinen eller neste kjøring.
2. Verktøymiljø: Kompilator, systembiblioteker og godkjente avhengigheter endres når miljøet endres – ikke ved hver endring i programlogikken.
3. Validering: Testene som må kjøres på nytt, bestemmes av hvilke endringer som gjør tidligere bevis ugyldige.
4. Dokumentasjon: Resultater skal registreres, men en vanlig oppdatering av status bør ikke i seg selv gjøre alle funksjonstester ugyldige.

Prosjektplanen krever både kontroll av oppdatert dokumentasjon og gjentatte oppdateringer av kjørehistorikken. Dette kan gi en nyttig beskyttelse mot uautoriserte endringer. Men hvis kontraktsgrunnlaget og testresultatene ikke holdes atskilt, kan det oppstå en runddans: Resultatet registreres, dokumentasjonen endres, testene kjøres på nytt, og resultatet registreres igjen. Kildene viser en slik strukturell risiko, ikke at en uendelig løkke faktisk har oppstått.

Det er viktig å skille mellom to ting: Et uforanderlig verktøymiljø kan gjenbrukes uten at et skittent testmiljø beholdes. Og et nytt, midlertidig testmiljø trenger ikke å innebære at verktøyene installeres på nytt.

Sikkerhetskrav bør dessuten beskrives som grenser som kan kontrolleres, heller enn som «absolutt sikkerhet». For eksempel kan kravene forby ekstern nettverkstilgang og uautorisert varig lagring, samtidig som de tillater begrenset midlertidig lagring og bestemte testartefakter. En godkjent kjøring med Go race detector dekker bare stiene som faktisk ble kjørt; den beviser ikke at programmet aldri har datakappløp. 9

En tredelt modell for testing

Dette er en anbefalt arbeidsmodell, ikke en beskrivelse av funksjonalitet som allerede er innført.

Nivå	Formål	Når det brukes
L0 – låst kjøremiljø	Inneholder godkjente verktøy, systembiblioteker og avhengigheter. Miljøidentitet, verktøyversjoner og sikkerhetsinnstillinger registreres.	Forberedes på nytt når miljøgrunnlaget endres – ikke fordi programkoden endres.
L1 – løpende utviklingstester	Kjører relevante enhets- og modultester, og nødvendig målrettet regresjon, for en meningsfull endring.	Kjøres for hver semantisk endringspakke i godkjent isolasjon.
L2 – kontroll før leveranse	Kontrollerer den fryste kandidaten med fasens påkrevde testmatrise, separat måling av RSS uten instrumentering og avstemming av dokumentasjon.	Kjøres ved faseavslutning eller før godkjent levering.

L0: Gjenbruk miljøet, ikke et uryddig testoppsett

• Bruk et miljø med fast identitet. Testinngangen skal ikke installere systempakker, hente containerbilder eller løse avhengigheter på nett.
• Hvis miljøet, verktøyene eller avhengighetene mangler, skal kjøringen stoppe og melde at miljøet ikke er klart. Den skal ikke koble seg på nettet for å fylle hullene automatisk.
• Gi klargjøring en egen godkjenning og et eget tidsbudsjett. Ikke skjul den inne i testkommandoen.
• Behold krav om skrivebeskyttet kildekode, stengt ekstern nettilgang, minste nødvendige rettigheter og begrenset midlertidig lagring. Ikke monter inn legitimasjon, kontrollsokler for vertsmaskinen eller irrelevante kataloger.
• Skill mellomlagring etter prosjekt, verktøykjede, plattform og tillitsgrense. At et mellomlager treffes, betyr bare at beregningsresultater gjenbrukes – ikke at testene har bestått.

L1: Lettvektskjøring betyr ikke kjøring utenfor sandkassen

Den dokumenterte godkjenningen avgrenser valideringen til offline-kjøring i isolerte containere. Den gir derfor ikke i seg selv grunnlag for å gjøre tester på vertsmaskinen til standardvalg.

Et bedre standardvalg er en raskere testsløyfe med de samme sikkerhetsbegrensningene. Kjøring på vertsmaskinen bør kreve særskilt godkjenning og tydelige vilkår – ikke innføres i stillhet for å spare tid.

L2: Kontroller en fryst kandidat, ikke installer miljøet på nytt

• Knytt fasekontrollen til et fast øyeblikksbilde av kildekode og tester, avhengigheter, kjøremiljø, konfigurasjon og valideringssett.
• Mål RSS i en egen kjøring uten instrumentering. Registrer resultat for datakappløp og ressursbruk separat. Den tidligere prosjektplanen har allerede et slikt krav for ressurskontroll.
• Hvis relevante innganger endres etter sluttkontrollen, skal gamle resultater ikke uten videre brukes på den nye kandidaten. Det kan være tilstrekkelig å kjøre de berørte testene på nytt dersom det kan dokumenteres at resten av bevisene fortsatt gjelder. Hvis ikke må omfanget utvides.

Når bør testomfanget endres?

En nyttig regel bør styres av hva som har endret seg, ikke av antall filer eller verktøykall.

Endring eller hendelse	Anbefalt handling	Ikke utløst automatisk
Implementasjon og tester for én og samme atferd er ferdige	Kjør relevant L1-validering én gang	Ny L0-bygging eller full L2-matrise
Låser, samtidige oppslag, avbryting eller frigjøring av ressurser endres	Legg til målrettede tester for datakappløp og livsløp i den aktuelle endringspakken	Å utsette all kontroll for datakappløp til slutt
Grensesnitt mellom moduler eller delte avhengigheter endres	Utvid testene til berørte kallkjeder	Å teste bare filen som ble endret uten å vurdere påvirkningen
Verktøykjede, systemavhengighet eller isolasjonsinnstilling endres	Kontroller L0 på nytt og vurder hvilke bevis som fortsatt gjelder	Å installere manglende komponenter i testinngangen
Kandidaten fryses før faselevering	Kjør fasens påkrevde L2-matrise	Å gjenta hele matrisen etter hvert mellomliggende plaster
Bare kjørehistorikk eller statusnotater oppdateres	Kontroller dokumentasjonsfullstendighet og krav til dokumentasjon	Å kjøre funksjonstester og RSS-målinger på nytt automatisk

En semantisk endringspakke betyr her en atferdsendring som kan valideres selvstendig, sammen med tilhørende tester. Den kan bestå av flere presise kodeendringer. L1 må være bestått før arbeidet går videre til en avhengig pakke. Målet er verken å samle opp en ubegrenset mengde utestet arbeid eller å dele jobben mekanisk etter hvert verktøykall.

Forslag til regelendringer

1. Presiser den globale regelen for testing

Regelen i 02-bmad-core.md, del 3, kan erstattes med en bestemmelse som slår fast at:

• Fysisk validering betyr faktisk kjøring i et godkjent miljø med etterprøvbare resultater. Det betyr ikke at grunnmiljøet må bygges på nytt etter hver endring.
• Før arbeidet starter, defineres meningsfulle endringspakker, fasegrenser, relevante tester og vilkår for å utvide testomfanget. Hver pakke får L1; fasekontrollen bruker L2.
• Miljøklargjøring, kompilering, testkjøring og opprydding skal ha egne innganger, budsjetter og resultater. Testinngangen skal ikke installere systempakker, hente containerbilder eller laste ned avhengigheter i det skjulte.
• Manglende miljø, kompilering, testfeil, tidsavbrudd, null testtreff, ødelagte bevis og mislykket opprydding skal registreres som ulike typer feil. Påkrevde kontroller må være bestått før fasen kan gå videre.
• Et rødt testresultat stanser fremdrift mot neste fase, men ikke feilsøking og retting innenfor den godkjente arbeidsrammen. Å gjenta samme feilende kommando, fjerne tester eller lempe på sikkerheten er ikke en godkjent snarvei til grønt resultat.
• Resultater knyttes til de faktiske inngangene og testdekningen. De kan bare gjenbrukes når det er dokumentert at inngangene og vilkårene fortsatt gjelder. Ved gjenopptak av en eldre oppgave må godkjenning og gjeldende bevis bekreftes på nytt.

2. La ingeniørreglene følge samme nivåinndeling

I 01-bmad-engineer-core.md, del 3, bør det presiseres at ingeniørmodus følger L0/L1/L2 uten automatisk å gjøre hver redigering til en full leveransekontroll.

Hver validering bør forklare hva som ble endret, hvorfor de valgte testene er relevante, og hva som eventuelt gjorde det nødvendig å utvide omfanget. Filantall alene er ikke et risikomål. Hvis kompilering og testkjøring må holdes adskilt, må testfasen bruke et identifiserbart kompilert artefakt i stedet for å starte en ny, skjult byggeprosess.

Tidsbudsjettene bør deles mellom kompilering, testing og opprydding, og en eventuell samlet tidsgrense må omfatte alle trinnene den skal dekke – inkludert oppstart og en rimelig avslutningsfrist. Endringer i sikkerhetsgrenser, miljøklargjøring og utrulling av programvare må ha separate godkjenninger. Å opprette en testcontainer er ikke det samme som å distribuere programvaren.

3. Innfør en egen avtale for testutdata

Fullstendige diagnostikklogger og sammendraget som sendes inn i samtalekonteksten, bør behandles som to forskjellige ting. Rålogger kan lagres som sporbare artefakter i en godkjent kanal med tydelig grense for lagringstid og størrelse. De bør ikke automatisk sendes videre i sin helhet.

Et foreløpig forslag er å begrense sammendrag ved beståtte tester til 2 KiB og sammendrag ved feil til 8 KiB. Dette er startverdier for utprøving – ikke en etablert standard eller en grense som er målt fram i denne gjennomgangen.

Sammendraget bør minst oppgi identiteten til testen, nivået, hvor mange tester som ble truffet og fullført, feil og hoppede tester, varighet, avslutningsstatus og resultatet av oppryddingen. Ved for lange utdata må forkortingen merkes tydelig; et ufullstendig sammendrag må ikke presenteres som komplett.

Strukturerte testhendelser bør parses, telles og slås sammen. Det er ikke nok å fjerne tekstlinjer som inneholder ord som «feil». Manglende sluttmelding, parsefeil, null treff, uforklarte hopp eller utilgjengelige testartefakter skal hindre godkjenning – også når prosessens returkode er null. Miljøoppstart er ikke bevis på at funksjonene virker, men diagnostikk ved mislykket oppstart må fortsatt beholdes.

Denne filtreringen må skje før resultatet legges inn i modellens samtalehistorikk. Å be modellen «ignorere loggen», eller å skjule den i brukergrensesnittet, oppfyller ikke det kravet.

4. Oppdater planmalen slik at kravene ikke må gjettes

Verifikasjonsmatrisen i implementation-plan.template.md bør angi nivå, utløsende hendelse, forventet dekning og hva kontrollen ikke dekker. Hvert punkt bør også oppgi godkjent miljø, om nødvendig klargjøringsmateriell finnes, tidsbudsjett for klargjøring, kompilering, testing og opprydding, samt hvilke innganger som gjør tidligere bevis ugyldige.

Malen bør dessuten si hvor sammendrag og råartefakter lagres, hvor lenge de beholdes, og hva som skal skje ved miljøfeil, testfeil eller mangelfull dokumentasjon. Skilj kontraktsgrunnlaget fra resultatene: Å lagre et resultat skal ikke i seg selv starte den samme funksjonsvalideringen på nytt. Samtidig må kontroll av fullstendige filsignaturer beholdes for å beskytte mot uautoriserte endringer.

Praktisk rekkefølge for innføring

1. Oppdater regler og planmal først. Definer L0, L1 og L2, hva som regnes som en endringspakke, hvor mye utdata som kan sendes videre, og når bevis må fornyes. Kontroller både Roo- og native innganger, slik at de ikke tolker reglene ulikt.
2. Endre deretter testkjøreren. Forhåndsklargjør verktøyene, skill klargjøring fra testing, og lag strukturerte sammendrag. Å dempe installasjonsutdata alene er ikke tilstrekkelig.
3. Test endringen i liten skala. Kjør flere endringspakker i samme miljø. Kontroller at testfasen ikke installerer systempakker, at vanlige statusoppdateringer ikke utløser L2, og at sammendragene holder seg innenfor grensen. Prøv også med vilje å utløse testfeil, null treff, tidsavbrudd og mislykket opprydding – alle skal fortsatt hindre godkjenning.

Et allerede vedtatt styringsdokument fordeler ansvaret for vertsplattformen. Denne forbedringen bør ikke gjeninnføre en endeløs sirkel der en agent må bevise sine egne fullmakter på nytt, eller gi inntrykk av at en tekstlig regelendring alene har verifisert klientens faktiske oppførsel.

Kort sagt: Fjern unødvendig miljøklargjøring og støyende utdata før du vurderer å redusere testfrekvensen. Behold isolasjonen, og ikke kompenser for svakheter i kjøreverktøy eller uklare regler ved å kutte viktig dekning for datakappløp og sikkerhet.