Przejdź do treści

Czas reakcji i tryby

Co realnie oznacza „reagujemy w fazie utrzymania". Tu jest owner-facing harmonogram — kiedy oczekiwać odpowiedzi i kanał per-klasa zgłoszenia.

Krótko

  • Sprint cadence — weekendowy. Coding + deploy tylko Sob/Nd. Pn–Pt brak ingerencji w produkcję poza P0.
  • Owner-notification — jeden batch w niedzielę wieczór. Jedna wiadomość per sprint z listą zamkniętych spraw.
  • P0 (outage) — reakcja <2h dowolnego dnia tygodnia, kanał: dev@aiofactory.pl + opcjonalnie SMS przez TextBee.
  • Pełny opis cyklu sprintu i klas P0/P1/P2/P3 → On-call. Tu jest skrót pod kątem Twoich oczekiwań.

Macierz oczekiwań

Klasa Definicja w skrócie Kanał Pierwsza reakcja Naprawa
P0 Outage prod — panel / mailcow / sklep nieosiągalne Email [P0] na dev@aiofactory.pl (+ SMS) < 2 h, dowolny dzień Hotfix mid-week (linia już stoi → wyjątek od reguły weekend-only)
P1 Krytyczna funkcja zepsuta, jest workaround Forgejo bug + komentarz @-mention Triage w piątek wieczór Następny weekend (max 7 dni)
P2 Bug nie blokuje pracy (UI glitch, błędny komunikat) Forgejo bug Triage w piątek wieczór 2–4 sprinty (kolejka)
P3 Feature request / pomysł / pytanie Forgejo feature-request lub bez etykiety 1-linijkowy ack przy najbliższym triage'u Brak SLA — akumulacja na po-sierpniowy review

Sprint cadence — weekendowy

Konwencja od 2026-05-01 (backlog/docs/doc-085).

Faza Kiedy Co się dzieje
Triage Pt wieczór Pull aktualnych issue'ów, decyzja co wchodzi w sprint
Plan Pt wieczór Pod-tasków pod Epic, owner sign-off na design
Build + Deploy Sob/Nd Implementacja, push do mastera + auto-deploy na prod (wielokrotnie)
Verify Nd po południu Prod-on-dev verify, draft Forgejo replies
Ship-the-message Nd wieczór Jeden batch Forgejo replies + jeden email do ownera
Quiet Pn–Pt Brak kodowania, brak deployu. Nowe issue → kolejka do następnego sprintu

Powód: firma produkcyjna pracuje Pn–Pt; prod-issue spowodowany zmianą kodu w godzinach pracy = halt linii produkcyjnej. Eliminujemy ryzyko przez batchowanie zmian na weekend, gdy linia stoi.

P0 — kryterium

P0 wymaga wszystkich trzech jednocześnie:

  1. Skala — dotyka >50 % operatorów lub blokuje krytyczny proces (np. wszystkie publikacje na Allegro).
  2. Czas — trwa >15 min i nie samo-naprawia się.
  3. Brak workaroundu — nie ma alternatywnej ścieżki kontynuacji pracy.

Pojedynczy zepsuty scenariusz CS dla jednego konta = P1, nie P0. Cały moduł CS down = P0.

Kanał P0: dev@aiofactory.pl z prefiksem [P0]. Opcjonalnie SMS przez TextBee (jeśli skonfigurowane). Nie wpisuj P0 w Forgejo — Forgejo czeka do triage'u w piątek; email idzie natychmiast.

Treść [P0] powinna mieć:

Subject: [P0] panel.aiofactory.pl down — outage od 14:00

Co się dzieje: panel zwraca 502 od 14:00.
Wpływ: cały dział CS nie pracuje (4 osoby).
Co sprawdzono: Beszel pokazuje host-dad CPU 100 %.
Workaround: brak — panel jedyny dostęp.

P1 — kryterium

Krytyczna funkcja zepsuta, ale workaround istnieje:

  • Jeden marketplace fetch nie działa, ale manual publish pracuje.
  • Bramka SMS nie wysyła do nowych numerów, ale stare działają.
  • Backup BL pokazuje wczorajszą datę zamiast dzisiejszej.
  • Filtr po opiekunach przestaje działać dla nowych skrzynek.

Kanał: Forgejo z etykietą bug + komentarz @-mention dewelopera. Reakcja w trakcie sprintu (Pt-Nd następujący po zgłoszeniu, max 7 dni).

P2 / P3 — kolejka

P2 (bug nie blokujący) — czeka w backlogu, naprawiany w 2–4 sprintach. Każdy sprint może wciągnąć kilka P2 do paczki bug-fix mode.

P3 (feature request) — brak SLA. Forgejo issue z etykietą feature-request dostaje 1-linijkowy polski ack przy najbliższym triage'u:

„Oznaczone jako nowy pomysł — nie pracujemy nad tym w fazie utrzymania."

Po sierpniu 2026 — osobna wycena na podstawie zgromadzonej listy.

Kanały komunikacji — co gdzie

Kanał Zastosowanie Limit pojemności
Forgejo git.aiofactory.pl/aio/panel/issues Wszystkie bug-raporty + feature-requests + pytania Nielimitowane
Email dev@aiofactory.pl P0 / P1 (eskalacja) Unikaj P2/P3 emailem — łatwo zgubić
SMS przez TextBee (jeśli skonfigurowany) Tylko P0, gdy email może nie trafić w terminie Nie używaj do bug-raportów
Sprint-summary email (wykonawca → owner) My wysyłamy w niedzielę wieczór z listą zamkniętych spraw Jeden batch / sprint

Nie spodziewaj się odpowiedzi punkt-po-punkcie w trakcie sprintu

Jeśli zgłosisz 5 issue'ów w piątek wieczór, dostaniesz jeden email w niedzielę z 5-pozycyjną listą („zamknięte / odroczone / pytanie"). To celowy mechanizm — eliminuje noise, daje atomowy widok „co weekend zmienił".

NIE komentujemy issue'ów po naszej stronie

Konwencja od 2026-05: ship fix → zaktualizuj backlog task → Ty sam reviewujesz zmiany w prod, sam komentujesz „naprawione" + sam zamykasz issue na własnym timingu. To Twoja inicjatywa, nasz fix podpisany commit hashem w sprint-summary email.

Mid-week — kiedy wyjątek od „weekend only"

Mid-week zmiany są dozwolone tylko gdy:

  • Realny outage produkcji wymaga hotfixa (linia już stoi).
  • Owner explicitly prosi o mid-week zmianę („proszę zrób to dziś").

W innych przypadkach: zgłoś do Forgejo → kolejka do następnego sprintu.

3-miesięczne okno — harmonogram

Miesiąc Sprintów weekendowych Stan
Maj 2026 ~4 (W18 / W19 / W20 / W21) Aktywna naprawa znanych bugów + bug-fix mode kolejka
Czerwiec 2026 ~4 (W22-W26) Stabilizacja po pierwszej fali
Lipiec 2026 ~4 (W27-W30) Trickle bugfixes; obowiązkowy 90-dniowy re-auth Temu (TASK-248, do wykonania przed 2026-07-23)
Sierpień 2026 ~4 (W31-W35) Końcówka okna; ostatnia szansa na bug-fix
31.08.2026 — Koniec fazy utrzymania. Bugi otwarte tego dnia → patrz bug-fix mode SOP.

Cel weekendowych sprintów: 3–4 tygodnie do w pełni działającego, bug-free środowiska (CLAUDE.md weekly cadence). Po tym okresie tempo sprintów spada — większość weekendów to drobne poprawki, monitoring, planowanie kolejnych spotkań.

Powiązane