Låt inte Copilot döpa er styrmodell – granska förslagen till repository-egenskaper

Förslaget sparar skrivtid, inte styrbeslutet

I en släppnotis den 15 september 2026 meddelar GitHub att Copilot kan föreslå tillåtna värden när en ny custom property skapas på organisations- eller enterprise-nivå. Funktionen är public preview för Copilot Business och Copilot Enterprise. GitHub visar bland annat en multi-select-egenskap för FedRAMP och en single-select-egenskap för internet-facing med värden som yes och no. Ett förslag kan accepteras med ett klick.

Klicket är inte samma sak som att värdet passar er organisation. critical kan betyda att systemet har hög kundpåverkan, att incidentberedskap krävs eller bara att ett team upplever repositoryt som viktigt. Om ett ruleset senare riktas mot critical blir den språkliga oklarheten en teknisk skillnad: två repositories med samma risk kan få olika skydd.

Custom properties är enligt GitHub metadata som kan användas för att rikta repositories med rulesets. Det är därför ordningen spelar roll. Först taxonomi, sedan klassning, sist regel. Den närliggande guiden om secret-scanning som mergekontroll visar hur en konkret ruleset-konsekvens kan provas. Här stannar arbetet ett steg tidigare: ni kontrollerar att egenskapen verkligen pekar ut rätt repositories innan något ruleset förlitar sig på den.

Skriv ett kontrakt med fyra fält

Börja inte med listan över värden. Skriv först ett kort kontrakt för egenskapen. Fyra fält räcker för ett första prov:

Undvik namn som blandar två axlar. public-critical packar både exponering och verksamhetskritikalitet i samma värde. När en intern men kritisk tjänst dyker upp måste ni antingen lägga till kombinationer eller klassificera fel. Två egenskaper, exempelvis exposure och service_tier, är lättare att äga och kombinera.

GitHubs dokumentation för repository-egenskaper anger fyra typer: text, single select, multi select och true/false boolean. Välj boolean bara när frågan verkligen har två stabila svar. Välj single select när exakt ett tillstånd gäller. Multi select passar flera samtidiga etiketter, men gör ruleset-logiken svårare att resonera om. Fri text bör inte bära en styrande kategori om stavning och synonymer kan ändra urvalet.

Prova förslaget på tre repositories

Skapa inte egenskapen brett direkt. Välj tre testfall som tvingar fram olika resonemang:

1. Det typiska: ett repository där teamet väntar sig ett självklart värde.
2. Gränsfallet: ett repository med delad drift, oklar ägare eller både publik och intern yta.
3. Avvikaren: exempelvis ett arkiv, en mall, ett infrastruktur-repository eller kod utan egen produktionstrafik.

Låt två personer klassificera de tre exemplen var för sig med exakt samma definition. Spara repository, valt värde, en mening med motivering och vilket ruleset-utfall värdet skulle ge. Sex klassningar är inte statistik över hela organisationen; de är ett snabbt sätt att avslöja att orden tolkas olika.

repository,granskare,värde,motivering,ruleset_utfall
payments-api,A,external,"publik produktionsendpoint",strict-review
payments-api,B,external,"publik produktionsendpoint",strict-review
docs-template,A,not-applicable,"mall utan egen drift",none

Godkänn provet bara om båda granskarna väljer samma värde för varje repository, motiveringarna hänvisar till definitionen och ruleset-utfallet blir begripligt. Vid oenighet ändrar ni definition eller värden och kör samma tre fall igen. Ändra inte klassningen enbart för att få provet grönt; då döljs just den tvetydighet som provet ska hitta.

Kontrollera standardvärde och ändringsrätt

GitHub låter organisationsägare göra en egenskap obligatorisk för alla repositories och ange ett standardvärde. Repositories utan ett uttryckligt värde ärver då standarden. Det finns också ett val som kräver ett uttryckligt användarvärde. Dessa lägen svarar på olika problem: ett standardvärde ger täckning, medan ett explicit val ger bevis på att någon har klassificerat repositoryt.

Prova därför ett fjärde scenario innan utrullning: ett nytt repository utan satt värde. Kontrollera om det är säkrare att det hamnar i en restriktiv standardklass, stoppas tills ägaren har valt eller uttryckligen lämnas utanför det planerade rulesetet. Värdet unknown kan vara användbart om det leder till en kö för granskning. Det är farligt om unknown i praktiken betyder att inget skydd gäller och ingen följer upp.

Dokumentationen beskriver även möjligheten att låta repository-aktörer sätta och uppdatera värdet när de har rätt finmaskig behörighet. Slå bara på det om ägarskapet är avsiktligt. Om ett team kan sänka sin egen skyddsnivå genom att byta egenskapsvärde behöver ändringen granskas eller övervakas som vilken policyändring som helst. Följ samma tänkesätt som i AI-kreatörs granskningsordning för AI-genererad kod: kontrollera först avgränsning och risk, därefter detaljer och stil.

Koppla rulesetet först efter en torrkörning

När namn, typ, värden, standard och ägare har klarat provet kan ni göra en torrkörning av det tänkta urvalet. Sök eller filtrera repositories på egenskapsvärdet och exportera eller dokumentera träfflistan. Markera tre kategorier: ska omfattas och gör det, ska inte omfattas och gör det inte samt överraskningar som kräver ny klassning.

Jämför sedan listan med rulesetets konsekvens. Ett krav på två godkännanden, en mergekö eller en blockerande säkerhetskontroll kan vara rimligt för applikationskod men fel för ett arkiverat repository. Taxonomin är klar först när urvalet kan förklaras utan att någon behöver känna till vem som råkade skapa värdena.

GitHub låter enterprise- och organisationsägare styra funktionens tillgänglighet med policyn Repository custom property suggestions Copilot. Policyn avgör om förslagsfunktionen kan användas; den ersätter inte er taxonomiägare. Om teamen ännu saknar definition, ansvarig och ett reproducerbart prov är det bättre att lämna förslaget oanvänt än att göra ett snabbt namn till långlivad styrning.