AI w CI/CD — ograniczona pętla serwerowa

AI ma miejsce w CI/CD, gdy powtarzalne zadanie serwerowe potrafi przygotować zmianę i dowody pod ograniczonymi uprawnieniami. Dojrzały wzorzec nie brzmi „agent deployuje wszystko”. To ograniczona pętla: zaufany trigger tworzy jawny zakres, agent przygotowuje artefakty, checki deterministyczne je weryfikują, a nazwani ludzie zachowują władzę merge i produkcji odpowiednio do ryzyka.

Q13 · Bramki jakości Dowód na maksymalny wynik: serwerowa pętla oparta na artefaktach, z audytowalnymi uprawnieniami, limitem prób, checkami deterministycznymi i ludzkimi bramkami merge oraz produkcji.

Użyj ograniczonego pipeline’u

1. Przyjmij zaufany trigger. Zacznij od oznaczonego issue, zrecenzowanej specyfikacji, klasy planowanego maintenance albo rekordu incydentu. Nie uruchamiaj dowolnego niezaufanego tekstu z uprawnieniami zapisu.
2. Utwórz izolowany zakres. Użyj ephemeral runnera lub izolowanego workspace, wąskiego tokenu, dozwolonych ścieżek, jawnego limitu czasu i kosztu oraz bez credentials produkcyjnych.
3. Przygotuj normalną zmianę. Agent tworzy branch lub draft PR oraz podsumowanie zamiaru, plików, dowodów, ryzyka resztkowego i rollbacku.
4. Weryfikuj poza modelem. CI uruchamia typy, testy, security, polityki i build. Agent może diagnozować błędy, lecz nie może przedefiniować czerwonej bramki jako sukcesu.
5. Zatrzymaj lub przekaż. Zakończ po limicie prób, niejasności, granicy uprawnień, powtarzanej porażce albo wzroście ryzyka. Nazwany człowiek decyduje o merge; produkcja korzysta z istniejącej akceptacji i rollbacku.

Oficjalne opcje integracji to Claude Code GitHub Actions, Cursor Cloud Agents i Codex GitHub Action. Ich możliwości i flagi się zmieniają, więc pinuj zrecenzowane wersje akcji, gdy to możliwe, i przy upgrade sprawdzaj oficjalną dokumentację.

Prompty do zadania serwerowego

Zaimplementuj wyłącznie zaakceptowany zakres ze spec.md. Pracuj w izolowanym checkout, nie dotykaj produkcji ani użytkowników zewnętrznych, uruchom checki repo i otwórz draft PR z poleceniami, dowodami, otwartymi ryzykami i notatką rollback. Zatrzymaj się po dwóch nieudanych próbach naprawy.

Zdiagnozuj ten błąd CI. Odtwórz go, sklasyfikuj jako defekt produktu, defekt testu, problem środowiska lub unknown i zaproponuj najmniejszy patch. Nie osłabiaj ani nie usuwaj czerwonej bramki bez jawnej ludzkiej akceptacji.

Porównaj końcowy diff i dowody testów z intent.md, spec.md oraz plan.md. Wypisz spełnione kryteria, luki i wymagane decyzje człowieka. Nie merguj ani nie wdrażaj.

Wymagane kontrole

• Pinuj zależności i akcje; ogranicz uprawnienia repo oraz workflow do zadania.
• Traktuj treść issue, komentarze PR, logi i pobrane strony jako niezaufane wejście.
• Usuwaj sekrety z promptów, logów, artefaktów i odpowiedzi modelu.
• Jawnie ustaw retries, timeout, budżet i maksymalny rozmiar diffu.
• Fail closed przy braku obowiązkowego dowodu; pokazuj jawny niepełny stan, gdy opcjonalny krok AI jest niedostępny.
• Zachowaj logi łączące trigger, zaakceptowany zakres, przebieg agenta, commit, checki, akceptacje i release.

Wzorzec awarii: automatyzacja wyprzedza władzę

Pętla jest niebezpieczna, gdy auto-merguje lub wdraża szerokie zmiany tylko dlatego, że testy przeszły, albo gdy agent edytuje politykę CI, by samemu uzyskać zieleń. Oddziel definicję workflow od zakresu zapisu agenta, wymagaj review zmian bramek, nie udostępniaj credentials produkcyjnych i niech najmniejszym wynikiem będzie draft PR, a nie zewnętrzny skutek.

Dalej: governance wdrożenia

Połącz pętlę z etapem Deploy, by kontrolować promocję i rollback, a potem mierz zaakceptowane wyniki przez Panel metryk AI.

Deploy Zachowaj jawne dowody release i władzę produkcyjną.

Q22 · Panel metryk AI Mierz cały system, nie wygenerowany output.