Maintain: zamknij pętlę

Etap maintain zmienia ograniczony sygnał produkcyjny w dowody, triage i następny intent.md bez czekania na ręczne uruchomienie sesji. Deterministyczna detekcja wywołuje agenta z dostępem tylko do odczytu lub wąskim zakresem zapisu; service owner nadal decyduje o ważności, właścicielu, naprawie i wydaniu.

Etapy 1–5 nadal potrzebują człowieka, by uruchomić pierwszy krok. Maintain to miejsce, w którym pętla działa headless. Niezależna bramka pewności między etapami — deterministyczny check lub adversarial reviewing agent — decyduje, czy output poprzedniego etapu idzie dalej, czy jest eskalowany do człowieka.

Tradycyjnie: Maintenance jest reaktywne. Tickety czekają na osobę. Alert o 3 w nocy może zostać przeoczony. Akcje z post-mortemów mogą nigdy nie dotrzeć do codebase.

AI-native: Trigger (naruszenie pasma kontrolnego, ticket, wiadomość w kanale lub harmonogram) woła agenta bez osoby na ścieżce. Agent diagnozuje, działa tylko przez gated routes i zapisuje to, co znajdzie, jako intent.md. Ludzie triagują i recenzują tę pracę; nie muszą jej już startować.

Zanim zaczniesz

• Format intent.md z Plan
• PR review agenta i hooki jako granica akcji z Deploy
• Przećwiczona ścieżka rollbacku

Infrastruktura: store metryk, który skrypt detekcji może query’ować; read access do repozytorium; sposób na nieinteraktywne uruchomienie agenta (CI, Cloud Agents, automations Codex lub Claude Agent SDK).

Zamknij pętlę z pasma kontrolnego

Detekcja pozostaje deterministyczna. Model jest wołany dopiero po naruszeniu pasma. Tier ustala, co może zrobić.

1. Wybierz jedną metrykę ze stabilnym rolling baseline: CI test failure rate, post-deploy 5xx rate lub PR cycle time.

2. Napisz skrypt detekcji (średnia i odchylenie standardowe w rolling window, reguły Western Electric lub podobne). Wersjonuj i unit-testuj skrypt. Żaden model nie bierze udziału w detekcji.

3. Zdefiniuj response tiers w wersjonowanej konfiguracji.

   Przy 1σ skrypt tylko loguje. Przy 2σ woła agenta read-only do diagnozy. Przy 3σ agent może działać, ale tylko otwierając PR do bramki review albo triggerując wcześniej zatwierdzony runbook.

4. Wybierz warstwę triggera: zaplanowany workflow GitHub lub GitLab, webhook ze stacku monitoringu albo cron wewnątrz sieci.

   Agent działa stateless. Bo run jest nieinteraktywny, pętla może zacząć się i skończyć bez kogoś, kto ją startuje.

5. Agent zapisuje diagnozę jako intent.md w formacie Plan: anomalia i jej evidence, proponowany outcome, dotknięte systemy, otwarte pytania. Stamtąd finding idzie przez pipeline jak wszystko inne.

6. Service owner lub on-call triaguje kolejkę: fix teraz, zaplanuj albo dismiss. Dismissale dostrajają pasma.

7. Gdy fix wypływa, dodaj eval dla incydentu (zobacz Test).

Przykładowy bands.yaml:

metric: ci_test_failure_rate
baseline: rolling_30d
rules: western_electric
tiers:
  1sigma: { action: log }
  2sigma: { action: diagnose,
            tools: "Read,Grep,Bash(gh run view *)" }
  3sigma: { action: propose,
            routes: [pull_request, runbook:rollback-deploy] }

Przykłady wzorca:

• CI test failure rate narusza 3σ → agent kwarantannuje flaky test albo otwiera revert PR; bramka review decyduje.
• Post-deploy 5xx rate narusza 3σ z deploymentem w oknie → agent triggeruje istniejący pipeline rollbacku.
• PR cycle time odpala regułę driftu → agent pisze raport dla engineering leadership.

Powtarzalne skany codebase

Skany security to stwierdzenie point-in-time o codebase pod konkretnym modelem, i obie połowy się starzeją. Uruchamiaj skan według harmonogramu, bez człowieka na ścieżce invocacji, i przepuszczaj findings przez te same bramki co każdą inną zmianę.

1. Podłącz repozytoria i pogrupuj je tak, by ownership findings był jasny.

2. Uruchom pierwszy pełny skan najbardziej krytycznych repozytoriów jako baseline. Pierwszy skan prawdopodobnie wyniesie findings w kodzie uważanym za czysty.

3. Ustaw harmonogram per projekt. Tygodniowy to rozsądny default dla aktywnie rozwijanych serwisów.

4. Triaguj z ratingiem pewności w ręku. Dismissuj z powodem, żeby ten sam finding nie wracał jako nowy.

5. Przy ograniczonym finding otwórz sugerowany patch, zrecenzuj go i wyślij przez bramkę PR review. Agent, który zaproponował fix, nie ma ścieżki do jego zatwierdzenia.

6. Przy czymś szerszym niż jeden patch zapisz to jako intent.md i zacznij od Plan.

7. Gdy fix dotrze na produkcję, dodaj eval dla tej klasy podatności.

8. Eksportuj findings do trackera, którego oczekują auditorzy.

Agent bezpieczeństwa producenta albo cykliczne zadanie repo może wdrożyć ten wzorzec, lecz uzupełnia, a nie zastępuje deterministycznego SAST, skanowania zależności, wykrywania sekretów i polityk CI. Każdy finding modelu nadal potrzebuje powtarzalnego dowodu, poziomu pewności, właściciela i zwykłej bramki review.

On-call w kanale

Incydenty przychodzą także przez chat zespołu i tracker. Używaj integracji Claude, Cursora lub Codex tylko wtedy, gdy jej tożsamość, zakresy, retencja danych i ślad audytowy spełniają wymagania organizacji. Mała poprawka może trafić jako PR przez zwykłą bramkę review; większa praca staje się intent.md do triage.

Kanał jest ścieżką audytu: request, diagnoza, ludzka autoryzacja i fix zostają tam, gdzie obsłużono incydent. Zobacz how Claude Tag runs on-call for CI/CD at Anthropic.

Governance

Granice tierów są egzekwowane z wersjonowanej konfiguracji. Permissions i managed settings odmawiają dostępu do produkcji. Invocacje, findings i decyzje triage są logowane z timestampem. Service owner triaguje i zatwierdza findings. Wynikające zmiany idą przez normalną bramkę PR review. Runbooki, które agent może triggerować, były zatwierdzone z wyprzedzeniem.

Verify

• Syntetyczne naruszenie 3σ produkuje intent.md w kolejce triage bez człowieka startującego sesję.
• Akcja 3σ może tylko otworzyć PR lub wcześniej zatwierdzony runbook — nigdy bezpośrednią mutację produkcji.
• Dismissale są zapisane z powodem.

Wskaźnik wiodący: czas od naruszenia pasma do intent.md w kolejce triage.

Wskaźnik opóźniony: udział findings, które stają się zmergowanymi fixami; powtarzające się incydenty tej samej klasy (powinny spadać, gdy evale się kumulują).

Zastosuj praktykę w swoim narzędziu

Adapter Claude Code Wywołaj ograniczony triage przez claude -p z harmonogramu, routine lub obsługi incydentu.

Adapter Cursora Użyj Cloud Agents i Automations do zadań cyklicznych lub zdarzeniowych.

Adapter Codex Użyj zadań cyklicznych aplikacji, hooków, CI, Slacka lub Lineara.

Pętla działa dalej. Ludzki osąd zostaje nad nią.