Foreldet kontekst og å starte på nytt

Utdatert kontekst oppstår når de gjenopptatte verktøyresultatene ikke lenger samsvarer med virkeligheten. Vanlige utløsere:

• En kollega redigerte de samme filene mellom sesjonene.
• En migrering endret databaseskjemaet modellen hadde lagret i konteksten.
• En oppgradering av en avhengighet endret et API modellen leste tidligere.
• Et byggartefakt eller testresultat som ble hentet tidligere, er nå foreldet.

Faren er at modellen fortsetter selvsikkert basert på utdaterte fakta og produserer endringer som er i konflikt med den aktuelle kodebasen.

De har to virkemidler for å håndtere en sesjon som har blitt gammel:

• --resume <name> fortsetter den navngitte sesjonen og spiller av hele den lagrede historikken.
• fork_session oppretter en gren fra et felles punkt – nyttig for å utforske et alternativ uten å forstyrre originalen.

Begge arver de gamle verktøyresultatene. Når kodebasen har drevet betydelig, er ingen av dem ideelle. Noen ganger er en ny sesjon med et strukturert sammendrag bedre enn å gjenoppta, fordi det tvinger frem ny innhenting av alle fakta mot den aktuelle virkeligheten.

Still ett spørsmål: Har de faktiske forholdene endret seg siden sesjonen ble registrert?

• Lite eller ingen endring (De tok en pause på én time, og ingen andre har endret repoet) → --resume er et godt og rimelig valg.
• Betydelig endring (det har gått flere dager, sammenslåinger er gjennomført, eller skjemaet er migrert) → start på nytt og oppsummer målet igjen. La deretter modellen hente inn aktuelle verktøyresultater på nytt.

Dette er en pålitelighetsbeslutning for konteksthåndtering – domene D5 på eksamen.

«Oppsummer på nytt» betyr at De viderefører hensikten og beslutningene, men forkaster de frosne verktøyresultatene slik at de kan hentes inn på nytt. Skriv et kort, strukturert sammendrag av hvor oppgaven står, og åpne deretter en ren sesjon med sammendraget som åpningsledetekst.

Modellen kjører så Read, Grep og Bash mot den aktuelle kodebasen – uten et utdatert øyeblikksbilde som kan villede den.

Progressiv oppsummering innebærer tap av informasjon: den gjør tall, prosenter og datoer vage. Når sammendraget må bevare nøyaktige verdier – en versjonslås, et radantall, en frist eller en ordre-ID – bør De ikke flette dem inn i løpende tekst.

Flytt dem til en separat «saksfakta»-blokk som bevares ordrett, utenfor det fortellende sammendraget. Sammendraget kan komprimere historien; faktablokken forblir nøyaktig.

I en ny sesjon er fremgangsmåten enkel: undersøk før De endrer. Bruk det trinnvise mønsteret – Grep etter inngangspunkter, Read filene, Grep etter bruk og Read forbrukerne – slik at hver endring bygger på det aktuelle innholdet.

Dette er også grunnen til at Edit bruker en kontrakt om unikt treff: Hvis filen har endret seg og den forventede teksten ikke lenger samsvarer på en unik måte, mislykkes endringen tydelig i stedet for å ødelegge filen. Kjør Read på nytt og prøv igjen.

/compact komprimerer den aktuelle samtalen for å frigjøre kontekstplass. Det er nyttig, men innebærer den samme risikoen for tap av informasjon: Tall og datoer kan bli vage. Det løser ikke problemet med foreldelse – de komprimerte faktaene stammer fortsatt fra de opprinnelige innhentingene.

Å starte på nytt er annerledes: De forkaster de gamle verktøyresultatene fullstendig og utleder dem på nytt direkte. Bruk /compact for en lang, men fortsatt nøyaktig sesjon; start på nytt når det underliggende systemet har gått videre.

Denne leksjonen om foreldelse har paralleller til design av flere agenter. Underagenter arver ikke koordinatorens samtalehistorikk – all kontekst må sendes eksplisitt i hver underagent-ledetekst.

Den samme disiplinen hjelper Dem: Når De gir en ny sesjon (eller en underagent) et strukturert sammendrag sammen med en ordrett faktablokk, gjør De med hensikt det som gjenopptakelse gjør utilsiktet – men De kontrollerer nøyaktig hvilke fakta som overlever, og tvinger frem ny, direkte innhenting av resten.

Før De gjenopptar en utdatert sesjon, bør De gå gjennom dette kontrollpunktet:

• Endringer? Har repoet, skjemaet eller avhengighetene blitt endret siden registreringen? Hvis ja → velg helst en ny sesjon.
• Oppsummer målet, beslutningene som er tatt, og gjenværende TODO-er.
• Bevar nøyaktige tall, datoer og ID-er i en ordrett faktablokk.
• Hent inn på nytt direkte: Grep → Read før enhver Edit.
• Bekreft mot den aktuelle tilstanden, ikke den huskede.

Det er rimelig å gjenoppta når ingenting har endret seg; det er billig forsikring å starte på nytt når det har skjedd.

Viktigste punkter:

• Gjenopptatte sesjoner spiller av frosne verktøyresultater fordi modellen ikke har noen egen tilstand og trekker slutninger basert på hele den lagrede historikken.
• Når systemet har drevet (sammenslåinger, migreringer eller oppgraderinger av avhengigheter), er resultatene utdaterte og kan føre til selvsikre, men feilaktige endringer.
• Når endringene er betydelige, bør De starte på nytt og oppsummere igjen i stedet for å bruke --resume eller fork_session, som begge arver de gamle øyeblikksbildene.
• Bevar nøyaktige tall, datoer og ID-er i en ordrett saksfaktablokk; oppsummering gjør dem vage.
• Hent inn data direkte på nytt (Grep → Read) før enhver Edit; /compact sparer plass, men løser ikke problemet med foreldelse.