The Perps tab currently displays hardcoded sample data owned by Evelyn Mission Control. Introduce a separate, view-only EvelynPerpsService that owns this data, and have EMC retrieve it automatically.
This establishes the service boundary while preserving the existing UI and behavior.
Scope
Create EvelynPerpsService using the project's existing service and process lifecycle patterns.
Move the existing hardcoded Perps sample data from EMC into the service implementation.
Expose a read operation returning the complete current positions snapshot.
Have EMC request the snapshot every three seconds without blocking the UI.
Preserve the existing columns, wallet → venue → position hierarchy, row colors, formatting, and sample-data indication.
Preserve expanded/collapsed groups and selection across polling cycles. Repeated retrieval of unchanged data must not cause flicker or reset the view.
The service owns position data. EMC owns presentation, including tree-table elements, colors, and formatting. The service response must not contain UI components.
EMC's polling interval is independent of any future integration update interval. Reading the snapshot returns the service's current in-memory data; it must not trigger requests to Jupiter or Phoenix. The hardcoded snapshot remains unchanged for this task.
Structure the snapshot so that wallets, venues, and positions can be consistently identified across responses. Future snapshots may add or remove positions, but implementing or simulating changing data is outside this task.
Polling follows the existing EMC lifecycle conventions and must not accumulate duplicate polling loops when the window is reopened.
Out of scope
Real Jupiter or Phoenix integrations.
Opening, closing, or modifying positions.
Simulated data changes.
Stale-data detection or indicators.
Refresh buttons or other UI additions.
Acceptance criteria
EvelynPerpsService runs as a separate service using the existing project conventions.
The existing hardcoded sample positions are owned by the service, not EMC.
EMC retrieves the current snapshot from the service every three seconds.
Service calls do not block the UI.
The Perps tab retains its existing appearance and sample-data indication.
Repeated polling preserves expansion state and selection without visible flicker.
Reopening EMC does not create duplicate polling loops.
Snapshot reads make no requests to Jupiter or Phoenix.
The service is view-only and exposes no position-management operations.
The Perps tab currently displays hardcoded sample data owned by Evelyn Mission Control. Introduce a separate, view-only `EvelynPerpsService` that owns this data, and have EMC retrieve it automatically.
This establishes the service boundary while preserving the existing UI and behavior.
**Scope**
- Create `EvelynPerpsService` using the project's existing service and process lifecycle patterns.
- Move the existing hardcoded Perps sample data from EMC into the service implementation.
- Expose a read operation returning the complete current positions snapshot.
- Have EMC request the snapshot every three seconds without blocking the UI.
- Preserve the existing columns, wallet → venue → position hierarchy, row colors, formatting, and sample-data indication.
- Preserve expanded/collapsed groups and selection across polling cycles. Repeated retrieval of unchanged data must not cause flicker or reset the view.
The service owns position data. EMC owns presentation, including tree-table elements, colors, and formatting. The service response must not contain UI components.
EMC's polling interval is independent of any future integration update interval. Reading the snapshot returns the service's current in-memory data; it must not trigger requests to Jupiter or Phoenix. The hardcoded snapshot remains unchanged for this task.
Structure the snapshot so that wallets, venues, and positions can be consistently identified across responses. Future snapshots may add or remove positions, but implementing or simulating changing data is outside this task.
Polling follows the existing EMC lifecycle conventions and must not accumulate duplicate polling loops when the window is reopened.
**Out of scope**
- Real Jupiter or Phoenix integrations.
- Opening, closing, or modifying positions.
- Simulated data changes.
- Stale-data detection or indicators.
- Refresh buttons or other UI additions.
**Acceptance criteria**
- `EvelynPerpsService` runs as a separate service using the existing project conventions.
- The existing hardcoded sample positions are owned by the service, not EMC.
- EMC retrieves the current snapshot from the service every three seconds.
- Service calls do not block the UI.
- The Perps tab retains its existing appearance and sample-data indication.
- Repeated polling preserves expansion state and selection without visible flicker.
- Reopening EMC does not create duplicate polling loops.
- Snapshot reads make no requests to Jupiter or Phoenix.
- The service is view-only and exposes no position-management operations.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
The Perps tab currently displays hardcoded sample data owned by Evelyn Mission Control. Introduce a separate, view-only
EvelynPerpsServicethat owns this data, and have EMC retrieve it automatically.This establishes the service boundary while preserving the existing UI and behavior.
Scope
EvelynPerpsServiceusing the project's existing service and process lifecycle patterns.The service owns position data. EMC owns presentation, including tree-table elements, colors, and formatting. The service response must not contain UI components.
EMC's polling interval is independent of any future integration update interval. Reading the snapshot returns the service's current in-memory data; it must not trigger requests to Jupiter or Phoenix. The hardcoded snapshot remains unchanged for this task.
Structure the snapshot so that wallets, venues, and positions can be consistently identified across responses. Future snapshots may add or remove positions, but implementing or simulating changing data is outside this task.
Polling follows the existing EMC lifecycle conventions and must not accumulate duplicate polling loops when the window is reopened.
Out of scope
Acceptance criteria
EvelynPerpsServiceruns as a separate service using the existing project conventions.