96: Extract Perps sample data into EvelynPerpsService and poll it from EMC

2026-10-22 10:36:24 +02:00
parent 2dce841cf4
commit 158fe3924b
10 changed files with 328 additions and 56 deletions
@@ -28,10 +28,29 @@ The overview SHALL include hardcoded Jupiter and Phoenix venues with multiple sa
 - **AND** only position rows use direction-based backgrounds, with direction also conveyed by text

 ### Requirement: Prototype is clearly labeled and entirely local
-The Perps view SHALL explicitly label its data as sample data and explain that Phoenix rows are illustrative without an existing integration. It SHALL remain entirely within EMC, using no network calls, service changes, service communication, Refresh button, or simulated live updates for the prototype.
+The Perps view SHALL explicitly label its data as sample data and explain that Phoenix rows are illustrative without an existing integration. It SHALL obtain positions only from the Perps service's current in-memory snapshot, with no external network calls, Refresh button, or simulated position changes. EMC SHALL own all UI components, row colors and formatting.

 #### Scenario: Inspect the prototype boundary
 - **WHEN** the Perps tab is displayed
 - **THEN** sample-data and illustrative-Phoenix labels are visible
- **AND** there is no Refresh button or automated update of sample positions
- **AND** displaying and interacting with the prototype uses only local EMC data
+- **AND** there is no Refresh button or simulated update of sample positions
+- **AND** displaying and interacting with the prototype uses only the service's local sample snapshot
+
+### Requirement: Asynchronous polling follows window visibility
+EMC SHALL request the current Perps snapshot immediately on opening and every three seconds while visible, without blocking the UI thread. UI updates SHALL occur only on the JavaFX thread. Hiding the window SHALL stop polling; reopening SHALL create only one active polling loop and ignore results belonging to an earlier window session. Poll failures SHALL preserve the current view and allow subsequent attempts.
+
+#### Scenario: Read takes time or fails
+- **WHEN** a snapshot read is delayed or fails
+- **THEN** the UI remains responsive and the existing view is retained
+- **AND** later polling remains possible without overlapping scheduled reads
+
+#### Scenario: Hide and reopen
+- **WHEN** the owner hides and reopens EMC repeatedly
+- **THEN** each visible session has only one polling loop and obsolete results cannot update its views
+
+### Requirement: Polling preserves Perps view state
+The Perps table SHALL retain matching wallet, venue and position identities across snapshots. Repeated unchanged snapshots SHALL leave existing rows, expansion, selection and formatting untouched without flicker. New groups SHALL be expanded by default, and future added or removed positions SHALL be reconciled by identity without resetting retained groups.
+
+#### Scenario: Poll unchanged positions
+- **WHEN** a user collapses a group or selects a position and repeated snapshots are unchanged
+- **THEN** the same rows remain, with the same expansion and selection and no rebuild or refresh
@@ -89,9 +89,9 @@ After validating the entire plan, the Hub SHALL construct the configured Registr
 - **THEN** its deployment configuration, dedicated signer/wallet, Jupiter service and direct Raydium service are neither loaded nor constructed nor registered

 ### Requirement: Selected processes are constructed and started lazily in exact order
-The Hub SHALL support the modern process IDs `nenjim.registry.service`, `nenjim.journal.service`, `assetaz.ticker.default`, `jupiter-perps-alarm.default`, `evelyn.status.prod`, `evelyn.status.test`, `evelyn.iou-burner.prod`, `evelyn.liquidity.prod`, `nenjim.javafx-runtime.service`, `evelyn.mission-control.default`, and `nenjim.process-manager.default` through implementation-only construction capability that creates no process instance during validation. After passive composition, the Hub SHALL visit every configured entry after Registry in declared order, beginning with Journal. At each entry it SHALL construct only that process and any explicitly composed process-specific passive dependencies or administration view, register the process under the exact configured ID, resolve it through the canonical `NenjimProcess` contract where applicable, call `start()`, and record the ID only after successful return.
+The Hub SHALL support the modern process IDs `nenjim.registry.service`, `nenjim.journal.service`, `assetaz.ticker.default`, `jupiter-perps-alarm.default`, `evelyn.status.prod`, `evelyn.status.test`, `evelyn.iou-burner.prod`, `evelyn.liquidity.prod`, `evelyn.perps.default`, `nenjim.javafx-runtime.service`, `evelyn.mission-control.default`, and `nenjim.process-manager.default` through implementation-only construction capability that creates no process instance during validation. After passive composition, the Hub SHALL visit every configured entry after Registry in declared order, beginning with Journal. At each entry it SHALL construct only that process and any explicitly composed process-specific passive dependencies or administration view, register the process under the exact configured ID, resolve it through the canonical `NenjimProcess` contract where applicable, call `start()`, and record the ID only after successful return.

-The production IOU burner SHALL receive the already constructed Production Evelyn status service, and SHALL require both Ticker and `evelyn.status.prod` to precede `evelyn.iou-burner.prod`. The configuration SHALL be the complete manually ordered process dependency closure. The Hub SHALL not discover, insert, recursively construct, reorder, or automatically start dependencies. A process omitted from `[AUTO_START]` SHALL not be constructed, registered, started, or recorded, even when its implementation is available. Legacy process prototypes outside the modern Hub graph SHALL not be selectable.
+The production IOU burner SHALL receive the already constructed Production Evelyn status service, and SHALL require both Ticker and `evelyn.status.prod` to precede `evelyn.iou-burner.prod`. EMC SHALL receive the already started `evelyn.perps.default` service, which SHALL precede EMC in the deployment autostart list. The configuration SHALL be the complete manually ordered process dependency closure. The Hub SHALL not discover, insert, recursively construct, reorder, or automatically start dependencies. A process omitted from `[AUTO_START]` SHALL not be constructed, registered, started, or recorded, even when its implementation is available. Legacy process prototypes outside the modern Hub graph SHALL not be selectable.

 #### Scenario: Configured process starts successfully
 - **WHEN** a configured process entry is reached and its dependencies are already available
@@ -133,6 +133,14 @@ The production IOU burner SHALL receive the already constructed Production Evely
 - **WHEN** the burner is reached without a previously constructed Production status service
 - **THEN** construction fails clearly without creating or starting the omitted dependency or the burner

+#### Scenario: EMC has its Perps dependency
+- **WHEN** `evelyn.perps.default` appears before EMC in the deployment's ordered autostart list
+- **THEN** the Hub registers and starts that service and injects its service view into EMC
+
+#### Scenario: EMC precedes Perps
+- **WHEN** EMC is selected without an earlier Perps process
+- **THEN** construction fails clearly without inserting or starting that dependency
+
 ### Requirement: Configured startup is fail-fast and reports actual milestones
 Registry and every selected process SHALL be registered before its `start()` call and appended to the Hub's immutable ordered startup snapshot only after `start()` returns successfully. Construction failure SHALL leave the selected process unregistered. Registration or startup failure SHALL stop the plan before any later entry is constructed or started; a startup failure MAY leave that process registered but SHALL not record it. Earlier successful processes SHALL remain in snapshots, no rollback or retry SHALL occur, and the Hub SHALL announce its existing online point and enter its blocking runtime wait only after every configured process succeeds.