Sesja jest komunikatem commita

Deweloper dziedziczy bazę kodu. git blame pokazuje 47 plików zmienionych w jednym commicie. Komunikat brzmi: „refactor auth module.” Autorem commita jest człowiek. Faktycznym autorem był agent kodujący, który działał przez 90 minut, przeczytał 200 plików, ocenił trzy alternatywne podejścia, odrzucił dwa z nich z konkretnych powodów i wyprodukował zestaw zmian obejmujący każdy endpoint uwierzytelniania. 90-minutowa sesja decyzji projektowych, odrzuconych alternatyw i omówionych przypadków brzegowych przepadła. Git zachował co się zmieniło. Nic nie zachowało dlaczego.

Mój post o długu poznawczym nazwał lukę między szybkością produkcji agenta a szybkością rozumienia dewelopera „długiem poznawczym” — zobowiązaniem, które narasta z każdym niezrecenzowanym commitem.¹ Projekt Memento, który zebrał 100 punktów na HN i 124 komentarze, stawia następne pytanie: jeśli sesja zawiera rozumowanie, czy sesja powinna być częścią commita?²

TL;DR

Git rejestruje CO się zmieniło. Sesje agentów rejestrują DLACZEGO. Gdy agenty piszą kod, transkrypt sesji jest prawdziwym dokumentem projektowym, a każdy workflow odrzucający transkrypt odrzuca pochodzenie zmian. Memento (open-source’owe rozszerzenie Git) dołącza transkrypty sesji AI do commitów jako git notes, tworząc łańcuch pochodzenia od commita do rozumowania. Claude Code z nową integracją LSP dodaje strukturalne rozumienie kodu, które czyni transkrypty sesji bardziej precyzyjnymi: go-to-definition zastępuje grep, a sygnatury typów zastępują zgadywanie. Poniżej: luka w pochodzeniu, cztery warstwy metadanych sesji, co buduje Memento, jak LSP zmienia jakość danych sesji oraz minimalne praktyki pochodzenia, które można wdrożyć już dziś.

Luka w pochodzeniu

Git śledzi pięć rzeczy dotyczących każdej zmiany: kto ją wprowadził, kiedy, jakie pliki się zmieniły, diff oraz komunikat commita. Dla kodu napisanego przez człowieka komunikat commita wypełnia lukę między diffem a intencją. Dobry komunikat wyjaśnia dlaczego zmiana istnieje. Zły komunikat („fix stuff”) zmusza recenzenta do rekonstruowania intencji z kodu.

Kod napisany przez agenta ma inną strukturę pochodzenia. Intencja nie żyje w głowie dewelopera. Intencja żyje w sesji: w prompcie, który rozpoczął zadanie, w plikach, które agent przeczytał, w alternatywach, które ocenił, w narzędziach, które wywołał, i w dowodach, które przytoczył przy raportowaniu ukończenia. Komunikat commita streszczający 90 minut rozumowania agenta w jednej linii odrzuca 99,9% kontekstu decyzyjnego.

Strata nie jest teoretyczna. Mój system orkiestracji generuje pliki stanu sesji (jiro.state.json, jiro.progress.json), które rejestrują każde ukończenie historyjki, werdykt recenzenta i wynik bramki dowodowej.³ Gdy recenzent pyta „dlaczego agent użył exponential backoff zamiast circuit breaker?” plik stanu sesji zawiera odpowiedź: agent ocenił oba wzorce, stwierdził, że usługa upstream zwraca powtarzalne odpowiedzi 503 z nagłówkiem Retry-After, i wybrał exponential backoff, aby honorować wartość nagłówka. Komunikat commita mówi „refactor: standardize retry patterns.” Stan sesji mówi dlaczego.

Bez pochodzenia sesji recenzja kodu zmian autorstwa agenta staje się archeologią. Recenzent czyta diff, odtwarza rozumowanie i formułuje teorię o tym, dlaczego zmiana istnieje. Teoria może być błędna. Faktyczne rozumowanie agenta jest dostępne, zapisane w transkrypcie sesji. Standardowy workflow w branży (commit, push, recenzja diffa) wyrzuca rozumowanie.

Problem mnoży się przy kompozycji agentów. Mój system orkiestracji uruchamia wyspecjalizowanych subagentów do recenzji kodu: recenzenta poprawności, recenzenta bezpieczeństwa, recenzenta konwencji.⁵ Każdy subagent prowadzi własną sesję, czyta własne pliki, formułuje własne wnioski. Agent nadrzędny agreguje werdykty. Końcowy komunikat commita mówi „3 reviewers: approve.” Trzy indywidualne sesje recenzji — każda zawierająca konkretne ustalenia, analizę przypadków brzegowych i uzasadnienie zatwierdzenia — żyją w oddzielnych transkryptach, do których commit nigdy się nie odwołuje. Każda warstwa delegacji agenta dodaje kolejną warstwę niewidocznego rozumowania.

Problem pochodzenia łączy się z trzema istniejącymi wzorcami awarii. Zapora przed konfabulacjami zidentyfikowała, jak agenty publikują niezweryfikowane twierdzenia, gdy nie istnieje bramka wyjściowa.⁶ Pochodzenie sesji pozwoliłoby wykryć konfabulację wcześniej: transkrypt sesji pokazywał, jak agent wymyślał metodologię liczenia tokenów, której żaden człowiek nie zrecenzował. Niewidoczny agent udokumentował, jak działania agentów pozostają niemonitorowane bez jawnej instrumentacji.⁷ Pochodzenie sesji to ścieżka audytu, którą generuje stos widoczności. Komentarz publiczny do NIST zalecał ustandaryzowane logowanie audytowe dla działań agentów.⁹ Git notes przechowujące transkrypty sesji to jedna implementacja tego zalecenia.

Bramka dowodowa w moim systemie jakości wymaga od agenta przytoczenia konkretnego dowodu dla każdego kryterium jakości: wskazania wzorca, wyjaśnienia alternatyw, wymienienia przypadków brzegowych, wklejenia wyników testów.¹⁰ Bramka dowodowa zmusza agenta do generowania danych warstwy Rozumowania i Weryfikacji, które w innym przypadku by nie istniały. Bez bramki agent raportuje „done”, a sesja zawiera tylko dane Procesu (wywołania narzędzi). Z bramką sesja zawiera jawne uzasadnienie, które recenzent może zweryfikować wobec kodu.

Sam Git nie potrafi rozróżnić commita z 47 plikami, który reprezentuje 90 minut starannego rozumowania, od commita z 47 plikami, który reprezentuje agenta działającego bez ograniczeń przez 90 minut bez recenzji. Dokumentacja Git opisuje notes jako „dodatkowe informacje o obiekcie, które można dołączyć bez zmiany samego obiektu”.⁸ Transkrypty sesji idealnie pasują do tej definicji: dodatkowe informacje o pochodzeniu commita, które nie zmieniają hasha, diffa ani historii.

Pytanie Memento

Projekt Memento odpowiada na lukę w pochodzeniu rozszerzeniem Git.² Narzędzie przechwytuje transkrypty sesji kodowania AI i dołącza je do commitów jako git notes, przechowywane w refs/notes/commits i refs/notes/memento-full-audit.

Workflow: git memento init konfiguruje repozytorium. git memento commit <session-id> zastępuje git commit, automatycznie pobierając transkrypt sesji od skonfigurowanego dostawcy AI (Codex lub Claude Code) i przechowując go jako ustrukturyzowane metadane commita.

Dyskusja na HN z 124 komentarzami ujawniła cztery stanowiska:

Stanowisko 1: Sesje to niezbędny kontekst. Sesje agentów zawierają rozumowanie, którego komunikaty commitów nie mogą przekazać. Dołączanie sesji do commitów zachowuje łańcuch pochodzenia. Recenzenci mogą prześledzić każdą linię kodu wstecz przez commit, sesję i oryginalny prompt.

Stanowisko 2: Sesje to szum. 90-minutowy transkrypt sesji to tysiące linii konwersacji. Większość z nich jest irrelewantna dla końcowego zestawu zmian. Dołączanie pełnego transkryptu zakopuje sygnał w szumie i utrudnia recenzję zamiast ją ułatwiać.

Stanowisko 3: Podsumowania, nie transkrypty. Sesja powinna być destylowana do ustrukturyzowanego podsumowania: opis zadania, rozpatrywane alternatywy, uzasadnienie decyzji, przytoczone dowody. Podsumowanie zachowuje pochodzenie bez szumu. Memento generuje podsumowania w formacie markdown z oznaczonymi turami użytkownika i asystenta.

Stanowisko 4: Obawy dotyczące prywatności i bezpieczeństwa. Transkrypty sesji mogą zawierać klucze API, wewnętrzne URL-e, zastrzeżony kod z innych plików lub treści konwersacyjne, których deweloper nie chciałby w trwałym rekordzie Git. Sesje wymagają sanityzacji przed dołączeniem.

Wszystkie cztery stanowiska mają uzasadnienie. Wartość pochodzenia sesji jest niezaprzeczalna. Problem szumu jest realny. Obawa o prywatność jest strukturalna. Memento adresuje stanowiska 1 i 3 (przechowywanie transkryptów z konwersją do markdown) oraz stanowisko 4 (traktowanie transkryptów jako niezaufanych danych przy generowaniu podsumowań). Stanowisko 2 pozostaje otwartym pytaniem projektowym: ile kontekstu sesji wystarczy?

Komplementarne narzędzie podchodzi do tego samego problemu inaczej. claude-replay konwertuje transkrypty sesji Claude Code na odtwarzanie przypominające wideo, pozwalając recenzentom obserwować pracę agenta krok po kroku zamiast czytać statyczny transkrypt.¹² Tam gdzie Memento odpowiada na pytanie „co powinniśmy przechowywać?”, claude-replay odpowiada „jak powinniśmy to recenzować?”. Oba narzędzia adresują różne części workflow pochodzenia: Memento zachowuje dane (przechowywanie), claude-replay czyni dane zrozumiałymi (prezentacja). Fakt, że oba projekty powstały niezależnie w ciągu tego samego miesiąca, potwierdza tezę: praktycy odczuwają lukę w pochodzeniu i budują narzędzia, aby ją zamknąć.

Cztery warstwy pochodzenia

Metadane sesji agenta organizują się w cztery warstwy, z których każda odpowiada na inne pytanie dotyczące zmiany.

Każda warstwa generuje koszty. Przechowywanie pełnej warstwy Intencji (oryginalny prompt) jest tanie: jedno pole tekstowe. Przechowywanie pełnej warstwy Procesu (każde wywołanie narzędzia) dla 90-minutowej sesji generuje megabajty JSON. Przechowywanie warstwy Rozumowania wymaga, aby agent jawnie narrował swój proces decyzyjny, czego większość agentów domyślnie nie robi. Przechowywanie warstwy Weryfikacji wymaga integracji z systemem uruchamiania testów i recenzji.

Mój system orkiestracji przechwytuje wszystkie cztery warstwy różnymi mechanizmami.³ Infrastruktura hooków umożliwiająca to przechwytywanie obejmuje 84 hooki w 15 typach zdarzeń.⁵ Intencja: hook UserPromptSubmit loguje oryginalny prompt. Proces: hooki PostToolUse logują każde wywołanie narzędzia i wynik. Rozumowanie: bramka dowodowa wymaga od agenta przytoczenia konkretnego uzasadnienia dla każdego kryterium jakości. Weryfikacja: plik jiro.state.json rejestruje wyniki testów i werdykty recenzentów.

Hooki śledzą również, jakie umiejętności agent wywołał i w jakiej kolejności.¹¹ Commit będący wynikiem umiejętności /review, po której następuje umiejętność /test, ma inny profil pochodzenia niż commit z pojedynczej nieustrukturyzowanej sesji. Sekwencja umiejętności ujawnia wzorzec workflow: recenzja przed testowaniem czy testowanie przed recenzją? Kolejność ma znaczenie dla zrozumienia pokrycia zapewniania jakości. Dane istnieją w wielu plikach stanu. Problem polega na tym, że żadne z nich nie są dołączone do commita Git.

LSP jako most pochodzenia

Nowa integracja LSP (Language Server Protocol) w Claude Code zmienia jakość danych pochodzenia sesji.⁴

Przed LSP Claude Code nawigował po bazach kodu za pomocą grep i odczytów plików. Gdy agent potrzebował znaleźć definicję funkcji, szukał nazwy funkcji we wszystkich plikach. Wyszukiwanie zwracało rozmyte wyniki: wiele dopasowań, częściowe dopasowania, pliki testowe zawierające nazwę funkcji w komentarzach. Agent wybierał najbardziej prawdopodobne dopasowanie. Transkrypt sesji rejestrował: „szukano authenticate_user, znaleziono w auth.py, test_auth.py i middleware.py.” Dane pochodzenia zawierają wyszukiwanie, niejednoznaczność i najlepsze przypuszczenie agenta.

Z LSP agent wywołuje goToDefinition i otrzymuje dokładny plik i numer linii w ~50 milisekund.⁴ Transkrypt sesji rejestruje: „authenticate_user zdefiniowane w auth.py:47.” Dane pochodzenia są precyzyjne, jednoznaczne i maszynowo weryfikowalne. Recenzent czytający sesję może zaufać, że agent znalazł właściwą definicję, a nie podobnie nazwaną funkcję w innym module.

Poprawa kumuluje się w ramach sesji. Agent, który czyta 200 plików używając grep, generuje dane sesji pełne „szukano X, znaleziono potencjalne dopasowania A, B, C, wybrano A.” Agent, który czyta 200 plików używając LSP, generuje dane sesji mówiące „X zdefiniowane w file:line, referencje w file:line, file:line, file:line.” Sesja wsparta LSP to precyzyjna mapa rozumienia kodu przez agenta. Sesja wsparta grepem to rozmyte przybliżenie.

LSP dodaje sześć możliwości poprawiających jakość pochodzenia:

Implikacja dla pochodzenia: transkrypty sesji z agentów z włączonym LSP są cenniejsze jako dokumenty projektowe, ponieważ każdy krok nawigacji po kodzie jest weryfikowalny. Recenzent może potwierdzić, że rozumienie bazy kodu przez agenta było poprawne, a nie tylko prawdopodobne.

Projekt code-review-graph idzie dalej ze strukturalnym rozumieniem: trwały graf kodu, który przetrwa między sesjami, obniżając koszt tokenów ponownego rozumienia bazy kodu przy każdym wywołaniu.¹³ Tam gdzie LSP zapewnia zapytania strukturalne w ramach sesji, trwały graf zapewnia pamięć strukturalną między sesjami. Dla pochodzenia implikacja jest taka, że przyszłe agenty będą przenosić nie tylko transkrypt sesji, ale strukturalne rozumienie, które wygenerowało decyzje. Graf staje się kolejną warstwą danych pochodzenia: nie tylko „agent znalazł authenticate_user w auth.py:47”, ale „graf kodu agenta już zawierał hierarchię wywołań, więc pominął nawigację i przeszedł bezpośrednio do implementacji.” Wcześniejsza wiedza agenta wpływa na jego decyzje, a ta wcześniejsza wiedza należy do łańcucha pochodzenia.

Jak wyglądają metadane sesji

Prawdziwy przykład z mojego systemu orkiestracji. Historyjka: „Dodaj rate limiting do endpointu uwierzytelniania.”

Warstwa intencji (z hooka UserPromptSubmit):

Prompt: "Implement rate limiting on POST /auth/login.
  Use sliding window, 5 attempts per minute per IP.
  Return 429 with Retry-After header."

Warstwa procesu (z hooków PostToolUse):

Files read: 14 (auth/, middleware/, tests/)
Files written: 3 (rate_limiter.py, auth.py, test_rate_limit.py)
Bash commands: 7 (pytest x3, pip install x1, curl x3)
Duration: 23 minutes
Token usage: 87K input, 24K output

Warstwa rozumowania (z bramki dowodowej):

Pattern: Sliding window (token bucket rejected
  because per-IP granularity requires separate
  counters, sliding window handles this natively)
Edge cases: IPv6 normalization, proxy headers
  (X-Forwarded-For validated against trusted proxy list)

Warstwa weryfikacji (z jiro.state.json):

Tests: 12 passed, 0 failed, 0 skipped
Reviewers: correctness (approve), security (approve),
  conventions (approve with note: add docstring to
  rate_limiter.py:RateLimiter class)
Evidence gate: 6/6 criteria met

Komunikat commita dla tej samej zmiany: „feat: add rate limiting to auth endpoint.” Czternaście słów. Metadane sesji zawierają 2300 słów ustrukturyzowanego pochodzenia. Luka między komunikatem commita a kontekstem sesji to dwa rzędy wielkości.

Koszt pochodzenia

Pochodzenie sesji nie jest darmowe. Trzy koszty ograniczają adopcję.

Przechowywanie. 90-minutowa sesja agenta generuje 500 KB–2 MB surowego transkryptu. Przy 10 commitach dziennie pełny transkrypt dodaje 5–20 MB dziennie do repozytorium Git. Git notes przechowują dane poza główną historią (domyślnie nie wpływają na rozmiar git clone), ale ścieżka audytu w refs/notes/memento-full-audit się kumuluje. Konwersja do markdown w Memento redukuje surowy rozmiar o około 60%.²

Prywatność. Transkrypty sesji zawierają wszystko, co agent widział: zawartość plików, zmienne środowiskowe, odpowiedzi API, komunikaty błędów ze stosami wywołań. Transkrypt dołączony do publicznego repozytorium ujawnia wewnętrzne szczegóły implementacji. Memento traktuje transkrypty jako niezaufane dane i instruuje model podsumowujący, aby ignorował osadzone instrukcje, ale surowy transkrypt w pełnej ścieżce audytu wymaga kontroli dostępu.²

Stosunek sygnału do szumu. 90-minutowa sesja, w której agent czyta 200 plików, aby zmienić 12, zawiera 188 plików irrelewantnych danych procesowych. Wyzwaniem jest odróżnienie nawigacji (szum) od punktów decyzyjnych (sygnał). Model czteropoziomowy pomaga: Intencja i Rozumowanie to wysoki sygnał, Proces jest mieszany, Weryfikacja to wysoki sygnał. System pochodzenia przechowujący Intencję i Rozumowanie domyślnie, a Proces na żądanie, redukuje szum bez utraty kluczowego kontekstu decyzyjnego.

Co można wdrożyć już dziś

Cztery minimalne praktyki pochodzenia niewymagające nowych narzędzi:

1. Ustrukturyzowane komunikaty commitów. Zamiana „refactor auth module” na ustrukturyzowany format:

feat: add rate limiting to auth endpoint

Task: sliding window rate limiter, 5/min per IP
Alternatives: token bucket (rejected: per-IP overhead)
Evidence: 12 tests pass, 3 reviewers approve
Session: 23 min, 87K tokens, 14 files read

Format jest ręczną wersją czterech warstw pochodzenia. Komunikat odpowiada na intencję (task), rozumowanie (alternatives) i weryfikację (evidence) w czterech liniach. Nie wymaga żadnych narzędzi.

2. Zapisywanie transkryptów sesji obok commitów. Po sesji agenta wyeksportowanie transkryptu do pliku w repozytorium (np. .sessions/2026-03-02-auth-rate-limit.md). Dodanie pliku do .gitignore dla publicznych repozytoriów lub commitowanie go dla wewnętrznych. Transkrypt jest dostępny do recenzji bez infrastruktury git notes.

3. Tagowanie commitów autorstwa agenta. Użycie trailera Git do oznaczenia commitów wyprodukowanych przez agenta:

Agent: Claude Code (Opus)
Session-Duration: 23m
Files-Read: 14
Files-Written: 3

Trailer tworzy maszynowo parsowalny rekord zaangażowania agenta. git log --grep="Agent: Claude Code" wyświetla wszystkie commity autorstwa agenta. Metadane umożliwiają przyszłemu oprzyrządowaniu rekonstruowanie łańcuchów pochodzenia bez retroaktywnej adnotacji.

4. Wymaganie bramek dowodowych dla commitów agenta. Zanim agent zatwierdzi commit, wymagane jest odpowiedź na sześć pytań: Jaki wzorzec stosuje kod? Jakie prostsze alternatywy istnieją? Jakie przypadki brzegowe są obsługiwane? Czy testy przechodzą? Które pliki sprawdzono pod kątem regresji? Czy zmiana rozwiązuje faktyczny problem?¹⁰ Odpowiedzi tworzą warstwy Rozumowania i Weryfikacji. Bez bramki agent raportuje „done”, a sesja zawiera tylko dane Procesu. Z bramką każdy commit generuje ustrukturyzowane pochodzenie jako efekt uboczny zapewniania jakości.

Praktyka bramki dowodowej łączy się z szerszym argumentem o pochodzeniu. Agent, który musi uzasadnić swoje decyzje przed zatwierdzeniem commita, generuje metadane sesji wyższej jakości niż agent działający bez ograniczeń. Bramka przekształca pochodzenie z pasywnego produktu ubocznego (rejestrowanie co się wydarzyło) w aktywny sygnał jakości (wymaganie od agenta wyjaśnienia co się wydarzyło i dlaczego).

Kluczowe wnioski

Dla menedżerów inżynierii: Każdy commit autorstwa agenta z jednoliniowym komunikatem odrzuca dokument projektowy. Transkrypt sesji zawiera rozumowanie. Zdecyduj, czy to rozumowanie ma wartość dla procesów recenzji kodu, onboardingu i reagowania na incydenty w Twoim zespole. Jeśli odpowiedź brzmi tak, wdróż przynajmniej ustrukturyzowane komunikaty commitów.

Dla deweloperów: Gdy dziedziczysz kod napisany przez agenta, komunikat commita mówi co się zmieniło. Transkrypt sesji (jeśli zachowany) mówi dlaczego. Domagaj się pochodzenia sesji w workflow agentowym swojego zespołu. Projekt Memento zapewnia podejście natywne dla Git. Ustrukturyzowane komunikaty commitów to punkt wyjścia niewymagający infrastruktury.

Dla twórców narzędzi: Integracja LSP czyni transkrypty sesji cenniejszymi, zastępując rozmytą nawigację opartą na grep precyzyjnymi, weryfikowalnymi referencjami kodu. Każda poprawa rozumienia kodu przez agenta poprawia jakość danych pochodzenia generowanych przez sesje. Twórzcie formaty eksportu zachowujące cztery warstwy pochodzenia.

FAQ

Czym jest pochodzenie sesji? Pochodzenie sesji to zapis procesu rozumowania agenta AI podczas sesji kodowania: oryginalne zadanie, przeczytane pliki, ocenione alternatywy, podjęte decyzje i wygenerowane dowody. Transkrypt sesji przechwytuje „dlaczego”, którego komunikaty commitów i diffy nie są w stanie przekazać.

Czym jest Memento? Memento to open-source’owe rozszerzenie Git, które przechwytuje transkrypty sesji kodowania AI i dołącza je do commitów jako git notes. Narzędzie wspiera Codex i Claude Code, generuje podsumowania w markdown i zapewnia GitHub Action do integracji z PR.²

Jak LSP poprawia sesje agentów? Language Server Protocol daje agentom strukturalne rozumienie kodu: dokładne definicje, typowane referencje, hierarchie wywołań i diagnostykę w czasie rzeczywistym. Transkrypty sesji z agentów z włączonym LSP zawierają precyzyjne, weryfikowalne dane nawigacji po kodzie zamiast rozmytych wyników grep.⁴

Czy transkrypty sesji powinny być commitowane do Git? Odpowiedź zależy od wymagań prywatności repozytorium. Dla wewnętrznych repozytoriów commitowanie transkryptów zachowuje pochodzenie. Dla publicznych repozytoriów git notes (które domyślnie nie są transferowane przy klonowaniu) lub oddzielne przechowywanie z referencjami do commitów są bezpieczniejszymi podejściami.²

Ile przestrzeni dyskowej wymaga pochodzenie sesji? Typowa 30-minutowa sesja agenta generuje 200 KB–800 KB surowego transkryptu. Git notes przechowują dane poza główną bazą obiektów, domyślnie nie zmieniając rozmiaru git clone. Konwersja do markdown w Memento redukuje surowy rozmiar o około 60%. Dla zespołów prowadzących 10–20 sesji agentowych dziennie należy spodziewać się 2–10 MB dziennych danych pochodzenia, co jest porównywalne ze zrzutem ekranu o średniej rozdzielczości na sesję.²

Jaki jest związek między obserwowalnością agentów a pochodzeniem sesji? Obserwowalność agentów monitoruje co agenty robią w czasie rzeczywistym: zużycie zasobów, zgodność z politykami, zachowanie w runtime.⁷ Pochodzenie sesji rejestruje co agenty zdecydowały i dlaczego, po fakcie. Obserwowalność odpowiada na pytanie „czy agent zachowuje się poprawnie w tej chwili?”. Pochodzenie odpowiada na pytanie „dlaczego agent podjął tę decyzję w zeszły wtorek?”. Oba systemy się uzupełniają: obserwowalność wychwytuje problemy na żywo, pochodzenie je wyjaśnia po fakcie.

Źródła