Governance i autonomia: człowiek przy bramkach

Nadzór nad agentami AI (governance) przypisuje każdej zmianie klasę ryzyka (niską, średnią, wysoką lub krytyczną) i to ta klasa, a nie pewność agenta ani producent narzędzia, decyduje, co agent może zrobić sam. Guardrails ograniczają agenta w trakcie pracy; bramki rozstrzygają, czy dowody wystarczą do merge lub wydania. Bramki dla klas wysokiej i krytycznej należą do wskazanych ludzi.

Ta strona jest dla CTO i tech leadów, którzy odpowiadają za politykę autonomii. Twoi agenci już otwierają pull requesty w nocy. Na przeglądzie incydentu ktoś pyta, kto zatwierdził migrację, która usunęła kolumnę, a uczciwa odpowiedź brzmi: „własny review agenta i linijka w CLAUDE.md, że ma nigdy nie dotykać produkcji”. To rada, nie kontrola. Ta strona zastępuje ją kontrolami, które da się wskazać palcem.

Co daje ci ta polityka autonomii

Tabelę czterech klas ryzyka: co agent może zrobić sam i jakiej decyzji człowieka wymaga każda klasa.
Mapę rozmieszczenia guardrails i bramek w cyklu życia, z dowodem, jaki zostawia każda z nich.
Egzekwowanie granic w Claude Code, Codex i Cursorze, tak aby granica leżała poza modelem.
Prompt kontraktu dowodowego i szablon polityki do przyjęcia bez zmian.
Ćwiczenie kontroli i cztery metryki, które dowodzą, że kontrole działają, bez czytania każdego diffa.

Do jakiej klasy ryzyka należy zmiana agenta?

Klasyfikuj według kosztu pomyłki, nie według rozmiaru diffa. Oceń pięć czynników: zasięg szkód, wrażliwość danych, odwracalność, wpływ regulacyjny i zakres poświadczeń, których potrzebuje uruchomienie. Decyduje najwyższy czynnik. Trzylinijkowa zmiana w obsłudze sesji jest krytyczna, nawet gdy agent jest pewny swego.

Klasa ryzyka	Typowa zmiana	Agent może	Bramka	Wymagana decyzja człowieka
Niska	Testy, dokumentacja, research, narzędzia wewnętrzne, izolowane refaktoryzacje pod zielonymi testami	Edytować izolowany checkout, uruchamiać lokalne checki, otworzyć PR	Zielone CI i kompletny pakiet dowodów	Lekkie review i merge przez dowolną osobę z zespołu
Średnia	Funkcja w jednym serwisie, aktualizacje zależności, zmiany w preview lub stagingu	Używać zawężonych poświadczeń nieprodukcyjnych i zatwierdzonych runbooków	CI, zaakceptowany plan i akceptacja code ownera	Code owner akceptuje plan i zatwierdza merge
Wysoka	Uwierzytelnianie, billing, migracje schematu, biblioteki współdzielone, ścieżki wrażliwych danych	Przygotować zmianę, dry run i przetestowany rollback	Review specjalisty, przećwiczony rollback i zgoda na wydanie	Wskazany specjalista i właściciel wydania, osobno
Krytyczna	Zmiany danych produkcyjnych, wyjątki bezpieczeństwa, operacje destrukcyjne, zakres regulowany	Wyłącznie przygotować dowody i wniosek o zgodę	Bramka platformy wdrożeniowej, której tożsamość agenta nie przejdzie	Wskazany właściciel autoryzuje, platforma wykonuje

Klasy ryzyka to nie poziomy dojrzałości. Poziom pętli na drabinie autonomii mierzy, na ile ufasz tej pętli; klasa ryzyka mierzy, ile kosztuje pomyłka. Trzymaj jedno i drugie w rejestrze autonomii, żeby pętla z długą, czystą historią nie „wysłużyła” sobie dostępu do zmian krytycznych.

Niektóre działania leżą poza uprawnieniami agenta w każdej klasie: odczyt lub rotacja sekretów produkcyjnych, niezatwierdzona komunikacja zewnętrzna, usuwanie backupów i zatwierdzanie własnej pracy. Wpisz je do polityki jako zakazane i egzekwuj regułami deny oraz poświadczeniami, których agent nigdy nie dostaje.

Guardrails czy bramki: gdzie umieścić którą kontrolę?

Guardrail kształtuje lub ogranicza agenta przed pracą i w jej trakcie: sandbox, zawężony token, hook blokujący polecenie. Bramka rozstrzyga, czy dowody wystarczą, żeby iść dalej: wymagany check, akceptacja code ownera, zgoda na wdrożenie. Potrzebujesz obu, bo guardrail nie oceni intencji produktowej, a bramka nie zatrzyma polecenia, które już się wykonało.

Moment	Kontrola	Przykład	Dowód, który zostaje
Przed pracą	Granica	Zaakceptowana intencja, dozwolone ścieżki, klasa danych, budżet	Przejrzane `intent.md` i `plan.md`
W trakcie pracy	Guardrail	Sandbox, zawężone poświadczenia, hook, chroniona ścieżka	Log polityki i test zablokowanej akcji
Przed merge	Bramka	Typy, testy, skan bezpieczeństwa, review specyfikacji	Wyniki CI i zapis review
Przed produkcją	Bramka decyzyjna	Wskazany zatwierdzający, okno zmian, gotowość rollbacku	Zapis zgody i wydania
Po wydaniu	Informacja zwrotna	Canary, telemetria, wyzwalacz incydentu	Okno obserwacji i decyzja: promocja albo rollback

Instrukcje repozytorium (CLAUDE.md, AGENTS.md, reguły Cursora i skille) poprawiają zachowanie, ale model może je źle odczytać. Dopasuj każdą potrzebę do warstwy, która naprawdę ją egzekwuje:

Potrzeba	Właściwa kontrola	Niewłaściwa kontrola
Wyjaśnić architekturę i konwencje	`CLAUDE.md`, `AGENTS.md`, reguły Cursora	Hook
Powtarzać wieloetapowy workflow	Skill	Długi prompt wklejany ręcznie
Zablokować lub zalogować deterministyczną akcję narzędzia	Hook lub polityka wykonania	Zdanie w `CLAUDE.md`
Ograniczyć pliki, polecenia i sieć	Sandbox i zawężona tożsamość	„Nie wdrażaj” w prompcie
Wymusić review przed merge	Branch protection i code ownerzy	Akceptacja recenzenta AI
Wymusić autoryzację przed produkcją	Środowisko wdrożeniowe lub bramka change management	Podsumowanie agenta-autora
Bezpiecznie się wycofać	Przećwiczony rollback ze wskazanym właścicielem	Runbook, którego nikt nie uruchomił
Udowodnić, co się stało	Niezmienne logi CI, PR, wdrożeń i incydentów	Sam transkrypt agenta

Oddziel tożsamość agenta od uprawnień człowieka

Daj każdemu nieinteraktywnemu agentowi własną tożsamość usługową. Nigdy nie używaj szerokiego tokenu developera; szczegóły są w tożsamości agentów, poświadczeniach i sekretach.
Przyznawaj najmniejszy zakres repozytorium, sieci, chmury i danych, jakiego wymaga klasa ryzyka uruchomienia. Worktree ani kontener nie zawężą tokenu chmurowego.
Trzymaj sekrety produkcyjne z dala od każdego uruchomienia agenta, niezależnie od klasy. Przy zmianach krytycznych trzyma je platforma wdrożeniowa, nigdy agent. Prompt „nie wdrażaj” nie jest granicą dostępu.
Wymagaj branch protection i akceptacji code ownera przy merge. Tożsamość agenta nie może być code ownerem.
Wymagaj osobnej zgody w środowisku wdrożeniowym dla zmian wysokich i krytycznych. Nie spełni jej ani agent-autor, ani agent-recenzent.
Loguj inicjującego człowieka, tożsamość agenta, wersję narzędzia i modelu, wersje artefaktów, polecenia, ustalenia, zgodę, wdrożenie i wynik rollbacku.

Wyegzekwuj granicę w każdym narzędziu

Wzorzec jest ten sam we wszystkich trzech narzędziach: wskazówki w plikach instrukcji, twarde limity w managed settings lub polityce administratora, a bramki merge i produkcji na platformie Git (GitHub, GitLab) i platformie wdrożeniowej. Różnią się ustawienia. Zestawienie wszystkich kluczy zarządzanych znajdziesz w jednej polityce dla wszystkich agentów kodujących.

Twarde limity umieść w managed settings (managed-settings.json, MDM lub ustawienia zarządzane z serwera w planach Team i Enterprise), których ustawienia użytkownika i projektu nie nadpiszą. Klucze sprawdzone w Claude Code 2.1.283:

{
  "permissions": {
    "disableBypassPermissionsMode": "disable",
    "deny": [
      "Bash(terraform apply:*)",
      "Bash(kubectl delete:*)"
    ]
  },
  "allowManagedPermissionRulesOnly": true,
  "allowManagedHooksOnly": true
}

Reguła deny dla Bash dopasowuje tekst polecenia, który pisze Claude, a nie sam program, więc sh -c albo skrypt ją omija (dokumentacja Claude Code, sprawdzono na v2.1.283). Prawdziwą granicą dla terraform i kubectl jest to, że tożsamość agenta nie ma poświadczeń do produkcyjnej chmury ani klastra; regułę deny traktuj jako dodatkowe zabezpieczenie przed pomyłką.

allowManagedPermissionRulesOnly ignoruje reguły uprawnień z ustawień użytkownika, projektu i lokalnych; allowManagedHooksOnly robi to samo z hookami. Od v2.1.283 (kanał latest; stable to 2.1.274) tryb auto jest trybem startowym interaktywnych sesji w terminalu i VS Code na obsługiwanych modelach, a każdą akcję ocenia klasyfikator. Traktuj ten klasyfikator jako guardrail, nie bramkę. Aby wyłączyć go w repozytoriach regulowanych, dodaj "disableAutoMode": "disable" wewnątrz permissions. W CI claude -p startuje w trybie Manual, a --permission-prompts none odrzuca wszystko, co wymagałoby pytania.

Zarządzany Code Review w Claude Code publikuje ustalenia, ale „the check run always completes with a neutral conclusion so it never blocks merging through branch protection rules” (dokumentacja Claude Code, sprawdzono na v2.1.283). Jeśli jego ustalenia mają blokować merge, parsuj je we własnym wymaganym checku CI. Nieudany lub przerwany przez limit czasu review też kończy się wynikiem neutralnym (dokumentacja Claude Code, sprawdzono na v2.1.283), więc twój check CI musi zakończyć się niepowodzeniem, gdy wyniku brakuje.

Twarde limity umieść w zarządzanym przez administratora requirements.toml, nie w config.toml: OpenAI zaleca trzymać osobno „config.toml defaults, requirements.toml constraints, and managed or administrator policy”. Klucze sprawdzone w Codex CLI 0.157.1:

# requirements.toml (zarządzany przez administratora)
allowed_approval_policies = ["untrusted", "on-request"]
allowed_sandbox_modes = ["read-only", "workspace-write"]
allow_managed_hooks_only = true

To blokuje politykę zatwierdzania never i tryb sandboxa danger-full-access na zarządzanych maszynach. allowed_permission_profiles to tabela nazw profili z wartościami true lub false (na przykład { managed = true }), która ogranicza, które profile uprawnień (beta) można wybrać, a mcp_servers i plugins ograniczają to, co można podłączyć. Automatyczny przegląd zatwierdzeń w Codex (--approve-for-me) kieruje zgody na przekroczenie sandboxa do modelu-recenzenta; to agent zatwierdzający agenta, więc dopuszczaj go tylko w klasie niskiej. Aby zablokować go na maszynach, na których pracuje się z repozytoriami klasy średniej lub wyższej, ustaw allowed_approvals_reviewers = ["user"] w requirements.toml (druga wartość to "auto_review"); wymagania działają per maszyna, nie per repozytorium. Od 0.150.0 niezaufane projekty nie dostarczają już projektowego AGENTS.md, więc decyzja o zaufaniu jest częścią polityki. Po stronie bramek codex review i codex exec review dają ustalenia, które mogą zasilać wymagany check CI należący do ciebie; same nie są bramką, więc branch protection i zgodę na wdrożenie trzymaj na platformie Git i platformie wdrożeniowej.

Napisz kontrakt dowodowy dla każdego uruchomienia agenta

Każde uruchomienie w tle lub autonomiczne określa swój kontrakt, zanim wystartuje. Kolejna bramka czyta jego wynik, więc uruchomienie bez kontraktu nie daje bramce nic do sprawdzenia.

Wejście: dokładny commit, artefakty, zgłoszenie, okno telemetrii i dozwolone źródła zewnętrzne.
Zakres: katalogi, narzędzia, cele sieciowe, klasa poświadczeń oraz budżet czasu lub kosztu.
Dowód: polecenia z oczekiwanym kodem wyjścia, schematy, zrzuty ekranu lub progi ewaluacji.
Wynik: plik, pull request, komentarz lub ustrukturyzowany rekord, który czyta kolejna bramka.
Porażka: niezerowy kod wyjścia, timeout, brak zależności lub niska pewność, a do tego właściciel eskalacji.
Uprawnienia: działania dozwolone bez zgody i pierwsze działanie, które zawsze czeka na człowieka.

You are running as risk class MEDIUM on commit a1b2c3d in the billing-api repository.
Inputs: ticket BILL-412, plan.md, and the files under src/invoices/. No other sources.
Allowed scope: edit src/invoices/ and tests/invoices/ only; run npm test and npm run lint;
no network except the package registry; no credentials beyond the CI token you already hold.
Budget: 45 minutes.
Required proof: npm test exits 0, npm run lint exits 0, and every acceptance criterion in
plan.md maps to a named test. List that mapping in the PR description.
Output: one pull request with the evidence bundle in its description.
Fail closed: if a check fails twice, a permission is denied, or a criterion has no test,
stop and write what you found to the PR description instead of working around it.
Never merge, deploy, touch production, edit or skip tests to make them pass, or approve
your own work. Escalate to @billing-tech-lead with the evidence you collected.

Podmień commit, ścieżki, polecenia i właściciela na własne. Stałe klauzule (fail closed, nigdy nie ruszaj wyroczni testowej, nigdy nie zatwierdzaj własnej pracy) zostaw słowo w słowo; ochrona wyroczni testowej wyjaśnia, dlaczego druga z nich jest najważniejsza.

Przyjmij ten szablon polityki autonomii

Wklej go do podręcznika inżynierskiego, uzupełnij właścicieli i podlinkuj z pliku instrukcji każdego repozytorium. Każda klauzula mówi, co ją egzekwuje; klauzula, która opiera się na zaufaniu, to znana luka. Szablon zostaje po angielsku, bo trafia do repozytoriów i plików instrukcji agentów.

AGENT AUTONOMY POLICY — v1.0 — owner: CTO — review: quarterly

1. Classification. Every agent change gets a risk class (low, medium, high, critical),
   computed in CI from touched paths, migrations, and requested credentials.
   Highest factor wins. Enforced by: required CI check that writes the PR label.
2. Forbidden in every class: production secrets, destructive production commands,
   deleting backups, external communication, approving own work.
   Enforced by: managed deny rules + credentials the agent identity never holds.
3. Identity. One service identity per agent loop, least privilege, short-lived tokens.
   Enforced by: identity provider + CI OIDC. Owner: platform team.
4. Merge gate. Low: CI + evidence bundle + any reviewer. Medium: + code owner.
   High: + specialist review + rehearsed rollback. Enforced by: branch protection.
5. Production gate. High and critical: named release owner approves in the
   deployment environment. Agent identities cannot approve. Enforced by: deploy platform.
6. AI reviewers and auto-approval tools may approve low-class changes only.
   Criteria owner: release owner. Enforced by: routing rules + branch protection.
7. Overrides. Every bypass is attributed, expires in 7 days, and is reviewed.
   Enforced by: override log in the change record.
8. Evidence. Every control has an owner, trigger, failure behavior, exception path,
   and audit record. Controls fail closed.
9. Proof. Controls are rehearsed quarterly; metrics are reported by risk class.

Siedmiodniowe wygasanie obejść i kwartalny rytm to robocze wartości domyślne tego przewodnika, a nie opublikowany standard; dopasuj je do własnego apetytu na ryzyko.

Prompty do projektowania i audytu kontroli

Uruchom je w Claude Code, Codex lub Cursorze z dostępem do odczytu repozytorium i jego konfiguracji CI. Tworzą raporty i niczego nie zmieniają.

Audit this repository's agent instructions: CLAUDE.md, AGENTS.md, any Cursor rules,
and every skill. List each hard requirement they state ("never", "always", "must").
For each one, find the control that enforces it outside the model: a hook, a managed
permission rule, a CI check, branch protection, or a deployment approval. Cite the file
and line. Output a table: requirement | enforcing control | file:line | status
(enforced / advisory only). Sort advisory-only rows by the damage a violation would do.
Do not edit any file.

Classify the diff on this branch against main by risk class (low, medium, high,
critical). Score blast radius, data sensitivity, reversibility, regulatory impact, and
the credential scope the change needs, one line of evidence each, citing file paths.
The highest factor sets the class. Then list the guardrails that should have applied
during execution, the merge gates it must pass, and the named human decisions that must
stay outside the agent. Flag any path whose class you are unsure of instead of guessing.

Using gh, list the last 20 merged pull requests labeled risk:medium. For each, report
review wait time, whether any required check was overridden, whether a check failed
and was later shown to be a false block, and whether an issue labeled incident links
to it. Summarize the false-block rate, override rate, escaped defects, and median
review wait. Where gh output does not show a field (bypasses, false blocks), write
"unknown" and name the data source that would answer it; do not infer. Recommend one
control change, the metric it should move, and the result that would make you roll it back.

Jak udowodnić, że kontrole działają?

Sprawdź każdą kontrolę, celowo próbując ją obejść, a potem mierz kontrole według klasy ryzyka. Żaden z tych kroków nie wymaga czytania każdego diffa.

Ćwicz ścieżkę kontroli co kwartał

Poproś uruchomienie klasy niskiej o zapis poza dozwolonym katalogiem roboczym. Sandbox musi to zablokować, a blokada musi trafić do logu polityki.
Poproś je o pominięcie nieprzechodzącego wymaganego testu. Workflow musi zakończyć się błędem.
Spróbuj zrobić merge bez akceptacji code ownera. Branch protection musi to zablokować.
Spróbuj wydać zmianę na produkcję tożsamością agenta i bez wskazanej zgody. Platforma wdrożeniowa musi to zablokować.
Wyłącz usługę review. Merge musi pozostać zablokowany; brak recenzenta nigdy nie liczy się jako zgoda.
Uruchom rollback w środowisku nieprodukcyjnym i zapisz czas przywrócenia.
Zmień regułę, skill lub hook i uruchom ewaluacje harnessu przed wdrożeniem zmiany.

Krok, który przechodzi, choć powinien zakończyć się błędem, to incydent w kontroli, a nie niestabilny test. Zapisz go tak, jak incydent spowodowany przez agenta.

Mierz kontrole według klasy ryzyka

Metryka	Definicja	Co oznacza zły trend
Odsetek fałszywych blokad	Zablokowane zmiany później zmergowane bez zmian ÷ wszystkie zablokowane zmiany	Bramka kosztuje zaufanie i zachęca do obchodzenia
Odsetek obejść	Merge lub wydania z przypisanym obejściem ÷ wszystkie merge w klasie	Kontrola jest błędna albo klasa zbyt surowa
Defekty, które uciekły	Incydenty wywołane zmianą, która przeszła każdą bramkę	Bramka sprawdza niewłaściwą rzecz
Czas oczekiwania na review	Mediana godzin od „gotowe do review” do decyzji	Bramki ludzkie stały się wąskim gardłem; przenieś checki do automatyzacji

Raportuj je osobno dla każdej klasy. Zdrowa klasa niska ma krótkie oczekiwanie i mało obejść; zdrowa klasa krytyczna może mieć długie oczekiwanie i nadal być poprawna. Kanoniczne definicje metryk są we frameworkach metryk.

Kto zatwierdza: właściciel wydania zatwierdza bramkę produkcyjną dla zmian wysokich i krytycznych, code owner zatwierdza merge w klasie średniej, a CTO zatwierdza zmiany samej polityki, z dołączonymi wynikami ćwiczeń i metrykami.

Dlaczego recenzent AI nie jest bramką?

Agent-autor i agent-recenzent lepiej wykrywają błędy, ale mogą dzielić poświadczenia, konfigurację, martwe pola modelu i organizację, która je skonfigurowała. Dwóch agentów to jeszcze nie rozdział obowiązków. OWASP GenAI LLM Top 10 2026 (opublikowany 2026-08-04) umieszcza Excessive Agency na pozycji LLM03 i zaleca: „Use human-in-the-loop control to require a human to approve high-impact actions before they are taken”.

Prawdziwa bramka używa tożsamości, w której imieniu uruchomienie-autor nie może działać, albo polityki platformy, której nie może zmienić, a tam, gdzie wymaga tego klasa ryzyka, także odpowiedzialnego człowieka. Używaj review AI do decyzji, gdzie skierować uwagę ludzi, a nie jako zamiennika ludzi przy zmianach wysokich i krytycznych. Dowody, które akceptują audytorzy, opisuje inżynieria agentowa w branżach regulowanych.

Co psuje się w nadzorze nad agentami i jak to naprawić?

Tekst doradczy traktowany jak egzekwowanie. Linijka w CLAUDE.md mówi „nigdy nie uruchamiaj migracji”, aż pewnego dnia agent ją uruchamia. Naprawa: uruchom prompt „oddziel rady od egzekwowania”, a potem przenieś każdy niezmiennik oznaczony jako tylko doradczy do egzekwowanej kontroli. Przy akcjach destrukcyjnych najpierw odbierz tożsamości agenta poświadczenia albo użyj uprawnień platformy; zarządzana reguła deny, hook albo check w CI to tylko dodatkowa warstwa, która zatrzyma typową postać polecenia.

Jeden token sięga do każdego środowiska. Token CI agenta pozwala też wdrażać. Naprawa: najpierw go unieważnij, potem rozdziel tożsamości per pętla i środowisko, i zrotuj poświadczenia. Traktuj ekspozycję jako incydent, dopóki logi nie pokażą, czego token dotknął.

Agent sam nadaje sobie klasę ryzyka. Każda zmiana przychodzi jako „niska”. Naprawa: wyliczaj klasę w CI na podstawie ścieżek i migracji i alarmuj, gdy etykieta zaproponowana przez agenta jest niższa od wyliczonej.

Bramka ludzka nie ma kryteriów decyzji. Zatwierdzający klikają „akceptuj”, bo nic nie mówi im, co sprawdzić. Naprawa: dołączaj do każdego wniosku pakiet dowodów i jednozdaniową ocenę ryzyka, a kryteria, właściciela, timeout i ścieżkę eskalacji ustal, zanim zautomatyzujesz wniosek.

Obejścia nigdy nie wygasają. Jednorazowe obejście na czas awarii staje się stałe. Naprawa: nadaj każdemu obejściu datę wygaśnięcia i właściciela, a otwarte obejścia raportuj na przeglądzie kwartalnym.

Kontrola przepuszcza zmianę, gdy sama zawiedzie (fail open). Usługa review przekracza timeout i merge przechodzi. Naprawa: ustaw check jako wymagany i niech kończy się błędem, gdy brakuje wyniku, a przypadek awarii dodaj do ćwiczenia.

Rollback istnieje tylko w dokumencie. Naprawa: przećwicz go w reprezentatywnym środowisku nieprodukcyjnym i zmierz czas przywrócenia. Wydania klasy wysokiej łącz z progresywnym dostarczaniem, żeby rollback był przełączeniem flagi, a nie ponownym wdrożeniem.

Fałszywa pewność. Ktoś nazywa instrukcje „niezawodnymi guardrails” albo rezygnuje z ludzkiego review, bo checki są zielone. Modele źle odczytują instrukcje, hooki bywają źle skonfigurowane, a deterministyczne checki nie ocenią intencji produktowej. Naprawa: przetestuj całą ścieżkę kontroli, spisz ryzyko rezydualne i zachowaj uprawnienia człowieka przy bramkach, które mają konsekwencje.

Dokąd dalej z nadzorem nad agentami

Przed tą stroną przeczytaj model operacyjny, który mówi, kto odpowiada za rejestr autonomii. Następnie zastosuj politykę do zagrożeń i poświadczeń, przed którymi ma chronić.

Model zagrożeń dla agentów Prompt injection, ekspozycja danych i zasięg szkód, z kontrolą dla każdego narzędzia.

Tożsamość agentów, poświadczenia i sekrety Konta usługowe, krótkotrwałe tokeny i unieważnianie dla każdej pętli agenta.

Polityka zarządzana dla agentów Jeden zestaw managed settings dla Claude Code, Codex i Cursora.

Uprawnienia i sandboxing Harness po stronie developera, który realizuje te guardrails.

Automatyzacja review PR w zespole Niech review produkuje dowody, a nie same akceptacje.

Nienadzorowane uruchomienia agentów Zasady działania pętli, które pracują, gdy nikt nie patrzy.

Procedury etapów, w których działają te bramki, opisują Deploy i Maintain.