Init repo infra + poprawki runbooka bootstrap i HANDOFF

- Krok 9 (tmux): tee -> tee -a (nie nadpisuj configu), dodano
  focus-events on, poprawiono nazwę sesji na "bootstrap"
- Krok 10: struktura katalogów odzwierciedla stan faktyczny
  (/srv i /srv/infra już istnieją, brakuje apps i data)
- Krok 12: Claude Code oznaczony jako wykonany 20-08-2026,
  instalator natywny bez Node.js
- Nowy Krok 14: audyt po bootstrapie (SSH, ufw, fail2ban,
  unattended-upgrades, swap, Docker, porty, klucze)
- HANDOFF.md: poprawiona numeracja sekcji 6

docs/runbooks/20-domena.md

@@ -0,0 +1,101 @@
+# Runbook 20 — domeny i DNS
+
+Wszystkie trzy domeny są w OVH, DNS też w OVH. To upraszcza sprawę: Traefik może
+używać API OVH do wyzwania **DNS-01**, więc dostajemy certyfikaty wildcard.
+
+---
+
+## 1. Dlaczego DNS-01, a nie HTTP-01
+
+| | HTTP-01 | DNS-01 (nasz wybór) |
+|---|---|---|
+| Jak działa | Let's Encrypt puka na port 80 | Traefik wpisuje rekord TXT przez API |
+| Wildcard | niemożliwy | możliwy |
+| Nowa subdomena | osobny certyfikat, osobne wyzwanie | działa od razu, zero akcji |
+| Usługi niepubliczne | nie da się | da się |
+| Wymaga | otwartego portu 80 | kluczy API dostawcy DNS |
+
+Przy wildcardzie `*.dfkk.cloud` dodanie `nowyprojekt.dfkk.cloud` to jeden rekord A
+i restart kontenera. Certyfikatem nie zajmujesz się w ogóle.
+
+---
+
+## 2. Klucze API OVH — jednorazowo
+
+1. Wejdź na stronę tworzenia tokenów API OVH dla właściwego regionu konta
+   (uwaga: konto jest w regionie **CA** — patrz adres panelu w `SERVER.md`,
+   to zmienia zarówno adres, pod którym generujesz token, jak i endpoint w konfiguracji)
+2. Uprawnienia zawężone do stref DNS — `GET`, `POST`, `PUT`, `DELETE`
+   na `/domain/zone/*`. Nie dawaj tokenowi pełnego dostępu do konta.
+3. Ważność: bez limitu, ale **wpisz token do `SERVER.md`, sekcja 9**, żeby wiadomo było,
+   co unieważnić przy incydencie
+4. Trzy wartości — application key, application secret, consumer key —
+   lądują w `/srv/infra/stacks/traefik/.env`, `chmod 600`, poza repo
+
+---
+
+## 3. Nowa subdomena
+
+```
+Typ: A
+Nazwa: <projekt>
+Cel: <IP serwera>
+TTL: 300 (na czas testów; potem można podnieść)
+```
+
+Sprawdzenie propagacji:
+
+```bash
+dig +short <projekt>.dfkk.cloud
+```
+
+Dopóki `dig` nie zwraca IP serwera, nie ma sensu debugować Traefika —
+problem jest w DNS, nie w kontenerze.
+
+---
+
+## 4. Nowa domena (druga lub trzecia)
+
+Wildcard obejmuje **tylko** `*.dfkk.cloud`. Kolejna domena wymaga:
+
+1. Rekordu A na IP serwera
+2. Dopisania nowej domeny do konfiguracji certresolvera w Traefiku
+   (osobny wpis `domains` z `main` i `sans`)
+3. Sprawdzenia, że token API OVH ma uprawnienia **także do tej strefy**
+4. Wpisu w `SERVER.md`, sekcja 2
+
+---
+
+## 5. Odpinanie domeny
+
+Kolejność odwrotna niż przy podpinaniu:
+
+- [ ] Usuń labele Traefika z compose i zrestartuj usługę
+- [ ] Usuń rekord A w panelu OVH
+- [ ] Sprawdź, że nie ma innych rekordów wskazujących na serwer (CNAME, MX)
+- [ ] Wykreśl subdomenę z `SERVER.md`, sekcja 2
+- [ ] Usuń monitor z Uptime Kuma
+
+Martwy rekord A wskazujący na Twój serwer to nie tylko bałagan — jeśli kiedyś oddasz
+to IP, ktoś inny odziedziczy ruch kierowany na Twoją nazwę.
+
+---
+
+## 6. Diagnostyka
+
+| Objaw | Gdzie szukać |
+|---|---|
+| `dig` nie zwraca IP | DNS, panel OVH — nie ruszaj serwera |
+| DNS ok, ale 404 z Traefika | literówka w `Host()` albo brak `traefik.enable=true` |
+| DNS ok, ale połączenie odrzucone | kontener nie działa lub nie jest w sieci `edge` |
+| Błąd certyfikatu | logi Traefika, klucze API OVH, uprawnienia do strefy |
+| Certyfikat „fake" / staging | w konfiguracji został adres staging Let's Encrypt |
+
+```bash
+docker logs traefik --tail=100 | grep -i -E "acme|error|certificate"
+```
+
+> **Uwaga na limity Let's Encrypt.** Przy debugowaniu certyfikatów łatwo wpaść
+> w limit żądań i zostać zablokowanym na tydzień. Jeśli certyfikat nie chce się
+> wystawić — przełącz się na serwer **staging** Let's Encrypt, dopracuj konfigurację
+> tam, i dopiero potem wróć na produkcyjny.