# Sesja 2026-06-22 — KB spine relokowany na PIHA + przygotowanie hosta

## Cel

Przenieść spine KB (Postgres + pgvector) z SOLARIA na PIHA, przygotować host PIHA pod
kontener z twardym limitem pamięci, zdeployować i zweryfikować schemat. SOLARIA bywa
offline — zapytania KB muszą działać 24/7, więc spine musi stać na always-on maszynie.

---

## DECYZJA

- **Spine Postgres + pgvector przeniesiony SOLARIA → PIHA.** Powód: PIHA (Raspberry Pi 5)
  jest always-on, SOLARIA bywa offline; zapytania KB mają działać 24/7. SOLARIA zostaje do
  GPU/embeddingów (bge-m3) i indexera.
- **Archiwum maili `.eml` docelowo też na PIHA** (NVMe).

---

## PIHA — przygotowanie hosta

- **Swap:** dodano 4GB swapfile (`/swapfile`), utrwalony w `/etc/fstab`. Brak swapa był
  ryzykiem OOM dla Home Assistant.
- **Cgroup memory:** kernel nie eksponował cgroup memory controllera → dopisano
  `cgroup_enable=memory cgroup_memory=1` do `/boot/firmware/cmdline.txt`
  (backup: `cmdline.txt.bak`) + reboot. Po reboocie `cgroup.controllers` zawiera `memory`,
  docker `mem_limit` faktycznie działa (wcześniej był ignorowany).

---

## Relokacja w git

Praca w worktree `task/kb-postgres-piha`, zmergowana do master jako commit **2b3cb89**.

- Override SOLARIA (`hosts/solaria/runtime/kb-postgres/`) **usunięty**;
  wpis z `hosts/solaria/services.yaml` zdjęty.
- Dodany `hosts/piha/runtime/kb-postgres/docker-compose.override.yml`:
  - `mem_limit: 1g`, `mem_reservation: 512m` (soft reservation ignorowany przez kernel —
    nieszkodliwe; twardy `mem_limit` chroni HA przed OOM).
  - Tuning Postgresa pod małą maszynę: `shared_buffers 256MB`, `effective_cache_size 512MB`,
    `work_mem 8MB`, `maintenance_work_mem 64MB`, `max_connections 30`.
- Obraz `pgvector/pgvector:pg16` potwierdzony **arm64**.
- Named volume `kb_postgres_data` na **NVMe** (docker `data-root = /home/docker` →
  `/dev/nvme0n1p3`, ~170GB wolne).
- `inventory/topology.yaml` + `hosts/piha/services.yaml` — wpisy przeniesione.

---

## Deploy na PIHA

- Kontener **healthy**.
- Schemat `envelope` + extension `vector` zweryfikowane w działającej bazie.
- `mem_limit 1g` zaaplikowany po **force-recreate** (zwykły `up` nie podmienia limitu).

---

## Google Takeout (bulk Gmail)

- Pobrany: **15GB zip**, jeden plik; Mail po rozpakowaniu **~26.9GB**.
- Leży na **SOLARIA `~/Downloads`**, NIE rozpakowany jeszcze.
- Docelowo: transfer na PIHA NVMe → import. Czeka na importer (etap 3).

---

## Higiena git

- Cała praca przez worktree: `task/kb-foundations` (zmergowany i sprzątnięty),
  `task/kb-postgres-piha` (zmergowany).
- Master deploy-only, czysty.

---

## GOTCHA PIHA (do zapamiętania)

`~/.ssh/id_rsa` na PIHA miał perms **0640** → `git fetch` przez SSH padał
(`bad permissions`). Fix: `chmod 600 ~/.ssh/id_rsa`. To ta sama klasa problemów
uid/permisji co wcześniej na PIHA — przy onboardingu PIHA warto sprawdzać perms kluczy.

---

## Następny krok

**Importer bulk Gmail** (worktree `task/kb-gmail-import`):
- CLI w `packages/kb-mail`, `mbox → archiwum (.eml) + envelope`, **idempotentny**, `--dsn` na PIHA.
- Potem: transfer Takeout na PIHA NVMe + run.

---

## BACKLOG (osobno, nieruszane w tej sesji)

- **`hosts/piha/capabilities.yaml` rozjazd danych:** mówi `memory 4GB` / `sd-card 32GB`;
  realnie **8GB RAM + NVMe 170GB**. Ten sam typ rozjazdu danych co przy 8-dniowej ślepocie
  floty — do poprawienia.
- **`KB_TEST_DSN` w `packages/kb-mail/tests/test_db.py`** — wskazuje na solaria, powinien piha.
- **Deklaratywny zapis `cgroup_enable` + swap dla PIHA** — firmware/host config jest poza
  obecnym GitOps; rozważyć jak go ująć.