docs(snapshot): sync workspace documentation

dlob-retention-feature-store-plan.md

@@ -0,0 +1,236 @@
+# DLOB Retention And Feature Store Plan
+
+Status na `2026-03-29`.
+
+Ten dokument zapisuje robocze ustalenia o:
+
+- retencji danych DLOB na `mevnode_bot`
+- ryzyku zajetosci dysku
+- tym, co warto trzymac dlugo pod modele / "economic transformers"
+
+## Aktualny stan operacyjny
+
+### Dysk
+
+- root `/` na `mevnode_bot`: `3.6T`
+- zajete: ok. `471G`
+- wolne: ok. `3.0T`
+- biezace uzycie: ok. `14%`
+
+Najwiekszy konsument miejsca:
+
+- PostgreSQL / TimescaleDB na local volume poda `postgres-0`
+- rozmiar bazy `crypto`: ok. `457 GB`
+
+Najwieksze hypertable:
+
+- `public.dlob_all_derived_ts`: ok. `260 GB`
+- `public.dlob_hot_snapshot_ts`: ok. `177 GB`
+- `public.dlob_hot_derived_ts`: ok. `19 GB`
+
+Wniosek:
+
+- miejsca nie brakuje teraz
+- ale storage DLOB jest juz na tyle duzy, ze trzeba nim zarzadzac swiadomie
+
+## Od kiedy sa dane
+
+- `dlob_hot_snapshot_ts`: od `2026-03-17 00:23:36.013+00`
+- `dlob_hot_derived_ts`: od `2026-03-17 00:23:36.013+00`
+- `dlob_all_derived_ts`: od `2026-03-17 00:44:42.386+00`
+
+## Aktualna retencja TimescaleDB
+
+Na `2026-03-29` retencja jest juz ustawiona i joby sa `Success`.
+
+- `dlob_hot_snapshot_ts`: `30 days`
+- `dlob_all_derived_ts`: `30 days`
+- `dlob_hot_derived_ts`: `180 days`
+- legacy `dlob_stats_ts` / `dlob_depth_bps_ts` / `dlob_slippage_ts*`: `7 days`
+
+Wazne doprecyzowanie:
+
+- stare rekordy nie beda "nadpisywane"
+- stare chunki beda usuwane przez polityki retencji
+
+Praktycznie:
+
+- tabele `30-day` zaczna byc realnie przycinane okolo `2026-04-16`
+- `dlob_hot_derived_ts` zacznie byc realnie przycinane dopiero po osiagnieciu ok. `180 days`
+
+## Czy trzeba juz robic ring buffer
+
+Nie pilnie.
+
+Lepsza kolejnosc:
+
+1. Zostawic obecna retencje.
+2. Sprawdzic po `2026-04-16`, czy `30-day` tabele rzeczywiscie zaczely sie wyplaszczac rozmiarowo.
+3. Wlaczyc kompresje TimescaleDB dla duzych hypertabli.
+4. Dopiero potem decydowac, czy potrzebny jest dodatkowy custom ring buffer.
+
+Powod:
+
+- miejsca jest duzo
+- retencja juz istnieje
+- najwiekszy zysk teraz da kompresja, nie customowa logika bufora
+
+## Wazna obserwacja
+
+Na `2026-03-29` kompresja TimescaleDB dla tabel `dlob_*` jest wylaczona:
+
+- `public.dlob_all_derived_ts`: `compression_enabled = false`
+- `public.dlob_hot_snapshot_ts`: `compression_enabled = false`
+- `public.dlob_hot_derived_ts`: `compression_enabled = false`
+
+To jest najprostszy kandydat na kolejny krok oszczedzania miejsca.
+
+## Co warto trzymac dlugo dla modeli
+
+Nie warto trzymac wszystkiego w raw snapshotach.
+
+Do treningu modeli bardziej oplacalne jest trzymanie:
+
+- stalych cech numerycznych
+- etykiet future outcome
+- kilku skal czasowych
+
+Zamiast:
+
+- pelnego `payload JSON`
+- wszystkich poziomow `bids/asks` dla kazdego ticka
+- duplikowania raw i derived w dlugim horyzoncie
+
+## Rekomendowana piramida danych
+
+### Warstwa 1. Short-term raw
+
+Przechowywac krotko jako source of truth:
+
+- `dlob_hot_snapshot_ts`
+- `dlob_all_derived_ts`
+
+Cel:
+
+- debugging
+- replay
+- reprocessing
+- walidacja feature engineering
+
+### Warstwa 2. Feature bars
+
+Z raw / derived budowac stale, numeryczne wektory cech:
+
+- `1s` feature bars na `180d+`
+- `5s` albo `15s` feature bars na `1y+`
+- `1m` regime bars bardzo dlugo
+
+To powinno byc glownym wejsciem do modeli.
+
+### Warstwa 3. Labels
+
+Osobno trzymac etykiety przyszlego wyniku:
+
+- `fwd_ret_1s`
+- `fwd_ret_5s`
+- `fwd_ret_30s`
+- `fwd_ret_5m`
+- `max_up`
+- `max_down`
+- adverse selection
+- fill probability proxy
+- edge net of fees / funding / slippage
+
+## Jakie cechy warto trzymac
+
+### Mikrostruktura
+
+- `mid`
+- `microprice`
+- `spread_bps`
+- `mark - oracle`
+- `mid - oracle`
+- basis
+
+### Plynnosc i ksiega
+
+- `best_bid_size`
+- `best_ask_size`
+- imbalance
+- depth w koszykach `1/2/5/10/20/50 bps`
+- slope / curvature booka
+
+### Aktywnosc i jakosc feedu
+
+- liczba update'ow w bucketcie
+- udział `indicative` vs normalnych snapshotow
+- staleness feedu
+- luki czasowe
+
+### Statystyki krotkoterminowe
+
+- realized vol `5s`
+- realized vol `30s`
+- realized vol `5m`
+- momentum score
+- mean reversion score
+- spread capture proxy
+- slippage dla stalych notionals
+
+## Proponowane tabele docelowe
+
+Minimalny zestaw:
+
+- `dlob_features_1s`
+- `dlob_features_5s`
+- `dlob_regime_1m`
+- `bot_labels_horizons`
+
+Kazda z tych tabel powinna miec:
+
+- `event_ts`
+- `source`
+- `market_type`
+- `market_index`
+- zestaw cech numerycznych
+- opcjonalnie `meta`
+
+To da:
+
+- staly rozmiar rekordu
+- tansze trenowanie
+- latwiejsze sample / batch / join
+- mniej miejsca niz raw JSON
+
+## Dlaczego to jest lepsze od trzymania wszystkiego
+
+Bo modele nie potrzebuja pelnego surowego payloadu do kazdego kroku.
+
+Dla modeli wazniejsze sa:
+
+- stabilne, stale-wymiarowe wejscia
+- konsekwentne etykiety
+- latwe agregowanie po oknach czasu
+
+Raw trzeba trzymac krotko.
+Feature store i labels trzeba trzymac dlugo.
+
+## Rekomendacja na kolejny tydzien
+
+1. Nie wdrazac jeszcze custom ring buffer.
+2. Zweryfikowac po `2026-04-16`, czy `30-day` retencja rzeczywiscie przycina `hot_snapshot` i `all_derived`.
+3. Przygotowac plan wlaczenia kompresji TimescaleDB dla:
+   - `dlob_all_derived_ts`
+   - `dlob_hot_snapshot_ts`
+   - `dlob_hot_derived_ts`
+4. Zaprojektowac schemat `dlob_features_1s`, `dlob_features_5s`, `dlob_regime_1m`, `bot_labels_horizons`.
+5. Uznac raw DLOB za short-term storage, a feature bars + labels za long-term storage pod modele.
+
+## Decyzja robocza
+
+Obecny kierunek:
+
+- retencja raw zostaje
+- kompresja powinna byc kolejnym krokiem
+- dlugoterminowo nie trzymac wszystkiego jako raw snapshots
+- dla modeli przejsc na warstwy cech i etykiet o nizszej skali