98: Populate EvelynPerpsService with real Jupiter positions

docs/Evelyn.md

@@ -434,25 +434,26 @@ Price Index beregnes og vises, mens de øvrige fem felter fortsat er nul. Legacy
 
 ## 12. Perps-service og Mission Control
 
-`com.r35157.evelyn.service.perps.EvelynPerpsService` ejer positionsdata og udleverer hele det aktuelle,
-immutable `PerpsSnapshot` gennem `getPositionsSnapshot()`. Snapshot'et indeholder wallets, deres venues og
-positioner med stabile ID'er blandt søskende, adskilt fra visningsnavne. Positioner indeholder instrument,
-`LONG`/`SHORT` og decimal USD-størrelse. Svaret indeholder ingen JavaFX-elementer, farver eller formatering.
+`EvelynPerpsService` udleverer et immutable `PerpsSnapshot` gennem det parameterløse
+`getPositionsSnapshot()`. Læsning foretager ingen integrationskald. Hub'en starter separate processer
+`evelyn.perps.prod` og `evelyn.perps.test` og injicerer de tilsvarende eksisterende `JupiterPerpsService`-views.
+`PerpsWalletConfiguration` indeholder en `SolanaWalletId`-adresse, der også bruges som række-ID og label.
+Hub'en ejer de hardcodede lister: seks PROD-adresser og én TEST-adresse fra issue #98.
 
-`impl.ref.EvelynPerpsServiceImpl` implementerer desuden `NenjimProcess`. Hub'en registrerer og starter det samme
-objekt pr. miljø som `evelyn.perps.prod` og `evelyn.perps.test` før EMC.
-Hub'en definerer den fælles hardcodede liste af `PerpsWalletConfiguration` (ID og visningsnavn) og giver den
-til begge konstruktører. Hver instans kopierer konfigurationen og ejer sit eget snapshot. Eksempel-ID'erne er
-ikke Solana-adresser. Servicen fordeler de to eksisterende eksempelporteføljer skiftevis efter wallet-rækkefølge;
-positionerne for de to konfigurerede wallets er uændrede. Før `start()` afvises læsning; gentagen start afvises også.
-Service-API'et eksponerer kun læsning, ingen lifecycle- eller positionsændringer. Servicen ejer de otte
-uændrede eksempelpositioner fra den oprindelige Perps-fane og har ingen workers eller Jupiter/Phoenix-kald.
+Servicen henter åbne Jupiter-positioner asynkront ved start og venter 60 sekunder efter hvert gennemløb,
+så runder ikke overlapper. Den eksisterende Solana-cache med 60 sekunders TTL bevares. Data er derfor ikke
+øjeblikkelige børsdata. Positionskontoen er stabilt ID; retning og `positionSize()` vises, kendte mints
+bliver SOL-PERP/BTC-PERP/ETH-PERP, og ukendte mints vises som adressen. Positioner sorteres efter konto.
 
-EMC læser hvert miljøs snapshot fra den tilsvarende service straks ved åbning og hvert tredje sekund på en
-separat worker, uafhængigt af en eventuel senere integrations opdateringsinterval. Fejl i ét servicekald forhindrer ikke forsøget på det andet.
-Begge miljøfaner viser fortsat de samme tydeligt markerede eksempler;
-EMC ejer træstruktur, USD-formatering og grønne/røde rækker. Uændrede snapshots berører ikke eksisterende rækker,
-foldestatus eller markering. Ved ændringer genbruges træelementer efter deres ID'er inden for samme forælder.
-UI-opdateringer sker kun på JavaFX-tråden. Fejl bevarer visningen og stopper ikke næste pollingforsøg.
-Skjul/luk stopper polling; genåbning starter én ny løkke og afviser gamle resultater. Servicen fortsætter uafhængigt
-af vinduet. Der er ingen rigtig integration, simulerede ændringer, Refresh-knap eller handel i denne service.
+Før første vellykkede opslag er der ingen positioner. Hver wallets succes publiceres i et nyt snapshot;
+fejl logges og bevarer den wallets sidste data uden at afbryde de øvrige. Et vellykket tomt svar fjerner
+positionerne, men bevarer wallet/Jupiter-gruppen. Der vises ingen indikator for forældede data.
+Implementationens `close()` afbryder worker'en; consumer-API'et indeholder kun læsning.
+
+EMC spørger hver miljøservice straks ved åbning og hvert tredje sekund uden at blokere JavaFX-tråden.
+Skjul/luk stopper kun EMC-polling; services fortsætter. Træstruktur, tre kolonner, farver, formatering,
+foldestatus og markering bevares for eksisterende rækker. Nye/lukkede positioner afstemmes efter ID.
+Der er ingen sample-positioner, Phoenix-eksempler, sample-tekster, Refresh-knap eller handel.
+
+Den kanoniske systembeskrivelse findes i
+[Evelyn: services og status](../../r35157_docs/projects/evelyn/README.md#evelynperpsservice).

docs/Nenjim.md

@@ -288,12 +288,14 @@ Historik ligger fortsat i `data/evelyn/<instance-name>/status.log` med formatver
 Mission Control kræver både `evelyn.perps.prod` og `evelyn.perps.test` før `evelyn.mission-control.default`
 i den private `conf/NenjimHub.conf`. Erstat den tidligere `evelyn.perps.default`-linje med de to nye ID'er;
 det gamle ID accepteres ikke længere. Hub'en konstruerer, registrerer og starter to separate
-`EvelynPerpsServiceImpl`-processer med samme hardcodede wallet-konfiguration og injicerer deres read-only
+`EvelynPerpsServiceImpl`-processer med separate hardcodede wallet-lister og tilhørende Jupiter-integrationer.
+Hub'en injicerer deres read-only
 service-views til de tilsvarende miljøfaner i EMC. Process Manager viser begge ID'er efter vellykket startup.
 Den lokale udviklingskonfiguration er opdateret; andre deployments med EMC skal migreres tilsvarende.
 Udeladt eller forkert rækkefølge giver en tydelig konstruktionsfejl uden automatisk indsættelse.
-Det minimale versionsstyrede bootstrap-eksempel er uændret. Hver service ejer sit eget snapshot med
-uændrede in-memory-eksempler og foretager ingen eksterne positionskald.
+Det minimale versionsstyrede bootstrap-eksempel er uændret. Hver service ejer sit eget snapshot og
+opdaterer det fra Jupiter i baggrunden med 60 sekunders pause mellem gennemløb. EMC-læsninger bruger kun
+det publicerede snapshot. Wallet-listerne fra issue #98 indeholder seks PROD-adresser og én TEST-adresse.
 
 Hvis `evelyn.iou-burner.prod` vælges, skal både `assetaz.ticker.default` og
 `evelyn.status.prod` stå før den. Hub'en injicerer Production status-servicen til