Pochodzenie zmiany i routing ryzyka

Pochodzenie zmiany i routing ryzyka to polityka, która ustala głębokość review, wymagane akceptacje i kontrole wydania dla każdego pull requesta na podstawie tego, czego zmiana dotyka: wrażliwych systemów, klas danych, publicznych kontraktów, plików testów i CI oraz odwracalności, zapisanych w pakiecie dowodów. Autorstwo, ludzkie lub agenta, też jest zapisywane, ale wyłącznie do pomiaru i audytu, nigdy jako sygnał routingu.

Pół roku temu twoja organizacja wprowadziła etykietę ai-generated i powiązała ją z wymogiem dwóch reviewerów. Po miesiącu inżynierowie przestali zaznaczać to pole, bo etykieta oznaczała dzień czekania. W zeszłym tygodniu jednoliniowa, ręcznie napisana zmiana w weryfikacji podpisu webhooka przeszła z jedną akceptacją i to ona położyła produkcję. Etykieta mierzyła nie to, co trzeba, i kierowała zmiany w złą stronę.

Ta strona jest dla CTO lub VP Engineering, który odpowiada na pytanie Q11 scorecardu, oraz dla tech leadów, którzy egzekwują wynik. Nie definiuje manifestu: pola, szablon pull requesta i checker w CI są na stronie pakietu dowodów, jedynego schematu manifestu zmiany w serwisie. Tutaj ustalasz, do czego te pola kierują, jak zachować pochodzenie, żeby nie stało się bramką, i jak udowodnić, że routing działa.

Q11 · Bramki jakości Dowód na maksymalny wynik: metadane intencji, dotkniętego systemu, danych i odwracalności kierują dowodami i imiennymi akceptacjami; autorstwo zostaje do pomiaru.

Co daje polityka pochodzenia i routingu

• Tabelę pole → kontrola, która zamienia każde pole pakietu dowodów w wymagany check, imiennego akceptującego albo kontrolę wydania.
• Trzy klasy, których nie ma w startowej polityce pakietu (dane osobowe, publiczny kontrakt i konfiguracja agentów), razem z wpisami w CODEOWNERS.
• Jednostronicowy szablon change-routing-policy.md do przyjęcia bez zmian.
• Test na fiksturach, który dowodzi, że zmiana w danych osobowych nie przejdzie jako standard.
• Dwie definicje metryk, które używają pochodzenia do pomiaru: wskaźnik ucieczek routingu i pokrycie pochodzenia.
• Trzy prompty do skopiowania: audyt routingu z ostatniego miesiąca, szkic globów polityki i przegląd routingu po incydencie.

Dlaczego „napisane przez AI” to słaby sygnał routingu?

Autorstwo kieruje źle w obie strony. Dodatkowe review każdej zmiany wspomaganej przez AI zalewa kolejkę drobiazgami i daje inżynierom powód, żeby etykietę pominąć. Lżejsze review kodu „ludzkiego” zostawia martwe pole dokładnie tam, gdzie była zmiana webhooka z przykładu. Żaden z tych efektów nie zależy od tego, co zmiana robi.

Ryzyko zmiany wynika z zasięgu skutków, wrażliwości danych, do których sięga, tego, czy coś poza repozytorium od niej zależy, tego, czy osłabia checki oceniające każdą inną zmianę, oraz z trudności jej cofnięcia. Wszystkie pięć widać w diffie i w pakiecie dowodów. Nazwy modelu ani odsetka wygenerowanych linii w nich nie widać.

Pochodzenie nadal się przydaje, w trzech zadaniach, które nie są routingiem:

• Pomiar. Kanoniczne metryki AI dzielą każdą metrykę wpływu na zmiany wspomagane przez agenta i pozostałe, a do tego potrzebny jest wiarygodny znacznik na każdym scalonym pull requeście.
• Analiza incydentów. Gdy zmiana zawiedzie, sesja, prompt i zadanie, z których powstała, pokazują, jak defekt się dostał, a więc jakich dowodów powinna była wymagać klasa ryzyka.
• Audyt. Zespoły regulowane muszą pokazać, kto zaakceptował intencję, kto zatwierdził merge i kto wypuścił zmianę. Na pierwsze pytanie odpowiada human_owner w pakiecie, na dwa pozostałe — historia pull requesta na platformie (GitHub, GitLab).

Które pola pakietu dowodów kierują zmianą?

Kieruj według pól, które checker przelicza lub weryfikuje na podstawie diffu, a resztę traktuj jak deklaracje do audytu. Zadeklarowana klasa ryzyka może tylko podnieść próg wyznaczony przez diff, zgodnie z zasadami pakietu.

Pole pakietu	Co sygnalizuje	Jaką kontrolę uruchamia	Kto egzekwuje
Brak spec.link lub spec.delta albo link do nieistniejącego pliku	Nikt nie opisał zamierzonego zachowania, więc żaden check go nie udowodni	Blokada merge’a, dopóki autor nie podlinkuje specyfikacji i nie wypisze zmian zachowania	Wymagany status check evidence
risk.touches: auth, money, schema, migrations	Błąd jest kosztowny i wolno wychodzi na jaw	Imienny code owner czyta kod oprócz pakietu	CODEOWNERS plus wymagane review code ownera
risk.touches: infra	Zmienia się zachowanie wdrożenia lub CI	Klasa co najmniej standard: jeden reviewer czyta pakiet i uwagi agenta review	Próg w checkerze (min_risk: standard) plus CODEOWNERS na .github/workflows/
risk.touches: personal_data (dodana niżej)	Dane klientów mogą wyciec albo się uszkodzić	Akceptuje właściciel prywatności lub bezpieczeństwa; testy tylko na danych syntetycznych	CODEOWNERS na ścieżkach obsługi danych
risk.touches: public_contract (dodana niżej)	Psują się konsumenci spoza repozytorium	Testy kompatybilności lub kontraktowe w checks, akceptuje zespół konsumenta	CODEOWNERS plus wymagany job testów kontraktowych
risk.touches: agent_config (dodana niżej)	Każde kolejne uruchomienie agenta działa inaczej, łącznie z agentami review	Akceptuje właściciel platformy	CODEOWNERS
risk.oracle_changes z direction: looser	Zmienia się znaczenie „zielonego” dla każdej innej zmiany	Klasa high; zmianę czyta code owner testu	Próg w checkerze plus CODEOWNERS na ścieżkach testów
risk.rollback wskazuje migrację, przepisanie danych lub efekt zewnętrzny	Revert nie cofnie zmiany	Dry run, sprawdzenie backupu, stopniowe wdrożenie, akceptacja produkcyjna	Środowisko wdrożeniowe z wymaganymi reviewerami
acceptance z wynikiem innym niż pass, puste checks, brak runtime lub evals tam, gdzie są wymagane	Deklaracja nie jest udowodniona	Blokada merge’a, niezależnie od autora	Wymagany status check evidence
provenance.*	Kto i czym wytworzył zmianę	Brak wpływu na routing; zapisywane do metryk i audytu	Checker wymaga agent, model i human_owner

Ostatni wiersz to reguła Q11 w jednym zdaniu. Wszystkie pozostałe działają tak samo dla zmian czysto ludzkich, wspomaganych przez AI i wytworzonych przez agenta.

Jak łączą się skale ryzyka używane w serwisie?

Trzy strony opisują tę samą ideę trzema skalami. Ta tabela pozwala utrzymać spójną politykę, która odwołuje się do wszystkich trzech:

Klasa pakietu dowodów	Tor review	Poziom governance	Kontrola wydania
low	0 · Niskie ryzyko	1 · Odwracalne lokalnie	Zwykłe wdrożenie
standard	1 · Standard	1 · Odwracalne lokalnie	Canary albo flaga, jeśli są dostępne
high	2 · Wrażliwe	1, albo 2, gdy zmiana wymaga próby na stagingu	Stopniowe wdrożenie, potem akceptacja produkcyjna
high z nieodwracalnym rollback	2 · Wrażliwe	3 · Produkcja lub obszar regulowany	Imienny właściciel zatwierdza chroniony job produkcyjny

Jak kierować pull requesty na podstawie pakietu dowodów?

Polityka routingu stoi na bramce pakietu dowodów, więc najpierw zainstaluj bramkę. Każdy krok poniżej dodaje jedną kontrolę i żaden nie patrzy na autora.

1. Zainstaluj bramkę pakietu dowodów. Dodaj szablon, politykę, checker, workflow i CODEOWNERS ze strony pakietu dowodów, scal je, a potem ustaw check evidence jako wymagany. Wszystko niżej rozszerza .github/evidence-policy.yml i CODEOWNERS.

2. Dodaj klasy, które wymienia Q11, a których brakuje w polityce startowej. Polityka startowa obejmuje auth, pieniądze, schemat, migracje i infrastrukturę. Dane osobowe, publiczne kontrakty i konfiguracja agentów potrzebują własnych klas. Dopisz je pod sensitive: i dopasuj globy do swojego repozytorium:

   # .github/evidence-policy.yml: append under the existing sensitive: key
     personal_data:   { globs: ['**/customers/**', '**/*pii*', '**/exports/**'], min_risk: high }
     public_contract: { globs: ['packages/sdk/**', '**/public-api/**'], min_risk: high }
     agent_config:    { globs: ['**/CLAUDE.md', '**/AGENTS.md', '.claude/**', '.codex/**', '.cursor/**', '.mcp.json'], min_risk: high }

   Checker przechodzi po każdym wpisie pod sensitive:, więc nowe klasy nie wymagają zmian w kodzie: diff, który do nich pasuje, nie przejdzie, dopóki risk.touches ich nie wymieni, a risk.class nie będzie high. W tym samym pull requeście przypisz każdemu globowi właściciela, który nie jest agentem:

   # .github/CODEOWNERS: insert above the oracle globs (**/*.test.* and below)
   **/customers/**     @acme/privacy
   **/*pii*            @acme/privacy
   **/exports/**       @acme/privacy
   packages/sdk/**     @acme/api-owners
   **/public-api/**    @acme/api-owners
   **/CLAUDE.md        @acme/platform
   **/AGENTS.md        @acme/platform
   .claude/            @acme/platform
   .codex/             @acme/platform
   .cursor/            @acme/platform
   .mcp.json           @acme/platform

   CODEOWNERS stosuje ostatnią pasującą linię. Dopisany pod globami wyroczni ze strony pakietu wpis **/customers/** odebrałby @acme/platform plik src/customers/export.test.ts i osłabił kontrolę luźniejszej wyroczni, więc wstaw te linie nad globami wyroczni. Dwa zespoły w jednej linii nie oznaczają wymogu obu akceptacji: wystarczy akceptacja jednego z nich.

   Globy ścieżek znajdują obsługę danych tylko tam, gdzie kod jest według niej zorganizowany. Zapytanie, które dokleja e-mail klienta do tabeli analitycznej, może leżeć gdziekolwiek. Dlatego pakiet pozwala autorowi dopisać do risk.touches klasę, której globy nie wykryły, i dlatego prompt audytu routingu niżej szuka właśnie tej luki.

3. Zapisz decyzje routingu raz. Checker i CODEOWNERS egzekwują trasy; plik polityki zapisuje, dlaczego tak jest, kto jest właścicielem każdej klasy i kto może przyznać wyjątek. Trzymaj go obok polityki review:

   change-routing-policy.md

   # Change routing policy (version 1.0, owner: VP Engineering)
   
   ## 1. Signal
   Review depth, approvals and release controls follow the evidence bundle
   (.github/evidence-policy.yml): sensitive classes touched, oracle changes,
   rollback, and completeness of evidence. The class computed from the diff
   is the floor; a person may raise it, nobody may lower it.
   
   ## 2. Authorship
   Provenance (human, AI-assisted, agent; tool, model, session) is recorded
   on every change, including human-only ones (agent: none, model: none).
   It is never an input to routing, approval or release. It is used for the
   metrics in section 5 and for incident review.
   
   ## 3. Routes
   - low: one reviewer reads the bundle.
   - standard: one reviewer reads the bundle, the oracle changes and any
     unrequested behavior; a review agent's findings are attached.
   - high: the code owner of every touched class reads the code.
   - irreversible rollback: dry run, backup check, staged rollout, and a
     named approver on the production environment.
   - incomplete evidence: blocked, regardless of author or class.
   
   ## 4. Exceptions
   Only the owner of a class may waive its control, in writing on the pull
   request, with an expiry date. The platform team reviews open exceptions
   monthly.
   
   ## 5. Measurement
   Monthly: routing escape rate, provenance coverage, share of pull
   requests routed high, and the agent-cohort metrics from the metrics
   framework. A class whose escape rate rises gets stronger evidence
   requirements, not an authorship rule.

   Szablon zostaje po angielsku, bo trafia do repozytorium obok plików, które czytają agenci; przetłumacz go, jeśli twoje repozytoria prowadzicie po polsku.

4. Umieść kontrole wydania tam, gdzie żadna etykieta ich nie ominie. Routing, który kończy się na merge’u, zostawia najbardziej ryzykowną część, czyli produkcję, pamięci ludzi. Nadaj produkcyjnemu środowisku wdrożeniowemu wymaganych reviewerów, a workflow wdrożenia niech czyta klasę z wyniku checku evidence, a nie z etykiety, którą każdy może zmienić. Szczegóły są na stronach o bramce akceptacji produkcyjnej i progressive delivery.

5. Zapisuj pochodzenie przy każdej zmianie. Pull requesty czysto ludzkie wypełniają provenance w pakiecie wartościami agent: none i model: none, więc pole jest obecne na każdej scalonej zmianie, a podział na kohorty w metrykach nie ma niewiadomych. Zakładki niżej pokazują, skąd każde narzędzie może dostarczyć pochodzenie automatycznie.

6. Udowodnij, że nowe klasy kierują poprawnie. Użyj metody fikstur ze strony pakietu: EVIDENCE_CHANGED_FILES zastępuje git diff, więc fikstura potrzebuje tylko sztucznego zdarzenia i listy ścieżek. Weź kopię pakietu z szablonu zadeklarowaną jako standard, z cytowanymi plikami specyfikacji i testów obecnymi w gałęzi:

   # Terminal, repository root
   GITHUB_EVENT_PATH=fixtures/ev-standard.json \
   EVIDENCE_CHANGED_FILES='src/customers/export.ts' \
   node scripts/check-evidence.mjs .github/evidence-policy.yml

   Uruchomienie musi zakończyć się kodem 1 i zgłosić zarówno diff touches personal_data (src/customers/export.ts) but risk.touches omits it, jak i risk.class is standard, but the diff requires at least high. Dodaj taką fiksturę dla każdej nowej klasy, plus jedną, która dotyka samego .github/evidence-policy.yml, i uruchamiaj je w zwykłym jobie testów.

Skąd wziąć pochodzenie w Claude Code, Codex i Cursorze?

Blok provenance w pakiecie działa tak samo we wszystkich trzech narzędziach: agent wypełnia go na podstawie promptu pakietu ze strony pakietu dowodów. Różni się automatyczny zapis, z którym możesz go porównać. W każdym z narzędzi Entire CLI (v0.11.3, 2026-09-25) łączy każdy commit z sesją agenta, która go wytworzyła, przez trailer Entire-Checkpoint:.

Zainstaluj Entire CLI raz na maszynie: brew install --cask entireio/tap/entire (macOS i Linux) albo curl -fsSL https://entire.io/install.sh | bash. To binarka w Go; pakiet npm entire to niezwiązany projekt.

Claude Code

W planach Team i Enterprise, z zainstalowaną aplikacją Claude na GitHubie i włączoną analityką GitHuba, analityka kontrybucji Claude Code oznacza zaliczone scalone pull requesty etykietą claude-code-assisted. Atrybucja dopasowuje sesje od 21 dni przed do 2 dni po merge’u, a kod przepisany w ponad 20% nie jest zaliczany. Przy Zero Data Retention metryki kontrybucji są niedostępne; wtedy używaj pola w pakiecie i trailerów Entire.

# Terminal, repository root: per-commit session provenance
entire enable --agent claude-code

W wyszukiwarce GitHuba zapytanie is:pr is:merged label:claude-code-assisted zwraca zaliczone pull requesty, czyli próbkę do metryki pokrycia pochodzenia opisanej niżej.

Codex

codex exec -o pr-body.md zapisuje końcową wiadomość agenta, razem z pakietem, jako treść pull requesta; pełne polecenie jest na stronie pakietu dowodów. Dodaj pochodzenie sesji dla każdego commita:

# Terminal, repository root
entire enable --agent codex

Dla Codexa źródłem atrybucji są blok provenance w pakiecie i trailery Entire; porównuj je przez opisaną niżej metrykę pokrycia pochodzenia.

Cursor

Umieść instrukcję pakietu w regule projektu, żeby agenci wypełniali provenance w pull requestach, które otwierają, i dodaj pochodzenie sesji dla każdego commita:

# Terminal, repository root
entire enable --agent cursor

PR Routing & Approval w Cursorze „assigns reviewers based on code ownership and commit history, and can approve low-risk PRs when your criteria are met” (cursor.com, sprawdzone 2026-08-28). Ustaw te kryteria tak, żeby pasowały wyłącznie do trasy low, nigdy do standard ani high. Zobacz Rollouts i PR Routing & Approval.

Entire przechowuje transkrypcje sesji w twoim repozytorium git. W publicznym repozytorium wysyłaj checkpointy do prywatnego przez entire enable --checkpoint-remote github:your-org/checkpoints i sprawdź ograniczenia redakcji sekretów, zanim włączysz narzędzie w całym zespole.

Jak mierzyć routing, nie kierując według autorstwa?

Dla metryk kohorty agentowej (wskaźnik nieudanych zmian w kohorcie agentowej, wskaźnik poprawek w ciągu 14 dni, defekty, które uciekły na produkcję) używaj kanonicznych definicji. Dwie dodatkowe definicje mierzą samą politykę routingu:

Metryka	Definicja	Co oznacza zły trend
Wskaźnik ucieczek routingu	Incydenty i reverty, którym przegląd poincydentalny przypisał wyższą klasę niż ta, z którą pull request przeszedł ÷ wszystkie incydenty i reverty przypisane do zmiany, kwartalnie	Brakuje klasy albo glob rozjechał się z kodem. Popraw politykę, potem dodaj fiksturę.
Pokrycie pochodzenia	Scalone pull requesty, w których provenance.agent z pakietu zgadza się z zapisem automatycznym (etykietą analityki lub trailerem Entire) ÷ scalone pull requesty z zapisem automatycznym, miesięcznie	Ludzie albo agenci ukrywają lub zgadują pochodzenie, więc metryki kohort są niewiarygodne.

Obserwuj też udział pull requestów skierowanych do high. Gdy zbliża się do większości kolejki, globy obejmują za dużo, a reviewerzy znów czytają każdy diff.

Jeśli kohorta agentowa zawodzi częściej niż pozostała w tej samej klasie, zaostrz dowody, których ta klasa wymaga od każdej zmiany, na przykład wynik testów mutacyjnych na zmienionych plikach. Reguła oparta na autorstwie cofnie cię do etykiety, której nikt nie zaznacza.

Prompty do skopiowania: pochodzenie i routing

Prompt do skopiowania: audyt routingu z ostatniego miesiąca

Audit how pull requests were routed in this repository over the last 30 days.
Read .github/evidence-policy.yml and .github/CODEOWNERS. For each merged pull
request, compare the class a diff-based reading of the policy would assign
with the class in its evidence bundle and the approvals it actually received.

Report a table: PR number, computed class, declared class, approvals received,
mismatch (yes/no), reason. Then list:
1. Changes that touched customer data, public contracts or agent configuration
   without matching any glob, with the path a new glob should cover.
2. Any route that depended on authorship or on the AI label.
Do not edit files, labels or pull requests. Cite file paths for every finding.

Prompt do skopiowania: szkic globów klas wrażliwych z repozytorium

Propose sensitive-class globs for .github/evidence-policy.yml from this
repository's structure. Classes: auth, money, schema, migrations,
personal_data, public_contract, agent_config, infra.

For each class, list the directories and files that belong to it, with one
line of evidence each (an import, a table name, a route, a package export).
Mark any class whose code is spread across modules so that no glob can catch
it reliably. Output YAML in the format of the existing sensitive: block and a
matching CODEOWNERS draft with TEAM placeholders. Do not edit files.

Prompt do skopiowania: przegląd routingu po incydencie

This incident was traced to the pull request below. Read its evidence bundle,
its diff, .github/evidence-policy.yml and the incident summary.

Answer:
1. Which class should this change have been routed at, and which control in
   that class would most likely have caught the defect?
2. Was the gap a missing class, a drifted glob, an understated rollback, a
   loosened oracle, or evidence that passed without testing the behavior?
3. What policy change and which fixture would stop the same escape?
Do not use the author or the AI label as a cause. Do not edit files.

PULL REQUEST: <link>
INCIDENT SUMMARY: <paste>

Jak przejść z każdej odpowiedzi Q11 do następnej?

Odpowiedź Q11	Jak to wygląda	Następny krok na tej stronie
Brak pochodzenia i routingu ryzyka	Każdy pull request dostaje takie samo review	Krok 1: zainstaluj bramkę pakietu dowodów
Tylko ręczny znacznik AI lub umowa reviewerów	Pole wyboru ai-generated, dodatkowe review z przyzwyczajenia	Kroki 1 i 5: zapisuj pochodzenie przy każdej zmianie i przestań według niego kierować
Maszynowo czytelne pochodzenie plus etykiety ryzyka według ścieżek	Pakiet i etykiety risk:*, tylko klasy startowe	Kroki 2–4: dodaj klasy danych, kontraktu i konfiguracji agentów; powiąż kontrole wydania z klasą
Intencja, system, dane i odwracalność kierują dowodami i imiennymi akceptacjami; autorstwo zostaje do pomiaru	Ta strona wdrożona, z fiksturami i obiema metrykami	Pilnuj spadku wskaźnika ucieczek routingu; przeglądaj wyjątki co miesiąc

Co się psuje, gdy kierujesz zmiany według manifestu?

Routing czyta etykietę, którą da się edytować. Każdy z uprawnieniem triage może zmienić risk:standard na risk:low. Wyjście: akceptacje merge’a kieruj przez ścieżki w CODEOWNERS, kontrole wydania przez wynik checku evidence, a etykietę traktuj wyłącznie jako informację.

Zmiana w obsłudze danych nie pasuje do żadnego globu. Dane klientów płyną przez moduł sync/, więc zmiana przechodzi jako standard. Wyjście: co miesiąc uruchamiaj prompt audytu routingu, dodaj brakujący glob z właścicielem i fiksturę, żeby następna zmiana nazwy katalogu wywaliła test.

Wszystko staje się high. Szerokie globy wysyłają większość kolejki do code ownerów, którzy zaczynają zatwierdzać bez czytania. Wyjście: zawęź każdą klasę do kodu, w którym błąd jest kosztowny i wolno wychodzi na jaw, i co miesiąc sprawdzaj udział zmian skierowanych do high.

Pochodzenie znika, gdy przestaje mieć znaczenie dla review. Skoro nie wpływa na routing, ludzie pomijają pole. Wyjście: checker już wymaga agent, model i human_owner; porównuj je z zapisem automatycznym przez metrykę pokrycia pochodzenia.

Reviewer AI albo bot akceptujący zaspokaja trasę high. Wyjście: code ownerami klas high są zespoły ludzi i żadne konto bota do nich nie należy. Akceptacja maszynowa jest dozwolona tylko dla low, jak ustala polityka automatyzacji review.

Wyciekają transkrypcje sesji. Entire zapisuje prompty i transkrypcje w gicie, a redakcja sekretów działa na zasadzie „best effort”. Wyjście: używaj prywatnego zdalnego repozytorium na checkpointy, usuń dotknięte checkpointy i zrotuj każde ujawnione poświadczenie.

Dokąd dalej z routingiem zmian

Pakiet dowodów Schemat manifestu, szablon pull requesta i checker w CI, z których korzysta ten routing.

Polityka automatyzacji review PR Tory ryzyka, checki rozstrzygające i to, kto może zatwierdzać.

Governance i autonomia Poziomy ryzyka w organizacji i bramki, których agent nie zatwierdzi sam.

Frameworki metryk Kanoniczne definicje metryk kohorty agentowej, które używają pochodzenia.

Telemetria i pochodzenie agentów Dashboardy analityczne, OpenTelemetry i Entire CLI dla każdego narzędzia.

Progressive delivery Kontrole wydania dla zmian wysokiego ryzyka i nieodwracalnych.