evelyn-perps-overview Specification

Purpose

Let the owner inspect Evelyn perpetual positions grouped by wallet and venue in Mission Control, beginning with a clearly labeled sample-data prototype.

Requirements

Requirement: Perps overview displays a collapsible position hierarchy

The Perps tab SHALL display a tree table with columns Position, Direction, and Position size, USD. The hierarchy SHALL be wallet → venue → position, expanded by default, with collapsible wallet and venue groups. Wallet and venue rows SHALL leave direction and size empty.

Scenario: Open either environment's Perps tab

WHEN the owner opens Perps in Production or Test
THEN the three named columns and the fully expanded hierarchy are visible
AND direction and size appear only on position rows

Scenario: Collapse and expand groups

WHEN the owner collapses and then expands a wallet or venue
THEN its descendants are hidden and then shown again

Requirement: Sample positions communicate direction and USD size

The overview SHALL include hardcoded Jupiter and Phoenix venues with multiple sample positions, including both Long and Short directions. Position rows SHALL show Long or Short text and USD sizes with grouping separators and two decimal places. Long rows SHALL have faint green backgrounds and Short rows faint red backgrounds with readable text; wallet and venue rows SHALL have no direction-based color.

Scenario: Inspect sample positions

WHEN the owner inspects Jupiter and Phoenix examples
THEN both venues have multiple positions and both directions are demonstrated
AND position sizes use readable USD formatting
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 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

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

4.0 KiB Raw Blame History