lethe-ui nie ma własnej logiki zbierania danych — czyta bezpośrednio pliki DuckDB (pl_web.duckdb, cz_web.duckdb, eu_web.duckdb, info_web.duckdb, łącznie ~30GB) i CSV wygenerowane przez backend /var/www/lethe. Wybór Nuxt 3 + @nuxt/ui i uruchamianie zapytań SQL przez `execFileSync('python3', ...duckdb...)` (server/utils/duckdb.ts) pokazuje, że to szybka wizualizacyjna nakładka na dane, a nie osobny system.

źródło: /var/www/lethe-ui/server/utils/duckdb.ts, /var/www/lethe-ui/nuxt.config.ts (LETHE_DATA_DIR)

Strony index/explorer/expiry/scoring/pipeline/vatican wskazują na konkretny cel: ranking domen po 'tier' (confirmed live, VA-linked, fresh, scored), monitoring wygasania (cron expiry_monitor co 12h) i wgląd w scoring wyjaśnialny per domena (server/api/scoring/explain/[domain]).

źródło: /var/www/lethe-ui/app/pages/index.vue (TIER_META), /var/www/lethe-ui/app/pages/expiry.vue, crontab -l (expiry_monitor.py)

Wszystkie ścieżki danych (LETHE_DATA_DIR, LETHE_LOG_DIR, LETHE_SRC_DIR) wskazują na katalog /var/www/lethe; zapytania SQL odpalane są przez podproces python3 z modułem duckdb — jeśli backend lethe przesunie/zmieni schemat bazy, lethe-ui się wysypie bez żadnej warstwy abstrakcji.

źródło: /var/www/lethe-ui/ecosystem.config.cjs, /var/www/lethe-ui/server/utils/duckdb.ts

Bez lethe-ui dane z Common Crawl (43GB w /var/www/lethe/data) byłyby dostępne tylko przez surowe zapytania SQL/CLI — ten dashboard to jedyny sposób by operator biznesowy realnie przeglądał i podejmował decyzje bez pisania kodu.

źródło: du -sh /var/www/lethe/data (43G), struktura stron app/pages/*.vue

pm2 jlist pokazuje status 'online', 18 restartów w ok. 2 tygodnie działania (od 27.06), logi out.log potwierdzają regularne 'Listening on http://127.0.0.1:3076' po każdym restarcie/deployu — brak pętli crashowania.

źródło: pm2 jlist (lethe-ui: status online, restart_time 18), lethe-ui-out.log

Katalog .builds/ zawiera 11 historycznych snapshotów (od 20260627-195106 do 20260630-193116) z symlinkiem .current — dowód, że mechanizm build→publish→smoke-test→ewentualny rollback jest realnie wykorzystywany, nie tylko napisany.

źródło: ls -la /var/www/lethe-ui/.builds/, scripts/release.mjs

W error logu z 27.06 widać powtarzający się błąd '[duckdb] Unexpected non-whitespace character after JSON at position 4' przez ok. 4 minuty — sugeruje, że któreś zapytanie zwracało dane w formacie, którego parser nie obsłużył. Nie powtarza się w nowszych logach.

źródło: lethe-ui-error.log (linie 2026-06-27T18:43-18:47)

2140 z 2185 linii błędów to 'Vue Router warn: No match found' dla ścieżek typu /wp-login.php — boty skanujące, nie błędy funkcjonalne. Nie zweryfikowano czy generują niepotrzebne obciążenie SSR.

źródło: grep -c 'Vue Router warn' lethe-ui-error.log (2140/2185)

Skanowanie WordPressa/botów utrudnia wyłapanie realnych błędów (jak duckdb JSON parse); warto dodać server middleware odrzucający typowe ścieżki (/wp-*, /.env, /xmlrpc.php) przed dojściem do routera.

źródło: analiza lethe-ui-error.log