r35157/com_r35157_nenjim-hubd-impl_ref
0
0
Fork 0
Code Issues 18 Pull Requests Actions Packages Projects Releases Wiki Activity

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

Browse Source
This commit is contained in:
minimons
2026-10-22 10:37:04 +02:00
parent 2dce841cf4
commit 1ab439b578
19 changed files with 592 additions and 56 deletions
Download Patch File Download Diff File Expand all files Collapse all files
openspec/specs/evelyn-perps-overview/spec.md
+22 -3
View File
@@ -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
openspec/specs/evelyn-perps-service/spec.md
+29
View File
@@ -0,0 +1,29 @@
# evelyn-perps-service Specification
## Purpose
Provide a view-only source of current Evelyn perpetual positions independently of Mission Control presentation and refresh timing.
## Requirements
### Requirement: Read-only current positions snapshot
The Perps service SHALL expose only a read operation returning its complete current in-memory snapshot. Wallets, venues within wallets, and positions within venues SHALL have stable identifiers across reads. Responses SHALL be immutable domain data without UI components, colors or formatting, and SHALL make no Jupiter or Phoenix requests.
#### Scenario: Repeated reads
- **WHEN** clients repeatedly retrieve the started service's snapshot
- **THEN** they receive the same complete positions with stable identifiers and cannot mutate service-owned collections
- **AND** no exchange requests or position-management operations occur
### Requirement: Service owns the unchanged sample positions
The service SHALL own the existing eight sample positions grouped under Sample wallet A and Sample wallet B and their Jupiter and Phoenix venues, retaining every existing instrument, direction and decimal USD size. The snapshot SHALL remain unchanged for this task.
#### Scenario: Existing samples are retrieved
- **WHEN** EMC retrieves the service snapshot
- **THEN** wallet A contains Jupiter SOL Long 12500.00 and BTC Short 8250.50, Phoenix SOL Short 3200.75 and ETH Long 5400.00
- **AND** wallet B contains Jupiter ETH Long 1875.25 and SOL Short 950.00, Phoenix BTC Long 21000.00 and SOL Short 640.50
### Requirement: Hub owns Perps startup
The service SHALL run as a separate Hub-managed process registered as `evelyn.perps.default`. The service API SHALL expose no lifecycle operations. Snapshot reads before process startup SHALL fail clearly.
#### Scenario: Service starts
- **WHEN** the Hub starts the registered Perps process
- **THEN** its service view makes the complete sample snapshot available without starting a polling or integration worker
openspec/specs/nenjim-hub-configuration/spec.md
+10 -2
View File
@@ -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.