Skapa en syntetisk krasch med ett unikt incident-id och ett känt fel. Spara exakt vad Sentry-canvasen visar, be Copilot formulera en reproduktion innan någon kod ändras och kräv sedan samma test rött före fixen och grönt efter. Pull requesten är bara redo för granskning när incident, basrevision, reproduktionskommando, testutfall och diff går att knyta ihop. Saknas nödvändig kontext ska agenten stoppa och be om den.
Vad GitHub faktiskt har släppt
I sin veckonotis den 18 september 2026 presenterar GitHub en Sentry-canvas i GitHub Copilot-appen. Den beskrivna kedjan är att granska fel, stackspår och relaterad kontext, arbeta med Copilot för att undersöka orsaken, validera en fix och förbereda en pull request. Notisen anger däremot inte ett obligatoriskt fältschema för incidenten, hur fixen valideras eller att varje rapport har tillräckligt underlag. Läs därför orden som ett arbetsflöde, inte som ett kvalitetsbevis.
En canvas är enligt GitHubs dokumentation en delad interaktiv yta där både människa och agent kan arbeta mot samma tillstånd. GitHub lyfter just struktur, iteration och verifiering som skäl att använda en canvas. Det är användbart i incidentarbete: du kan inspektera synliga artefakter i stället för att enbart lita på agentens sammanfattning. Featured canvases hittas under Customize och Canvas; vissa kräver en plugin. Kontrollera därför först att Sentry-ytan faktiskt går att öppna i en ny session och att den är ansluten till rätt testprojekt.
Bygg en krasch med känt facit
Prova inte första gången mot en skarp incident vars orsak du ännu inte känner. Lägg i stället ett avgränsat fel i ett testprojekt, exempelvis att en funktion anropar profile.name.trim() när profile.name är null. Märk körningen med ett unikt värde som mb-sentry-2026-09-21-a, skicka ett syntetiskt anrop som utlöser felet och notera commit-SHA, miljö, tidpunkt och förväntad stackrad.
Facit ska rymmas i en mening: ”Nullvärdet passerar valideringen och kraschar på trim(); korrekt fix avvisar eller hanterar null före anropet.” Nu kan du skilja en riktig undersökning från en trovärdig gissning. Om canvasen pekar på en annan fil eller föreslår bred felinfångning som döljer signalen har den inte visat orsaken, även om applikationen slutar kasta just det undantaget.
Frys incidentens indata innan du frågar efter en fix
Ta en skärmbild eller export av canvasen och skriv en liten inventering innan Copilot får redigera. Minimikolumnerna är incident-id, feltyp och meddelande, översta relevanta stackram, observerad commit eller release, miljö samt de metadata som behövs för att återskapa anropet. Hemligheter, persondata och fullständiga produktionspayloads hör inte hemma i provet; använd syntetiska värden.
Be sedan agenten svara på fyra frågor utan att ändra kod: vilken kodrad tros vara första felande rad, vilken indata krävs, vilket kommando reproducerar felet lokalt och vilken observation skulle motbevisa hypotesen? Svaren ska peka tillbaka på synlig incident- eller repositorykontext. Ett allmänt råd som ”lägg till en null-kontroll” är ingen spårbar analys.
Stoppa sessionen om canvasen inte visar eller kan koppla incidenten till rätt revision, relevant stackram och den indata som krävs för en säker reproduktion. Be om den saknade uppgiften och öppna inte en PR på antagandet att senaste main motsvarar koden som kraschade. Samma disciplin används i AI-kreatörs metod för AI-agentfel i produktion när spårningen är ofullständig.
Kräv samma test före och efter
Gör hypotesen körbar med ett regressionstest som använder den syntetiska indatan. Före ändringen ska testet misslyckas av rätt skäl: samma felklass och kodväg som i incidenten, inte ett konfigurationsfel eller saknad beroendemodul. Spara kommandot, exitkoden och den relevanta felraden. Ett test som är grönt redan före diffen bevisar ingenting om kraschen.
Låt därefter Copilot föreslå minsta ändring som gör testet grönt utan att ändra testets omslutning eller namn. Kör exakt samma kommando efter ändringen och kör dessutom den närmaste befintliga testsviten. Om agenten ändrar både implementationen och förväntningen så att problemet definieras bort ska du återställa testet och stoppa. För mer om hur bevisvärdet hålls intakt, använd guiden om att testa AI-genererad kod.
| Bevispunkt | Godkänt | Stoppa när |
|---|---|---|
| Incident | Unikt id, stackram, revision och syntetisk indata är synliga | Revision eller relevant kodkontext saknas |
| Reproduktion | Ett sparat kommando ger rätt fel före diffen | Felet kan inte återskapas eller ger annan felklass |
| Ändring | Diffen är avgränsad till den kända orsaken | Bred felinfångning eller orelaterade filer tillkommer |
| Eftertest | Samma regressionstest och närliggande svit passerar | Testet skrivs om för att acceptera beteendet |
| PR | Beskrivningen länkar incident, kommandon, utfall och risk | Granskaren måste lita på en chattsammanfattning |
Granska diffen innan canvasen får skapa PR
En validerad fix är mer än en grön ruta. Läs diffen med samma frågor som i en vanlig kodgranskning: ändras endast den felande vägen, bevaras kontraktet för giltig indata, introduceras tyst databortfall och hanteras felet på rätt lager? Markera varje fil som incidentstyrd eller orelaterad. Orelaterade formatteringar, namnbyten och beroendeuppdateringar ska bort ur den här pull requesten.
PR-beskrivningen ska innehålla sex konkreta fält: incident-id, basrevision, rotorsak, reproduktionskommando, före- och efterutfall samt kvarvarande risk. Lägg även in den exakta testrevisionen. Då kan en granskare köra om beviset utan canvasens sessionshistorik. En länk till Sentry räcker inte om läsaren saknar behörighet eller om incidentdata senare gallras.
Acceptansprotokoll för en syntetisk incident
Källor
- GitHub Changelog: GitHub Copilot weekly releases – September 14 – publiceringsdatumet och Sentry-canvasens beskrivna kedja från felrapport och stackspår till undersökning, validerad fix och förberedd pull request.
- GitHub Docs: Working with canvas extensions in the GitHub Copilot app – canvas som delad arbetsyta, synlig verifiering, navigeringen via Customize och villkoret att vissa canvases kräver plugin.
Uppgifterna kontrollerades mot GitHubs primärkällor den 21 september 2026. Acceptansprotokollet, stoppregeln och kraven på före- och eftertest är AI-kreatörs föreslagna metod, inte GitHub-krav.