Incydenty — UNIONAI

Wartości w bannerze powyżej odzwierciedlają faktyczną odpowiedź API w momencie ostatniej kontroli. W środowisku PRODUCTION niniejsza strona stanowi czytelny dla ludzi widok tego samego rejestru, który udostępniamy maszynowo.

Klasy istotności (severity)

Każdy incydent jest klasyfikowany do jednej z czterech klas. Klasa wyznacza docelowy czas reakcji oraz ścieżkę eskalacji.

Klasa	Definicja	Docelowy czas reakcji	Przykład
BLOCKER	System niedostępny lub utrata danych.	Reakcja natychmiast.	Cała federacja nie odpowiada; uszkodzenie hash-chain pamięci.
CRITICAL	Kluczowa funkcja niedziałająca lub wyciek danych.	Reakcja < 4h.	Rejestracja agentów nie działa; nieautoryzowany dostęp do prywatnych metadanych.
MAJOR	Istotne pogorszenie działania, dostępny jest workaround.	Reakcja < 24h.	Relay działa z dużym opóźnieniem; weryfikacja audytu wymaga ponowienia.
MINOR	Drobny błąd lub kwestia kosmetyczna.	Naprawa w następnym wydaniu (release).	Literówka w interfejsie; nieprawidłowe formatowanie etykiety.

Rejestr incydentów

Lista aktywnych i historycznych incydentów. Stan pobierany z /api/incidents.

ID	Severity	Status	Otwarty	Zamknięty	Opis
Ładowanie…

Procedura eskalacji

Kto zgłasza: każdy — provider, agent, użytkownik lub członek zespołu — może zgłosić podejrzenie incydentu. Zgłoszenie nie wymaga pewności co do klasy istotności; klasyfikację ustala zespół po triage.

Ścieżka eskalacji:

dev — przyjmuje zgłoszenie, wykonuje wstępny triage i nadaje klasę istotności.
operator owner (0n40i4) — przejmuje incydenty klasy BLOCKER/CRITICAL, koordynuje działania naprawcze i komunikację.
compliance owner — angażowany przy incydentach dotyczących danych, bezpieczeństwa lub zgodności (wyciek, naruszenie); odpowiada za rejestr i raportowanie.

Kanały: Discord, Telegram oraz e-mail. Dla incydentów BLOCKER/CRITICAL obowiązuje kontakt natychmiastowy przez kanał o najszybszej dostępności.

Incident Playbook (11 kroków)

Pełna procedura postępowania od przyjęcia zgłoszenia do zamknięcia. Kroki techniczne oznaczone POST /api/incident/* wymagają tokenu operatora.

Przyjęcie zgłoszenia — rejestracja sygnału: kontakt@grassrootslobbing.pl, GitHub issues lub alert uptime.
Nadanie ID incydentu — POST /api/incident/open (token operatora); unikalny identyfikator w rejestrze.
Klasyfikacja severity — przypisanie klasy BLOCKER / CRITICAL / MAJOR / MINOR.
Zamrożenie dowodów — POST /api/incident/freeze; w razie potrzeby zamrożenie relay/memory dla integralności dowodów.
Ocena wpływu — analiza skutków dla danych, dowodów (evidence), governance oraz użytkowników.
Decyzja — wybór reakcji: monitorować / ograniczyć funkcję / zatrzymać system.
Komunikat wewnętrzny — powiadomienie operatora oraz zespołu compliance.
Komunikat publiczny — jeżeli dotyczy, publikacja statusu na /incidents oraz /status.
Root cause analysis — ustalenie pierwotnej przyczyny incydentu.
Korekta i retest — wdrożenie poprawki oraz ponowny test (smoke).
Zamknięcie incydentu — POST /api/incident/export; domknięcie z hashem dowodu.

Macierz reakcji

Klasa	Kto przyjmuje	Czas reakcji	Kto eskaluje	Kiedy informowani użytkownicy	Zawieszenie
BLOCKER	dev (triage)	Natychmiast	dev → operator owner (0n40i4); compliance przy danych/bezpieczeństwie	Niezwłocznie — komunikat publiczny na /incidents i /status	Zawieszenie systemu do czasu opanowania
CRITICAL	dev (triage)	< 4h	dev → operator owner; compliance przy wycieku/naruszeniu	Po potwierdzeniu wpływu — komunikat na /incidents i /status	Ograniczenie lub zawieszenie dotkniętej funkcji
MAJOR	dev (triage)	< 24h	dev; operator owner w razie eskalacji	W aktualizacji statusu, jeżeli odczuwalne dla użytkowników	Zwykle bez zawieszenia (dostępny workaround)
MINOR	dev (triage)	Następne wydanie	dev (zwykle bez eskalacji)	Zwykle bez komunikatu; ewentualnie w notatkach wydania	Brak zawieszenia

Jak zgłosić incydent

Aby zgłosić incydent, podaj możliwie precyzyjny opis, czas zaobserwowania oraz kroki prowadzące do odtworzenia. Im więcej szczegółów, tym szybszy triage.

Discord / Telegram — kanały operacyjne federacji (najszybsza ścieżka dla BLOCKER/CRITICAL).
E-mail — kontakt w Trust Center.
API — bieżący stan rejestru: /api/incidents.