Forældet kontekst og en ny start

Forældet kontekst opstår, når genoptagne værktøjsresultater ikke længere stemmer overens med virkeligheden. Almindelige udløsere er:

• En kollega har redigeret de samme filer mellem sessionerne.
• En migrering har ændret databaseskemaet, som modellen havde gemt.
• En opgradering af en afhængighed har ændret en API, som modellen tidligere læste.
• Et build-resultat eller testoutput, der blev gemt tidligere, er nu forældet.

Faren er, at modellen fortsætter selvsikkert ud fra forældede fakta og producerer ændringer, der er i konflikt med den aktuelle kodebase.

Du har to muligheder for at komme videre, når en session er blevet gammel:

• --resume <name> fortsætter den navngivne session og afspiller hele den gemte historik.
• fork_session opretter en gren fra et fælles punkt – nyttigt til at udforske et alternativ uden at forstyrre originalen.

Begge arver de gamle værktøjsresultater. Når kodebasen har ændret sig markant, er ingen af dem ideelle. Nogle gange er en ny session med en struktureret opsummering bedre end at genoptage, fordi det tvinger alle fakta til at blive hentet igen i forhold til den aktuelle virkelighed.

Stil ét spørgsmål: Har den faktiske grundlag ændret sig, siden sessionen blev gemt?

• Lille eller ingen ændring (du holdt pause i en time, og ingen andre har rørt repositoriet) → --resume er fint og billigt.
• Betydelig ændring (der er gået dage, fletninger er landet, skemaet er migreret) → start forfra, og opsummer målet igen. Lad derefter modellen hente aktuelle værktøjsresultater på ny.

Det er en beslutning om pålidelig kontexthåndtering – domæne D5 til eksamen.

"Opsummer på ny" betyder: før hensigten og beslutningerne videre, men fjern de fastfrosne værktøjsresultater, så de kan hentes igen. Skriv en kort, struktureret opsummering af opgavens status, og åbn derefter en ren session med opsummeringen som den indledende prompt.

Modellen kører derefter Read, Grep og Bash mod den aktuelle kodebase – uden et forældet øjebliksbillede, der kan vildlede den.

Progressiv opsummering medfører tab: den gør tal, procentdele og datoer upræcise. Når din opsummering skal bevare nøjagtige værdier – en fastlåst version, et antal rækker, en deadline eller et ordre-id – skal du ikke flette dem ind i brødteksten.

Flyt dem til en separat blok med "sagsfakta", der bevares ordret, uden for den fortællende opsummering. Opsummeringen kan komprimere historien; faktablokken forbliver nøjagtig.

I en ny session er disciplinen enkel: undersøg, før du ændrer. Brug det trinvise mønster – Grep efter indgangspunkter, Read filerne, Grep efter anvendelser, og Read forbrugerne – så hver ændring er baseret på det aktuelle indhold.

Det er også grunden til, at Edit bruger en kontrakt om entydigt match: Hvis filen har ændret sig, og den forventede tekst ikke længere matcher entydigt, mislykkes ændringen tydeligt i stedet for at ødelægge filen. Kør Read igen, og prøv på ny.

/compact komprimerer den aktuelle samtale for at frigøre kontekstplads. Det er nyttigt, men medfører den samme risiko for tab: tal og datoer kan blive upræcise. Det løser ikke forældelse – de komprimerede fakta stammer stadig fra de oprindelige optagelser.

At starte forfra er anderledes: Du kasserer de gamle værktøjsresultater fuldstændigt og udleder dem igen live. Brug /compact til en lang, men stadig korrekt session; start forfra, når det underliggende system er kommet videre.

Denne lektion om forældelse minder om design til flere agenter. Underagenter arver ikke koordinatorens samtalehistorik – al kontekst skal overdrages eksplicit i hver underagents prompt.

Den samme praksis hjælper dig: Når du giver en ny session (eller en underagent) en struktureret opsummering plus en faktablok, der er ordret, gør du bevidst det, som genoptagelse gør utilsigtet – men du styrer præcis, hvilke fakta der overlever, og tvinger resten til at blive hentet live igen.

Udfør dette tjek, før du genoptager en forældet session:

• Ændringer? Er repositoriet, skemaet eller afhængighederne ændret siden optagelsen? Hvis ja → hæld til en ny session.
• Opsummer målet, de trufne beslutninger og de resterende TODO'er.
• Bevar nøjagtige tal, datoer og id'er i en faktablok, der er ordret.
• Hent på ny live: Grep → Read før enhver Edit.
• Kontrollér mod den aktuelle tilstand, ikke den huskede.

Det er billigt at genoptage, når intet har flyttet sig; det er billig forsikring at starte forfra, når noget har.

Vigtigste pointer:

• Genoptagne sessioner afspiller fastfrosne værktøjsresultater, fordi modellen ikke har nogen tilstand og ræsonnerer ud fra hele den gemte historik.
• Når systemet har ændret sig (fletninger, migreringer, opgraderinger af afhængigheder), er resultaterne forældede og kan føre til selvsikre, men forkerte ændringer.
• Når ændringerne er betydelige, skal du starte forfra og opsummere på ny i stedet for at bruge --resume eller fork_session, som begge arver de gamle øjebliksbilleder.
• Bevar nøjagtige tal, datoer og id'er i en ordret faktablok; opsummering gør dem upræcise.
• Hent live på ny (Grep → Read), før du bruger Edit; /compact sparer plads, men fjerner ikke forældelsen.