Deploy: recenzuj w obie strony, bramkuj produkcję

Etap deploy daje każdemu pull requestowi powtarzalne, priorytetyzowane review agentowe, zachowując ludzką odpowiedzialność za merge i produkcję. Automatyczne przejścia sprawdzają błędy, bezpieczeństwo i zgodność ze specyfikacją, a ochrona gałęzi oraz akceptacje środowisk nie pozwalają agentowi przekroczyć bramki wydania.

Tradycyjnie: Capacity review planowano wokół ludzkiego outputu. PR czeka, aż reviewer przeczyta całość. Jakość review waha się z obciążeniem. Autor goni, a backlog rośnie.

AI-native: Wszystkie PR-y dostają identyczny zestaw przejść review, z findings rankingowanymi według severity. Ludzka uwaga przesuwa się o poziom wyżej: czy zmiana robi to, co plan zamierzał, i czy ryzyko jest akceptowalne?

Recenzowanie każdej linii ręcznie miało sens, gdy pisała ją osoba. Nie nadąża, gdy agenci piszą większość diffa. Ludzka recenzja jest zarezerwowana dla kodu regulowanego i krytycznego; wszystko inne najpierw recenzuje agent.

Zanim zaczniesz

Zaktualizowany plik instrukcji projektu z Build
Skills, jeśli przejścia review egzekwują spisane polityki
Branch protection wymagające akceptacji code ownera

Prerequisites: Claude / Cursor / Codex w pętli PR oraz hooki jako bramki akceptacji, zanim zautomatyzujesz cokolwiek przez te bramki.

Wstaw agenta w pętlę PR review

Włącz integrację review vendora.

Claude Code: managed Code Review (najszybszy start) lub claude-code-action we własnym CI (Bedrock, Vertex lub Foundry, gdy ruch musi zostać na Twojej umowie chmurowej). Cursor: Bugbot na repozytorium plus /review lub /review-bugbot przed pushem. Codex: openai/codex-action@v1 uruchamiający codex exec z pliku promptu.
Napisz REVIEW.md w rootcie repo.

Podziel go na przejścia, na których zależy organizacji: bugi i błędy logiczne; security; compliance względem spec.md, plan.md i zasad designu. Zdefiniuj, co liczy się jako Important versus Nit, i co pomijać.
Ustaw ludzki próg.

Findings same z siebie nie akceptują ani nie blokują PR. Branch protection nadal wymaga code ownera. Jeśli chcesz bramkować merge’e findingsami, czytaj severity counts, które publikuje check run.
Pozwól agentowi adresować komentarze review na własnych PR-ach.

Otagowanie bota na komentarzu powinno produkować fix commit. Zawiń pętlę w slash command lub skill, który zamiata nierozwiązane komentarze i failing checki, aż PR jest zielony i czeka tylko na akceptację code ownera. Agent, który napisał kod, nie ma ścieżki do jego zatwierdzenia.
Wrzucaj findings z review z powrotem do pliku instrukcji.

Gdy review flaguje ten sam błąd drugi raz, korekta trafia do CLAUDE.md / rules / AGENTS.md jako część tego review.
Raz w miesiącu dostrój setup.

Oceń findings, żeby reviewer się poprawiał. Ogranicz wolumen Nitów w REVIEW.md. Wyklucz wygenerowane ścieżki i wszystko, co CI już egzekwuje.

Przykładowy REVIEW.md:

# Review instructions

## Passes
Run three passes and tag each finding with its pass:
- Bugs: logic errors, broken edge cases, subtle regressions
- Security: injection risks, authentication gaps, PII in logs
- Compliance: the change matches spec.md, plan.md and our design principles

## What Important means here
Reserve Important for findings that would break behavior, leak data,
or breach a policy. Style and naming are nits.

## Cap the nits
Report at most five nits per review; summarize the rest as a count.

## Do not report
Generated files under src/gen/ and anything CI already enforces.

Hooki jako bramki akceptacji

Hooki fazy build pozwalają lub blokują bez udziału człowieka. Hook release’owy pyta: pauzuje, aż konkretna osoba zatwierdzi.

Wymień ludzkie bramki akceptacji, które muszą przetrwać: sign-off change-management, autoryzacja release’u, edycje chronionych ścieżek.
Wyraź każdą bramkę jako hook (lub najbliższy odpowiednik Codex/Cursor), który może allow, ask lub block.
Trzymaj team hooks w gicie. Trzymaj niepodlegające negocjacji hooki w managed settings należących do platformy lub admina IT, gdzie indywidualni inżynierowie nie mogą ich wyłączyć.
Gdy hook zatrzymuje akcję, powód i ścieżka do akceptacji pojawiają się w outputcie agenta.

Przykład Claude Code (.claude/hooks/production-gate.sh za matcherem PreToolUse na Bash):

#!/bin/bash
# Production deploys require a named release authorization
cmd=$(jq -r '.tool_input.command' < /dev/stdin)
if [[ "$cmd" == *"deploy"* && "$cmd" == *"production"* ]]; then
  if [ -z "$RELEASE_APPROVAL" ]; then
    echo "Production deploys need a release authorization." >&2
    exit 2
  fi
fi
exit 0

Exit code 2 blokuje akcję; wiadomość idzie do agenta.

Cursor: zakoduj tę samą bramkę jako hook beforeShellExecution w .cursor/hooks.json. Na Enterprise ustaw też team i enterprise-managed hooks w dashboardzie, żeby Cloud Agents je podchwyciły.

Codex: nie ma VM hooków identycznego z Claude Code. Połącz sandbox (workspace-write versus danger-full-access), approval_policy oraz job CI, który odmawia credentiali deployu produkcyjnego tożsamości agenta.

Jak te kontrole składają się w skali produkcji, zobacz How Anthropic secures its AI-native SDLC.

CI/CD

Zacznij od kroków osądu tylko do odczytu w pipeline: triage failed builda, podsumuj flaky test, zdraftuj changelog (claude -p lub codex exec).
Dodaj kroki zapisu za istniejącymi bramkami: fix lint, aktualizacja wygenerowanych docs, adresowanie komentarzy review. Wszystko, co agent napisze, przychodzi jako PR. Agent nie ma ścieżki do pusha na main.
Sandboxuj joby agenta: kontenery, network policy, krótkie scoped tokeny, bez standing credentiali produkcyjnych.
Udostępniaj deploy, status i rollback przez MCP, scoped per środowisko, żeby moc deploymentu była allowlistą.
Stopniuj autonomię według środowiska. W jednorazowym lokalnym lub development sandboxie agent może wykonać procedurę wdrożenia z ograniczonymi credentials. Dla produkcji agent przygotowuje dowody; release manager autoryzuje promocję; kontrole poza modelem egzekwują bramkę. Staging ma własną udokumentowaną klasę ryzyka.
Ćwicz rollback na stagingu, aż będzie jedną komendą, którą agent może uruchomić. Maintain woła tę ścieżkę przy naruszeniu pasma kontrolnego.

Governance

Zasada rządząca: agent może działać aż do bramki produkcji i nie może jej przejść.

Branch protection zamienia wszystko, co agent napisze, w PR.
Hook deployu produkcyjnego blokuje release, aż nazwany release manager go autoryzuje.
Każdy nieinteraktywny run działa pod własną tożsamością agenta, więc log pipeline rozdziela to, co zrobił agent, od tego, co zrobił inżynier, który go odpalił.
Per-environment permission tiers ustalają, ile agent może zrobić w drodze do bramki.

Separation of duties jest zachowane, bo agent, który napisał kod, nie ma sposobu go zatwierdzić. PR jest rekordem audytu.

Verify

PR otwarty przez agenta dostał automatyczne przejście review w ciągu minut.
Merge nadal wymaga ludzkiego code ownera.
Komenda deployu produkcyjnego bez RELEASE_APPROVAL (lub odpowiednika Cursor/Codex) jest blokowana.

Wskaźnik wiodący: czas do pierwszego review; udział komentarzy review rozwiązanych bez ludzkiego dotknięcia brancha.

Wskaźnik opóźniony: defekty i podatności złapane przed mergem versus te, które uciekły na produkcję; miary DORA, które system CI już emituje.

Zastosuj praktykę w swoim narzędziu

Adapter Claude Code Użyj managed review lub claude-code-action przed chronionym mergem i wydaniem.

Adapter Cursora Użyj Bugbota i Autofix jako dowodu przed chronionym mergem i wydaniem.

Adapter Codex Użyj codex review lub openai/codex-action@v1 przed bramkami platformy.

Zwróć dowody z produkcji do planowania

Zamknij pętlę z produkcji — Maintain.