1.**Archiwum ≠ indeks.** Archiwum surowe/niezmienne (asset, wieczne); indeks pochodny i odtwarzalny (wyrzucalny). Re-indeks z archiwum przy lepszym modelu.
2.**Koperta = jedyny kontrakt zamrożony z góry.** Addytywna. Zamrożone: `id · source · ts(UTC) · geo · raw_ref` + otwarte pole `entities[]`. Cała semantyka (typy encji, resolution, graf) **płynie** — rośnie z danych.
3.**Czas + miejsce jako byty pierwszej klasy od dnia zero.** Uniwersalny klucz złączeń między źródłami, karmiony OwnTracks. Nie da się retrofitować bez re-ingestu — stąd w kopercie od startu.
4.**Local-first / privacy.** Korpus (bank + prywatne zdjęcia + maile) → wszystko lokalnie. Embeddingi i modele na SOLARIA (GPU + ollama). Zero chmury dla danych wrażliwych.
5.**Protokół, nie provider.** Ingest pisany przeciw standardom (JMAP, IMAP, WebDAV), nie przeciw firmie → przenośność.
6.**Jeden spine: Postgres + pgvector.** Koperta + wektory (+ później encje + punkty OwnTracks) w jednym store. Mniej ruchomych części. Spine stoi na **PIHA** (Raspberry Pi 5, always-on) — zapytania KB muszą działać 24/7, a SOLARIA bywa offline. SOLARIA zostaje do GPU/embeddingów (bge-m3) i indexera.
7.**Warstwa 4 nie jest waterfallem.** Kontrakt encji (warstwa 3) definiujemy wcześnie — przy 2 źródłach; po drugim źródle stawiamy *cienką* wersję warstwy 4, by udowodnić cross-source linking; dopiero potem dokładamy resztę.
---
## Kolejność projektów (z uzasadnieniem)
1.**Maile** — urgency historyczna (Gmail), czysty text RAG (najprostszy), stawia wzorce reużywalne przez resztę (archiwum, embeddingi na SOLARIA, szkielet agenta, deploy). Wzorzec referencyjny.
3.**Zdjęcia** — silnie zde-ryzykowane: Immich już robi multimodal. Projekt = cienki agent nad API Immicha. Może iść w parze z dokumentami.
4.**Transakcje** — inny paradygmat (strukturalny/analityka, *nie* RAG); najmniej danych, najtrudniejszy acquisition. Na koniec.
5.**Interdyscyplinarny** — capstone; ale jego *szkielet* (schema encji) powstaje już przy 1–2.
---
## Stan per źródło
- **Maile** — **dwa żywe źródła:** Fastmail (JMAP, primary) + Gmail (IMAP, bo konto **zostaje** jako śmieciowe/loginy/2FA). Plus jednorazowy bulk historyczny Gmaila. Reguła: **archiwizuj wszystko, indeksuj selektywnie** (filtr odrzuca login/2FA/notyfikacje z wektorów). Design: `kb-01-email-design.md`. **Następny do realizacji.**
- **Dokumenty** — **zdecydowane:** Nextcloud (zamiennik Drive, dowolne pliki + sync) **i** Paperless-ngx (podzbiór: skany/faktury/umowy z OCR). Dwa deploye; w ingeście jeden adapter na każdy (Nextcloud WebDAV + Paperless API).
- **Zdjęcia** — **Immich już działa** (storage + sync z telefonu + CLIP + twarze + EXIF). Projekt = cienki agent nad API Immicha + job: twarze→osoby, EXIF→miejsca do warstwy encji.
- **Transakcje** — **OPEN ISSUE.** Banki: gł. mBank + Revolut (+ reszta PL). Cel: maks automatyzacja. Kandydat: **agregator PSD2** (GoCardless Bank Account Data / Tink) — jedno wejście zamiast N adapterów. Ograniczenie regulacyjne: **zgoda PSD2 wygasa co 90 dni (SCA)** — pełnego bezobsługowego sync nie da się zrobić legalnie. Fallback zero-API: import CSV/MT940. Pokrycie mBanku, koszt agregatora, Revolut → do weryfikacji przy starcie filaru #4.
- **OwnTracks** — **działa**; feed do middleware jako warstwa spatio-temporalna (warstwa 3).
- **Płynne (rośnie z danych):** typy encji, entity resolution, graf tożsamości, linki cross-source.
- Powód: koperta jest retrofit-hostile ale data-independent (można ustalić „na ślepo"); semantyka odwrotnie — wymaga prawdziwych danych, więc jej nie usztywniamy.
| `packages/<lib>/` | Reużywalne biblioteki (nie deployowane samodzielnie). Instalacja: `pip install /repo/packages/<lib>/`. Nie mają `docker-compose.yml` ani `service.yaml`. |
| `services/<svc>/` | Długo żyjące serwisy Docker z `docker-compose.yml` + `service.yaml`. |
| `jobs/<job>/` | Jednorazowe i periodyczne joby CLI — bez Dockera, odpalane bezpośrednio na węźle (`pip install -e`). |
