Code review i wdrożenie z Cursorem

Bezpieczne wdrażanie kodu napisanego w Cursorze polega na ułożeniu kontroli między diffem a produkcją: review przed pushem, Bugbot na pull requeście, deterministyczne bramki CI, zatwierdzanie według reguł tylko dla zmian niskiego ryzyka i monitorowany rollout. Recenzenci Cursora zgłaszają uwagi; o merge’u decydują testy, klasa ryzyka liczona w CI i wskazany z imienia właściciel.

Ta strona jest dla programistów i tech leadów, których agenci w Cursorze otwierają więcej pull requestów, niż zespół jest w stanie przeczytać. Schludne diffy ukrywają błędy: poluzowaną asercję, brakujące sprawdzenie uprawnień, migrację bez uzupełnienia danych. Strony poniżej zastępują czytanie linia po linii sprawdzalnymi bramkami.

Która strona o wdrażaniu z Cursorem odpowiada na twoje pytanie?

Twoje pytanie	Strona
Który recenzent Cursora działa gdzie i jak zrobić triaż pull requesta?	Code review w Cursorze
Jak dostroić reguły Bugbota i Autofix?	Bugbot: wyuczone reguły i Autofix
Jak bezpiecznie pozwolić Cursorowi zatwierdzać pull requesty niskiego ryzyka?	Rollouts oraz PR Routing & Approval
Jak zbudować pipeline GitHub Actions albo uruchomić w CI agenta tylko do odczytu?	Pipeline’y CI/CD z Cursorem
Jak pisać konfigurację Terraform, Docker i Kubernetes?	Infrastruktura jako kod z Cursorem

Bramka review jest tylko tak mocna jak testy, które za nią stoją; najpierw napisz je według strony testowanie i debugowanie z Cursorem.

W jakiej kolejności zmiana z Cursora powinna trafić na produkcję?

Najpierw uruchom tanie, prywatne kontrole.

Przed pushem. Uruchom testy, sprawdzanie typów i linter, a potem jedno przejście review po gałęzi: Agent Review względem gałęzi głównej albo /review-bugbot. Checklistę review trzymaj w .cursor/BUGBOT.md: czytają ją Bugbot i Agent Review, a Bugbot pomija .cursor/rules/ (dokumentacja Cursora, nieoficjalne lustro na GitHubie odczytane 26 września 2026).
Na pull requeście. Bugbot recenzuje diff, a w planach Teams i Enterprise Security Agents uruchamiają włączone przez ciebie kontrole. Przebieg Bugbota, który znajdzie problemy, domyślnie kończy się statusem neutral, a nie failure, więc wymaganie tego checka dowodzi tylko, że Bugbot się uruchomił. Przejście /review-bugbot przed pushem na tym samym diffie sprawia, że Bugbot pomija pull request; na ścieżkach high pomiń /review-bugbot przed pushem albo zmień diff. Komentarz bugbot run w pull requeście może ponownie uruchomić recenzję, ale dokumentacja Cursora nie mówi, że omija to pominięcie, więc sprawdź, czy check rzeczywiście się wykonał.
W CI. Testy, typy, linter i check pakietu dowodów działają na commicie HEAD pull requesta, ale z definicjami workflow pobranymi z gałęzi bazowej, i wyliczają klasę ryzyka: low, standard albo high. Własny recenzent Cursora w CI dostaje narzędzia tylko do odczytu i żadnego tokenu z prawem zapisu.
Przy zatwierdzaniu. PR Routing & Approval przydziela recenzentów według własności kodu i może zatwierdzić pull request low, który spełnia twoje kryteria. O merge’u decyduje ruleset GitHuba; CODEOWNERS przypisuje migracje, uwierzytelnianie, rozliczenia, publiczne API, testy i konfigurację CI do konkretnej, wskazanej osoby.
Po merge’u. Zmiany standard wychodzą za flagą funkcji albo jako wdrożenie kanarkowe (canary); zmiany high dostają rollout etapowy. Promocję musi zatrzymać bramka twojego własnego systemu CD, gdy sygnału brakuje albo jest niejednoznaczny, a ścieżka revertu musi być przećwiczona. O funkcji Rollouts Cursora i teście akceptacyjnym, który musi przejść każdy monitor rolloutu, przeczytasz w Rollouts oraz PR Routing & Approval.

Review this branch cold; you did not write it. Do not edit any files.
1. Run `git diff main...HEAD --stat`, then our test, typecheck and lint commands
   from package.json. Report each command and its exit code; never claim a result
   you did not run.
2. List every change to an existing test or assertion as stricter, neutral or
   looser, quoting before and after for each looser one.
3. List every changed path under migrations, authentication, billing, public API
   routes, tests or .github/, so a code owner can review those first.
4. Apply .cursor/BUGBOT.md to the changed lines only; one line per finding with file:line.
End with one line: READY, or NOT READY and the reason.

Read the diff against main, .github/workflows/ and any migration in this branch.
Write docs/releases/rollout.md: deploy order, the flag or canary step, three
signals to watch for 30 minutes, the exact revert command, and whether a
migration makes rollback unsafe. Run no deploy or migration command.

Skąd wiesz, że zmianę z Cursora można wdrożyć bez czytania każdej linii?

Każda bramka produkuje dowód, który ma właściciela. Diff otwieraj tylko tam, gdzie wskazują dowody.

Dowód	Czego dowodzi	Właściciel
Zielone CI na commicie HEAD: testy, typy, linter, pakiet dowodów	Dotychczasowe zachowanie działa; zmiana deklaruje, czego dotknęła	CI, skonfigurowane z gałęzi bazowej
Etykieta ryzyka wyliczona przez CI, nie przez agenta	Agent może podnieść klasę, nigdy jej obniżyć	Właściciel `.github/` w `CODEOWNERS`
Zatwierdzenie właściciela kodu na ścieżkach eskalacji	Człowiek przyjął ryzyko tam, gdzie pomyłka kosztuje najwięcej	Wskazany właściciel kodu
Monitor rolloutu, który przeszedł test ze wstrzykniętą awarią	Produkcja potwierdza zmianę albo szybko ją cofniesz	Dyżurny inżynier

Triaż opisuje code review PR-a agenta bez czytania każdej linii, a uzasadnienie strona dowody zamiast diffów. Odsetek celowo wstrzykniętych błędów, które wychwytują recenzenci, zmierzysz według strony o Bugbocie.

Co psuje się między review w Cursorze a działającym wdrożeniem?

Objaw	Przyczyna	Jak naprawić
Bugbot ignoruje twoją checklistę review	Bugbot nie czyta `.cursor/rules/`	Przenieś ją do `.cursor/BUGBOT.md`; zostaw krótką regułę projektu, która do niej odsyła
Pull request z błędem przechodzi z zielonym Bugbotem	Check zgłasza uwagi jako `neutral` i niczego nie blokuje	Traktuj uwagi Bugbota jako jedną z przesłanek dla klasy `standard`, nie jako bramkę merge’u; decyzję zostaw testom i właścicielowi kodu. Jeśli to możliwe, włącz blokowanie na nierozwiązanych uwagach
Cursor zatwierdza pull request, który dotyka rozliczeń	Klasa ryzyka pochodziła z opisu agenta	Wyliczaj klasę w CI na podstawie ścieżek; deklaracja agenta może ją tylko podnieść
Pull request kontrybutora osłabia własne review	Workflow albo prompt załadował się z gałęzi pull requesta	Ładuj oba z gałęzi bazowej; zobacz tożsamość agentów i sekrety
Monitor rolloutu uznaje za zdrową zmianę, która zepsuła produkcję	Sprawdzane sygnały nie miały telemetrii (luka w instrumentacji)	Przed merge’em dodaj instrumentację tych sygnałów; w CD traktuj brak danych jak nieudany check
Rollback pada na produkcji	Migracja usunęła dane, których potrzebuje stary kod	Rozbij ją według wzorca expand and contract; stosuj progressive delivery

Dokąd dalej z wdrażaniem zmian z Cursora

Eksploatacja tego, co wdrożone Monitoring, wydajność i bezpieczeństwo systemów zbudowanych w Cursorze na produkcji.

Wdrażanie z każdym agentem Wspólny pakiet dowodów, code review pull requestów i progressive delivery.

Używasz też innego agenta? Ten sam etap opisują strony przegląd i wdrożenie z Claude Code oraz przegląd i wdrożenie z Codexem.