Rollouts oraz PR Routing & Approval w Cursorze

PR Routing & Approval w Cursorze przydziela recenzentów na podstawie własności kodu i historii commitów oraz może zatwierdzać pull requesty niskiego ryzyka, gdy spełniają zdefiniowane przez zespół kryteria. Jest to bezpieczne tylko wtedy, gdy klasę ryzyka liczy CI, a nie agent, o merge’u decyduje ruleset GitHuba, każde zatwierdzenie trafia do audytu, a zmianę po merge’u obserwuje monitor rolloutu.

Ta strona jest dla tech leada lub CTO, który decyduje, co agent może zatwierdzać, i dla developera, który to konfiguruje. Agenci twojego zespołu otwierają 30 pull requestów dziennie. Połowa zmienia dokumentację, teksty w UI albo izolowany komponent, a dwóch seniorów spędza poranki na ich zatwierdzaniu, podczas gdy zmiana w rozliczeniach czeka. Automatyczne zatwierdzanie według reguł to oczywiste rozwiązanie. To także najszybszy sposób, żeby wmergować błąd w płatnościach z zielonym checkiem, chyba że „niskie ryzyko” liczy coś, czego agent nie może edytować.

Presję da się zmierzyć. Raport Faros AI AI Engineering Report 2026 (kwiecień 2026, telemetria dostawcy od 22 000 developerów u klientów Faros, czyli z grupy, która sama się wybrała) pokazał wzrost liczby mergowanych pull requestów na developera o 16,2%, wzrost mediany czasu w review o 441,5%, wzrost liczby incydentów na pull request o 242,7% i o 31,3% więcej pull requestów mergowanych bez żadnego review. Merge’e bez review już się zdarzają; ta strona zamienia je w merge’e według reguł, z pełnym śladem audytowym.

Co daje zatwierdzanie pull requestów według reguł

• Podział pracy, w którym CI liczy klasę ryzyka, Cursor zatwierdza, a GitHub egzekwuje, więc nikt nie zatwierdza własnej pracy.
• Kryteria zatwierdzania do wklejenia w PR Routing & Approval i startowe reguły ryzyka, na których się opierają.
• Konfigurację rulesetu i CODEOWNERS, która zostawia ścieżki wysokiego ryzyka konkretnym ludziom, nawet gdy przyjdzie zatwierdzenie.
• Krok workflow, który włącza auto-merge tylko dla pull requestów low, przypięty do sprawdzonego commita.
• Zapytanie audytowe, cotygodniową próbkę i trzy metryki, które mówią, kiedy regułę poszerzyć, a kiedy zawęzić.
• Test akceptacyjny monitora rolloutu, niezależnie od tego, czy to Rollouts Cursora, czy twoje własne canary.

Co robią PR Routing & Approval i Rollouts?

Cursor dokumentuje obie funkcje z różną szczegółowością, a ta strona opiera się tylko na tym, co dało się sprawdzić. 26 września 2026 cursor.com był niedostępny ze środowiska, w którym powstał tekst, więc tabela podaje ostatni zweryfikowany odczyt.

Funkcja	Co dokumentuje Cursor	Ostatnio sprawdzone	Co zakłada ta strona
PR Routing & Approval	„It assigns reviewers based on code ownership and commit history, and can approve low-risk PRs when your criteria are met.” (approval-agents)	2026-08-28	Kryteria piszesz sam. Jakie sygnały mogą czytać (etykiety, status checków, ścieżki), potwierdzasz w dokumentacji Cursora, zanim zaczniesz polegać na którymkolwiek z nich.
Bugbot	„Bugbot reviews pull requests and identifies bugs, security issues, and code quality problems.” (bugbot)	2026-08-28	Jego uwagi są wejściem dla klasy standard, a nie zatwierdzeniem. Zobacz Bugbot: wyuczone reguły i Autofix.
Rollouts	Wyniki wyszukiwania dla changelogu Cursora (wpis z 23 września 2026) opisują funkcję Rollouts dla etapu po merge’u; ani changelogu, ani dokumentacji nie udało się pobrać 26 września 2026.	niezweryfikowane	Ta strona nie podaje żadnych jej ustawień. Daje za to test akceptacyjny, który musi przejść każdy monitor rolloutu, zanim mu zaufasz.

Sprawdź przed konfiguracją

Cursor wydaje szybko, a strony ustawień się zmieniają. Otwórz dokumentację Cursora dla PR Routing & Approval i Rollouts obok tej strony. Przy rozbieżności dostawca ma rację co do przełączników, a ta strona co do projektu całości.

Kto decyduje, że pull request jest niskiego ryzyka?

Zatwierdzenie jest warte tyle, co to, co nadaje pull requestowi etykietę. Podziel zadanie między trzech aktorów i daj każdemu dokładnie jedno uprawnienie:

Aktor	Odpowiada za	Nigdy nie może
CI (check pakietu dowodów)	Liczy klasę ryzyka z diffu i nadaje etykietę risk:low, risk:standard albo risk:high	Czytać polityki ani checkera z gałęzi pull requesta
Cursor PR Routing & Approval	Prosi o review według własności kodu; zatwierdza pull request spełniający kryteria	Ustalać klasy na podstawie opisu napisanego przez agenta ani figurować w CODEOWNERS lub na liście bypass rulesetu
Ruleset GitHuba	Blokuje merge, dopóki checki nie przejdą, zatwierdzenia nie będą aktualne, a code ownerzy nie zatwierdzą swoich ścieżek	Być edytowalny przez agenta, który otworzył pull request

Agent, który napisał zmianę, może zadeklarować klasę w swoim pakiecie dowodów, ale deklaracja może tylko podnieść próg wyliczony przez CI, nigdy go obniżyć. Ta jedna reguła sprawia, że „zatwierdzaj niskie ryzyko” w ogóle coś znaczy.

Klasy ryzyka to nie poziomy dojrzałości

Ta strona używa trzech klas z pakietu dowodów: low, standard i high. Jeśli polityka autonomii i klas ryzyka twojej organizacji ma ich więcej, zmapuj każdą na te trzy etykiety i trzymaj mapowanie w .github/evidence-policy.yml, skąd czyta je CI.

Skonfiguruj zatwierdzanie pull requestów niskiego ryzyka według reguł

Kolejność ma znaczenie: najpierw klasyfikator, potem egzekwowanie, na końcu zatwierdzający. Zatwierdzający włączony przed dwoma pozostałymi zatwierdza wszystko, co zadeklaruje agent.

1. Wdróż bramkę pakietu dowodów. Przejdź konfigurację pakietu dowodów do momentu, w którym check evidence jest wymagany na main, a każdy pull request agenta ma jedną etykietę risk:*. Checker i polityka ładują się z commita bazowego, więc pull request nie osłabi bramki, która go ocenia.

2. Zadbaj o wiarygodność etykiety. Workflow pakietu dowodów dodaje etykietę, ale nie usuwa starej. Pull request, który był low, a potem dotknął src/billing/, może więc mieć jednocześnie risk:low i risk:high. Zastąp krok etykietowania takim, który najpierw czyści pozostałe:

   # .github/workflows/evidence-bundle.yml — zastępuje krok "Label the risk class"
         - name: Label the risk class
           if: always() && steps.check.outputs.risk != ''
           env:
             GH_TOKEN: ${{ github.token }}
             PR: ${{ github.event.pull_request.number }}
             RISK: ${{ steps.check.outputs.risk }}
           run: |
             for c in low standard high; do
               [ "$c" = "$RISK" ] || gh pr edit "$PR" --remove-label "risk:$c" || true
             done
             gh pr edit "$PR" --add-label "risk:$RISK"

3. Chroń main rulesetem. W Settings repozytorium otwórz Rulesets w sekcji Code and automation, wskaż domyślną gałąź i włącz: wymagany pull request z jednym zatwierdzeniem; odrzucanie nieaktualnych zatwierdzeń po nowych commitach; wymagane review code ownerów; wymagany check evidence i job testów; blokadę force pushy. Integracji Cursora nie dodawaj do listy bypass. Dokumentacja GitHuba opisuje regułę nieaktualnych zatwierdzeń precyzyjnie: jeśli diff zmieni się po zatwierdzeniu, „the approving review is dismissed as stale, and the pull request cannot be merged until someone approves the work again”.

4. Zostaw ścieżki wysokiego ryzyka konkretnym ludziom. Przy wymaganym review code ownerów pull request dotykający przypisanej ścieżki potrzebuje zatwierdzenia jej właściciela, niezależnie od tego, kto jeszcze go zatwierdził. Wpisz każdą klasę eskalacji do CODEOWNERS i nigdy nie wpisuj tam tożsamości Cursora:

   # .github/CODEOWNERS
   .github/                        @acme/platform
   scripts/check-evidence.mjs      @acme/platform
   **/auth/**                      @acme/security
   **/billing/**                   @acme/payments
   **/payments/**                  @acme/payments
   **/migrations/**                @acme/data
   **/*.sql                        @acme/data
   **/*.test.*                     @acme/platform

   Ostatnia linia kieruje każdą zmianę testów do człowieka, bo edycja testu zmienia znaczenie „zielonego” dla wszystkich innych zmian. Globy odpowiadają klasom eskalacji z czytania dowodów zamiast kodu.

5. Zapisz kryteria zatwierdzania w Cursorze. Wklej poniższe kryteria do PR Routing & Approval. Następnie sprawdź w dokumentacji Cursora, które z tych sygnałów kryteria potrafią odczytać. Warunek, którego Cursor nie oceni, nie znika: przenosisz go do rulesetu albo do CI.

   Approve a pull request only when ALL of these are true:
   1. It carries exactly one risk label, and that label is risk:low.
   2. The required checks, including "evidence", passed on the current head commit.
   3. No changed file matches a path in .github/CODEOWNERS.
   4. No test, snapshot, CI workflow, lint config, tsconfig or lockfile changed.
   5. No new dependency was added to package.json or any other manifest.
   6. The diff is at most 300 changed lines across at most 10 files.
   7. The evidence bundle lists every acceptance criterion with result: pass.
   
   If any condition fails, do not approve. Request reviewers by code ownership
   and commit history, and leave one comment naming the condition that failed.
   Never approve on the basis of the pull request description alone.

6. Przez dwa tygodnie pracuj w trybie cienia. Nie włączaj jeszcze auto-merge’a. Cursor zatwierdza, człowiek nadal merguje i zapisuje każdy pull request, przy którym zdecydowałby inaczej. Do kroku 7 przejdź, gdy rozbieżności nie ma albo wszystkie są w bezpieczną stronę (Cursor odmówił czegoś, co człowiek by zatwierdził).

7. Po dwóch czystych tygodniach włącz auto-merge tylko dla low. Zaznacz Allow auto-merge w ustawieniach repozytorium, a potem dodaj te kroki na końcu joba evidence. O bezpieczeństwie decydują dwa szczegóły. --match-head-commit przypina merge do commita, który sprawdziło CI. Merge wykonuje token GitHub App, bo według dokumentacji GitHuba zdarzenia wywołane przez GITHUB_TOKEN repozytorium „will not create a new workflow run”, więc merge wykonany nim nie uruchomiłby workflow deployu.

         - name: Create a merge token
           id: app-token
           if: always() && steps.check.outputs.risk != ''
           uses: actions/create-github-app-token@v3
           with:
             client-id: ${{ vars.MERGE_APP_CLIENT_ID }}
             private-key: ${{ secrets.MERGE_APP_PRIVATE_KEY }}
         - name: Arm auto-merge for low risk only
           if: always() && steps.check.outputs.risk != ''
           env:
             GH_TOKEN: ${{ steps.app-token.outputs.token }}
             PR: ${{ github.event.pull_request.number }}
             HEAD: ${{ github.event.pull_request.head.sha }}
           run: |
             if [ "${{ steps.check.outcome }}" = "success" ] && [ "${{ steps.check.outputs.risk }}" = "low" ]; then
               gh pr merge "$PR" --auto --squash --match-head-commit "$HEAD"
             else
               gh pr merge "$PR" --disable-auto || true
             fi

   --auto merguje „only after necessary requirements are met”, więc decyzja nadal należy do rulesetu. Gałąź else wyłącza auto-merge, gdy późniejszy push podniesie klasę. Daj aplikacji uprawnienia zapisu Contents i Pull requests tylko do tego repozytorium.

Od jakich reguł ryzyka zacząć?

Zacznij wąsko. Klasa low obejmująca pół repozytorium wysyła na produkcję kod, którego nikt nie przeczytał i nic nie sprawdziło. Poszerzaj ją po jednym wierszu, za każdym razem gdy audyt opisany niżej pokaże czysty miesiąc dla wierszy, które już masz.

Zmiana	Klasa na start	Dlaczego
Dokumentacja, komentarze, README	low	Błąd jest widoczny, tani i odwracalny
Teksty w UI i tłumaczenia, ze zrzutem ekranu w runtime	low	Dowód z działania aplikacji jest checkiem
Izolowany komponent za wyłączonym feature flagiem, z dowodem z działania	low	Flaga ogranicza zasięg szkód
Zmiana zachowania w kodzie z testami, tylko nowe lub zaostrzone testy	standard	Wymaga recenzenta pakietu dowodów i uwag agenta recenzującego
Dodana lub podbita zależność, zmiana lockfile’a	standard	Zmyślone i podszywające się pakiety; zobacz weryfikację zależności
Workflow CI, infrastruktura, tsconfig, konfiguracja lintera	standard lub wyżej	Zmienia wyrocznię albo środowisko dla wszystkich innych zmian
Uwierzytelnianie, pieniądze, schemat, migracje, poluzowany test	high	Wskazany code owner czyta kod; po merge’u rollout etapami

Dwie reguły obowiązują w każdym wierszu. Zmiana, której nie pokrywa żaden check, nigdy nie jest low, niezależnie od ścieżki, bo jedynym dowodem jest wtedy kod. A pull request agenta, który edytuje politykę ryzyka, CODEOWNERS lub checker, jest high z definicji, bo tymi plikami zarządza @acme/platform.

Jak udowodnić, że konfiguracja działa, zanim jej zaufasz?

Testuj bramkę jak każdą wyrocznię: przypadkami, które muszą przejść, i takimi, które muszą polec. Otwórz z agenta cztery testowe pull requesty na gałąź chronioną tym samym rulesetem i zapisz, co się stało.

Testowy pull request	Oczekiwany wynik
Poprawka literówki w docs/setup.md	Etykieta risk:low, zatwierdzenie Cursora, automatyczny merge, uruchomiony workflow deployu
Zmiana jednej linii w src/billing/refund.ts, a pakiet dowodów deklaruje class: low	CI podnosi klasę do risk:high, Cursor nie zatwierdza, prośba o review trafia do @acme/payments, auto-merge pozostaje wyłączony
Znowu pull request z dokumentacją, z drugim commitem wypchniętym po zatwierdzeniu przez Cursora	Zatwierdzenie zostaje odrzucone jako nieaktualne; nic się nie merguje bez nowego zatwierdzenia na nowym commicie
Zmiana w dokumentacji plus edycja tests/orders.test.ts	Nie low; prośba o review trafia do code ownera testów

Jeśli któryś wiersz zachowa się inaczej, popraw konfigurację, zanim uruchomisz krok 7. Najważniejszy jest drugi wiersz: dowodzi, że deklaracja agenta nie obniży klasy.

Jak audytować to, co zatwierdził Cursor?

Każde zatwierdzenie to review na GitHubie z autorem, stanem, znacznikiem czasu i commitem, na którym je złożono. To twój ślad audytowy i leży poza Cursorem. To zapytanie wypisuje zmergowane pull requesty low z ostatnich 30 dni, kto zatwierdził każdy z nich i czy zatwierdzenie dotyczyło commita, który trafił do main:

# Terminal, katalog główny repozytorium. Wymaga gh i jq.
gh pr list --state merged --label risk:low --limit 200 \
  --search "merged:>=$(date -d '30 days ago' +%F)" \
  --json number,title,url,mergedAt,headRefOid,reviews \
| jq -r '.[] | . as $pr
  | [.reviews[] | select(.state == "APPROVED")] as $ok
  | [$pr.number, $pr.mergedAt[:10],
     ($ok | map(.author.login) | unique | join(",")),
     (if any($ok[]; .commit.oid == $pr.headRefOid) then "head" else "STALE" end),
     $pr.title] | @tsv'

Na macOS zamień date -d '30 days ago' +%F na date -v-30d +%F. Każdy wiersz oznaczony STALE oznacza, że zatwierdzenie nie objęło kodu, który trafił na produkcję; najpierw sprawdź ruleset.

Potem prowadź cotygodniową próbkę. Ktoś z zespołu losuje pięć zmergowanych pull requestów low, czyta cały diff i zapisuje w dzienniku zaufania, czy lektura kodu znalazła coś, czego nie wychwyciły dowody. Próbkowanie utrzymuje w ryzach zasadę „nikt nie czyta low”.

Śledź co miesiąc trzy liczby i reaguj na nie:

Metryka	Definicja	Działanie
Udział automatycznych zatwierdzeń	Zmergowane pull requesty zatwierdzone wyłącznie przez Cursora ÷ wszystkie zmergowane pull requesty	Kontekst dla dwóch pozostałych; rosnący udział jest dobry tylko, dopóki one stoją w miejscu
Wskaźnik revertów po automatycznym zatwierdzeniu	Automatycznie zatwierdzone merge’e wycofane lub poprawione hotfixem w ciągu 14 dni ÷ automatycznie zatwierdzone merge’e	Powyżej wskaźnika dla merge’y standard zatwierdzanych przez ludzi: zawęź reguły low
Wskaźnik przeoczeń w próbce	Wylosowane pull requesty, w których lektura kodu znalazła defekt ÷ wylosowane pull requesty	Każde przeoczenie: napisz check, który by je wychwycił, i zdecyduj, czy wiersz zostaje low

Jak rollout wyłapuje to, co przepuściło zatwierdzenie?

Zatwierdzanie według reguł zakłada, że część defektów dotrze do main. Rollout sprawia, że pozostają małe. Dopasuj zabezpieczenie po merge’u do klasy, tak jak robi to tabela routingu pakietu dowodów:

Klasa	Po merge’u
low	Zwykły deploy, z monitorem błędów i opóźnień dla zmienionej usługi
standard	Za feature flagiem albo jako canary, promowane, gdy monitor zgłosi „zdrowe”
high	Rollout etapami i bramka zatwierdzenia produkcyjnego

Cokolwiek monitoruje rollout (Rollouts Cursora, analiza canary w twoim systemie CD albo alert SLO), przeprowadź ten test akceptacyjny na stagingu, zanim pozwolisz mu o czymkolwiek decydować:

1. Wdróż build, który zwraca HTTP 500 dla 5% żądań do jednego endpointu. Monitor musi zgłosić regresję w ustawionym oknie czasowym.
2. Wdróż zmianę w usłudze, która na stagingu nie dostaje ruchu. Wynik „brak danych” albo „niejednoznaczny” musi zatrzymać promocję, a nie ją przepuścić.
3. Przejdź ścieżkę revertu. Revert to taki sam pull request jak każdy inny, więc musi przejść ten sam ruleset; potwierdź, że revert zmiany low sam jest low i merguje się bez czekania na człowieka.
4. Zmierz czas od złego deployu do dotarcia revertu na produkcję. Ta liczba to twój realny budżet zasięgu szkód dla low.

Progressive delivery w pełnym zakresie, z flagami, canary i rollbackiem wyzwalanym przez SLO, opisuje strona progressive delivery dla zmian pisanych przez agentów.

Jak to samo zatwierdzanie wygląda w Claude Code i Codex?

Projekt z tej strony jest taki sam we wszystkich trzech narzędziach; różni się tylko to, kto klika Approve.

Cursor

PR Routing & Approval zatwierdza pull requesty spełniające twoje kryteria i prosi o review według własności kodu i historii. Ruleset i CODEOWNERS z tej strony nadal decydują, czy to zatwierdzenie wystarcza do merge’a.

Claude Code

Code Review w Claude Code publikuje uwagi w pull requeście, ale go nie zatwierdza: jego check run „always completes with a neutral conclusion so it never blocks merging through branch protection rules”. Zatwierdzenie dla low daje człowiek czytający pakiet dowodów albo twój własny bot sterowany tymi samymi kryteriami. Zobacz automatyzację review w Claude Code.

Codex

Codex recenzuje pull requesty przez @codex review i automatyczne review, a dokumentacja OpenAI nie opisywała funkcji zatwierdzania pull requestów przy ostatnim sprawdzeniu (2026-08-28). Użyj tego samego rulesetu, etykiet i kroku auto-merge, a low niech zatwierdza człowiek albo twój własny bot. Zobacz Codex GitHub Action.

Prompty do skopiowania: zatwierdzanie i rollout

Prompt do skopiowania: szkic polityki ryzyka i CODEOWNERS na podstawie repozytorium

Read this repository's directory tree, .github/CODEOWNERS (if any), and
.github/evidence-policy.yml (if any). Then propose, without editing any file:

1. Every directory that handles authentication, authorization, money,
   database schema, migrations, or infrastructure, with one line of evidence
   per directory (a file name and what it does).
2. A CODEOWNERS block that routes each of those directories, all test files,
   and all of .github/ to a team placeholder such as @acme/payments.
3. The directories that could safely be risk:low (docs, copy, isolated UI
   behind a flag), and for each, the check that would catch a mistake there.
   If no check covers a directory, say so and do not list it as low.

Output a table for 1 and 3, and the CODEOWNERS block as a code block.

Prompt do skopiowania: cotygodniowy audyt automatycznie zatwierdzonych pull requestów

Here is the TSV output of our audit query for merged risk:low pull requests
over the last 30 days, and the list of pull requests whose title starts with
"Revert" or that are labelled hotfix in the same period.

For each auto-approved pull request, report whether a later revert or hotfix
touched the same files within 14 days. Then compute:
- auto-approval share (I will give you the total merged count),
- auto-approved revert rate,
- any row marked STALE, which is a ruleset failure, listed first.

Finally, pick five pull requests at random for a human to read in full, and
explain in one line each why a reader might find something the evidence missed.
Do not recommend widening the low class unless the revert rate is zero.

Prompt do skopiowania: zamień regresję z rolloutu w check

The rollout monitor reported a regression after pull request #PR_NUMBER merged
as risk:low. The monitor output is below.

1. Open a revert pull request for that merge, with an evidence bundle whose
   rollback field says what the revert restores.
2. On a separate branch, write the failing test or eval that would have caught
   this defect before merge. Show it failing against the reverted code path.
3. Say whether the change class that let it through should move from low to
   standard in .github/evidence-policy.yml, and propose the exact glob change.
Do not edit tests other than the new one, and do not edit CODEOWNERS.

PR_NUMBER to numer zmergowanego pull requesta, który wskazał monitor.

Co się psuje, gdy Cursor zatwierdza pull requesty?

Zatwierdzenie dotyczy commita, który nie jest już najnowszy. Agent wypycha poprawkę po zatwierdzeniu, a pull request merguje się na starym zatwierdzeniu. Naprawa: włącz w rulesecie odrzucanie nieaktualnych zatwierdzeń, zostaw --match-head-commit w kroku auto-merge i szukaj wierszy STALE w zapytaniu audytowym.

Kryteria czytają deklarację agenta. Jeśli kryteria Cursora patrzą na pole class w pakiecie dowodów zamiast na etykietę z CI, agent, który wpisze class: low przy zmianie w rozliczeniach, dostanie zatwierdzenie. Naprawa: kryteria odwołują się wyłącznie do etykiety risk:low, a drugi testowy pull request uruchamiasz ponownie po każdej zmianie kryteriów.

Dwie etykiety ryzyka na jednym pull requeście. Pull request oznaczony low przy pierwszym pushu i high przy drugim zachowa obie, jeśli workflow nie usunie starej. Naprawa: krok etykietowania z punktu 2 plus kryterium 1 („dokładnie jedna etykieta ryzyka”).

Tożsamość Cursora jest w CODEOWNERS albo na liście bypass. Wtedy jego zatwierdzenie spełnia regułę code ownerów dla wrażliwych ścieżek. Naprawa: jako właścicieli wpisuj zespoły ludzi, przejrzyj listę bypass i sprawdzaj autora reviews w zapytaniu audytowym dla zatwierdzeń na przypisanych ścieżkach.

Auto-merge się wykonał, deploy nie. Merge poszedł przez GITHUB_TOKEN, więc workflow na push nie wystartował. Naprawa: merguj tokenem GitHub App jak w kroku 7.

Nowy katalog obsługuje pieniądze i nie pasuje do żadnego globu. Pojawia się src/checkout/, nic go nie łapie, a zmiany w rozliczeniach przychodzą jako low. Naprawa: przeglądaj politykę przy każdym nowym katalogu najwyższego poziomu i trzymaj fixture dla każdego wrażliwego katalogu, żeby zmiana nazwy powodowała błąd w testach checkera.

„Niejednoznaczny” wynik czytany jako „zdrowy”. Monitor bez ruchu do oceny nic nie zgłasza, a rollout idzie dalej. Naprawa: powtórz drugi test akceptacyjny rolloutu i wymagaj jawnego wyniku „zdrowy” przed promocją.

Wszystko staje się low albo nic. Pierwsze wysyła nieprzeczytany kod na produkcję; drugie zostawia seniorów przy zatwierdzaniu literówek. Naprawa: co miesiąc czytaj trzy metryki i przesuwaj po jednym wierszu tabeli ryzyka.

Dokąd dalej: zatwierdzanie i rollout

Pakiet dowodów Warunek wstępny: kontrakt pull requesta i check CI, który liczy klasę ryzyka.

Progressive delivery dla zmian pisanych przez agentów Flagi, canary i rollback wyzwalany przez SLO dla każdej klasy ryzyka.

Czytanie dowodów zamiast kodu Klasy eskalacji i dziennik zaufania, na którym opiera się cotygodniowa próbka.

Review pull requesta agenta Co czyta recenzent przy pull requestach klasy standard.

Bugbot: wyuczone reguły i Autofix Agent recenzujący Cursora, którego uwagi zasilają klasę standard.

Od intencji do produkcji Kompletny potok: auto-merge według klasy ryzyka, rollout, rollback i incydent zamieniony w eval.