Ekosystem Aion

← Wróć do katalogu

Cedepe Discovery Report Gatewayactive

Slugreport-aionflow

Domenareport.aionflow.pl

Port3048

Wzorzec deployplain-script

Ścieżka repo/var/www/report.aionflow.pl

Status PM2 (na żywo)

Brak danych z pm2 jlist dla: report-dev-aionflow

Głębsze spojrzenie

inspiracja

Auth gateway budowany jako osobny express server, nie część głównej apkiinsight

package.json opisuje projekt jako 'Cedepe discovery report — auth gateway (client + admin)'. Lekki serwer express + express-session + dotenv, jedynym zadaniem jest logowanie i serwowanie raportu Cedepe pod osobnymi rolami.

źródło: /var/www/report.aionflow.pl/package.json, server.js

cel

Bramka logowania SSO do discovery report dla klienta Cedepe Consultinggoal

server.js buduje mapę użytkowników z ról 'client' (cedepe, EWA_USER, PIOTR_USER) i 'admin' (aion), z hasłami z .env, integruje się z lib/oidc.js do logowania SSO Aion ID.

źródło: server.js (buildUsers, oidc require)

zależności

Minimalny stack: express, express-session, dotenvdependency

Brak frameworka frontendowego — dane raportu (cedepe-report.js, comp-dossiers.js, timeline.js, signals-catalog.js) leżą w /data i są serwowane bezpośrednio przez ten serwer.

źródło: package.json, ls data/

znaczenie

Jedyny publiczny dostęp klienta do dużego pakietu danych badawczych Cedepeinsight

Katalog /data zawiera rozbudowany raport konkurencyjny (mapy konkurentów, dossiers, timeline, sygnały, dokumenty GA4/GSC/KRS) — realny deliverable dla klienta, nie prototyp.

źródło: ls -la data/ i data/_deploy

co działa

Proces JEST uruchomiony i online — ale pod PM2 roota, niewidoczny w standardowym pm2 jlisttested-ok

`pm2 jlist` jako user claude nie pokazuje 'report-aionflow', ale `sudo pm2 describe report-aionflow` potwierdza: status online, uptime 15D, restarts 6, nasłuchuje na 127.0.0.1:3048, nginx zwraca 302 redirect do /login.

źródło: sudo pm2 describe report-aionflow; ss -tlnp | grep 3048; curl 127.0.0.1:3048 -> 302

co nie działa

Proces produkcyjny żyje w PM2 roota, poza normalnym ekosystemem PM2 usera claude — realna luka operacyjnatested-broken

Wszystkie pozostałe usługi ekosystemu są zarządzane w PM2 usera claude i widoczne w standardowym pm2 jlist/monit. report-aionflow działa wyłącznie w /root/.pm2, więc standardowy monitoring/triage (aion-daily-triage) go nie widzi i nie obejmie restartów/alertów.

źródło: pm2 describe (as claude) -> nie istnieje; sudo pm2 describe -> online, ppid = God Daemon /root/.pm2

express-session używa domyślnego MemoryStore — ostrzeżenie produkcyjne w logachtested-broken

Logi błędów pokazują powtarzające się ostrzeżenie Express: 'connect.session() MemoryStore is not designed for a production environment, as it will leak memory, and will not scale past a single process.'

źródło: sudo pm2 logs report-aionflow --lines 15 --nostream

co do przetestowania

Nieznana przyczyna 6 restartów i brak repozytorium gituntested

Katalog nie jest repozytorium git, więc nie ma historii zmian do zbadania; log błędów nie pokazuje crashy poza ostrzeżeniem MemoryStore, więc 6 restartów wygląda na ręczne redeploye, ale nie potwierdzono wprost.

źródło: git status -> not a git repository; pm2 logs --err

rekomendacja

Zmigrować proces pod PM2 usera claude i podłączyć realny session storerecommendation

1) Przenieść zarządzanie report-aionflow z /root/.pm2 do PM2 usera claude (jak report-dev-aionflow), żeby monitoring go widział. 2) Zastąpić MemoryStore np. connect-redis przed jakimkolwiek skalowaniem.

źródło: porównanie z report-dev-aionflow oraz logi MemoryStore