diff --git a/docs/backlog.md b/docs/backlog.md
index 5ebd918..6d1adf2 100644
--- a/docs/backlog.md
+++ b/docs/backlog.md
@@ -643,3 +643,23 @@ zero `File not found`. Dokumenty testowe usunięte po teście (`document.delete(
 - Test formalnego fallbacku (stop worker@SOLARIA → kolejka mieli na PIHA →
   start → drenaż) nie był wykonany w tej sesji — mechanizm nie zmienił się
   tym fixem (był już OK), ale warto zweryfikować przy okazji.
+
+## Nowe serwisy KB nie sa w monitoringu (desired-state)
+
+**Data:** 2026-07-12
+
+**Problem:** Zdeployowane serwisy filaru dokumentow nie maja wpisow w `hosts/*/services.yaml`
+i `inventory/topology.yaml`, wiec supervisor/observer ich NIE WIDZA w desired-state:
+- `paperless` + `paperless-db` + `paperless-broker` (PIHA) — Deploy 1, 2026-07-10
+- `paperless-worker` (SOLARIA) — Deploy 2, 2026-07-12 (SOLARIA ma tam tylko `node-agent`)
+
+**Skutek:** drift nie jest wykrywany. Jesli worker padnie i nie wstanie, albo paperless
+przestanie dzialac — agent system tego nie zglosi. Dowiesz sie dopiero po tym, ze kolejka
+nie jest przetwarzana / strona nie odpowiada.
+
+**Fix:** dodac wpisy do `hosts/piha/services.yaml`, `hosts/solaria/services.yaml`,
+`inventory/topology.yaml`. Zweryfikowac ze observer/supervisor je widza (healthcheck,
+liveness). Dotyczy tez przyszlych: nextcloud, gokapi.
+
+**Zasada na przyszlosc:** rejestracja w services.yaml/topology to CZESC deployu, nie osobny
+krok "kiedys" — inaczej kazdy nowy serwis to slepy punkt monitoringu.
diff --git a/docs/sessions/2026-07-12-deploy2-ocr-worker.md b/docs/sessions/2026-07-12-deploy2-ocr-worker.md
new file mode 100644
index 0000000..efadc87
--- /dev/null
+++ b/docs/sessions/2026-07-12-deploy2-ocr-worker.md
@@ -0,0 +1,44 @@
+# Sesja 2026-07-12 — Deploy 2: split-host OCR-worker (DZIALA) + decyzja kierunku KB
+
+## Deploy 2 — OCR-worker na SOLARIA przez NFS: DZIALA end-to-end
+Najtrudniejsza technicznie czesc KB (wzorzec nieoficjalnie wspierany, GH #3900) — przeszla.
+
+### NFS
+- nfs-kernel-server JUZ byl na PIHA (aktywny, export /media/pimain istnial).
+- Dodany export: /opt/homelab/data/paperless 192.168.31.70(rw,sync,no_subtree_check,no_root_squash)
+  — tylko SOLARIA (nie *), UID przechodza 1:1.
+- UID: oskar=1004 na PIHA, 1000 na SOLARII (znany tech-debt floty), ALE pliki Paperlessa
+  sa 1000:1000 (kontener nadpisal nasz chown 1004) — wiec zgodnosc naturalna, bez squash.
+- nfs-common na SOLARII byl. Docker-managed NFS volumes (driver local, type nfs) — zero fstab.
+
+### Dwa bugi w configu (znalezione, naprawione, zweryfikowane)
+1. **command nie odpalal celery.** Entrypoint obrazu: `if [[ "$1" != "/"* ]]; then exec gosu
+   paperless python3 manage.py "$@"; else exec "$@"; fi` — argument bez "/" idzie do manage.py
+   -> "Unknown command: 'celery'". FIX: sciezka absolutna + jawny gosu:
+   command: /usr/sbin/gosu paperless /usr/local/bin/celery --app paperless worker ...
+2. **Brak wspoldzielonego SCRATCH.** Paperless@PIHA stage'uje upload w /tmp/paperless/tmpXXX
+   i niesie ABSOLUTNA sciezke w payloadzie celery. Worker@SOLARIA mial swoj lokalny /tmp ->
+   "Cannot consume ...: File not found" (czesc dokumentow padala — te ktore wzial SOLARIA).
+   FIX: /opt/homelab/data/paperless/scratch przez NFS, mount /tmp/paperless po OBU stronach.
+   Ta sama zasada co data/media/consume (identyczne sciezki kontenerowe) — scratch zostal pominiety.
+
+### Dowod (test na zywo, CC)
+3 PDF do consume/ na PIHA. split-host-test-2.pdf odebrany przez worker@SOLARIA:
+"pdftotext exited 0 -> ocrmypdf -> Output file is a PDF/A-2B; ConsumeTaskPlugin completed:
+Success. New document id 7 created". Zero "File not found". Wlasnosc pi:pi (1000) na NFS.
+Dokumenty testowe posprzatane, produkcyjne 6 nietkniete.
+
+## DECYZJA KIERUNKU (wazna)
+Nie lancuch importow, tylko **pionowy plaster**: jeden import probki -> warstwa uzytkowa.
+Kolejnosc: (1) import probki zalacznikow z maili -> Paperless (jego OCR+correspondent-detection,
+NIE osobny pipeline), (2) MODUL 5: koperta w kb-postgres (Paperless=REFERENCJA doc-id,
+Nextcloud=KOPIA) + embeddingi bge-m3 -> pgvector + cross-source link (correspondent <-> nadawca
+maila = ta sama encja, DOWOD zasady kb-00 #7), (3) interfejs pytan (RAG) — pierwszy moment
+realnej uzytecznosci. Dopiero POTEM dopelniac importy (reszta Takeout, zdjecia, transakcje).
+
+## TODO nastepne
+- MODUL 5 (koperta + ingest + embeddingi + cross-source) — docs/kb/modules/05-documents-ingest.md
+- Import probki zalacznikow z maili (kilkaset, nie 70k) — do zbudowania RAG
+- Interfejs pytan / RAG — warstwa uzytkowa
+- Deploy 3 (Nextcloud), Deploy 4 (Gokapi) — configi gotowe, czekaja
+- Google Takeout — zamowic selektywnie, PO zbudowaniu warstwy uzytkowej