Föråldrad kontext och att börja om

Kontexten är inaktuell när de återupptagna verktygsresultaten inte längre stämmer med verkligheten. Vanliga orsaker:

• En kollega redigerade samma filer mellan sessionerna.
• En migrering ändrade databasschemat som modellen hade sparat.
• En uppdatering av ett beroende ändrade ett API som modellen läste tidigare.
• Ett byggartefakt eller testresultat som sparades tidigare är nu föråldrat.

Risken är att modellen fortsätter självsäkert utifrån inaktuella fakta och skapar ändringar som strider mot den aktuella kodbasen.

Du har två sätt att återhämta dig när en session har blivit gammal:

• --resume <name> fortsätter den namngivna sessionen och spelar upp hela den sparade historiken.
• fork_session skapar en gren från en gemensam punkt – användbart när du vill utforska ett alternativ utan att påverka originalet.

Båda ärver de gamla verktygsresultaten. När kodbasen har förändrats betydligt är inget av alternativen idealiskt. Ibland är en ny session med en strukturerad sammanfattning bättre än att återuppta, eftersom det tvingar fram en ny hämtning av alla fakta mot den aktuella verkligheten.

Ställ en fråga: har den faktiska grunden ändrats sedan sessionen sparades?

• Små eller inga förändringar (du tog paus i en timme och ingen annan rörde repot) → --resume fungerar bra och är kostnadseffektivt.
• Betydande förändringar (flera dagar har gått, sammanslagningar har gjorts eller schemat har migrerats) → starta på nytt och sammanfatta målet igen. Låt sedan modellen hämta aktuella verktygsresultat på nytt.

Detta är ett tillförlitlighetsbeslut för kontexthantering – område D5 på provet.

"Sammanfatta på nytt" betyder att du tar med avsikten och besluten, men tar bort de frysta verktygsresultaten så att de kan hämtas igen. Skriv en kort och strukturerad sammanfattning av uppgiftens aktuella läge och öppna sedan en ren session med sammanfattningen som första instruktion.

Modellen kör därefter Read, Grep och Bash mot den aktuella kodbasen – utan någon inaktuell ögonblicksbild som kan vilseleda den.

Stegvis sammanfattning innebär informationsförlust: den gör tal, procentsatser och datum vaga. När sammanfattningen måste bevara exakta värden – en versionslåsning, ett radantal, en tidsfrist eller ett order-ID – ska du inte skriva in dem i löptexten.

Flytta dem till ett separat "ärendefakta"-block som bevaras ordagrant, utanför den berättande sammanfattningen. Sammanfattningen kan komprimera berättelsen, medan faktablocket förblir exakt.

I en ny session är principen enkel: undersök innan du ändrar. Använd det inkrementella mönstret – Grep efter ingångspunkter, Read filerna, Grep efter användningar och Read användarna – så att varje ändring grundas på aktuellt innehåll.

Det är också därför Edit använder ett kontrakt med unik matchning: om filen har förändrats och den förväntade texten inte längre matchar unikt, misslyckas redigeringen tydligt i stället för att förstöra filen. Kör Read igen och försök på nytt.

/compact komprimerar den aktuella konversationen för att frigöra kontextutrymme. Det är användbart, men medför samma risk för informationsförlust: tal och datum kan bli vaga. Det löser inte problemet med inaktuell information – de komprimerade fakta kommer fortfarande från de ursprungliga hämtningarna.

Att börja på nytt är något annat: du förkastar de gamla verktygsresultaten helt och hämtar fram dem igen i realtid. Använd /compact för en lång men fortfarande korrekt session; börja på nytt när det underliggande systemet har förändrats.

Den här lektionen om inaktuell information liknar design av system med flera agenter. Underagenter ärver inte koordinatorns konversationshistorik – all kontext måste skickas uttryckligen i varje underagents instruktion.

Samma noggrannhet hjälper dig: när du ger en ny session (eller en underagent) en strukturerad sammanfattning tillsammans med ett ordagrant faktablock gör du medvetet det som återupptagning gör av misstag – men du styr exakt vilka fakta som överlever och tvingar fram en ny hämtning av resten.

Innan du återupptar en inaktuell session, gå igenom detta kontrollsteg:

• Förändringar? Har repot, schemat eller beroendena ändrats sedan informationen sparades? Om ja → välj helst en ny session.
• Sammanfatta målet, fattade beslut och återstående TODO-punkter.
• Bevara exakta tal, datum och ID:n i ett ordagrant faktablock.
• Hämta på nytt i realtid: Grep → Read före alla Edit.
• Verifiera mot det aktuella tillståndet, inte det du minns.

Det är billigt att återuppta när inget har förändrats och billig försäkring att börja på nytt när det har gjort det.

Viktigaste slutsatserna:

• Återupptagna sessioner spelar upp frysta verktygsresultat eftersom modellen inte har något eget tillstånd och resonerar utifrån hela den sparade historiken.
• När systemet har förändrats (sammanslagningar, migreringar eller uppdateringar av beroenden) är resultaten inaktuella och kan leda till självsäkra men felaktiga ändringar.
• När förändringarna är betydande ska du börja på nytt och sammanfatta igen i stället för att använda --resume eller fork_session, eftersom båda ärver de gamla ögonblicksbilderna.
• Bevara exakta tal, datum och ID:n i ett ordagrant faktablock för ärendet; sammanfattning gör dem vaga.
• Hämta aktuella data på nytt (Grep → Read) före alla Edit; /compact sparar utrymme men botar inte inaktuell information.