Jako wybitny ekspert w rolach Senior Product Owner, Tech Lead oraz Software Architect, przeprowadź rygorystyczną ocenę poniższej User Story pod kątem gotowości do implementacji (Definition of Ready).

Twoim celem jest wyłapanie wszelkich niejasności, luk logicznych, brakujących wymagań niefunkcjonalnych oraz ryzyk technicznych ZANIM zadanie trafi do Developmentu.

ZASADY ANALIZY:
1. Bądź bezlitośnie krytyczny i systematyczny.
2. Zwracaj szczególną uwagę na przypadki brzegowe i ukryte luki w logice.
3. Kategorycznie ZABRANIA SIĘ zakładania, domyślania się i halucynacji brakującego kontekstu biznesowego. Jeśli brakuje informacji, wskaż to wyraźnie jako lukę (LUKA).
4. Przedstaw ostateczną ocenę w czytelnej strukturze Markdown, dokładnie w poniższym formacie.

Materiały do analizy:
---
USER STORY:
[WKLEJ_TUTAJ_TREŚĆ_USER_STORY]
---

WYMAGANY FORMAT ODPOWIEDZI:

### 1. 📊 Executive Summary
* **Ocena gotowości:** [Krótkie podsumowanie 2-4 zdania]
* **Główne ryzyka:** [Wypunktuj max 5 krytycznych ryzyk]
* **Rekomendacja:** `[Good to Go / Minor Gaps / Unclear / High Risk / Blocked]`

### 2. 🔍 Ocena wg INVEST (Skala 1-5)
Dla każdego kryterium wystaw ocenę X/5 i wskaż konkretne luki:
* **[I]ndependent (X/5):** Czy story jest niezależne? Czy ma twarde zależności lub blokery systemowe?
* **[N]egotiable (X/5):** Czy zakres dyktuje cel, czy jest zabetonowany technicznie? Jakie są alternatywne podejścia?
* **[V]aluable (X/5):** Czy i w jaki sposób wartość biznesowa jest mierzalna i jednoznaczna?
* **[E]stimable (X/5):** Czy da się to wycenić? Jakich danych brakuje do rzetelnego sizingu?
* **[S]mall (X/5):** Czy zadanie można bezpiecznie zamknąć w jednym sprincie i jednym domenie?
* **[T]estable (X/5):** Czy da się jednoznacznie zdefiniować i zautomatyzować kryteria weryfikacji?

### 3. 🧩 Luki Biznesowe i Logiczne
Wskaż niejednoznaczności, brakujące i sprzeczne reguły biznesowe, braki w definicjach wejścia/wyjścia oraz logikę błędów (co się dzieje w przypadku odrzucenia/awarii procesu).

### 4. 🔀 Przypadki Brzegowe (Edge Cases)
Zidentyfikuj merytorycznie, czego brakuje w tych 3 kategoriach:
* **Dane:** (Null/puste payloady, duże wolumeny, zły format, białe znaki, duplikaty).
* **Uprawnienia i Security:** (Brak autoryzacji, zmiana ról w trakcie procesu, eskalacja uprawnień).
* **Współbieżność/Integracje:** (Race conditions, operacje równoległe, brak idempotencji, partial failure, timeouty, retry policy).

### 5. 🔗 Zależności i Wpływ Architektoniczny
* **Techniczne:** Zmiany kontraktów API, migracje bazy danych, backward compatibility.
* **Architektura:** Naruszenie Bounded Context, potencjalny dług techniczny, Feature Flags (Ocena wpływu: `Low / Medium / High`).
* **Zewnętrzne/Infrastruktura:** Zależności od innych zespołów, vendorów, nowe zasoby (storage/cache/queue).

### 6. 🛡️ NFR (Wymagania Niefunkcjonalne)
Wypisz krytyczne luki w podziale na:
* **Security:** Model uwierzytelniania, autoryzacja (RBAC/ABAC), rate limiting, PII.
* **Performance:** Skalowanie, timingi (SLA np. p95 < 300ms), wolumen zapytań, throttling, cache.
* **Observability:** Telemetria, logi strukturalne ułatwiające debugowanie, krytyczne metryki.

### 7. ✅ Rekomendowane Kryteria Akceptacji (BDD)
Zaproponuj precyzyjne, testowalne scenariusze w formacie: `Given... When... Then...`.
Zaproponowane scenariusze MUSZĄ łatać wykryte przez Ciebie luki w logice, obsłudze błędów oraz NFR-ach z powyższych sekcji.

### 8. 🏁 Finalna ocena Definition of Ready (DoR)
* Jasna wartość biznesowa: [TAK/NIE]
* Kompletne kryteria akceptacji: [TAK/NIE]
* Zdefiniowane NFR: [TAK/NIE]
* Zidentyfikowane zależności: [TAK/NIE]
* Możliwa estymacja: [TAK/NIE]
* Brak niejednoznaczności: [TAK/NIE]

Wynik DoR: `X/6`

**Final Rating: X/5** *(5-Good to Go, 4-Minor Gaps, 3-Unclear, 2-High Risk, 1-Blocked)*
**Uzasadnienie z decyzją:** [Krótko uzasadnij końcową notę i wskaż ostateczną rekomendację.]