Bugbot: wyuczone reguły i Autofix

Bugbot to agent Cursora do code review pull requestów: sprawdza każdy pull request pod kątem błędów, problemów bezpieczeństwa i jakości kodu, stosuje reguły z plików .cursor/BUGBOT.md oraz reguły wyuczone z review zespołu, a przez Autofix może przekazać znaleziska Cloud Agentowi. Domyślnie jego check zgłasza znaleziska, ale nie kończy się błędem, więc informuje bramkę merge’a, a nie nią jest.

Ta strona jest dla developera, który włącza Bugbota, i dla tech leada, który utrzymuje jego przydatność. Po miesiącu od wdrożenia obraz jest znajomy: Bugbot na każdym pull requeście zgłasza ten sam wygenerowany plik, połowa jego komentarzy kończy jako „won’t fix”, checklista review leży w katalogu .cursor/rules/, którego Bugbot nie czyta, a Autofix wypchnął commit na gałąź w połowie review przez człowieka. Każda z tych sytuacji to decyzja konfiguracyjna, a nie problem modelu.

Co daje dobrze dostrojony Bugbot

Układ głównego .cursor/BUGBOT.md i plików dla ścieżek, który trzyma znaleziska przy realnych ryzykach zespołu.
Rutynę dla wyuczonych reguł: uczysz, czytasz i przenosisz te, na których polegasz, do kontroli wersji.
Politykę Autofixa dla każdego repozytorium, z uzasadnieniem każdego trybu i bramkami, przez które jego commity nadal muszą przejść.
Test z podłożonymi defektami i zapytanie analityczne, które pokazują, czy Bugbot łapie błędy, a nie tylko czy komentuje.
Jasne miejsce Bugbota w warstwowym review pull requestów, obok CI, właścicieli kodu i pakietu dowodów.

Gdzie Bugbot mieści się w warstwowym review?

Bugbot to warstwa, która czyta diff z osądem; nie decyduje o merge’u. Check publikowany przez Bugbota na GitHubie nazywa się Cursor Bugbot, a przebieg, który znalazł problemy, kończy się konkluzją neutral, chyba że twoja organizacja włączyła opcję, która kończy check niepowodzeniem przy nierozwiązanych znaleziskach. Wymaganie tego checka w ochronie gałęzi gwarantuje więc, że Bugbot się uruchomił, a nie że jego znaleziska zostały obsłużone.

Warstwa	Co udowadnia	Kto lub co za nią odpowiada
Lokalne review przed pushem	Diff autora przeszedł jedno review, zanim zobaczy go ktokolwiek inny	Autor, z Agent Review albo skillem `/review-bugbot`
Deterministyczne bramki CI	Typy, lint, testy i pakiet dowodów przechodzą na ostatnim commicie	CI, z konfiguracją z gałęzi bazowej
Bugbot	Błędy logiczne, pominięte przypadki brzegowe i naruszenia reguł, których nie wyrazi linter	Bugbot, z regułami utrzymywanymi przez zespół
Review bezpieczeństwa	Wstrzyknięcia, sekrety, autoryzacja i ryzyka zależności	Security Agents Cursora albo twój własny skaner
Akceptacja człowieka	Intencja, architektura i ścieżki wysokiego ryzyka	Wskazany właściciel kodu, który czyta dowody, a przy ryzyku `high` także kod
Rollout	Zachowanie na produkcji	Canary, flagi i monitory

Wynikają z tego trzy rzeczy. Po pierwsze, znaleziska Bugbota zasilają klasę ryzyka standard; niczego nie zatwierdzają. Rollouts oraz PR Routing & Approval opiera zatwierdzanie według reguł na etykietach ryzyka liczonych przez CI. Po drugie, jeśli przed pushem uruchomisz w edytorze /review-bugbot, Bugbot zapisze patch ID sprawdzonego diffu i pominie review pull requesta, gdy przyjdzie ten sam diff, więc pull request nie ma świeżego przebiegu Bugbota. Po trzecie, review jest domyślnie przyrostowe: po pierwszym przebiegu każdy push jest sprawdzany tylko pod kątem zmian od poprzedniego review Bugbota. Błąd, który wymaga wczesnego i późnego commita naraz, może prześlizgnąć się między przebiegami, więc tam, gdzie polegasz na Bugbocie przy ścieżkach ryzyka high, wyłącz Incremental Review.

Skonfiguruj Bugbota w repozytorium

Reguły trafiają na miejsce przed pierwszym automatycznym review, więc pierwsze wrażenie zespołu to nie ściana szumu.

Podłącz system kontroli wersji. W panelu Cursora podłącz GitHuba (także GitHub Enterprise Server), GitLaba (także self-hosted), Bitbucketa (także Data Center) albo Azure DevOps Services. Na GitHubie Bugbot komentuje potem jako cursor[bot], konto aplikacji GitHuba Cursora.
Zacommituj główny .cursor/BUGBOT.md, zanim włączysz review. Zacznij od pliku z następnej sekcji. Krótki plik z listą „nie zgłaszaj” daje więcej sygnału niż długa checklista.
Włącz Bugbota w jednym repozytorium. Otwórz Bugbota w sekcji Automations panelu Cursora i włącz go dla jednego, aktywnego repozytorium. W planach zespołowych Bugbot sprawdza wtedy pull requesty wszystkich kontrybutorów tego repozytorium, niezależnie od tego, czy należą do zespołu w Cursorze. W planie indywidualnym sprawdza tylko pull requesty, których jesteś autorem.
Wybierz, kiedy ma działać. W repozytorium pilotażowym zostaw automatyczne review. Ustawienia repozytorium oferują Incremental Review (domyślnie włączone), Post PR Summary (w opisie, jako komentarz albo wyłączone) oraz, w planach rozliczanych według zużycia, poziom wysiłku: Low, Default, High albo Smart, gdzie Smart przyjmuje instrukcję zwykłym językiem, na przykład „High dla wszystkiego w src/billing/”. Podnoś wysiłek tylko tam, gdzie test z podłożonymi defektami (niżej) pokazuje przeoczone błędy; kosztuje to więcej zużycia. Przełączniki częstotliwości działają na trzech poziomach:
- Instalacja: admini zespołu mogą ustawić Run only once na pull request.
- Ustawienia osobiste (członkowie zespołu i enterprise): Run only when mentioned, Run only once i Enable reviews on draft PRs, dla własnych pull requestów.
- Repozytorium: manualTriggerOnly w Admin API (krok 7) sprawia, że Bugbot działa tylko po wywołaniu.
Udowodnij, że reguły się ładują. Otwórz mały pull request i dodaj komentarz:
```
bugbot run verbose=true
```
Bugbot publikuje tabelę wszystkich reguł użytych w tym przebiegu, oznacza reguły obcięte lub pominięte i podaje request ID dla supportu. cursor review verbose=true działa tak samo. Jeśli twojego BUGBOT.md nie ma w tabeli, napraw to, zanim pójdziesz dalej.
Wymagaj checka, potem zdecyduj, czy ma blokować. Dodaj Cursor Bugbot do wymaganych checków w zestawie reguł ochrony gałęzi (ruleset), żeby żaden pull request nie wszedł przed przebiegiem Bugbota. Jeśli twoja organizacja ma opcję, która kończy check niepowodzeniem przy nierozwiązanych znaleziskach, włącz ją dopiero po teście z podłożonymi defektami i dwóch tygodniach niskiego szumu; czerwony check, który zespół nauczył się ignorować, jest gorszy niż neutralny.

Rozszerzaj wdrożenie skryptem. Gdy pilotaż przejdzie sprawdziany opisane dalej, admin zespołu może włączać kolejne repozytoria przez Admin API Bugbota. manualTriggerOnly: true włącza repozytorium w trybie ręcznym, co jest bezpiecznym startem dla repozytorium bez BUGBOT.md:

# Terminal. CURSOR_ADMIN_API_KEY to zespołowy Admin API key czytany z magazynu sekretów.
curl -sS -X POST https://api.cursor.com/bugbot/repo/update \
  -H "Authorization: Bearer $CURSOR_ADMIN_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"repoUrl": "https://github.com/acme/orders-api", "enabled": true, "manualTriggerOnly": true}'

# Lista wszystkich repozytoriów z ustawieniami Bugbota, do sprawdzenia wdrożenia.
curl -sS https://api.cursor.com/bugbot/repos -H "Authorization: Bearer $CURSOR_ADMIN_API_KEY"

Napisz `BUGBOT.md`, który utrzyma wysoki sygnał

Bugbot zawsze dołącza główny .cursor/BUGBOT.md, a potem kolejne pliki .cursor/BUGBOT.md, które znajdzie, idąc w górę od każdego zmienionego pliku. Reguły dla całego repozytorium umieść w pliku głównym, a ostrzejsze obok kodu, którego dotyczą:

orders-api/
  .cursor/BUGBOT.md              # dołączany zawsze
  src/billing/.cursor/BUGBOT.md  # dołączany, gdy zmienia się plik w billingu
  migrations/.cursor/BUGBOT.md   # dołączany, gdy zmienia się migracja

BUGBOT.md to jedno z czterech źródeł reguł. Bugbot łączy je w jeden blok w tej kolejności: reguły zespołu (pisane przez adminów zespołu w ustawieniach Bugbota i stosowane w każdym włączonym repozytorium), potem pliki BUGBOT.md projektu, potem reguły wyuczone, na końcu reguły ręczne. Niezmienniki całej organizacji, takie jak „nigdy nie loguj tokenu”, umieść w regułach zespołu, a najważniejsze oznacz jako wymagane: po przekroczeniu limitu opisanego dalej w tej sekcji Bugbot traktuje wymagane reguły zespołu priorytetowo, więc trzymaj łączną długość poniżej limitu, zamiast na tym polegać.

Reguły projektu Cursora (pliki .mdc w .cursor/rules/) nie działają w przebiegach Bugbota. Jeśli jedna reguła jest ważna i dla agenta, i dla review, zapisz ją w obu miejscach.

Pisz reguły jako warunki, które Bugbot sprawdzi w diffie („handler, który robi await bez obsługi odrzucenia”), a nie jako wartości („pisz solidny kod”). Proś Bugbota, żeby cytował regułę, tak jak robi to publiczny BUGBOT.md Sentry dla jego SDK JavaScript, dzięki czemu recenzent prześledzi hałaśliwe znalezisko do źródła. I trzymaj pliki krótko: każda reguła jest obcinana do 30 000 znaków, a łączne reguły jednego review mają limit 100 000 znaków, po którego przekroczeniu część reguł wypada. Główny plik dla serwisu API w TypeScripcie:

# Review rules for orders-api

Flag only issues you can tie to a line in this diff. When a finding comes
from this file, say so in the comment and name the section.

## Always flag
- A handler in src/routes/ that awaits a call without handling rejection.
- Money stored or computed as a JavaScript number. Amounts are integer
  cents (bigint) or Decimal from src/lib/money.ts.
- A new SQL string built with template literals instead of the query builder.
- Logging of request bodies, tokens, email addresses or card data.
- A feat change with no new or changed test; a fix with no test that fails
  without the fix.
- A test whose assertion was loosened (toBeTruthy replacing toEqual, a
  removed expect, an added .skip) in the same PR as a code change.

## Do not flag
- Formatting, import order or naming: dprint and oxlint own these.
- Files under src/generated/ and any *.snap file.
- Speculative refactors unrelated to the diff.

A plik dla ścieżki billingu tak:

# Billing rules (src/billing/)

- Every state change to an invoice must be idempotent on the webhook event
  id. Flag any handler that writes before checking processed_events.
- Currency conversion happens only in src/billing/fx.ts. Flag it anywhere else.
- Treat any change to refund logic as high severity.

Naucz Bugbota reguł z historii code review

Wyuczone reguły żyją w panelu Cursora, nie w repozytorium. Biorą się z aktywności zespołu na pull requestach w GitHubie (dokumentacja wymienia tylko GitHuba), z jednorazowego backfillu historii repozytorium i z jawnych komentarzy @cursor remember. Każda wyuczona reguła ma Name, treść (Rule content) i opcjonalne Scoped paths, na przykład src/components/**.

Włącz uczenie. W regułach repozytorium Bugbota włącz uczenie dla organizacji i repozytorium pilotażowego, a potem uruchom backfill z historii repozytorium. Reguły ręczne, które piszesz na tym samym ekranie, też działają tylko wtedy, gdy uczenie jest włączone zarówno dla organizacji, jak i dla repozytorium.
Przeczytaj, czego Bugbot się nauczył, zanim mu zaufasz. Traktuj tę listę jak pull request: usuń jednorazowe decyzje, zawęź do ścieżki reguły dotyczące jednego katalogu i przepisz mgliste reguły na sprawdzalne warunki.

Ucz w miejscu, gdy człowiek pisze ten sam komentarz drugi raz. Gdy recenzent po raz drugi wpisuje tę samą uwagę, odpowiada na pull requeście tak:

@cursor remember Background jobs in src/jobs/ must be idempotent: flag any job that inserts a row without an ON CONFLICT clause or a prior existence check.

Co miesiąc przeglądaj analitykę reguł. Każda reguła pokazuje Issues found, PRs reviewed, Accepted issues i Acceptance rate. Reguła z wieloma znaleziskami i niską akceptacją to szum; przepisz ją albo usuń. Wybierz własny próg i go zapisz, na przykład „poniżej 30% akceptacji po 20 znaleziskach”.
Przenieś reguły, na których polegasz, do BUGBOT.md. Cursor sam włącza i wyłącza wyuczone reguły, w miarę jak widzi więcej aktywności. To przydatne przy zmianach stylu i groźne przy niezmiennikach: reguła o idempotentnych webhookach billingu nie może się wyłączyć, bo przez miesiąc nikt jej nie naruszył. Regułę, która udowodniła swoją wartość, przenieś do właściwego BUGBOT.md przez pull request, gdzie jest wersjonowana, przejrzana i ma właściciela.

Jak daleko może sięgać Autofix?

Autofix uruchamia Cloud Agenta, który naprawia błędy znalezione przez Bugbota, wypycha poprawkę i komentuje wynik na pull requeście. Używa twojego Default agent model (a w razie jego braku domyślnego modelu zespołu), wymaga włączonego zużycia on-demand i przechowywania danych (nie Legacy Privacy Mode) i jest rozliczany jako zużycie Cloud Agents. Gdy jest włączony, GitHub może pokazać osobny check Cursor Bugbot Autofix, który zwraca tylko success albo neutral, więc sam nigdy nie blokuje merge’a.

Tryb	Co się dzieje	Kiedy go użyć
Off	Znaleziska mają linki Fix in Cursor i Fix in Web; poprawkę uruchamia człowiek	Repozytoria ze ścieżkami ryzyka `high` albo czas, gdy dopiero stroisz reguły
Create New Branch (tryb zalecany przez Cursora)	Poprawka trafia na nową gałąź; autor decyduje, czy ją przyjąć	Domyślnie w większości repozytoriów: poprawka jest widoczna i opcjonalna
Commit to Existing Branch	Poprawka trafia na gałąź pull requesta, maksymalnie trzy próby na pull request	Repozytoria niskiego ryzyka z mocnymi testami i włączonym unieważnianiem nieaktualnych zatwierdzeń

Obsługa zależy od dostawcy. GitHub i Origin Cursora obsługują oba tryby; GitLab i Bitbucket tylko Commit to Existing Branch; Azure DevOps żadnego. Nieobsługiwany tryb osobisty sprawia, że Bugbot pomija Autofix dla tego pull requesta.

Tryb zespołu to wartość domyślna, a nie polityka. Każdy developer może go nadpisać dla własnych pull requestów (Use Installation Default, Off albo jeden z trybów gałęzi), więc zespołowe Create New Branch nie powstrzyma autora, który wybierze Commit to Existing Branch. Kontrole obowiązujące wszystkich żyją w systemie kontroli wersji: ochrona gałęzi, wymagane checki i unieważnianie nieaktualnych zatwierdzeń.

Tabela wynika z trzech ograniczeń:

Commit Autofixa to kod napisany przez agenta. Jak każdy commit przechodzi przez CI, check pakietu dowodów i review właściciela kodu. Nigdy nie zwalniaj go z ochrony gałęzi i trzymaj włączone unieważnianie nieaktualnych zatwierdzeń.
Autofix może „usunąć” znalezisko, zmieniając test. Dodaj testy do CODEOWNERS i zostaw w BUGBOT.md regułę o poluzowanych asercjach.
Trzy próby to limit pętli, a nie próg jakości. Znalezisko, które je przetrwa, trafia do człowieka.

Skąd wiesz, że Bugbot łapie błędy?

Liczba komentarzy nic nie mówi o jakości. Mówią o niej dwa pomiary: test z podłożonymi defektami i odsetek znalezisk, na które zespół reaguje.

Uruchom test z podłożonymi defektami. Trzymaj gałąź z pięcioma podłożonymi defektami, które odpowiadają twoim regułom: nieobsłużone odrzucenie promise’a w handlerze trasy, kwota trzymana jako liczba JavaScript, zapytanie SQL z template literala, zalogowany token i poluzowana asercja w teście. Otwórz z niej draft pull requesta z etykietą do-not-merge, skomentuj bugbot run verbose=true (automatyczne review pomija drafty, chyba że je włączono) i zapisz, które defekty Bugbot znalazł. Nigdy go nie merge’uj i zamknij po zapisaniu wyników. Powtarzaj po każdej zmianie BUGBOT.md albo poziomu wysiłku. Defekt, którego Bugbot przestał łapać, to regresja w twojej warstwie review, znaleziona, zanim potrzebował jej prawdziwy pull request.

Mierz, co zespół rozwiązuje. W planach Enterprise API analityczne Bugbota zwraca jeden element na zakończone review z liczbą znalezisk, naliczonym kosztem oraz ważnością i statusem rozwiązania każdego znaleziska. Klucz potrzebuje zakresu read:*; trzymaj go w menedżerze sekretów i czytaj ze zmiennej środowiskowej:

# Terminal. CURSOR_ANALYTICS_API_KEY pochodzi z menedżera sekretów, nigdy z linii poleceń.
curl -sS --get https://api.cursor.com/analytics/team/bugbot-reviews \
  -u "$CURSOR_ANALYTICS_API_KEY:" \
  --data-urlencode "startDate=$(date -d '30 days ago' +%F)" \
  --data-urlencode "repo=github.com/acme/orders-api" \
  --data-urlencode "pageSize=250" \
  --data-urlencode "dryRun=false" \
| jq -r '
  ([.data[].cost_cents // 0] | add) as $cents
  | ([.data[] | (.bugs // [])[]] | group_by(.severity // "unknown")[]
     | [ (.[0].severity // "unknown"), length,
         (map(select(.resolution_status == "resolved")) | length) ]
     | @tsv),
    "total_usd\t\($cents / 100)"'

Na macOS zamień date -d '30 days ago' +%F na date -v-30d +%F. dryRun=false wyłącza z odsetka przebiegi próbne, których znaleziska nigdy nie są rozwiązywane. Wynik to jedna linia na poziom ważności ze znaleziskami i znaleziskami rozwiązanymi (znalezisko bez ważności liczy się jako unknown), a potem jedna linia total_usd z kosztem okresu w dolarach. Jeśli w miesiącu jest więcej niż 250 review, pobieraj kolejne strony, dopóki pagination.hasNextPage ma wartość true.

Spadający odsetek rozwiązanych przy stałej liczbie znalezisk oznacza szum: zawęź reguły. Wysoki odsetek rozwiązanych przy przeoczonym podłożonym defekcie oznacza zbyt wąskie reguły: dodaj sprawdzenie. Żeby przetestować Bugbota przed ogłoszeniem go zespołowi, użyj POST /bugbot/review z "dryRun": true (zakres klucza admin:*): sprawdza pull request bez publikowania na nim czegokolwiek, znaleziska trafiają tylko do analityki, a dry-run jest rozliczany jak zwykłe review.

Akceptacja nie przechodzi na Bugbota. Ścieżki ryzyka high nadal zatwierdza właściciel kodu, a właściciel warstwy review (zwykle tech lead) odpowiada za reguły, gałąź z podłożonymi defektami i comiesięczne liczby.

Jak Bugbot wypada na tle review w Claude Code i Codex?

Projekt z tej strony przenosi się między narzędziami; różni się mechanika:

	Cursor Bugbot	Claude Code	Codex
Review pull requestów	Automatycznie przy każdej aktualizacji albo `bugbot run` / `cursor review`	Zarządzane Code Review (research preview, Team i Enterprise)	`@codex review` i automatyczne review na GitHubie (według dokumentacji OpenAI, sprawdzone 28.08.2026)
Review lokalne	Skill `/review-bugbot`	`/code-review`	`/review`; z powłoki `codex review` (0.157.1)
Gdzie żyją reguły	`.cursor/BUGBOT.md`, reguły wyuczone, ręczne i zespołowe	`CLAUDE.md`; zarządzane Code Review czyta też `REVIEW.md` w katalogu głównym (lokalne `/code-review` nie)	`AGENTS.md`
Naprawa znalezisk	Autofix przez Cloud Agenta	Osobna sesja, którą uruchamiasz	Osobne zadanie, które uruchamiasz

Pełne porównanie szumu, konfiguracji i kosztu, także botów zewnętrznych, znajdziesz w porównaniu botów do AI code review. Odpowiednik tej strony dla Claude Code to automatyczne przeglądy kodu w Claude Code. W planach Team i Enterprise Bugbot może też wywoływać narzędzia MCP dodane w jego ustawieniach; dodaj serwer tylko wtedy, gdy reguła potrzebuje danych spoza diffu, na przykład kryteriów akceptacji.

Prompty do skopiowania: reguły Bugbota i Autofix

Uruchamiaj je w agencie Cursora w katalogu głównym repozytorium. Pierwszy wymaga GitHub CLI (gh) zalogowanego do repozytorium.

Run: gh api "repos/{owner}/{repo}/pulls/comments?per_page=100" --paginate
Keep only comments whose user.login does not end in [bot].

Group the human review comments by the problem they point out. For each group
with at least three comments:
- write one rule as a condition Bugbot can check in a diff, naming the path
  or pattern it applies to,
- quote two example comments and their file paths as evidence.

Then write a draft .cursor/BUGBOT.md with an "Always flag" section, a
"Do not flag" section (formatting, generated files, anything our linters
already enforce: read package.json and the lint config to find them), and one
scoped .cursor/BUGBOT.md per directory that has three or more rules of its own.
Keep the root file under 60 lines. Do not commit; show me the files.

Run: gh api "repos/{owner}/{repo}/pulls/comments?per_page=100" --paginate
Keep only comments from user.login "cursor[bot]" in the last 60 days, and for
each one fetch the replies in its thread.

Classify each Bugbot finding as: acted on (a later commit changed the flagged
lines), dismissed with a reason, or ignored. For every pattern that was
dismissed or ignored three or more times, propose one of:
1. a "Do not flag" line for .cursor/BUGBOT.md,
2. a narrower version of an existing rule, with a scoped path,
3. no change, if the dismissals look wrong to you (say why).

Read .cursor/BUGBOT.md first, and show the proposed edit as a diff.

Create a branch named bugbot-canary from main. Read .cursor/BUGBOT.md and pick
five rules from "Always flag". For each rule, make the smallest realistic
change that violates it, in a file where the rule applies (production code
under src/, or a test file for the loosened-assertion rule), and keep the
code compiling. Record each planted defect in docs/bugbot-canary.md with the
file, line, and rule it violates.

Touch no files other than the five you seed and docs/bugbot-canary.md.
Do not fix anything. Commit with the message
"test: seeded defects for Bugbot recall check" and stop; I will open the
pull request and run bugbot run verbose=true myself.
This branch must never be merged: do not open a pull request yourself.

Co się psuje, gdy Bugbot sprawdza twoje pull requesty?

Bugbot ignoruje checklistę review. Checklista leży w katalogu .cursor/rules/, którego Bugbot nie czyta. Co zrobić: przenieś reguły review do .cursor/BUGBOT.md i sprawdź przez bugbot run verbose=true, że plik jest w tabeli reguł.

Reguła, na której polegasz, przestała działać. Była regułą wyuczoną i Cursor ją wyłączył albo łączne reguły przekroczyły limit 100 000 znaków i wypadła. Co zrobić: sprawdź w tabeli z trybu verbose reguły pominięte i obcięte, skróć pliki i przenieś niezmienniki z reguł wyuczonych do BUGBOT.md.

Ten sam fałszywy alarm na każdym pull requeście. Dotyczy wygenerowanego kodu, snapshotów albo wzorca pilnowanego przez linter. Co zrobić: dodaj go do „Do not flag” i po dwóch tygodniach uruchom prompt o szumie z poprzedniej sekcji.

Wymagany check, zielony merge, otwarte znaleziska. Check Cursor Bugbot zakończył się jako neutral, co ochrona gałęzi traktuje jako zaliczony. Co zrobić: jeśli opcja, która kończy check niepowodzeniem przy nierozwiązanych znaleziskach, jest dostępna, włącz ją dla repozytorium; w przeciwnym razie dodaj rozwiązanie wątków Bugbota do checka pakietu dowodów albo wymagaj rozwiązania konwersacji w zestawie reguł ochrony gałęzi (ruleset).

Na produkcję trafił błąd, którego nie zawierał żaden pojedynczy push. Przyrostowe review oglądało każdy push osobno, a defekt istnieje dopiero po połączeniu dwóch z nich. Co zrobić: w repozytoriach ze ścieżkami ryzyka high wyłącz Incremental Review, a potem skomentuj bugbot run na otwartych pull requestach, żeby każdy dostał przebieg po całym diffie.

Commity Autofixa lądują w środku review człowieka. Repozytorium albo osobiste ustawienie autora używa Commit to Existing Branch. Co zrobić: przełącz domyślny tryb zespołu na Create New Branch, poproś autora o ustawienie Use Installation Default i sprawdź, czy unieważnianie nieaktualnych zatwierdzeń jest włączone, żeby każda poprawka, która jednak trafi na gałąź, wymagała nowego zatwierdzenia.

Autofix nigdy się nie uruchamia. Zużycie on-demand jest wyłączone, przechowywanie danych jest wyłączone, dostawca nie obsługuje wybranego trybu albo ustawienie osobiste nadpisuje ustawienie instalacji. Co zrobić: sprawdź te cztery rzeczy w tej kolejności.

Brak review Bugbota na pull requeście, na którym go oczekiwałeś. Autor uruchomił lokalnie /review-bugbot na tym samym diffie, repozytorium działa tylko raz albo w trybie ręcznym, albo osobiste ustawienia autora uruchamiają Bugbota tylko po wzmiance lub pomijają drafty. Co zrobić: skomentuj bugbot run i opisz zasady uruchamiania w szablonie pull requesta.

Rachunek rośnie szybciej niż wartość. Wysiłek podniesiono wszędzie albo dry-run służy do eksperymentów na dużą skalę. Co zrobić: zostaw wysiłek High tylko tam, gdzie test z podłożonymi defektami pokazuje przeoczenia, i co miesiąc czytaj linię total_usd.

Dokąd dalej z Bugbotem

Code review wspierane przez AI w Cursorze Wymaganie wstępne: Agent Review, własne review przed pull requestem i review cudzej zmiany.

Rollouts oraz PR Routing & Approval Następny krok: zatwierdzanie pull requestów niskiego ryzyka według reguł, ze znaleziskami Bugbota w klasie standard.

Zarządzaj warstwowym review pull requestów Kontrakt review i osobne przebiegi, których jedną warstwą jest Bugbot.

Pakiet dowodów Co musi udowodnić pull request agenta i check CI, który liczy jego klasę ryzyka.

Code review PR-a agenta Triage, który człowiek przeprowadza na pull requestach klasy standard.

Cloud Agents i Automations Agenci, na których działa Autofix, i uruchamianie ich zdarzeniami.