96: Extract Perps sample data into EvelynPerpsService and poll it from EMC
This commit is contained in:
@@ -0,0 +1,33 @@
|
||||
# Spec Delta
|
||||
|
||||
## MODIFIED Requirements
|
||||
|
||||
### 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 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 simulated update of sample positions
|
||||
- **AND** displaying and interacting with the prototype uses only the service's local sample snapshot
|
||||
|
||||
## ADDED Requirements
|
||||
|
||||
### 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
|
||||
@@ -0,0 +1,30 @@
|
||||
# Spec Delta
|
||||
|
||||
## Purpose
|
||||
|
||||
Provide a view-only source of current Evelyn perpetual positions independently of Mission Control presentation and refresh timing.
|
||||
|
||||
## ADDED 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
|
||||
+56
@@ -0,0 +1,56 @@
|
||||
# Spec Delta
|
||||
|
||||
## MODIFIED Requirements
|
||||
|
||||
### 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`, `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`. 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
|
||||
- **THEN** that process is constructed, registered, started, and recorded before the next entry is reached
|
||||
|
||||
#### Scenario: Process is omitted
|
||||
- **WHEN** a known process ID does not appear in `[AUTO_START]`
|
||||
- **THEN** no instance of that process is constructed or registered and its lifecycle is never started or recorded
|
||||
|
||||
#### Scenario: Jupiter Perps Alarm is selected
|
||||
- **WHEN** `jupiter-perps-alarm.default` is explicitly listed after its required predecessors
|
||||
- **THEN** the otherwise inactive modern alarm process is constructed, registered, started and recorded at that exact position
|
||||
|
||||
#### Scenario: Dependency order is invalid
|
||||
- **WHEN** a selected process is reached before a process dependency required by its current constructor or startup behavior
|
||||
- **THEN** construction or startup fails clearly without implicit dependency construction, repair, or reordering
|
||||
|
||||
#### Scenario: JavaFX processes are omitted
|
||||
- **WHEN** a valid headless plan omits `nenjim.javafx-runtime.service`, `evelyn.mission-control.default`, and `nenjim.process-manager.default`
|
||||
- **THEN** none of those objects is constructed or registered and the JavaFX toolkit remains uninitialized by the Hub
|
||||
|
||||
#### Scenario: Renamed status services retain dependency wiring
|
||||
- **WHEN** `evelyn.status.prod` and `evelyn.status.test` are listed after Ticker and before Mission Control
|
||||
- **THEN** the Hub constructs separate Production/Test status services, registers the renamed IDs, and injects the corresponding typed service views into Mission Control in the configured order
|
||||
|
||||
#### Scenario: Deployment still contains an old status ID
|
||||
- **WHEN** a private deployment configuration contains `evelyn.service.prod` or `evelyn.service.test`
|
||||
- **THEN** validation rejects the unknown ID before startup; deployment migration replaces only that ID with `evelyn.status.prod` or `evelyn.status.test`, preserving selection and order
|
||||
|
||||
#### Scenario: Liquidity is explicitly selected
|
||||
- **WHEN** `evelyn.liquidity.prod` is reached in a valid startup plan
|
||||
- **THEN** the Hub loads its runtime configuration, binds the dedicated signer/wallet and Jupiter service to each other, constructs direct Raydium access and registers/starts the liquidity process without inserting a Ticker or status dependency or reordering the plan
|
||||
|
||||
#### Scenario: Production burner has its reference-price dependency
|
||||
- **WHEN** `evelyn.iou-burner.prod` is reached after Ticker and `evelyn.status.prod`
|
||||
- **THEN** the Hub injects the corresponding Production status service for buyback price decisions
|
||||
|
||||
#### Scenario: Production burner precedes its status dependency
|
||||
- **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
|
||||
Reference in New Issue
Block a user