Audyt Jakości Specyfikacji v2: Browser-VPN SaaS

Data audytu: 2026-07-22

Dokument: docs/superpowers/specs/2026-07-22-browser-vpn-v2-design.md (296 linii, 13 sekcji)

Cel biznesowy: Poprawiona specyfikacja produktu Browser-VPN — hostowanego SaaS z anonimowym dostępem przez krypto-płatności, z wirtualną przeglądarką w kontenerze Docker.

Audyty bazowe: v1 (CEO, 6.3/10), v2 (s_1 MOA, 6/10), v3 (s_2 MOA, 6/10), v4 (s_3 MOA, 6.5/10)

Publikacja: https://10s.pl/v5-private-browser/

1. Wprowadzenie

Niniejszy raport stanowi piąty audyt jakości (v5) specyfikacji Browser-VPN SaaS. Ocenia dokument v2 — poprawioną wersję po 4 poprzednich audytach — pod kątem gotowości implementacyjnej. Poprzednie audyty wykazały szereg problemów krytycznych (P0), które v2 adresuje. Celem niniejszego raportu jest sprawdzenie, które problemy zostały faktycznie rozwiązane, które pozostały, oraz identyfikacja nowych zagrożeń.

Zakres audytu:

Analiza strukturalna dokumentu v2 (296 linii)
Weryfikacja 13 zmian względem v1
Ocena wg 5 kryteriów: kompletność, spójność, mierzalność, wykonalność, bezpieczeństwo
Porównanie v1 vs v2 — mapa problemów rozwiązanych, pozostałych i nowych
Konkretne rekomendacje przed implementacją

2. Podsumowanie wykonawcze i ocena ogólna

Specyfikacja v2 to znacząca poprawa względem v1. Większość krytycznych problemów P0 z v1 została rozwiązana: Caddy → Traefik, SYS_ADMIN → NET_ADMIN+SYS_PTRACE, localStorage → httpOnly cookie, dodano limity zasobów, timeouty, recovery, backup off-site. Dokument jest znacznie krótszy (296 vs 738 linii), bardziej konkretny i pozbawiony martwej wagi.

Mimo to, dokument nie osiąga deklarowanej oceny 8.5/10. Pozostają luki w szczegółach implementacyjnych (BTCPay integration, Selkies streaming, seccomp profile), brak SLO/SLA, brak kryteriów akceptacji, oraz niedospecyfikowany admin panel.

Scorecard — ocena wg wymiarów (skala 1-10)

Wymiar	Ocena	Komentarz
Kompletność	7.5/10	Adresuje 11/13 problemów z v1, ale brak szczegółów BTCPay, Selkies, secrets management
Spójność	8.5/10	Wewnętrznie spójna — Traefik flow, httpOnly cookie, capabilities są zgodne z deklaracjami
Mierzalność	7.0/10	Limity, timeouty, capacity planning są konkretne. Brak SLO/SLA, brak kryteriów akceptacji
Wykonalność	7.5/10	Traefik, Docker, httpOnly cookie — dobrze znane technologie. BTCPay self-hosted + Selkies wymagają więcej detali
Bezpieczeństwo	8.0/10	Silna poprawa: SYS_ADMIN→NET_ADMIN, CSP, HSTS, TOTP, backup off-site. Brak: secrets management, scanning obrazów
Ocena ogólna	7.7/10	Blisko implementacji — wymaga 2-3 doprecyzowań przed dev

Werdykt: Approve with minor revisions — dokument zatwierdzić do implementacji, ale z obowiązkiem doprecyzowania 3 obszarów: (1) integracja BTCPay, (2) architektura Selkies-GStreamer, (3) secrets management.

3. Analiza szczegółowa wg 5 kryteriów

3.1 Kompletność (7.5/10)

Co jest pokryte:

Architektura: Traefik z Docker provider — poprawnie opisany, konfiguracja docker-compose dołączona
Płatności: Trocador primary + BTCPay fallback — failover logic opisana
Bezpieczeństwo kontenera: NET_ADMIN + SYS_PTRACE, no-new-privileges, seccomp, userns-remap
deviceToken: tylko httpOnly cookie + fingerprint serwerowy
Limity zasobów: memory 2g, cpu 1.0, pids 200, capacity planning z kosztami
Timeout first access: 1h buffer + idle timeout 30 min
Delivery: QR code + download order info + ostrzeżenie UX
Recovery: order number + 6-cyfrowy PIN (bcrypt, max 3 próby)
TOTP: obowiązkowe dla admina
Backup: lokalny 7 dni + off-site encrypted (GPG/age)
Kontrakty API: przykład OpenAPI dla POST /api/v1/orders
Obsługa błędów: tabela 5 scenariuszy z akcjami

Czego brakuje:

BTCPay Server integration details — brak opisu webhook handlingu, tworzenia invoice, obsługi refundów, konfiguracji failover timeout (2 min tylko wzmiankowane)
Selkies-GStreamer streaming — brak informacji jak to jest konfigurowane, jakie porty, protokoły, zależności
Secrets management — brak informacji gdzie i jak przechowywane są klucze API (Trocador, BTCPay, GPG), hasła, TOTP secrets
CI/CD pipeline — brak specyfikacji deploymentu, buildowania obrazów, testów
Monitoring/alerting — wzmianka o Telegram alert, ale brak konkretnych metryk, progów, dashboardów
Diagram ERD — relacje między tabelami orders, sessions, tickets, vpn_configs nadal bez wizualizacji
Test plan — brak specyfikacji testów (unit, integration, e2e)
Seccomp profile — wzmiankowany, ale nie dołączony ani nie opisany

3.2 Spójność (8.5/10)

Mocne strony:

Traefik Docker provider jest w pełni spójny z opisanym routingiem — kontener startuje z labelami, Traefik wykrywa automatycznie
httpOnly cookie + fingerprint serwerowy to spójna para (bez localStorage)
NET_ADMIN + SYS_PTRACE są spójne z wymaganiami WireGuard + Selkies
Limity zasobów (2g, 1.0 CPU) są spójne z capacity planning (30 instancji = 60 GB RAM)
CSP + HSTS + rate limiting tworzą spójną warstwę bezpieczeństwa HTTP
Backup off-site encrypted jest spójny z modelem privacy (brak zaufania do hostingu)

Drobne niespójności:

Capacity planning mówi o 30 instancjach, ale zmienne środowiskowe (MAX_INSTANCES=30) i restart: unless-stopped sugerują podejście serwisowe, a nie one-shot container per session
Rate limiting 5 req/h na IP może być zbyt restrykcyjne — normalny użytkownik może wywołać kilka requestów w trakcie zakupu (wybór browsera, regionu, planu, kliknięcie pay)
Tabela obsługi błędów nie zawiera scenariusza dla wyczerpania limitów (memory/cpu/pids) — restart z >3 crashami w 1h, ale co jeśli limit pamięci jest osiągany wolno?

3.3 Mierzalność (7.0/10)

Co jest mierzalne:

Limity per kontener: memory 2g, cpu 1.0, pids 200 (konkretne wartości)
30 instancji dla MVP (konkretna liczba)
Timeout first access: 1h (konkretny czas)
Idle timeout: 30 min (konkretny czas)
Payment timeout: 30 min (konkretny czas)
Container start timeout: 5 min, retry 3x (konkretny czas i liczba)
Health check: heartbeat co 30s, brak odpowiedzi >5 min = restart
Rate limiting: 5 avg, 10 burst, 1h period
PIN recovery: max 3 próby, blokada 24h
Backup retention: 7 dni lokalny, off-site (częstotliwość nieokreślona)
Koszty: $195-565/mies., break-even 2-4 klientów/dzień

Czego brakuje:

SLO/SLA — brak zdefiniowanych celów: uptime (99%/99.9%?), czas startu kontenera (30s/60s/120s?), response time API
Kryteria akceptacji — żaden przepływ nie ma zdefiniowanych warunków przejścia testów
Metryki jakości — brak definicji co oznacza "dobra jakość streamingu" (FPS? latency? resolution?)
Częstotliwość backupu off-site — określona jako "codziennie" dla lokalnego, ale off-site tylko "daily" lub "co godzinę"?
Progi skalowania — przy jakim obciążeniu uruchomić 30. instancję? Kiedy dodać kolejny serwer?

3.4 Wykonalność (7.5/10)

Technologie znane i sprawdzone:

Traefik — dojrzały projekt (v3), powszechnie używany, Docker provider to standardowa funkcja
Docker — limitowanie zasobów (memory, cpu, pids) to standardowa funkcjonalność
httpOnly cookie — standard web security, dobrze udokumentowany

WireGuard — lekki, prosty w konfiguracji

BTCPay Server — dojrzały, self-hosted, z pluginem Monero, ale wymaga własnej infrastruktury

GPG/age backup — standardowe narzędzia szyfrowania

Obszary ryzyka:

Selkies-GStreamer — streamowanie ekranu przeglądarki przez WebRTC/WebSocket to najbardziej złożony komponent. Brak informacji czy chodzi o Selkies-GStreamer (Jupyter/desktop streaming) czy KasmVNC / noVNC. W v1 był Novnc, w v2 jest Selkies. To wymaga doprecyzowania.

BTCPay self-hosted — wymaga osobnego serwera lub sub-domeny, certyfikatów SSL, konfiguracji Lightning. To nie jest trywialne, a specyfikacja nie określa tego jako osobny deployment.

Trocador API — w dniu audytu v1 root zwracał HTTP 503. Należy potwierdzić stabilność API przed implementacją.

30 kontenerów × 2 GB RAM = 60 GB RAM + rezerwa na system, Traefik, backend, DB. Serwer 128 GB RAM od Hetznera (AX102) to ~€200/mies. — feasiblity potwierdzona, ale na granicy.

User namespace remapping — --userns-remap=default może powodować problemy z mapowaniem UID/GID dla woluminów i permissions.

3.5 Bezpieczeństwo (8.0/10)

Silne strony:

SYS_ADMIN usunięte — największa poprawa. Kontener nie ma dostępu do mount, namespace, cgroups hosta

no-new-privileges — blokada eskalacji przez setuid binaries

seccomp — filtrowanie syscalli (wzmiankowane, ale brak konkretnego profilu)

userns-remap — root w kontenerze ≠ root na hoście

httpOnly cookie + Secure + SameSite=Strict — XSS nie może ukraść tokena

Fingerprint serwerowy — User-Agent + IP hash jako dodatkowa weryfikacja

CSP — restrykcyjna polityka (default-src 'self', connect-src ws: wss:)

HSTS — max-age=31536000, includeSubDomains, preload

Rate limiting — 5 req/h z burst 10 (ale może być za niskie)

TOTP obowiązkowe dla admina

Admin IP allowlist — ograniczenie dostępu do panelu

Backup off-site encrypted — GPG/age przed wysyłką, klucz poza serwerem

Słabe strony / luki:

Secrets management — brak specyfikacji: gdzie przechowywane są klucze API Trocador, BTCPay, secret key dla JWT/cookie, TOTP secrets, klucz GPG? Hashicorp Vault? Docker secrets? .env na dysku?

Container image scanning — brak wzmianki o skanowaniu obrazów (Chrome/Brave/Firefox) pod kątem podatności. Obrazy linuxserver.io są aktualizowane, ale nie ma procesu weryfikacji.

Audit logging admina — logowanie prób logowania jest, ale brak logowania akcji (kto i kiedy stopował kontener, anulował zamówienie)

DDoS protection — rate limiting na poziomie Traefik, ale brak warstwy WAF lub Cloudflare (świadomie wykluczone w v1, ale warte rozważenia)

Supply chain attack — Docker images z Docker Hub bez weryfikacji podpisów (Cosign, Notary)

Database encryption at rest — brak specyfikacji szyfrowania bazy danych (SQLite/PostgreSQL?)

4. Lista problemów

KRYTYCZNY (blokuje implementację)

# Problem Status w v1

K1 Brak szczegółów integracji BTCPay Server — webhook handling, invoice creation, refund flow, konfiguracja failover timeou (2 min tylko wzmiankowane). Bez tego nie da się zaimplementować płatności. Nowy (v1 nie miał BTCPay)

K2 Selkies-GStreamer niedospecyfikowany — brak informacji jak streamowanie jest konfigurowane w kontenerze, jakie protokoły (WebRTC/WebSocket/NO VNC), porty, zależności, obraz. W v1 był Novnc, w v2 Selkies — bez doprecyzowania implementacja jest niemożliwa. Nowy (zmiana z Novnc)

WAŻNY (istotne ryzyko)

# Problem Status w v1

W1 Brak SLO/SLA — uptime, czas startu kontenera, response time API. Bez tego nie można określić czy produkt działa poprawnie. Pozostał z v1

W2 Brak kryteriów akceptacji — żaden przepływ nie ma zdefiniowanych warunków przejścia testów. Pozostał z v1

W3 Secrets management — brak specyfikacji przechowywania kluczy API, haseł, TOTP secrets, klucza GPG. Nowy

W4 Admin panel wciąż niedospecyfikowany — jakie akcje admin może wykonać? Dashboard, orders, containers, VPN configs, tickets, settings, sales reports — lista jest, ale brak konkretnych endpointów i uprawnień. Pozostał z v1 (częściowo adresowany)

W5 Rate limiting 5 req/h może być zbyt restrykcyjne — normalny użytkownik wybierający browser, region, plan, klikający pay wygeneruje kilka requestów. Ryzyko fałszywych blokad. Nowy

W6 Brak skanowania obrazów kontenerów — Chrome/Brave/Firefox mają znane podatności. Obrazy linuxserver.io są bezpieczne, ale nie ma procesu weryfikacji. Nowy

W7 Brak deployment/CI/CD spec — jak buildować, testować i deployować? Nadaje się do implementacji, ale bez procesu CI/CD ryzyko regresji. Pozostał z v1

KOSMETYCZNY (drobne poprawki)

# Problem Status w v1

C1 Brak diagramu ERD — relacje między tabelami orders, sessions, tickets, vpn_configs. Pozostał z v1

C2 Brak specyfikacji monitoringu/alerting — jakie metryki, progi, dashboardy, kanały alertów (Telegram tylko wzmiankowany). Pozostał z v1

C3 Brak profilu seccomp — wzmiankowany custom.json, ale nie dołączony ani nie opisany. Nowy

C4 Brak polityki wersjonowania API — URL /api/v1/ sugeruje wersjonowanie, ale brak zasad (deprecation, backward compatibility). Nowy

C5 Brak specyfikacji częstości backupu off-site — "codziennie" dla lokalnego, ale off-site? Nowy

C6 Brak informacji o bazie danych — SQLite czy PostgreSQL? Backup bazy danych? Migracje? Pozostał z v1

5. Porównanie: v1 vs v2 — mapa problemów

Problemy rozwiązane (v1 → v2)

Problem v1 Rozwiązanie w v2 Ocena

P0-1: Trocador SPoF (503, brak failover) Trocador + BTCPay dual provider z automatycznym failover ✅ W pełni rozwiązany

P0-2: Caddy WebSocket (brak dynamicznego resolve) Traefik z Docker provider, WebSocket wspierany natywnie ✅ W pełni rozwiązany

P0-3: SYS_ADMIN (zbyt szeroka capability) NET_ADMIN + SYS_PTRACE, no-new-privileges, seccomp, userns-remap ✅ W pełni rozwiązany

P0-4: localStorage + XSS (deviceToken dostępny przez JS) Tylko httpOnly cookie, fingerprint serwerowy ✅ W pełni rozwiązany

P0-5: Brak limitów zasobów (wyciek pamięci = 50 sesji) memory 2g, cpu 1.0, pids 200, reservations ✅ W pełni rozwiązany

W2: Brak timeoutu płatności pending Scheduler co 1 min, timeout 30 min, kolumna payment_timeout_at ✅ W pełni rozwiązany

W3: Brak recovery device binding Order number + 6-cyfrowy PIN (bcrypt, max 3 próby) ✅ W pełni rozwiązany

W4: Niejednoznaczny 1h buffer Jasny opis: 1h na pierwszy dostęp, potem zegar, idle timeout 30 min ✅ W pełni rozwiązany

C8: Brak statusu underpaid Nowy status underpaid, alert, user widzi info ✅ W pełni rozwiązany

Problemy pozostałe (v1 → v2 nadal nierozwiązane)

Problem v1 Status w v2 Uwaga

W7: Brak kryteriów akceptacji ❌ Nadal brak W2 w nowym raporcie

Brak SLO/SLA ❌ Nadal brak W1 w nowym raporcie

Admin panel niedospecyfikowany ⚠️ Częściowo — lista działań jest, ale brak endpointów W4 w nowym raporcie

Brak diagramu ERD ❌ Nadal brak C1

Brak deployment/CI/CD ❌ Nadal brak W7

Brak specyfikacji bazy danych ❌ Nadal brak C6

Brak monitoringu/alerting ❌ Nadal brak C2

Nowe problemy (v2)

Problem Kategoria Uwaga

Brak szczegółów integracji BTCPay KRYTYCZNY Nowy komponent

Selkies-GStreamer niedospecyfikowany KRYTYCZNY Zmiana z Novnc

Secrets management WAŻNY Nowa konieczność

Rate limiting może być za niskie WAŻNY Nowa konfiguracja

Brak skanowania obrazów WAŻNY Nowa praktyka security

Brak profilu seccomp KOSMETYCZNY Nowy wymóg

Brak wersjonowania API KOSMETYCZNY Nowy wzór

Częstość backupu off-site KOSMETYCZNY Nowy proces

6. Glosariusz

Termin Definicja

BTCPay Server Self-hostowany procesor płatności kryptowalut (BTC/Lightning, altcoiny przez pluginy)

Caddy Web server i reverse proxy w Go z automatycznym HTTPS

Capabilities (Linux) Podział uprawnień roota na niezależne jednostki (np. NET_ADMIN, SYS_ADMIN)

CSP (Content Security Policy) Nagłówek HTTP ograniczający źródła zasobów (skrypty, style, obrazy)

Docker provider Mechanizm Traefik do automatycznego wykrywania routingu z labeli Docker

Fingerprint serwerowy Hash User-Agent + IP klienta jako dodatkowa weryfikacja tożsamości

GPG/age Narzędzia do szyfrowania plików (GNU Privacy Guard / age)

HSTS HTTP Strict-Transport-Security — wymusza HTTPS dla wszystkich połączeń

httpOnly cookie Ciasteczko niedostępne z JavaScript (ochrona przed XSS)

Idle timeout Automatyczne zatrzymanie kontenera po okresie braku aktywności

NET_ADMIN Linux capability — zarządzanie siecią (WireGuard, iptables)

no-new-privileges Security option Docker — blokada eskalacji uprawnień

OpenAPI Standard specyfikacji REST API

Seccomp Linux security module — filtrowanie syscalli

Selkies-GStreamer Framework do streamowania desktopu/ekranu przez WebRTC

SPoF Single Point of Failure — pojedynczy punkt awarii

SYS_ADMIN Linux capability — szeroki zestaw uprawnień administracyjnych

SYS_PTRACE Linux capability — debugowanie procesów (trace, ptrace wymagany przez GStreamer)

TOTP Time-based One-Time Password — dwuskładnikowe uwierzytelnianie

Traefik Reverse proxy i load balancer z automatycznym HTTPS i Docker provider

Trocador AnonPay Aggregator krypto-płatności wspierający Monero

userns-remap User namespace remapping — root w kontenerze mapowany na nieuprzywilejowanego użytkownika hosta

WireGuard Lekki, nowoczesny protokół VPN w jądrze Linux

7. Źródła

Pliki źródłowe

Specyfikacja v2: /root/browser-vpn-deploy/docs/superpowers/specs/2026-07-22-browser-vpn-v2-design.md (296 linii)

Specyfikacja v1: /root/browser-vpn-deploy/docs/superpowers/specs/2026-07-22-browser-vpn-product-design.md (738 linii, 15 sekcji)

Raport v1 (CEO): /root/convertere/reports/v1-private-browser.md (338 linii, 6.3/10)

Raport v2 (s_1): /root/convertere/reports/v2-private-browser.md (96 linii, 6/10)

Raport bieżący (v5): /root/convertere/reports/v5-private-browser.md

Linki zewnętrzne

Traefik Docker provider: https://doc.traefik.io/traefik/providers/docker/

BTCPay Server: https://btcpayserver.org/

Trocador AnonPay: https://trocador.app/

Selkies-GStreamer: https://github.com/selkies-project/selkies-gstreamer

Linux capabilities: https://docs.docker.com/engine/security/security/#linux-kernel-capabilities

Seccomp Docker: https://docs.docker.com/engine/security/seccomp/

User namespace remap: https://docs.docker.com/engine/security/userns-remap/

CSP Reference: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy

HSTS: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Strict-Transport-Security

WireGuard: https://www.wireguard.com/

8. Rekomendacje

Przed implementacją (obowiązkowe)

Doprecyzuj integrację BTCPay — opisz webhook handling, tworzenie invoice, failover flow, obsługę refundów, jakie kryptowaluty są wspierane

Doprecyzuj Selkies streaming — określ konkretny obraz, porty, protokoły (WebRTC/WebSocket), konfigurację, zależności

Dodaj secrets management — opisz gdzie i jak przechowywane są klucze API, hasła, TOTP secrets, klucz GPG (Docker secrets, .env, Vault)

W pierwszym sprincie (zalecane)

Dodaj kryteria akceptacji dla każdego przepływu (zakup, aktywacja, sesja, wygaśnięcie, support, backup)

Zdefiniuj SLO — uptime 99.5%+, czas startu kontenera <60s, response time API <200ms

Dodaj profil seccomp dla kontenera przeglądarki

Określ częstotliwość backupu off-site — codziennie, co godzinę, co 6h?

Dodaj skanowanie obrazów — Trivy, Grype, Docker Scout

Drugi sprint (nice-to-have)

Diagram ERD

Polityka wersjonowania API

Specyfikacja monitoringu (Prometheus/Grafana?)

CI/CD pipeline (GitHub Actions / GitLab CI)

Koniec raportu v5. 2026-07-22.

#	Problem	Status w v1
K1	Brak szczegółów integracji BTCPay Server — webhook handling, invoice creation, refund flow, konfiguracja failover timeou (2 min tylko wzmiankowane). Bez tego nie da się zaimplementować płatności.	Nowy (v1 nie miał BTCPay)
K2	Selkies-GStreamer niedospecyfikowany — brak informacji jak streamowanie jest konfigurowane w kontenerze, jakie protokoły (WebRTC/WebSocket/NO VNC), porty, zależności, obraz. W v1 był Novnc, w v2 Selkies — bez doprecyzowania implementacja jest niemożliwa.	Nowy (zmiana z Novnc)

#	Problem	Status w v1
W1	Brak SLO/SLA — uptime, czas startu kontenera, response time API. Bez tego nie można określić czy produkt działa poprawnie.	Pozostał z v1
W2	Brak kryteriów akceptacji — żaden przepływ nie ma zdefiniowanych warunków przejścia testów.	Pozostał z v1
W3	Secrets management — brak specyfikacji przechowywania kluczy API, haseł, TOTP secrets, klucza GPG.	Nowy
W4	Admin panel wciąż niedospecyfikowany — jakie akcje admin może wykonać? Dashboard, orders, containers, VPN configs, tickets, settings, sales reports — lista jest, ale brak konkretnych endpointów i uprawnień.	Pozostał z v1 (częściowo adresowany)
W5	Rate limiting 5 req/h może być zbyt restrykcyjne — normalny użytkownik wybierający browser, region, plan, klikający pay wygeneruje kilka requestów. Ryzyko fałszywych blokad.	Nowy
W6	Brak skanowania obrazów kontenerów — Chrome/Brave/Firefox mają znane podatności. Obrazy linuxserver.io są bezpieczne, ale nie ma procesu weryfikacji.	Nowy
W7	Brak deployment/CI/CD spec — jak buildować, testować i deployować? Nadaje się do implementacji, ale bez procesu CI/CD ryzyko regresji.	Pozostał z v1

#	Problem	Status w v1
C1	Brak diagramu ERD — relacje między tabelami orders, sessions, tickets, vpn_configs.	Pozostał z v1
C2	Brak specyfikacji monitoringu/alerting — jakie metryki, progi, dashboardy, kanały alertów (Telegram tylko wzmiankowany).	Pozostał z v1
C3	Brak profilu seccomp — wzmiankowany `custom.json`, ale nie dołączony ani nie opisany.	Nowy
C4	Brak polityki wersjonowania API — URL /api/v1/ sugeruje wersjonowanie, ale brak zasad (deprecation, backward compatibility).	Nowy
C5	Brak specyfikacji częstości backupu off-site — "codziennie" dla lokalnego, ale off-site?	Nowy
C6	Brak informacji o bazie danych — SQLite czy PostgreSQL? Backup bazy danych? Migracje?	Pozostał z v1

Problem v1	Rozwiązanie w v2	Ocena
P0-1: Trocador SPoF (503, brak failover)	Trocador + BTCPay dual provider z automatycznym failover	✅ W pełni rozwiązany
P0-2: Caddy WebSocket (brak dynamicznego resolve)	Traefik z Docker provider, WebSocket wspierany natywnie	✅ W pełni rozwiązany
P0-3: SYS_ADMIN (zbyt szeroka capability)	NET_ADMIN + SYS_PTRACE, no-new-privileges, seccomp, userns-remap	✅ W pełni rozwiązany
P0-4: localStorage + XSS (deviceToken dostępny przez JS)	Tylko httpOnly cookie, fingerprint serwerowy	✅ W pełni rozwiązany
P0-5: Brak limitów zasobów (wyciek pamięci = 50 sesji)	memory 2g, cpu 1.0, pids 200, reservations	✅ W pełni rozwiązany
W2: Brak timeoutu płatności pending	Scheduler co 1 min, timeout 30 min, kolumna payment_timeout_at	✅ W pełni rozwiązany
W3: Brak recovery device binding	Order number + 6-cyfrowy PIN (bcrypt, max 3 próby)	✅ W pełni rozwiązany
W4: Niejednoznaczny 1h buffer	Jasny opis: 1h na pierwszy dostęp, potem zegar, idle timeout 30 min	✅ W pełni rozwiązany
C8: Brak statusu underpaid	Nowy status `underpaid`, alert, user widzi info	✅ W pełni rozwiązany

Problem v1	Status w v2	Uwaga
W7: Brak kryteriów akceptacji	❌ Nadal brak	W2 w nowym raporcie
Brak SLO/SLA	❌ Nadal brak	W1 w nowym raporcie
Admin panel niedospecyfikowany	⚠️ Częściowo — lista działań jest, ale brak endpointów	W4 w nowym raporcie
Brak diagramu ERD	❌ Nadal brak	C1
Brak deployment/CI/CD	❌ Nadal brak	W7
Brak specyfikacji bazy danych	❌ Nadal brak	C6
Brak monitoringu/alerting	❌ Nadal brak	C2

Problem	Kategoria	Uwaga
Brak szczegółów integracji BTCPay	KRYTYCZNY	Nowy komponent
Selkies-GStreamer niedospecyfikowany	KRYTYCZNY	Zmiana z Novnc
Secrets management	WAŻNY	Nowa konieczność
Rate limiting może być za niskie	WAŻNY	Nowa konfiguracja
Brak skanowania obrazów	WAŻNY	Nowa praktyka security
Brak profilu seccomp	KOSMETYCZNY	Nowy wymóg
Brak wersjonowania API	KOSMETYCZNY	Nowy wzór
Częstość backupu off-site	KOSMETYCZNY	Nowy proces

Termin	Definicja
BTCPay Server	Self-hostowany procesor płatności kryptowalut (BTC/Lightning, altcoiny przez pluginy)
Caddy	Web server i reverse proxy w Go z automatycznym HTTPS
Capabilities (Linux)	Podział uprawnień roota na niezależne jednostki (np. NET_ADMIN, SYS_ADMIN)
CSP (Content Security Policy)	Nagłówek HTTP ograniczający źródła zasobów (skrypty, style, obrazy)
Docker provider	Mechanizm Traefik do automatycznego wykrywania routingu z labeli Docker
Fingerprint serwerowy	Hash User-Agent + IP klienta jako dodatkowa weryfikacja tożsamości
GPG/age	Narzędzia do szyfrowania plików (GNU Privacy Guard / age)
HSTS	HTTP Strict-Transport-Security — wymusza HTTPS dla wszystkich połączeń
httpOnly cookie	Ciasteczko niedostępne z JavaScript (ochrona przed XSS)
Idle timeout	Automatyczne zatrzymanie kontenera po okresie braku aktywności
NET_ADMIN	Linux capability — zarządzanie siecią (WireGuard, iptables)
no-new-privileges	Security option Docker — blokada eskalacji uprawnień
OpenAPI	Standard specyfikacji REST API
Seccomp	Linux security module — filtrowanie syscalli
Selkies-GStreamer	Framework do streamowania desktopu/ekranu przez WebRTC
SPoF	Single Point of Failure — pojedynczy punkt awarii
SYS_ADMIN	Linux capability — szeroki zestaw uprawnień administracyjnych
SYS_PTRACE	Linux capability — debugowanie procesów (trace, ptrace wymagany przez GStreamer)
TOTP	Time-based One-Time Password — dwuskładnikowe uwierzytelnianie
Traefik	Reverse proxy i load balancer z automatycznym HTTPS i Docker provider
Trocador AnonPay	Aggregator krypto-płatności wspierający Monero
userns-remap	User namespace remapping — root w kontenerze mapowany na nieuprzywilejowanego użytkownika hosta
WireGuard	Lekki, nowoczesny protokół VPN w jądrze Linux