97: Configure separate TEST and PROD instances of EvelynPerpsService

2026-10-22 11:32:49 +02:00
parent 7aab307381
commit 0ec22d5215
16 changed files with 308 additions and 57 deletions
@@ -37,7 +37,7 @@ The Perps view SHALL explicitly label its data as sample data and explain that P
 - **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.
+EMC SHALL request the current Perps snapshot from each environment's own service 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
@@ -48,6 +48,11 @@ EMC SHALL request the current Perps snapshot immediately on opening and every th
 - **WHEN** the owner hides and reopens EMC repeatedly
 - **THEN** each visible session has only one polling loop and obsolete results cannot update its views

+#### Scenario: Environment data stays separate
+- **WHEN** TEST and PROD return different snapshots
+- **THEN** each tab displays only its own service's data
+- **AND** a failure reading one service does not prevent attempting the other service
+
 ### 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.

@@ -22,8 +22,16 @@ The service SHALL own the existing eight sample positions grouped under Sample w
 - **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.
+The service SHALL run as two separate Hub-managed processes registered as `evelyn.perps.test` and `evelyn.perps.prod`. 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
+- **WHEN** the Hub starts either registered Perps process
 - **THEN** its service view makes the complete sample snapshot available without starting a polling or integration worker
+
+### Requirement: Wallet configuration belongs to service construction
+The Hub SHALL supply the same hardcoded wallet configuration to TEST and PROD at construction. Each service SHALL retain an immutable copy and own a separate snapshot. EMC SHALL neither own nor pass wallet configuration; snapshot reads SHALL remain parameterless.
+
+#### Scenario: Separate configured instances
+- **WHEN** the Hub constructs and starts both instances using the shared sample wallet configuration
+- **THEN** each snapshot contains the configured wallet identities and existing sample positions
+- **AND** the two instances own separate snapshots without defining the wallet list internally
@@ -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`, `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 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.prod` and `evelyn.perps.test`, `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.
+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.prod` and `evelyn.perps.test` services, both of 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
@@ -134,13 +134,18 @@ The production IOU burner SHALL receive the already constructed Production Evely
 - **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
+- **WHEN** `evelyn.perps.prod` and `evelyn.perps.test` appear before EMC in the deployment's ordered autostart list
+- **THEN** the Hub registers and starts separate service instances and injects their corresponding service views into EMC

 #### Scenario: EMC precedes Perps
- **WHEN** EMC is selected without an earlier Perps process
+- **WHEN** EMC is selected without both earlier Perps processes
 - **THEN** construction fails clearly without inserting or starting that dependency

+#### Scenario: Deployment contains the retired shared Perps ID
+- **WHEN** a deployment still selects `evelyn.perps.default`
+- **THEN** startup validation rejects the unknown ID before starting processes
+- **AND** migration replaces it with both new IDs before EMC
+
 ### 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.