# ADR-0003: Runtime w efemerycznym jobie GitLab CI, nie w usłudze

- Status: przyjęty
- Data: 2026-08-28

## Kontekst

agno pozwala wystawić agentów jako usługę (AgentOS/FastAPI) z bazą sesji, pamięcią i UI.
Kuszące, ale dla zadania "zmodyfikuj kod i otwórz MR" oznacza nową usługę produkcyjną:
własne SLA, uwierzytelnianie, przechowywanie stanu, przegląd bezpieczeństwa i dostęp
do repozytoriów z długożyjącego procesu.

## Decyzja

Runtime to efemeryczny job GitLab CI. Jedno uruchomienie = jeden job = jeden katalog roboczy
= jeden komplet artefaktów. Stan przebiegu żyje w artefaktach (`run.json`, `trace.jsonl`,
`changes.patch`), nie w bazie. Uprawnienia to uprawnienia joba (token projektowy),
a nie konta usługowego z dostępem do wszystkiego.

Wyzwalanie: issue z labelką (webhook → trigger token), zdarzenie na MR, harmonogram
oraz ręczny formularz w "Run pipeline" (zmienne z `description` i `options`).

## Konsekwencje

**Pozytywne**

- Zero nowej usługi do utrzymania i przeglądu bezpieczeństwa.
- Naturalna izolacja: brak stanu współdzielonego między przebiegami.
- Bramka manualna w CI daje właściciela podpisu pod zmianą.
- Limity zasobów i czasu przychodzą z platformy CI.

**Negatywne**

- Brak pamięci między przebiegami - powtórka zaczyna od zera (świadomy kompromis:
  pamięć między przebiegami w narzędziu modyfikującym kod to więcej ryzyka niż korzyści).
- Zimny start: instalacja kontekstu APM w każdym przebiegu (łagodzone cache'em i artefaktami).
- Brak interaktywnego trybu "zapytaj człowieka w trakcie" - stąd wzorzec `requires_human`:
  agent nie pyta, tylko oznacza i idzie dalej.